The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Security visibility from development to operations to minimize risk
GitLab provides the single application organizations need to find, triage, and fix vulnerabilities as well as protect applications, services, and cloud-native environments. This enables organizations to proactively manage their overall security risk.
This empowers organizations as they can apply repeatable, defensible processes that automate security and compliance policies from development to production.
The Sec Section focuses on providing security visibility across the entire software development lifecycle and is comprised of the Secure and Protect stages of the DevOps lifecycle. This is accomplished by shifting security testing left with the Secure stage enabling developers to begin security scanning with their first written line of code. As applications and application updates are moved into production, the Protect stage provides SecOps and Ops teams the ability to mitigate attacks targeting the applications in cloud-native environments. The combination of both stages provides organizations with visibility into their security risk from the first line of code written to applications deployed within production.
GitLab is uniquely positioned to fully support DevSecOps by providing a single application for the entire software development lifecycle. This includes both shifting application security testing (AST) left as well as protection capabilities for applications running within production.
GitLab’s single application completely maps directly to the DevSecOps lifecycle. The Secure Stage provides the Develop, Analyze, and Mitigate portions of the DevSecOps lifecycle, while GitLab's Protect stage provides the Protect portion. Together, GitLab supports all teams involved in delivering secure applications:
The earlier a security vulnerability can be remediated has both risk reduction and cost reduction benefits.
When security vulnerabilities are identified at the time of code commit, developers can understand how their newly introduced code has led to this new issue. This gives the developer a cause-and-effect enabling quicker resolution while not having the time hit of context switching. This is not true as security scanning is performed later in the software development lifecycle. New vulnerabilities may not be identified until weeks or months after they were added to the application while under development.
Time is not the only savings when shifting security left.
In “The Economic Impacts of Inadequate Infrastructure for Software Testing”, NIST estimated the cost of remediating software bugs at $59.5 billion/year. This is compounded when taking in the average time to remediate software bugs. In “Software Development Price Guide & Hourly Rate Comparison”, FullStack Labs estimates the average cost of a software developer at $300/hour. The following table outlines the cost to remediate software bugs at different stages of the software development lifecycle:
These costs are just the start of the financial impact when the software bug is also a software vulnerability. IBM, in partnership with the Ponemon Institute, put the average cost to remediate a data breach in 2020 at $3.86 million (USD). This does not take into consideration the reputation impact to the organization.
Having visibility into security risk in just development only provides you with half of the picture. Development and SecOps teams need to have a closed feedback loop enabling both teams to be successful. Development teams can gain insight into attacks targeting the applications they develop. This allows them to prioritize vulnerabilities correctly, enabling proactive resolutions to reduce risk. Likewise, SecOps teams can gain insight from their development counterparts, providing them with visibility into how the application works. This allows them to best apply proactive measures to mitigate attacks targeting the application until development can fix the vulnerability.
Closing the loop requires close collaboration, transparency, and efficiencies that only a single platform for the entire DevOps lifecycle can provide. Shifting security left while also providing protection for applications in production within a single application empowers teams to work closer together. Security is a team sport and teams working together can best reduce their organization’s overall security risk.
The Security Section is made up of two DevOps stages, Secure and Protect, and eight groups supporting the major categories of DevSecOps including:
The existing team members for the Sec Section can be found in the links below:
Learn more about GitLab's investment into the Sec section by visiting our Product Investment page within the Product Handbook.
The following are the updates from the Sec Section for November 2021 (as presented in the monthly Product Key Review). A complete list of released features can be found on the Release Feature Overview page and a complete list of upcoming features can be found on the Upcoming Releases page.
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 automatic 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:
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:
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:
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:
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.
Protect will focus first on providing reactive security solutions that are cloud native. Whenever possible, Protect capabilities will be cloud platform agnostic, including support for self-hosted cloud native environments.
For example, GitLab's current Protect capabilities leverage numerous open source cloud-native projects that integrate cleanly with Kubernetes to provide additional security in containerized environments. Any future expansion of security capabilities will come after the cloud native capabilities are mature.
Protect will focus on detecting and alerting on malicious traffic and activity as a first step followed by introducing prevention as a second step. This is valuable to you because it means that you can introduce Protect within your cloud native applications, services, and infrastructure gradually over time without disrupting your end users. This allows you to examine the alerts generated by Protect using detection policies to ensure all security settings are appropriate and accurate for your cloud native deployment prior to moving to protection policies. This allows you to eliminate false positives and prevents your users from having a poor user experience with your applications and services. Furthermore, Protect will provide you with evidence of malicious traffic and activity as well as any actions taken, allowing you to meet and exceed your compliance goals and requirements.
As examples, GitLab will provide:
One of the key advantages to GitLab being a single application for the entire DevOps lifecycle is that all of our stages are tightly integrated. This empowers Protect to both provide information into other stages, such as Plan, as well as to receive information from other stages, such as Secure.
Protect will leverage knowledge from the Secure Stage and provide virtual patching of security policies within Protect Categories. Additionally, Protect will eventually leverage Secure scanning capabilities to provide on-going scanning of applications after they have been deployed to production. This allows for detection of any new threat vectors or vulnerabilities that were published after the original push to production.
Protect will identify and protect against threats as they happen, and will also strive to provide actionable next steps to close a vulnerability or point of exploit, not just protect it.
Not only does shifting left and acting on results earlier give your apps better security, it helps enable collaboration with everyone at your company. We believe that security is everyone's responsibility and that everyone can contribute. Informing other stages is a powerful way to do this.
As examples, GitLab will provide:
Protect will leverage OSS security projects to build our solutions. Protect will contribute improvements to these projects upstream helping everyone be more secure.
For example, GitLab recently added a Policy Audit Mode to the upstream open source Cilium project to allow users to test their policies before enforcing them.
Protect capabilities will be pre-configured to provide value to protecting your applications. Rather than require you to read documentation manuals and provide complex configuration files, GitLab will always provide reasonable defaults out of the box.
We will provide the ability for advanced and customized configurations, but these will only be needed based on your specific use case and when you feel comfortable doing so.
For example, GitLab is currently working on an intuitive policy editor UI to allow for configuration of Network Policies. While advanced Network Policies can be created and managed by editing the .yaml file, the majority of policy use cases can be accomplished with the simpler UI.
The Secure team has been actively delivering updates to help you reduce risk. The following are some highlights from recent GitLab releases:
The Secure team is actively working to bring world class security to DevSecOps and the following outlines where we are currently investing our efforts:
To meet our audacious goals, the Secure Stage will focus on the following over the next 12 months:
In addition, the Protect Stage will focus on the following over the next 12 months:
The following will NOT be a focus over the next 12 months:
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 Sec Section 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, Secure and Protect, 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.
The Secure stage 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).
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 "complete" level of maturity.
Priority: high • Documentation • Direction
Check for credentials and secrets in commits. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Automatically analyze your source code to surface issues and see if quality is improving or getting worse with the latest commit. This category is at the "minimal" level of maturity.
Dynamic Application Security Testing analyzes your running web application for known runtime vulnerabilities. It runs live attacks against a Review App, an externally deployed application, or an active API, 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. Tests can also be run outside of CI/CD pipelines by utilizing on-demand DAST scans 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
API Security focuses on testing and protecting APIs. Testing for known vulnerabilities with DAST API and unknown vulnerabilities with API Fuzzing, API Security runs against a live API or a Review App to discover vulnerabilities that can only be uncovered after the API has been deployed. Users can provide credentials to test authenticated APIs. Vulnerabilities are shown in-line with every merge request. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Fuzz testing increase chances to get results by using arbitrary payloads instead of well-known ones. This category is at the "viable" 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
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 "minimal" 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
View, triage, trend, track, and resolve vulnerabilities detected in your applications. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Secure is focused on providing enterprise-grade application security testing (AST) capabilities to minimize overall risk. The intent is to provide enough value in paid features so as to allow Secure to contribute in a significant way over the next 3 years toward GitLab's company-level financial goals.
Although paid features are the primary focus, there are several reasons why features for unpaid tiers might be prioritized above paid features:
This tier is the primary way to increase broad adoption of the Secure stage, as well as encouraging community contributions and improving security across the entire GitLab user base.
As a general rule of thumb, features will fall in the Core/Free tier when they meet one or more of the following criteria:
Some examples include:
This tier is not a significant part of Secure's pricing strategy.
This tier is the primary focus for the Secure stage as the security posture of an organization is typically a primary concern of the executive team and even the board of directors. Just as a major security incident has far reaching consequences that impact the entirety of an organization, the features and capabilities that enable organizations to assess their overall security risk tend to be valued with equal weight. The types of capabilities that fall in the Ultimate/Gold tier vs an unpaid tier should be those that are necessary for an organization, rather than an individual, to properly secure their code before pushing it into a production environment.
As a general rule of thumb, features will fall in the Ultimate/Gold tier when they meet one or more of the following criteria:
Some examples include:
The Secure stage 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).
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 "complete" level of maturity.
Priority: high • Documentation • Direction
Check for credentials and secrets in commits. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Automatically analyze your source code to surface issues and see if quality is improving or getting worse with the latest commit. This category is at the "minimal" level of maturity.
Dynamic Application Security Testing analyzes your running web application for known runtime vulnerabilities. It runs live attacks against a Review App, an externally deployed application, or an active API, 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. Tests can also be run outside of CI/CD pipelines by utilizing on-demand DAST scans 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
API Security focuses on testing and protecting APIs. Testing for known vulnerabilities with DAST API and unknown vulnerabilities with API Fuzzing, API Security runs against a live API or a Review App to discover vulnerabilities that can only be uncovered after the API has been deployed. Users can provide credentials to test authenticated APIs. Vulnerabilities are shown in-line with every merge request. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Fuzz testing increase chances to get results by using arbitrary payloads instead of well-known ones. This category is at the "viable" 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
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 "minimal" 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
View, triage, trend, track, and resolve vulnerabilities detected in your applications. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Secure is focused on providing enterprise-grade application security testing (AST) capabilities to minimize overall risk. The intent is to provide enough value in paid features so as to allow Secure to contribute in a significant way over the next 3 years toward GitLab's company-level financial goals.
Although paid features are the primary focus, there are several reasons why features for unpaid tiers might be prioritized above paid features:
This tier is the primary way to increase broad adoption of the Secure stage, as well as encouraging community contributions and improving security across the entire GitLab user base.
As a general rule of thumb, features will fall in the Core/Free tier when they meet one or more of the following criteria:
Some examples include:
This tier is not a significant part of Secure's pricing strategy.
This tier is the primary focus for the Secure stage as the security posture of an organization is typically a primary concern of the executive team and even the board of directors. Just as a major security incident has far reaching consequences that impact the entirety of an organization, the features and capabilities that enable organizations to assess their overall security risk tend to be valued with equal weight. The types of capabilities that fall in the Ultimate/Gold tier vs an unpaid tier should be those that are necessary for an organization, rather than an individual, to properly secure their code before pushing it into a production environment.
As a general rule of thumb, features will fall in the Ultimate/Gold tier when they meet one or more of the following criteria:
Some examples include:
scan_result_policy from its initial implementationscan_result_policy as an approval rule functionalitycluster agent to vulnerability report graphQL query UltimateRuleScheduleService to process rules for sast scan type Ultimatescan_result_policy Ultimatevulnerability-check Ultimatestarboard_vulnerability API
Last Reviewed: 2020-12-29
Last Updated: 2020-12-29