|Product Marketing||Technical Marketing|
|Cindy Blake ( @cblake )||Fernando Diaz ( @fjdiaz )|
The DevSecOps usecase is applicable for customers who are trying to "shift left" to find security vulnerabilities earlier within their DevOps methodology but have not been able to achieve expected results.
Application Security is hard when security is separated from your DevOps flow. Security has traditionally been the final hurdle in the development life cycle. Iterative development workflows can make security a release bottleneck. Customers don't have enough security people to test all of their code, and hiring more security analysts won't automatically reduce the friction between app sec and engineering teams. Only testing major releases, or limiting tests to certain apps, leaves weak spots hackers can exploit. They need a way to balance risk and business agility. Instead of waiting for security at the end of the development process, they want to include it within their DevOps workflow. Often this is referred to as DevSecOps.
DevSecOps integrates security controls and best practices in the DevOps workflow. DevSecOps automates security and compliance workflows to create an adaptable process for your development and security teams.
Balancing business velocity with security is possible. With GitLab, DevSecOps architecture is built into the CI/CD process. Every merge request is scanned through its pipeline for security issues and vulnerabilities in the code and its dependencies using automated tests. This enables some magic to happen.
Every piece of code is tested upon commit for security threats, without incremental cost. The developer can remediate now, while they are still working in that code, or create an issue with one click. The dashboard for the security pro is a roll-up of vulnerabilities remaining that the developer did not resolve on their own. Vulnerabilities can be efficiently captured as a by-product of software development. A single tool also reduces cost over the approach to buy, integrate and maintain point solutions throughout the DevOps pipeline.
Users include both the developer and the security pro. We pride ourselves on having a united view of the software vulnerabilies and their status toward resolution.
The Developer uses GitLab primarily within the MR pipeline report
The developer cares about security but does not want to become a security expert. Their primary driver to write secure code is to protect their personal/professional reputation. They don't want to be the one that brings their company down via vulnerable code that they wrote. At the same time, they are goaled mostly on quickly turning out code that meets their users' requirements. Often they are not measured on security flaws. Security can seem like a necessary nuisance. Tools that fit within their workflow, without context-switching are most acceptable. The clarity GitLab provides by reporting vulnerabilities at code commit is helpful.
Sam the Security Analyst uses GitLab primarily in the Security Dashboard
The security pro cares most about managing risk to the enterprise/agency. They take a broad view of process looking for process improvement areas to reduce risk and avoid repeat mistakes. Because they care about risk, they want to identify unresolved vulnerabilities, their severity, and their remediation status. They care about trends over time and aggregate improvements. Often their metrics are mean time to remediation. It is rare that the security person themselves is able to remediate a software security flaw; they depend upon the developer to do this. This goal misalignment is often a reason for contention between the groups. In traditional app sec environments, where testing is done at the end of the SDLC, they may spend alot of their time tracking and reporting vulnerability statuses, vetting findings, and triaging to dev teams. Where development is more automated, they may be able to focus more on setting policies and allowing the tools to enforce them. They often want to avoid moving any new critical/high vulnerabilities into production and favor breaking the build to enforce this.
The Security Manager or CISO (Sam's boss) is usually the buyer
While developers and DevOps teams like to use GitLab for security, the security pro is often skeptical, comparing it to their favorite incumbant scanner. They may have bet their career on justifying a very expensive scanner like Fortify or Veracode and are often reluctant to replace it, even if it can simplify their work as well as that of the developer.
Examples of comparative research for this use case are listed just below. Additional research relevant to this use case can be found in the Analyst Reports - Use Cases spreadsheet.
It is important to note whether or not we have reprint rights for a piece of content. When we do, there will be two links. One is direct link to the content that you can download and share. The other link is to the gated page. Please use this link for lead generation activities. If we do not have reprint rights, you will get a link to an internal company document that you may use for your education but you may NOT share with customers, prospects or partners.
GitLab has reprint rights to the following document:
Please note that GitLab does NOT have reprint rights for these two reports, so please do not share these with customers, prospects, or partners.
|Market Requirements||Description||Typical capability-enabling features||Value/ROI|
|Scan results for the Developer||For developers to find and fix vulnerabilities while they are coding, vulnerability scan results must be made available to the developer within their native workflow. Findings that can be automatically corrected should use automation to apply a fix and test the results.||Incremental scanning for rapid, iterative scans. Integrate scan results into the CI pipeline. Auto Remediation to automatically create a fix, eliminating developer effort.||Allows security flaws to be fixed early, when less expensive, removes context-switching, and minimizes risk by preventing vulnerabilities from reaching production.|
|Application Security Testing of code and components||Often referred to as Software Composition Analysis (SCA), it tests all code components (custom code and open source), wherever it resides (e.g. within containers). The GitLab survey shows Dependency scanning is most frequently used scan type.||SAST, Dependency Scanning, Container scanning, Secrets Detection, and (optionally) License Compliance||Reduces security and compliance risks.|
|Application Security Testing of running app||Scans that look for vulnerable code behavior as the code executes.||DAST, IAST, Input Fuzzing, UEBA/Threat modeling, Mobile app sec testing||Reduces security and compliance risks.|
|Security Governance||The solution automatically applies security policies against code to ensure that only appropriate risks are taken. Application vulnerabilities, representing risk, are tracked, managed, and reported. The solution enables routine assessments of security practices to evaluate for risk, compliance, audit and process improvement opportunities (usually for education purposes).||Security policy automation, Risk and compliance reporting, Audit reporting, Variety of security metrics and process reporting, Vulnerability database and management||Efficiently monitor, manage and mitigate risk. Ability to identify exceptions and refine policies over time.|
|Security guardrails (Preventative - Pre CI/CD)||Preventative Application Security uses guardrails to help teams consistently build things that are secure from the start.||Spell-check-like functionality that identifies insecure phrases as the developer types, bill of materials that limit developer choices to pre-approved code libraries, and auto-discovery that catalogs all third party code.||Prevents creating new vulnerabilities.|
|Works with existing and diverse tools||Security scanners must integrate into an existing environment that may use third party CI and/or security scanners.||APIs and Plug-ins||Allows continued use of existing investments and avoids a rip-n-replace scenario.|
More detailed breakdown may be found on output tab of Use Case Requirements Discussion
GitLab DevSecOps use case overview
|Market Requirements||How GitLab Delivers||GitLab Category||Demos|
|Scan results for the Developer||Incremental scanning for rapid, iterative scans. Integrate scan results into the CI pipeline. Auto Remediation to automatically create a fix.||CI (for MR pipeline), Auto remediation||Adding Security to your CICD Pipeline|
|Application Security Testing of code and components||SAST, Dependency Scanning, Container scanning, Secrets Detection, and License Compliance||SAST, Dependency Scanning, Container scanning, Secrets Detection, and License Compliance|| SAST and Secret Detection
|Application Security Testing of running app||GitLab uses its review app, spun up during CI, to run dynamic application security tests. Recent acquisitions will provide multi-dimensional fuzz testing, useful for API scanning. Mobile app sec testing can be performed on any app within our language scanning capabilities||DAST, Input Fuzzing, Mobile app sec testing (partners needed)||DAST|
|Security Governance||Security Policy Automation, Compliance Assessment, Security Risk Assessment, Audit Assessment, Security Process Improvement/ Assessment, Vulnerability Management, Vulnerability Database||Security Dashboards, Vulnerability Management, Audit events Compliance Management||Accelerate AppSec Efficiency with the GitLab Security Dashboard|
|Security guardrails (Preventative - Pre CI/CD)||GitLab provides bill of materials showing dependencies. We do not yet use this to limit developers to use only pre-approved dependencies||bill of materials feature||Manage your Application Dependencies with GitLab|
|Works with existing and diverse tools||GitLab allows the integration of external CI tools to run alongside GitLab's CI enabling Jenkins users to also use GitLab Secure capabilities. Similarly, users may have invested in third party security scanners or may require another scanner for a language not covered by GitLab. We have made it easier for third party scanners to integrate into the GitLab MR and the security dashboards.||CI (for MR pipeline), Security Dashboards|| Using GitLab Application Security Capabilities with Jenkins
Creating Jira issues from GitLab vulns
|Detailed and Actionable Scan Results Displayed in MR created from Feature Branch||GitLab performs security scans like SAST, license compliance, dependency scanning before the code is merged - giving Developers opportunity to identify and fix security vulnerabilities before they context switch to other activities. This improves cycle time and development costs as the time and cost to resolve defects and vulnerabilities exponentially increase the later it is detected in the development cycle||Gartner - Integrating Security Into the DevSecOps Toolchain explains how Security should be included in the DevSecOps lifecycle in small actionable steps that developers can take action on quickly & integrating into defect tracking workflow to match the pace of security fixes to the pace of development.||Security Scans as Displayed in DevSecOps Overview|
|Block MR based on Security Policy||Bring Development and Security Teams closer by allowing security teams to apply organizational security policies before hand and review/approve security exceptions before the code is merged||-||Merge-Request Approvals as Displayed in DevSecOps Overview|
|Compliance Management||GitLab makes compliance easier by providing a single source of truth for Dev, Sec and Ops through a single data-store. Everything is audited and for every change, there is a single thread that contains the full audit log of every decision and action - making audit compliance a breeze||The auditor for Glympse observed that the company had remediated security issues faster than any other company that he had worked with before in his 20-year career. Within one sprint, just 2 weeks, Glympse was able to implement security jobs across all of their repositories using GitLab’s CI templates||Manage Compliance with GitLab|
|Coverage-Guided Fuzz Testing||GitLab provides using contextual information from source code to better inform fuzz tests as well as to help correlate the results of a fuzz testing crash directly to the region of code that was vulnerable. This dramatically improves the cycle time to go from an initial fuzz test to a crash to an update to vulnerable areas.||-||Finding Bugs with Coverage Guided Fuzz Testing|
|Offline Environments||GitLab provides a variety of scanners to run in offline or limited connectivity environments. This feature enables security vulnerabilities to be detected in code that lies in offline environments.||-||Running GitLab Security Scans in Limited Connectivity and Offline Environments|
Contextual. Unlike traditional application security tools primarily intended for use by security pros, GitLab secure code capabilities are built into the CI/CD workflows where the developers live. We empower developers to identify vulnerabilities and remove them early in the development cycles. While at the same time, providing security professionals a dashboard to view items not already resolved by the developer, across projects. This contextual approach helps each role deal with items that are most important and most relevant to their scope of work within the delivery process.
Congruent with DevOps processes. GitLab secure capabilities support the decision-makers, within their natural workflow. Reports are interactive, actionable, and iterative and most important immediate and relevant to changes made. Developers immediately see the cause and affect of their own specific changes so they may iteratively address security flaws alongside code flaws. Integrated with DevOps tools. When triaging vulnerabilities, users can confirm (creating an issue to solve the problem), or dismiss them (in case they are false positives or there are compensating controls). When using GitLab, no additional integration is needed between app sec and ticketing, CI/CD, etc.
Efficient and automated. Eliminates mundane work wherever possible. Auto remediation applies patches to vulnerable dependencies and even re-runs the pipeline to evaluate the viability of the patch.
The message house for the use case provides a structure to describe and discuss the value and differentiators for the use case.
See how we compare against other Security tools
See how we compare against GitHub's roadmap for Security
Why choose GitLab free for DevSecOps? Security matters to everyone, and we're committed to lowering the barriers to a fully secure, compliant SDLC. That's why we've migrated Brakeman SAST scanning to Free, allowing every Rails developer—at every product tier—to scan their source code for known vulnerabilities.
Key DevSecOps features with Free tier:
Why choose GitLab Ultimate for DevSecOps? Achieve advanced DevOps maturity with enterprise-level application security capabilities.
In addition, enjoy these benefits of Ultimate:
Key DevSecOps features with Ultimate:
We partner with key industry vendors to extend GitLab's ability to address customer needs and fulfil the market requirements.
To extend scanning language support to nearly 200 additonal languages and deeper dependency insight, WhiteSource integrates with GitLab and provides a seamless experience for developers to improve the secuirty of their code. Learn more about how to integrate WhiteSource into GitLab and more;
You can also watch Dependency Scanning with GitLab and WhiteSource to get started.
If you or your customer has a third party they'd like to see integrated into GitLab, send them to the partner integration page for instructions.
The suggested discovery questions below are meant to help you uncover opportunities when speaking with prospects or customers who are not currently using GitLab for Secure/Protect. They are grouped by topic or entry point. Don’t try to use them all, just those most relevant to your customer. The deeper you can dig into their processes, the more benefits you are likely to show of using GitLab. Feel free to contribute!
Initial probe for direction. Where’s the pain?
Integrating application security testing into Agile DevOps software development is difficult with many potential challenges. Use these 6 questions to probe a bit to see which areas are of most concern, then go deeper on those topics further below.
1. Finding security vulnerabilities
2. Collaboration /visibility
3. Efficiency of remediation
4. Managing Risk
5. Policy Automation
I have an incumbent tool. How does your scanning compare?
GitLab scanners use a combination of proven open source scanners and proprietary scanners.
Finding vulnerabilities is important, but what you do with the results is equally important. Consider:
Also, how predictable is the cost of these tools? If you find more vulnerabilities, or test more apps, does it cost you more? Are you essentially penalized for more testing? How does that work with DevOps breaking apps into microservices and running more frequent pipelines? In fact, Gartner even called us out in a report on how to set up an AppSec program inexpensively (7 Tips to Set Up an Application Security Program Without Breaking the Bank).
If using Fortify, Veracode or Synopsys
If using Snyk, WhiteSource or other point solutions
If using GitHub Actions and/or Azure DevOps
The Gartner Magic Quadrant for AST placed GitLab as a niche player. Does that mean your security scanners are not as good as the other vendors?
Our placement has nothing to do with the efficacy of our scanners. GitLab is a niche player because our security scanning capabilities are best used by people using GitLab for CI. We have demonstrated that people using GitLab for SCM and Jenkins for CI can still use GitLab’s security testing, however if you are not using GitLab for SCM nor for CI, it probably makes little sense for you to use GitLab for AST as a standalone app sec tool.
I can’t justify the cost difference for Ultimate.
NIST demonstrated the cost savings from shifting security left back in 2002. How far left are you currently? Hypothetically, if 50% of your vulnerabilities could have been found by the developer and if half those could hypothetically be fixed before the code ever leaves the developer’s hands, what value would that have for your cost and your risk exposure? Let's consider the potential benefit of:
How predictable is the cost of other app sec tools? If you find more vulnerabilities, or test more apps, does it cost you more? Are you essentially penalized for more testing? How does that work with DevOps breaking apps into microservices and running more frequent pipelines? What is the value of scanning every code change going forward? What is the impact on your technical debt over time? What would it cost you with your other tools to scan every software change?
For a list of analysts with a current understanding of GitLab's capabilities for this use case, please reach out to Analyst Relations via Slack (#analyst-relations) or by submitting an issue and selecting the "AR-Analyst-Validation" template.
GitLab customer, HERE, shares their experience with using GitLab to Shift Left
GitLab customer, Arctic Engine, shares their experience with using GitLab's fuzz testing to find unknown vulnerabilities.
Gartner Peer Insights reviews constitute the subjective opinions of individual end users based on their own experiences, and do not represent the views of Gartner or its affiliates. Obvious typos have been amended.
"GitLab Application Security Testing helps to analyze our source code for vulnerabilities, listed in GitLab Security Dashboard. It is easily configurable with Docker setup. It shows the complete vulnerabilities report immediately after a new merge request is created within a project. With listing potential risks in code, it also prioritizes vulnerabilities in terms of critical, high, low, medium which helps team to plan and focus on what first."
- Sr. Software Engineer, Gartner Peer Insights Review
"The Application testing feature of [GitLab] is very useful in scanning for vulnerabilities in the applications. There are multiple test[s] available. We mostly use the tools to scan the docker containers, dependencies, source code and web application for the vulnerabilities."
- Native Android Application Developer, Gartner Peer Insights Review
Sales Segment: SMB
Sales Segment: Mid-Market
The following section provides resources to help TAMs lead capabilities adoption, but can also be used for prospects or customers interested in adopting GitLab stages and categories.
There are multiple pathways to adoptiong GitLab's DevSecOps workflow, depending on the current state of the customers' current state. The following diagram shows the adoption sequence and relationship between scenarios.
This table shows the recommended use cases to adopt, links to product documentation, the respective subscription tier for the use case.
|Feature / Scenario||Free||Premium||Ultimate||Product Analytics||Notes|
|Adopt GitLab Flow||X||X||X|
|Try / Utilize Auto DevOps||Partial||Partial||X|
|Automated Testing with CI||X||X||X||Only SAST at all tiers|
|Review app||X||X||X||Needed to run DAST in CI/CD pipeline|
|Merge Request Approval Flow / Rules||X||X|
|Container Registry / Package Repo (When applicable)||X||X||X|
|SAST (Static Application Security Testing)||X||X||X||user_sast_jobs|
|DAST (Dynamic Application Security Testing)||X||user_dast_jobs|
|API Fuzzing||X||user_api_fuzzing_jobs, user_api_fuzzing_dnd_jobs on self-managed|
|Container Network Security||X||X||X||cluster_applications_cilium|
|Container Host Security||X||X||X|
|Security Alert Dashboard||X|
The table includes free/community and paid tiers associated with GitLab's self-managed and cloud offering.
The following will link to enablement and training videos and content.
GitLab offers a variety of pre-packaged and custom services for our customers and partners. The following are service offers specific to this solution. For additional services, see the full service catalog.
Sometimes customers and prospects have unique requirements, often around using an preferred scanning tool to integrating with some other part of their tool chain. If you or your customer has a third party they'd like to see integrated into GitLab, send them to the partner integration page for instructions. While GitLab can be a single platform to meet all of their needs, often they need an on-ramp to help them transition or proof of the integration before purchasing GitLab. The resources below may help. NOTE: Please do not use these to put GitLab in the position where users expect us to support a 3rdparty product integration that we do not officially recognize.
Inventory of key pages in the buyer's Journey
learning about the problem
looking for solution ideas
is this the right solution
|topic page?||solution page||proof points|
|-etc?||- product page x
- product page y
- product page z