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

Usecase: DevSecOps

Who to contact

Product Marketing Technical Marketing
Cindy Blake ( @cblake ) Fernando Diaz ( @fjdiaz )

The Market Viewpoint

DevSecOps

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.

Why is DevSecOps needed?

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.

Desired business outcomes

Personas

User Personas

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.

Buyer Personas

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

Industry Analyst Coverage

2021 Gartner Magic Quadrant for Application Security Testing

Market Requirements (in priority order)

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.

The GitLab Solution

How GitLab Meets the Market Requirements

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 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 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 SAST and Secret Detection
Dependency scanning Dependency scanning
Container scanning Container scanning
License compliance License compliance
Mobile SAST 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 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 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 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 Using GitLab Application Security Capabilities with Jenkins
Creating Jira issues from GitLab vulns Creating Jira issues from GitLab vulns

Top Differentiators

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 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 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 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 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 Running GitLab Security Scans in Limited Connectivity and Offline Environments

How the GitLab DevOps platform helps achieve DevSecOps

Simplicity/efficiency

Visibility

Control

What Are The GitLab Advantages?

Platform approach. With a single platform for the entire SDLC, governance is greatly simplified and it is more effective.

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. At the same time, we provide 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. Findings are interactive and actionable, 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. Issues are created with one click. 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.

Message House

The message house for DevSecOps provides a structure to describe and discuss the value and differentiators for the use case.

Competitive Comparison

See how we compare against other Security tools

How our governance compares:

  1. Role-based access control (RBAC) for separation of duties. Competitive products's roles are broader and when a person changes roles, his/her permissions must be changed manually. Why is this important? If someone has access to push to prod and is demoted or moves to another group, you'd want the permissions to change automatically to avoid insider threats.
  2. Our workflows include compliance within MR approvals. No manual checks that impact velocity. (In essence, we shift left compliance also.)
  3. External status checks is an important feature for regulated industries. Changes are approved and must be pushed to production within a given timeframe. Delays can cause the approval process to start over.
  4. With GitLab we have projects and groups where projects inherit policies from the group. Competitors cannot structure policies as flexibly as GitLab, an important feature for enterprise users. Examples include group level runners.
  5. Compliant pipelines allow GitLab users to select their compliance framework (e.g. PCI, HIPPA, etc) and those policies are used - and the developer cannot disable it (due to RBAC)

Key Value by tier

Free and Premium

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:

Ultimate

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:

Technology Partnerships

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.

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.

Selling the DevSecOps Solution

Customer Facing Slides

Discovery Questions

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 - Can your security scans keep up with your iterative coding velocity? How often are projects stopped waiting for a security scan?
  2. Collaboration /visibility - Is there friction between dev and sec? Can you see security risks at any point in the SDLC?
  3. Remediation - How much time is wasted translating what was found by sec to what needs to be done by dev and tracking if it was done? Can you quickly see the status of security remediations?
  4. Managing Risk in a DevOps environment - What percentage of code are you currently scanning? Are there holes where an attacker could more easily enter and then traverse laterally? How much more would it cost you to scan all of your code?
  5. Policy Automation - Are Security policies automated with security requirements built into the development process? Or are most projects secured a bit differently every time?
  6. Tools - Is your organization investing to improve application security in the short term or long term? Is there a clearly defined strategy or timeline? Are you working to integrate app sec tools into the DevOps tool chain?

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

Potential Objections

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?

Proof Points - customers

Quotes and reviews

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

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."

"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."

G2

G2 Grid® for Static Application Security Testing (SAST) Software
G2 Grid® for Dynamic Application Security Testing (DAST) Software

Customer Case Studies

HackerOne

Glympse

BI Worldwide

Chorus

References to help you close

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.

Adoption Guide

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.

Playbook Steps

Adoption Recommendation

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.

Secure Adoption path

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    
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.

Enablement and Training

The following will link to enablement and training videos and content.

Professional Service Offers

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.

Resources

White paper

eBook: Ten Steps Every CISO Should Take to Secure Next-gen Applications

Integration with third party commercial scanners

Blogs

Other DevSecOps Videos

Clickthrough & Live Demos

Roadmap

Technical Resources for Solution Architects

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.

Buyer's Journey

Inventory of key assets in the buyer's Journey

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license