The secure engineering sub-department is responsible for most of the secure stage of the product. (One portion of the secure stage (threat insights) is a responsibility of the Threat Management engineering sub-department).
To provide content and tools to support the best possible assessment at the earliest possible moment.
For more details about the vision for this area of the product, see the Secure stage page.
We will give back to the Open Source community We will provide Responsible Disclosure We will share our knowledge and findings at public speaking events
The Secure team works on GitLab's Secure stage.
The following people are permanent members of the Secure Sub-Department:
Person | Role |
---|---|
Todd Stadelhofer | Director of Engineering, Secure |
Person | Role |
---|---|
Olivier Gonzalez | Backend Engineering Manager, Secure:Composition Analysis |
Fabien Catteau | Staff Backend Engineer, Secure:Composition Analysis |
Tetiana Chupryna | Backend Engineer, Secure:Composition Analysis |
Adam Cohen | Senior Backend Engineer, Secure:Composition Analysis |
Igor Frenkel | Senior Backend Engineer, Secure:Composition Analysis |
Person | Role |
---|---|
Thomas Woodham | Backend Engineering Manager, Secure:Static Analysis |
Lucas Charles | Staff Backend Engineer, Secure:Static Analysis |
Ross Fuhrman | Backend Engineer, Secure:Static Analysis |
Daniel Searles | Senior Backend Engineer, Secure:Static Analysis |
Zach Rice | Backend Engineer, Secure:Static Analysis |
Saikat Sarkar | Senior Backend Engineer, Secure:Static Analysis |
Person | Role |
---|---|
Seth Berger | Backend Engineering Manager, Secure:Dynamic Analysis, Secure:Fuzz Testing |
Avielle Wolfe | Backend Engineer, Secure:Dynamic Analysis |
Cam Swords | Senior Backend Engineer, Secure:Dynamic Analysis |
Philip Cunningham | Senior Backend Engineer, Secure:Dynamic Analysis |
Craig Smith | Senior Backend Engineer, Secure:Dynamic Analysis |
Person | Role |
---|---|
Seth Berger | Backend Engineering Manager, Secure:Dynamic Analysis, Secure:Fuzz Testing |
Mike Eddington | Staff Backend Engineer, Secure:Fuzz Testing |
Yevgeny Pats | Senior Backend Engineer, Secure:Fuzz Testing |
Person | Role |
---|---|
Neil McCorrison | Frontend Engineering Manager, Secure |
Paul Gascou-Vaillancourt | Frontend Engineer, Secure |
Fernando Arias | Senior Frontend Engineer, Secure |
Mark Florian | Senior Frontend Engineer, Secure |
Dheeraj Joshi | Senior Frontend Engineer, Secure |
Jannik Lehmann | Frontend Engineer, Secure |
Person | Role |
---|---|
Mark Art | Manager, Vulnerability Research Engineering |
Julian Thome | Senior Security Engineer, Vulnerability Research |
James Johnson | Staff Security Engineer, Vulnerability Research |
Isaac Dawson | Senior Security Engineer, Vulnerability Research |
The following members of other functional teams are our stable counterparts:
Person | Role |
---|---|
Sam Kerr | Principal Product Manager, Secure:Fuzz Testing |
Nicole Schwartz | Product Manager, Secure:Composition Analysis |
Taylor McCaslin | Senior Product Manager, Secure:Static Analysis |
Derek Ferguson | Senior Product Manager, Secure:Dynamic Analysis |
Matt Wilson | Senior Product Manager, Secure |
Annabel Dunstone Gray | Product Designer, Secure:Dynamic Analysis |
Andy Volpe | Senior Product Designer, Secure:Threat Insights |
Camellia X. YANG | Senior Product Designer, Secure:Fuzz Testing |
Rebecca 'Becka' Lippert | Product Designer, Secure:Static Analysis |
Russell Dickenson | Senior Technical Writer, Secure (Static Analysis, Dynamic Analysis, Composition Analysis, Threat Insights, Vulnerability Research), Growth (Fulfillment) |
Nick Gaskill | Senior Technical Writer, Release, Secure (Fuzz Testing), Protect |
Nikhil George | Senior Security Engineer, Application Security, Secure (Composition Analysis, Fuzz Testing, Vulnerability Research) |
Tanya Pazitny | Quality Engineering Manager, Secure & Enablement |
Will Meek | Senior Software Engineer in Test, Secure:Composition Analysis |
Justin Mandell | Product Design Manager, Configure, Monitor, Secure & Protect |
Tali Lavi | UX Researcher, Secure |
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 Attack 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.
License Compliance helps with the licenses introduced by third-party libraries in the application. Licence management relies on the LicenseFinder gem.
The Vulnerability Research team's purpose is to perform research and develop proofs of concepts that increase the capabilities and effectiveness of the Secure stage.
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::fuzz testing |
Fuzz Testing |
~group::static analysis |
Secret Detection |
~group::vulnerability research |
Security Benchmarking |
Additional labels should be added according to the Workflow Labels Documentation.
It is important to delineate who the EM and PM DRIs are for every functionality, especially where this may not be obvious. It is documented on a dedicated delineation page.
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, Container Scanning |
Python | DAST |
SQL (PostgreSQL) | Dependency Scanning / all |
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.
See QA Process for more info.
500 errors on gitlab.com are reported to Sentry. Below are some quick links to pull up Sentry errors related to Secure.
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 accommodate 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 creative 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:
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:
~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).~Px
label.Since we are a remote company, having daily standup 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_passing:
emoji):ci_failing:
emoji):ci_running:
emoji):ci_pending:
emoji):ci_...
icon you find applicableExample:
What did you do since yesterday?
Spotbugs java analyzer compareKey is not unique
https://gitlab.com/gitlab-org/gitlab-ee/issues/10860Allow guests to create an issue from a vulnerability
https://gitlab.com/gitlab-org/gitlab-ee/issues/7813Slack Channels:
As our teams focus on different areas, we have Geekbot configured to broadcast to separate channels in addition to our common one at #s_secure-standup.
Our important meetings are recorded and published on YouTube, in the GitLab Secure Stage 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.
We welcome team members to join meetings that are on our shared calendar. The Secure Calendar is available to all logged in GitLab team members.
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.
Secure largely follows our Product Development Flow
See Issue Refinement to learn how we evaluate complexity, level of effort, our implementation plan and assign issue weights.
The Secure Team follows the coding standards and style guidelines outlined in the company-wide Contributor and Development Docs, however, please consult the following guidelines which are specific to the Secure Team:
Some components of the architecture that support Secure features are shared between multiple groups like the common Go library, the Security Report Schemas, the rails parsers, etc.
Modifying these shared pieces might impact other groups so we should rely as much as possible on approval rules to ensure such changes are reviewed by the relevant teams before being merged.
Impactless two-way door changes could skip the approval process, please use sound judgement and common sense in such situations.
The author of changes should announce broadly the changes made on these components to raise awareness (weekly meeting agenda, slack channel).
We occasionally need to build out new analyzer projects to support new frameworks and tools. In doing so we should follow our engineering Open Source guidelines, including licensing and code standards.
In addition, to write a custom analyzer that will integrate into the GitLab application a minimal featureset is required:
Please see our security-report-schemas for a full list of required fields.
The security-report-schema repository contains JSON schemas that list the required fields for each report type:
As our product evolves, the engineering teams are researching ways to achieve new functionality and improve our architecture.
The outcome of this research can be found in our Technical Documentation section.
The Secure sub-department conducts retrospectives at the group level that follow our engineering workflow. Each group's DRI is responsible to prepare and schedule the retrospective sync sessions and the async retrospective issues can be found in the corresponding project.
NB: we use to have a sub-department wide retrospective whose issues are still accessible in the deprecated project.