Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Secure Section

Vision

For more details about the vision for this area of the product, see the Secure stage page.

Mission

The Secure team works on GitLab's Secure stage.

Team Members

The following people are permanent members of the Secure Section:

Person Role
Todd Stadelhofer Director of Engineering, Secure

Composition Analysis

Person Role
Olivier Gonzalez Interim Engineering Manager, Secure:Composition Analysis
Fabien Catteau Staff Backend Engineer, Secure:Composition Analysis
Tetiana Chupryna Backend Engineer, Secure:Composition Analysis and Create:Knowledge (intern)
Can Eldem Backend Engineer, Secure:Composition Analysis
Mo Khan Senior Backend Engineer, Secure:Composition Analysis
Adam Cohen Senior Backend Engineer, Secure:Composition Analysis
Igor Frenkel Senior Backend Engineer, Secure:Composition Analysis

Static Analysis

Person Role

Dynamic Analysis

Person Role
Seth Berger Engineering Manager, Secure:Dynamic Analysis
Avielle Wolfe Backend Engineer, Secure
Cam Swords Senior Backend Engineer, Secure:Dynamic Analysis
Paula Burke Senior Backend Engineer, Secure:Dynamic Analysis

Frontend Team

Person Role

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Achilleas Pipinellis Technical Writer, Create, Package, Monitor, Secure, Defend
Annabel Dunstone Gray Product Designer, Secure
Valerie Karnes UX Manager, Secure & Defend
Philippe Lafoucrière Distinguished Backend Engineer, Secure, Defend
Tanya Pazitny Quality Engineering Manager, Secure & Enablement
David DeSanto Director of Product, Secure and Defend
Sam Beckham Senior Frontend Engineer, Secure and Create:Knowledge (intern)
Paul Gascou-Vaillancourt Frontend Engineer, Secure
Victor Zagorodny Senior Backend Engineer, Secure:Static Analysis
Lucas Charles Senior Backend Engineer, Secure:Static Analysis, Defend
Ross Fuhrman Backend Engineer, Secure:Static Analysis
Stacey Cardoso Backend Engineer, Secure:Static Analysis
Fernando Arias Senior Frontend Engineer, Secure
Mark Florian Senior Frontend Engineer, Secure, Defend
Henri Philipps Senior Site Reliability Engineer, Secure & Defend
Dave Pisek Senior Frontend Engineer, Secure
Dheeraj Joshi Senior Frontend Engineer, Secure
Anthony Sandoval Engineering Manager, Reliability Engineering, Secure & Defend
Aleksandr Soborov Test Automation Engineer, Secure
Craig Barrett Senior Site Reliability Engineer, Defend & Secure
Nicole Schwartz Product Manager, Secure:Composition Analysis
D.F. Senior Product Manager, Secure:Dynamic Analysis
Kyle Mann Senior Product Designer, Secure
Camellia X. YANG Senior Product Designer, Secure
Tali Lavi UX Researcher, Secure & Defend and Ops (Interim)

Secure Team

The Secure Team (previously known as the Security Products Team) is responsible for the security checks features in the GitLab platform, and maps to the secure transversal stage. You can learn more about our approach on the Secure Vision page.

The features provided by the Secure Team are mostly present at the pipeline level, and mostly available as Docker images. This particularity shapes our processes and QA, which differs a bit from the other backend teams.

Security Products

We still refer to "Security Products" as the tools developed by the Secure Team. Hence the home of our projects in GitLab: https://gitlab.com/gitlab-org/security-products/

Domains of expertise

SAST

SAST (Static Application Security Testing) refers to static code analysis. GitLab leverages the power of various opensource tools to provide a wide range of checks for many languages and support. These tools are wrapped inside docker images which ensure we get a standard output from there. An orchestrator, developed by GitLab, is in charge of running these images, and gathering all the data needed to generate the final report.

DAST

DAST (Dynamic Application Security Testing) is used to hit a live application. Because some vulnerabilities can only be detected once all the code is actually running, this method complements the static code analysis. DAST is relying on OWASP Zed Attach Proxy Project, modified by GitLab to enable authentication.

Dependency Scanning

Dependency Scanning is used to detect vulnerabilities introduced by external dependencies in the application. Because a large portion of the code shipped to production is actually coming from third-party libraries, it's important to monitor them as well. Dependency Scanning is relying mostly on the Gemnasium engine.

Container Scanning

Container Scanning is used when the application is shipped as a Docker image. It's very common to build the final image on top of an existing one, which must be checked like every other portion of the application. For that, Container Scanning is relying on the clair scanner.

License Compliance

License Compliance helps with the licenses introduced by third-party libraries in the application. Licence management relies on the LicenceFinder gem.

Label Usage

If you are submitting an issue about a Secure Stage feature, use ~devops::secure and one of the following group labels to get the issue in front of the most appropriate team members.

Label Use
~devops::secure All issues related to the Secure Stage
~group::static analysis SAST, Secret Detection
~group::dynamic analysis DAST, IAST, Fuzzing and Security Dashboard related
~group::software composition analysis Container or Dependency Scanning, Vulnerability Database, License Management

Additional labels should be added according to the Workflow Labels Documentation.

Release process

Our release process is specified in this project. The vulnerability database is updated on a regular basis.

Skills

Because we have a wide range of domains to cover, it requires a lot of different expertises and skills:

Technology skills Areas of interest
Ruby on Rails Backend development
Go SAST, Dependency Scanning
SQL (PostgreSQL) Dependency Scanning
Docker Container Scanning / all

Our team also must have a good sense of security, with at least basic skills in application security.

We provide tools for many different languages (ex: sast, dependency scanning, license compliance). It means our team is able to understand the basics of each of these languages, including their package managers. We maintain tests projects to ensure our features are working release after release for each of them.

QA process

Our release project also defines our QA process.

Engineering Grooming & Planning

To maximize our velocity and meet our deliverables, we follow a grooming process for all issues.

Meetings schedule:

The Product Manager and the Engineering Manager will do the milestone grooming during their 1:1 following the kickoff. Every issue still open will be evaluated for rescheduling (in the following milestone or not).

Brainstorming sessions

Our team occasionally schedules synchronous brainstorming sessions as a method of deep-diving on a specific topic. This approach can be useful in breaking down complexity and deriving actionable steps for problems that lack definition.

We tend to schedule these on a weekly cadence with a rotating timeslot to accomodate team members in different timezones. If a topic is not agreed upon prior to a given week, the slot is canceled to avoid unnecessary meetings. These slots can be viewed on the Secure Stage Team Calendar.

These are purposefully freeform to allow for creativity problem solving. When possible, time should be reserved for a list of actions to be taken from the open discussion.

Brainstorming Sessions Doc (Internal): https://docs.google.com/document/d/179JL5RzbgSIz2XZewbYn79cuX7_vUtte_TcoLwUUC5o/edit#

Examples of previous brainstorming topics:

Product Documentation

As the product evolves, it is important to maintain accurate and up to date documentation for our users. If it is not documented, customers may not know a feature exists.

To update the documentation, the following process should be followed:

  1. When an issue has been identified as needing documentation, add the ~Documentation label, outline in the description of the issue what documentation is needed, and assign a Backend Engineer and Technical Writer(TW) to the issue (find the appropriate TW by searching the product categories).
  2. If the task is documentation only, apply a ~Px label.
  3. For documentation around features or bugs, a backend engineer should write the documentation and work with the technical writer for editing. If the documentation only needs styling cleanup, clarification, or reorganization, this work should be lead by the Technical Writer with support from a BE as necessary. The availability of a technical writer should in no way hold up work on the documentation. Further information on the documentation process.

Async Daily Standups

Since we are a remote company, having daily stand-ups meetings would not make any sense, since we're not all in the same timezone. That's why we have async daily standups, where everyone can give some insights into what they did yesterday, what they plan to do today, etc. For that, we rely on the geekbot slack plugin to automate the process.

Standup messages format

Example:

What did you do since yesterday?

Recorded meetings

Our important meetings are recorded and published on YouTube, in the GitLab Secure Playlist. They give a good overview of the decision process, which is often a discussion with all the stakeholders. As we are a remote company, these video meetings help to synchronize and take decisions faster than commenting on issues. We prefer asynchronous work, but for large features and when the timing is tight, we can detail a lot of specifications. This will make the asynchronous work easier, since we have evaluated all edge cases.

Technical onboarding

New hires should go through these steps and read the corresponding documentation when onboarding in the Secure Team. Every new hire will have an assigned onboarding issue that will guide them through the whole process.

Workflow

Secure uses a workflow based on the Product Development Flow.

graph LR subgraph "Product to Engineering Flow" step1[scheduling] step1 --> step2[ready for development] step2 --> step3[In dev] step3 --> step4[In review] step4 --> step5[verification] end

All open issues that are assigned to a milestone and ready for engineering should have one of the above ~workflow:: labels. The process works as follows:

  1. Product managers will work on issues and when a PM determines the issue is ready for an engineer to review, the PM will apply the workflow::scheduling label. workflow::scheduling means that the issue is complete from a requirements perspective and needs to be groomed.
  2. workflow::ready for development should be assigned after an engineer grooms an issue.
  3. workflow::In dev should be assigned when an engineer is working on the issue.
  4. workflow::In Review should be assigned by the engineer when they open up a MR request and the MR is not WIP.
  5. workflow::Verification should be assigned by the engineer after the code has been merged into the code base.

If an engineer gets blocked the workflow::blocked label should be applied, and the engineer should @mention the PM and EM regarding the issue and anyone else that can help resolve the block.

Additional workflow information:

How to work with us