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

Product Section Direction - Secure

On this page

Proactively identify vulnerabilities and weaknesses to minimize risk

GitLab Secure enables accurate, automated, and continuous assessment of your applications and services enabling you to proactively identify vulnerabilities and weaknesses to minimize your security risk. Secure is not an additional step in your process nor an additional tool to introduce to your process. it is woven into your DevOps cycle thus allowing you to adapt your security testing and processes to your developers (and not the other way around).

Secure Overview

Section Overview

The Secure Section focuses on identifying security findings (e.g., vulnerabilities and weaknesses) within applications and services prior to moving them to operations. Furthermore, Secure can (and will) provide security visibility for applications and services already deployed to production. Secure’s goal is to proactively identify vulnerabilities and weaknesses before they are exploited. This is done by:


The Secure Section is made up of one DevOps stage, Secure, and seven groups supporting the major categories of DevSecOps including:

Resourcing and Investment

The existing team members for the Secure Section can be found in the links below:

SWOT Analysis & Challenges






Security Is A Team Effort

Everyone benefits when security is a team effort as testing happens regularly, issues are found earlier, and code shipped is more secure. To make this possible, security must be approachable, not overburden teams, and results must be easy to interpret. Security testing tools and processes must be adapted to your developers (and not the other way around). This means bringing security into the workflow of your developers such that they can stay within their context without having unnecessary steps added to their daily work. Furthermore, results provided as security findings must be presented in a way that they can be interpreted without needing a PhD in cybersecurity. This includes providing enough detail to begin identifying the root cause (including identifying the section of code causing the security finding) and suggesting remediation steps (including auto-remediation) as well as pointing to industry standards related to the security finding. By implementing an integrated DevSecOps lifecycle with actionable results, security becomes everyone’s responsibility.

As examples, GitLab will provide:

Shift Left. No, More Left Than That.

The “shift left” approach is not a new concept within software testing and DevOps best practices. It is commonly thought of when discussing the DevSecOps lifecycle. This usually includes security testing earlier in the software development lifecycle with the goal of identifying security vulnerabilities and weaknesses prior to shipping code to operations. Today’s techniques include static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), dependency scanning, and license compliance. The continuation of the “shift left” approach requires a harder shift left, bringing security testing as close as possible to the developer. This enables earlier detection of security vulnerabilities and weaknesses, thus lowering the cost of remediation (as well as reducing work for the entire team as security findings are addressed prior to reaching the QA and security teams).

As examples, GitLab will provide:

Shift Right. Yes, Right. Right Into Operations.

Security testing doesn’t stop once code is shipped. New vulnerabilities, security weaknesses and, attacker techniques are constantly discovered, leaving operations and their associated applications and services open to being compromised. Also, as organizations continue to shift to the cloud and employ cloud-native strategies, new attack surfaces are exposed that did not exist within the traditional data center. These include items like cloud storage permissions and unwanted network services. Applications, services, and their associated cloud-native infrastructure need to be assessed just as a user (or an attacker) would interact with them. This means performing the same tasks that an attacker would perform including reconnaissance, vulnerability assessment, and penetration testing. Implementing a continuous assessment strategy of operations is needed to provide full visibility into all potential risk.

As examples, GitLab will provide:

Provide Active Intelligence to Enable Data-Driven Decisions

Security findings, without context, can lead to making incorrect decisions on remediation, leaving applications and services vulnerable. With more data made available, better decisions can be made while prioritizing security findings, enabling users to best manage their security risk. Furthermore, this enables developers to write secure code, build operations to package dependencies free of vulnerabilities, and security team members to test deeper than previously achievable. Leveraging machine learning provides active intelligence, enabling users to make smart, data-driven decisions at the right time, lowering overall security risk. Machine learning, to be successful, relies on big data to build accurate models. The GitLab community includes developers, build operators, and security teams all working together within their organizations to code, build, deliver and secure application and services going into operations. As a global community, developers can learn from each other to identify and better secure code. Dependency vulnerabilities and weaknesses can be avoided, and security teams can test smarter, faster, and deeper. Machine learning, powered by anonymized data, provides active intelligence enabling data-driven decisions.

As examples, GitLab will provide:

BYOT - Bring Your Own (Security) Tools

At GitLab, we believe everyone can contribute and security is everyone’s responsibility. We empower GitLab users by providing security tools which include Static Analysis, Dynamic Analysis, Container Scanning, Dependency Scanning, and License Scanning. However, we recognize our users may have existing security tools and may want to continue to use them. As such, we strive to play well with others. Security tool vendors will be provided standardized components (e.g., APIs) within the GitLab complete DevOps platform enabling easy integration into our Security Dashboard and Merge Request controls including security approvals. This allows our users to have alternate security tools that either replace, or augment, our Secure tools.

As examples, GitLab will provide:

If you are interested in contributing such an integration, please create an issue so we can collaborate on questions and adding any enabling functionality.

3 Year Strategy

In three years the Secure Section market will:

As a result, in three years, Gitlab will:

1 Year Plan

What's Next for Secure

To meet our audacious goals, the Secure Section will focus on the following over the next 12 months:

What We're Not Doing

The following will NOT be a focus over the next 12 months:

Please explore the individual Category Direction pages for more information on 12 month plans.

Security Paradigm

We want to provide feedback during development and before your application is in production to reduce production vulnerabilities, and to reduce cycle time of releases by providing relevant point in time information. Think back on the recent breaches in the news, in most cases these were not the result of complex attacks, but rather teams who were unable for a variety of reasons to strictly follow best practices. We plan to assist you and your team to cover these, so your Security teams time and energy can focus on the more unique and advanced problems that you face in your risk profile, rather than spending time on things that are low hanging fruit.

The approach is to support decision makers, not to replace them. Instead of enforcing security, we want to give a very simple way to take the right action, and learn from it. Keeping it simple is a key value to prevent security features from being considered at all because they require more effort than the perceived benefit.

Our tools will help provide security in depth for your application, will cover the most common vulnerabilities, and the strongly recommended security basics. The results and recommendations of our secure tools will be made available at the relevant time, as well as through a variety of methods such as an API so that the information can be used at the time and in the way that works best for your team.

Tools are actionable: it means that users can interact with them and provide feedback about their content. When triaging vulnerabilities, users can confirm (creating an issue to solve the problem), or dismiss them (in case they are false positives and there is no further action to take). This information will be collected to improve the signal-to-noise ratio that the tool could provide in future executions.

We want to allow your team the choices to set your risk level as is appropriate to your business. Even accurate results may be considered false positives as this is dependent on many details about both your application and your environment. By default our tools will never block a merge request or pipeline if they find vulnerabilities. However, GitLab wants to help you customize this behavior by setting up Security approvals in Merge Requests and enforcing the execution of the analysis if this is what you need.

Our tools should be easy to use, and assist your team in making secure decisions with the minimal amount of effort and steps. Our findings should be informational enough to enable prioritizing and acting on findings in a way that works with your desired workflows and doesn’t result in users disabling or ignoring the checks, preventing the benefit.


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.



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.



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. This category is planned, but not yet available.



Fuzzy testing increase chances to get results by using arbitrary payloads instead of well-known ones. This category is planned, but not yet available.


Dependency Scanning

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.


Container Scanning

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.


License Compliance

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.


Secret Detection

Check for credentials and secrets in commits. This category is at the "minimal" level of maturity.


Vulnerability Database

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.


Attack Emulation

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

Malware Scanning

Detect and protect projects from malware and other malicious code


Other top-level features

In the Secure stage there are features that are cross-category. They allow Security Teams and Developers to manage security with a holistic approach. The prioritization of a security issue doesn't fully depend on the type of vulnerability, but on its severity and so which is the impact on the application.

That's why we want to create features where vulnerabilities are in one single place, no matter if they are coming from SAST, Dependency Scanning, Container Scanning, etc.

Auto Remediation

When a vulnerability is automatically detected by GitLab, users can be aware of that using the Security Dashboard or looking at security reports. But this still requires manual intervention to create a fix and push it to production, and during this time there is a vulnerable window where attackers can leverage the vulnerability.

Auto Remediation aims to automate vulnerability solution flow, and automatically create a fix. The fix is then tested, and if it passes all the tests already defined for the application, it is deployed to production.

GitLab can then monitor performances of the deployed app, and revert all the changes in case performances are decreasing dramatically, warning the user about the entire process and reducing the need for manual actions.

Read more in this epic.

Slides are available here.

Security Dashboards

Security Dashboards, available at group and project level, are the primary tool for Security Teams and Directors of Security. They can use those dashboards to access the current security status of their applications, and to start a remediation process from here.

The dashboard is also giving stats and charts to figure out how the team is performing to keep the security level to a proper level.

Bill of materials

Software is often based on many components that are reused. Every modern programming language makes it easy to pull and use external libraries via package managers. There is a growing need to know exactly what is included in the final app, and the relevant information about those third-party components, like the version number, the license, and the security status.

The bill of materials (BOM) makes this information available and accessible, so compliance can perform validation that the app can be released and deployed.

Read more in this epic.

DevOps coverage

The classic DevOps includes security testing as an activity in the Verify stage.

GitLab has a broader approach. That's why we introduced a Secure stage that is transversal to all other Dev stages.

Our Product Vision aims to increase the security coverage for all these stages in the DevOps lifecycle: Plan, Create, Verify, and Package.

This is possible because GitLab is a single application.

There are many advantages coming from complete coverage of all these stages with security features. It allows to shift-left security at a very early stage, even before the first lines of code are committed. If you start with security as a priority when you plan a new app, it is easier than just trying to add security later. Security should remain on the radar even when the create process happens, to support developers and help them to write secure code from the beginning. Security testing can then happen for any change, before it is merged into the stable branch of the application: in this way you can spot problems and fix them before they risk affecting the production environment or the stable version of your app. Packaging the app should also be done with security in mind, as well as the release process to the production environment: at that point, your code is publicly available and any remediation will impact heavily on your processes.

Security is a never-ending priority, and at GitLab we want to make it easy for our users to manage it.

Target audience

Security teams

We want to support security teams as first class citizens. GitLab should be their primary tool to manage monitoring and remediation of security issues. Using the Security Dashboard security specialists know exactly which is the most important thing they need to take care of, while Directors of Security can manage workflows and analyze historical data to figure out how to improve the response time.

This is a vulnerability-centric approach where items are grouped and ordered to suggest what's most important in a group, or in the entire instance.


Nonetheless, we want to support developers and provide feedback during the application development. Security Reports in merge request widgets and pipelines allow early access to security information that can be used to fix problems even before they are merged into the stable branch or released to the public, embracing the idea of shift left testing.

This approach is valuable to highlight how specific changes could affect the security of the application.


We expect that in most of the cases the number of potential security issues will be high, and we don't want that users will struggle in figuring out which is the impact of any possible item for their environment. That's why GitLab will prioritize security vulnerabilities based on different factors. The value given with this process is defined as the impact.

These are examples of factors that may contribute to define the impact for a specific security issue:


Ultimate/Gold subscribers

For now, security features are available in the Ultimate/Gold tier because we think that security matters for everyone, but automation of security in the development lifecycle is more valuable for organizations who want to optimize their DevOps investment to run securely at the highest business velocity.

Public projects on

Every project on with public visibility can benefit of all the security features for free, even if it doesn't have a Gold license.

Nevertheless, public groups can benefit of group security features (like the Group Security Dashboard only if they have a Gold license.


We also want to collect and provide metrics to better understand how the security workflow is performing. For example, the overall time taken to deploy a fix for a vulnerability once spotted could be useful for flow improvements.

Prioritization Process

Every month, a couple of weeks before the start of the development cycle, the team meets to plan what will be done in the upcoming milestone. Decisions are based on our general prioritization principles, and we specifically consider case by case what is most important to do next, since we always have so many awesome ideas but we have to choose what has to be done first.

The PM maintains a product roadmap for the next three milestones and beyond, to ensure that we are focusing on important things ahead of time and we can prepare them properly. We are always ready to adjust our plans and we normally commit only to issues that are scheduled for the current release: this is very important in order to guarantee that we can be fast enough to react to unexpected events.

We want everybody to be part of our prioritization process, that's why all the information is public. We encourage team members, customer, and the community to give feedback and to share what they consider very important to focus on in the future. This is a valuable help to make GitLab a great product.

Upcoming Releases

12.8 (2020-02-22)

12.9 (2020-03-22)

12.10 (2020-04-22)

13.0 (2020-05-22)

13.1 (2020-06-22)

Other Interesting Items

There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.

Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!