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.
Proactively identify security vulnerabilities and weaknesses in applications and services via a suite of highly performant & accurate application security scanners
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).
GitLab was named as a Challenger in the 2022 Magic Quadrant for Application Security Testing.
The Application Security Testing Stage 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 Application Security Testing stage is made up of 5 groups:
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.
Generative AI will empower small, centralized security teams to scale and effectively support their companies' development organizations, even when those teams are outnumbered 250:1. AI can enhance security teams' effectiveness, efficiency, and overall cost-effectiveness by being integrated into their daily operations. Additionally, AI will play a crucial role in helping companies shift security left, allowing developers to participate in vulnerability management and overall risk reduction.
When it comes to vulnerability and dependency management two problems are hard to solve that could be solved with AI:
In three years the Secure Stage market will:
As a result, in three years, Gitlab will:
Please explore the individual Category direction pages for more information on 12 month plans. Internal GitLab team members can view the 12 month roadmap for the AST stage and all groups there in here.
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. Definitions of our user personas can be found here.
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.
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.
Scans your application source code and binaries to spot potential vulnerabilities before deployment. SAST supports scanning a variety of different programming languages and automatically chooses the right analyzer even if your project uses more than one language. Vulnerabilities, additional data, and solutions are shown in-line with every merge request. Scanner results are collected and presented as a single report. This category is at the "complete" level of maturity.
Priority: high • Documentation • Direction
Scans your repository to help prevent your secrets from being exposed. Secret Detection scanning works on all text files, regardless of the language or framework used. Code pushed to a remote Git branch can be rejected if a secret is detected. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Analyzes your source code quality and complexity. This helps keep your project’s code simple, readable, and easier to maintain. This category is at the "minimal" level of maturity.
Runs automated penetration tests to find vulnerabilities in web applications and APIs as they are running. DAST can run live attacks against a Review App, an externally deployed application, or an active API. Scans can be run for every merge request, on a schedule, or even on-demand. DAST supports user inputted HTTP credentials to test private areas of your application. Vulnerabilities, additional data, and solutions are shown in-line with every merge request. Scanner results are presented as a single report. This category is at the "complete" level of maturity.
Priority: high • Documentation • Direction
Secures and protects web Application Programming Interfaces from unauthorized access, misuse, and attacks. Tests for known vulnerabilities by performing penetration testing of APIs with DAST. Finds unknown vulnerabilities by performing Fuzz Testing of web API operation parameters.Users can provide credentials to test authenticated APIs. Vulnerabilities, additional data, and solutions are shown in-line with every merge request.. Scanner results are collected and presented as a single report. This category is at the "complete" level of maturity.
Priority: high • Documentation • Direction
Sends random inputs to an instrumented version of your application in an effort to cause unexpected behavior in order to identify a bug that needs to be addressed. Helps you discover bugs and potential security issues that other QA processes may miss. This category is at the "complete" level of maturity.
Priority: high • Documentation • Direction
Analyzes external dependencies within your application for known vulnerabilities on each CI/CD code commit. Vulnerabilities, additional data, and solutions are shown in-line with every merge request. Scanner results are collected and presented as a single report. Upon code commit, project dependencies are searched for approved and denied licenses defined by per project custom policies. Software licenses are identified if they are not within policy and are shown in-line for every merge request for immediate resolution. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Scans your container images for known vulnerabilities within the application environment. Image contents are analyzed against public vulnerability databases.Security findings, additional data, and solutions reported in-line with every merge request along with additional data including solutions. Results are presented as a single report. Container Scanning is considered part of Software Composition Analysis. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
The GitLab Advisory Database serves as a repository for security advisories related to software dependencies. GitLab integrates the advisory database with its proprietary and open-source application security scanning tools. In order to maintain the efficacy of those scanners, we strive to keep their underlying vulnerability databases up-to-date.
Priority: high • Direction
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
We follow the buyer-based tiering strategy
This tier is the primary way to increase broad adoption of our suite of applcation security scanners, 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:
Examples:
This tier is not a significant part of the pricing strategy for the AST stage.
This tier is the primary focus for the AST 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:
Examples:
Last Reviewed: 2021-12-13
Last Updated: 2021-12-13
