The page below is intended to align GitLab sales and marketing efforts with a single source of truth for our go-to-market efforts around DevSecOps.
| 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 automated security scans and compliance controls within the CI pipeline. GitLab takes this approach further by seamlessly embedding security and compliance within the DevOps platform, providing simplicity, visibility, and control.
Security pros will always be outnumbered by developers. To scale application security efforts, developers must be enabled to find and fix software security vulnerabilities on their own, while they are working on their code. In addition, while the need for compliance and auditability has always been important, these requirements have greater attention following high-profile attacks on software supply chains and the related US President's Executive Order to improve cyber security.
Application security testing is still foundational, while now visibility and control across the entire software factory is even more paramount. Think of this as DevSecOps 2.0. GitLab's platform approach to DevOps provides a clear advantage to meet these new, broader DevSecOps requirements.
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 and vulnerability reports
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.
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 built up a complex dashboard of their own and have a career invested in their favorite scanner. They are often reluctant to replace it, even if it can simplify their work as well as that of the developer.
The Security Manager or CISO (Sam's boss) is usually the buyer for the Ultimate tier
The security leader 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 work for dev and sec.
The key to winning their hearts is to focus on Simplicity and control
2021 Gartner Magic Quadrant for Application Security Testing
| Market Requirements | Description | Typical capability-enabling features | Value/ROI |
|---|---|---|---|
| Common compliance controls | Controls necessary to protect the integrity of the software development and deployment process | Role-based access, MR approvals, and many others | Simplify audit and compliance and reduce risk of noncompliance. |
| 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. |
GitLab DevSecOps use case overview
| Market Requirements | How GitLab Delivers | GitLab Category | Demos |
|---|---|---|---|
| Common compliance controls | GitLab provides many common controls throughtout the SDLC | Access and Compliance within the Manage stage |  Compliance pipelines |
| 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 Dependency scanning Container scanning License compliance Mobile SAST |
| 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, Advisory 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 |
| Differentiator | Value | Proof Point | Demos |
|---|---|---|---|
| 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 |
Simplicity/efficiency
Visibility
Control
Platform approach. With a single platform for the entire SDLC, GitLab enables simplicity of embedded security scanning along with end-to-end visibility and control not possible with point solutions. Vulnerabilities can become issues for follow up with one click. Remediation status is always evident. Changes to the code and to the cloud native environment upon which it depends is tracked. When using GitLab, no additional integration is needed between app sec and ticketing, CI/CD, etc.
Congruent with DevOps processes. Unlike traditional application security tools primarily intended for use by security pros, GitLab's security scanning is built into the CI/CD workflows where the developers live. We empower developers to identify vulnerabilities and remove them early in the development cycles. At the same time, we provide security professionals the ability to evaluate, triage, and manage vulnerabilities not resolved by the developer, across projects and groups.
Comprehensive for modern applications. GitLab Ultimate includes not only SAST, DAST, and dependency scanning (which are table stakes for any software security program), but also comprehensive scanning critical for today's cloud native applications. Scanning includes Infrastructure-as-code (IaC), APIs, containers, Kubernetes cluster images, and fuzz testing. All of these represent new attack surfaces that must be secured as part of your software supply chain.
Consistency and control. In addition to automated scans, it's important to automate policies to provide guardrails that allow developers to run fast but run safely. Common controls for compliance, along with approval rules, and compliant pipeline workflows that are centrally administered all work together to help you protect your software supply chain.
The message house for DevSecOps provides a structure to describe and discuss the value and differentiators for the use case.
See how we compare against other Security tools
How our governance compares:
Why choose GitLab free or Premium 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 and secrets detectio to Free, developers at every product tier—to scan their source code for known vulnerabilities.
Key DevSecOps features with Free/Premium:
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.
One of the first partners to integrate their scan results into the GitLab Security Dashboard and the GitLab CI pipeline is WhiteSource.
Dependency Scanning with GitLab and WhiteSource to get started.A more complete list of technology partners can be found on our security partners page.
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.
When speaking with C-levels, ask them about Governance and control challenges.
1. Finding security vulnerabilities
2. Collaboration /visibility
3. Efficiency of remediation
4. Managing Risk
5. Policy Automation
6. Tools
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
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?
GitLab customer, HERE, shares their experience with using GitLab to Shift Left and also spoke at GitLab Commit 2021.
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
SFDC report of referenceable secure customers Note: Sales team members should have access to this report. If you do not have access, reach out to the customer reference team for assistance.
The following section provides resources to help CSMs 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 | counts.merged_merge_requests_using_approval_rules | ||
| Protected Environments | X | X | |||
| Container Registry | X | X | X | container_registry_enabled | |
| Package Registry | X | X | X | counts_monthly.packages | |
| SAST (Static Application Security Testing) | X | X | X | user_sast_jobs | |
| Secret Detection | X | X | X | user_secret_detection_jobs | |
| DAST (Dynamic Application Security Testing) | X | user_dast_jobs | |||
| Container Scanning | X | user_container_scanning_jobs | |||
| Dependency Scanning | X | user_dependency_scanning_jobs | |||
| License Compliance | X | user_license_management_jobs | |||
| API Fuzzing | X | user_api_fuzzing_jobs, user_api_fuzzing_dnd_jobs on self-managed | |||
| Coverage Fuzzing | X | user_coverage_fuzzing_jobs | |||
| Security Approvals | 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 assets in the buyer's Journey