Security visibility from development to operations to minimize risk
GitLab Security Direction is provided by the Sec Product Team.
The Security Section is made up of two DevOps stages, Secure and Defend, and eight groups supporting the major categories of DevSecOps including:
The existing team members for the Secure Stage can be found in the links below:
The existing team members for the Defend Stage can be found in the links below:
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
To capitalize on the opportunities listed above, the Secure Stage has features that make it useful to the following personas today.
As we execute our 3 year strategy, our medium term (1-2 year) goal is to provide a single DevSecOps application that enables collaboration between developers, security teams, SecOps teams, and QA Teams.
The Sec section is composed of two stages, each of which contains several categories. Each stage has an overall strategy statement below, aligned to the themes for Sec. Each category within each stage has a dedicated direction page plus optional documentation, marketing pages, and other materials linked below.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
Static Application Security Testing scans the application source code and binaries to spot potential vulnerabilities before deployment using open source tools that are installed as part of GitLab. Vulnerabilities are shown in-line with every merge request and results are collected and presented as a single report. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Dynamic Application Security Testing analyzes your running web application for known runtime vulnerabilities. It runs live attacks against a Review App, created for every merge request as part of the GitLab's CI/CD capabilities. Users can provide HTTP credentials to test private areas. Vulnerabilities are shown in-line with every merge request. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Interactive Application Security Testing checks runtime behavior of applications by instrumenting the code and checking for error conditions. It is composed by an agent that lives inside the application environment, and an external component, like DAST, that can interact and trigger unintended results.
Priority: low • Direction
Fuzz testing increase chances to get results by using arbitrary payloads instead of well-known ones. This category is at the "minimal" level of maturity.
Priority: high • Documentation • Direction
Analyze external dependencies (e.g. libraries like Ruby gems) for known vulnerabilities on each code commit with GitLab CI/CD. This scan relies on open source tools and on the integration with Gemnasium technology (now part of GitLab) to show, in-line with every merge request, vulnerable dependencies needing updating. Results are collected and available as a single report. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Check Docker images for known vulnerabilities in the application environment. Analyze image contents against public vulnerability databases using the open source tool, Clair, that is able to scan any kind of Docker (or App) image. Vulnerabilities are shown in-line with every merge request. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Upon code commit, project dependencies are searched for approved and blacklisted licenses defined by custom policies per project. Software licenses being used are identified if they are not within policy. This scan relies on an open source tool, LicenseFinder and license analysis results are shown in-line for every merge request for immediate resolution. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Check for credentials and secrets in commits. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
GitLab integrates access to proprietary and open-source application security scanning tools. In order to maintain the efficacy of those scans, we strive to keep their underlying vulnerability databases up-to-date.
Priority: high • Direction
GitLab Secure stage benchmarking for measuring security effectiveness in detecting security findings.
Continuously assess your applications and services are not vulnerable to security threats through automated, real-world emulated scenarios to identify weaknesses in your attack surface
Priority: low
Detect and protect projects from malware and other malicious code
Priority: low
Priority: medium • Direction
View, triage, trend, track, and resolve vulnerabilities detected in your applications. This category is at the "minimal" level of maturity.
Priority: high • Documentation • Direction
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
A Web Application Firewall (WAF) can examine traffic being sent to your web application and can detect then block malicious traffic before it reaches them. The ModSecurity WAF is installed via Auto DevOps behind the ingress controller in your Kubernetes cluster. It is configured by default to run the OWASP ModSecurity core ruleset. This category is at the "minimal" level of maturity.
Priority: medium • Documentation • Direction
Detect and respond to security threats at the Kubernetes, network, and host level. This category is at the "minimal" level of maturity.
Priority: high • Documentation • Direction
Container network security allows the implementation of network policies in Kubernetes to detect and block unauthorized network traffic between pods and to/from the Internet. This category is at the "minimal" level of maturity.
Priority: medium • Documentation • Direction
User and Entity Behavior Analytics (UEBA) is a solution that uses machine learning and other technologies to detect, alert, and block on anomalous behavior by users and systems.
Priority: high • Direction
Last Reviewed: 2020-07-09
Last Updated: 2020-07-09
