For more details about the vision for this area of the product, see the Secure stage page.
The Secure team works on GitLab's Secure stage.
The following people are permanent members of the Secure Section:
The following members of other functional teams are our stable counterparts:
|Achilleas Pipinellis||Technical Writer, Create, Package, Monitor, Secure, Defend|
|Andy Volpe||Senior Product Designer, Secure|
|Valerie Karnes||UX Manager, Secure & Defend|
|Philippe Lafoucrière||Distinguished Backend Engineer, Secure, Defend|
|Olivier Gonzalez||Interim Engineering Manager, Secure:Composition Analysis|
|Fabien Catteau||Staff Backend Engineer, Secure:Composition Analysis|
|Tetiana Chupryna||Backend Engineer, Secure:Composition Analysis|
|Can Eldem||Backend Engineer, Secure:Composition Analysis|
|Mo Khan||Senior Backend Engineer, Secure:Composition Analysis|
|Adam Cohen||Senior Backend Engineer, Secure:Composition Analysis|
|Igor F.||Senior Backend Engineer, Secure:Composition Analysis|
|Lukas Eipert||Interim Frontend Engineering Manager, Secure|
|New Vacancy - Lukas E. (interim)||Frontend Engineering Manager, Secure|
|Tanya Pazitny||Quality Engineering Manager, Secure & Enablement|
|David DeSanto||Director of Product, Secure and Defend|
|Sam Beckham||Senior Frontend Engineer, Secure|
|Paul Gascou-Vaillancourt||Frontend Engineer, Secure|
|Thomas Woodham||Engineering Manager, Secure:Static Analysis|
|Victor Zagorodny||Senior Backend Engineer, Secure:Static Analysis|
|Lucas Charles||Senior Backend Engineer, Secure:Static Analysis|
|Ross Fuhrman||Backend Engineer, Secure:Static Analysis|
|Stacey Cardoso||Backend Engineer, Secure:Static Analysis|
|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|
|Pulkit Sharma||Backend Engineer, Secure:Dynamic Analysis|
|Fernando Arias||Senior Frontend Engineer, Secure|
|Mark Florian||Senior Frontend Engineer, Secure|
|Henri Philipps||Senior Site Reliability Engineer, Secure & Defend|
|Dietrich Stein||Senior Frontend Engineer, Secure|
|Dave Pisek||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|
|Todd Stadelhofer||Director of Engineering, Secure|
|Kyle Mann||Senior Product Designer, Secure|
|Camellia X. YANG||Senior Product Designer, Secure|
|Tali Lavi||UX Researcher, Secure & Defend and Ops (Interim)|
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.
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/
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 (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 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 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.
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.
||All issues related to the Secure Stage|
||SAST, Secret Detection|
||DAST, IAST, Fuzzing and Security Dashboard related|
||Container or Dependency Scanning, Vulnerability Database, License Management|
Additional labels should be added according to the Workflow Labels Documentation.
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.
In order to be able to ship 100% of our Deliverables, we give a lot of attention to our planning. For that, we try to plan in advance as much as possible, and to freeze everything once the iteration starts. To avoid changes and uncertainty during the release, we must make sure everything is ready to start the development on the first day.
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).
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:
~Documentationlabel, 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).
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.
description in backquote+
[link to issue](#)" format when mentioning issues in your standup report.
What did you do since yesterday?to denote the current state:
:ci_...icon you find applicable
What did you do since yesterday?
Spotbugs java analyzer compareKey is not uniquehttps://gitlab.com/gitlab-org/gitlab-ee/issues/10860
Allow guests to create an issue from a vulnerabilityhttps://gitlab.com/gitlab-org/gitlab-ee/issues/7813
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.
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.
milestonefilter with the current milestone +1 (the current milestone is already released).