Secure Team

On this page

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, and the Security Paradigm section of the Product 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.

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 Management

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

Release process

Our release process is specified in this project.

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 management). 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 Rhythm

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.

Meetings schedule:

Async Daily Standups

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