Category Direction - Secret Detection

1. You are here:
2. GitLab Direction
3. Product Stage Direction - Secure
4. Static Analysis group priorities
5. Category Direction - Secret Detection

• Secret Detection
  • Introduction and how you can help
  • Overview
    • The problem
    • GitLab's solution
  • Strategy and Themes
  • 1 year plan
    • What is next for us
    • What we are currently working on
    • What we recently completed
    • What is Not Planned Right Now
  • Best in Class Landscape
    • Key Capabilities
    • Roadmap
    • Top Competitive Solutions
  • Target Audience
  • Pricing and Packaging
  • Analyst Landscape

Secret Detection

Stage	Secure
Maturity	Viable
Content Last Reviewed	2023-08-23

Introduction and how you can help

This direction page describes GitLab's plans for the Secret Detection category, which protects you against leaking credentials, tokens, or other secrets on GitLab.

This page is maintained by the Product Manager for Static Analysis, Connor Gilbert.

Everyone can contribute to where GitLab Secret Detection goes next, and we'd love to hear from you. The best ways to participate in the conversation are to:

• Comment or contribute to existing Secret Detection issues in the public gitlab-org/gitlab issue tracker.
• If you don't see an issue that matches, file a new issue.
  • Post a comment that says @gitlab-bot label ~"group::static analysis" ~"Category:Secret Detection" so your issue lands in our triage workflow.
• If you're a GitLab customer, discuss your needs with your account team.

Overview

GitLab Secret Detection helps you avoid a particularly dangerous type of mistake: leaking credentials or other secrets in your code repositories.

We want GitLab to be a safe place to develop software, so we're working to make Secret Detection a standard part of the software development lifecycle (SDLC). No one should have to think about secrets to be protected from leaking them.

The problem

Even experienced developers and teams can slip up and cause serious risk by committing secrets into their code repositories.

The potential damage is significant:

• Secrets often provide access to sensitive data, production systems, or cloud resources that can be abused.
• If a repository is public, automated tools or malicious users can detect and abuse leaked secrets—there are even public sites dedicated to listing these leaks.
• Even if a repository is private within a team or organization, leaked secrets can no longer be trusted to uniquely identify the authorized user(s) in a non-repudiable way.

GitLab's solution

GitLab Secret Detection helps you prevent the unintentional leak of sensitive information like authentication tokens and private keys.

Secret Detection checks your Git repositories to detect secrets or credentials, then it reports potential findings. Secret Detection jobs run in your CI/CD pipelines.

We want everyone to be secure, so:

• Parts of Secret Detection are available in every GitLab tier.
• Secret Detection is on by default in Auto DevOps.

In GitLab Ultimate, after you enable Secret Detection:

• You can see and address new Secret Detection findings in merge requests.
• Results appear in the Vulnerability Report.
• Automatic responses help mitigate leaks as soon as they occur.

Secret Detection doesn't target a specific language, so you can easily enable it in any project. Our approach takes advantage of patterns for well-identifiable credentials like service account keys and API tokens, but also searches for more generic secret types like passwords in certain contexts.

To learn more, check the Secret Detection documentation.

Outside of the Secret Detection category, GitLab also offers other features that relate to secret values:

• Push rules block files with certain names from being pushed to your repositories.
• The Secrets Management category focuses on enabling GitLab to use and manage secret values.

Strategy and Themes

We're working toward two overall goals in Secret Detection:

1. Making GitLab a safe place to develop software.
2. Helping customers achieve their security and compliance requirements in a unified DevSecOps platform.

We're specifically focusing on solving the following user problems:

1. Coverage: Protecting against credential leaks wherever they occur—in a Git repository, an issue, a job log, or anywhere else.
2. Time to Remediate: Reducing the window of time between when a secret is leaked and when it no longer poses a threat.
3. Prioritization: Knowing which leaks are the most urgent and serious, so teams can respond to those issues more quickly.

1 year plan

Our strategic one-year focus is a balance between:

1. Improving the usability of the Secret Detection product in its current architecture.
2. Delivering a platform-wide, on-by-default Secret Detection experience based on a new architecture that doesn't rely on CI/CD pipelines.

This means we plan to work on:

1. Prioritization: Adjusting severity of findings based on context.
2. Prioritization: Tracking leaks better as they move through a codebase, to avoid repeatedly surfacing the same leaks.
3. Prioritization: Speeding triage by allowing more exceptions and ruleset customization, including at the group level.
4. Time to Remediate: Adding new secret scanning partners who we notify when secrets are leaked on GitLab.com.
   • Interested potential partners can learn more in epic 4944.
5. Coverage: Designing and building a consistent, platform-wide, on-by-default experience that doesn't require users to modify their CI/CD pipelines, and protects content outside of codebases.
   • This includes aligning Minimum Viable Change (MVC) iterations in other areas, like client-side token detection or job-log token masking, toward a unified user experience.
6. Coverage: Supporting scanning before code leaves a developer's computer.
7. Prioritization: Improving the end-to-end workflow for detected secrets. This includes providing better organization-wide visibility of possible leaks and better context as leaks are detected.

Outside of these proactive priorities, we also react quickly to functional bugs and to problems with rule efficacy.

What is next for us

In the next 3 months, we are planning to:

• Add additional partners to our existing program where partners are automatically notified to protect our mutual customers.
• Improve the technical foundation of our partner integrations.
• Fix known bugs in the existing service.
• Complete technical investigations related to our forward-looking service architecture.
• Investigate, and implement if possible, a new approach to tracking detected secrets.

What we are currently working on

We are currently working on:

• Prototyping approaches to on-by-default system-wide secret detection scanning using a new architecture that doesn't require a CI/CD pipeline job.

We are also looking forward by investigating approaches to:

• Ways to better differentiate between higher- and lower-impact Secret Detection findings.
• Better tracking of Secret Detection findings as they move through the codebase.

What we recently completed

Our recent work includes:

• Completing a new benchmarking tool, then using its results to identify rules to target for false-positive reduction (16.3).
• Showing security findings in the VS Code IDE (with findings from CI/CD-pipeline-based scans) (16.3).
• Expansion of automatic response to leaked secrets:
  • Postman API (announced in 16.3)
  • Google Cloud (announced in 16.1)
• Ability to share ruleset customizations across multiple projects (16.1)
• Additional detection rules:
  • OpenAPI API keys and CircleCI access tokens (16.2)
  • Meta, Oculus, and Instagram API access tokens, and tokens for the Segment Public API (16.0)
• Updated the SECRET_DETECTION_DISABLED CI/CD variable to allow required jobs not to be overridden.
• Updated the Secret Detection analyzer to support a new JSON report format required by the GitLab security report processing system in version 16.0 and higher.

Check older release posts for our previous work in this area.

What is Not Planned Right Now

• Blocking pushes on the server side: We understand the value of preventing commits that contain secrets from even being pushed to GitLab. However, there are very tight latency requirements for any service that's in such a critical, high-traffic flow. Instead of pursuing server-side blocking now, we're:
  1. Working to improve how the system works in non-blocking mode.
  2. Working toward client-side features that provide similar protection without site reliability concerns.
• Repositories outside of GitLab: We don't plan to offer protections for projects hosted outside of GitLab.
• Credentials not common in software: We plan to focus on the types of credentials that are most common in DevSecOps workflows and in software development. This means we won't actively pursue rules that are:
  • For services unlikely to be used in a software project.
  • Closer to Data Loss Prevention, for example searching for personally identifiable information (PII) or credit card numbers.

Best in Class Landscape

ℹ️ Best In Class (BIC) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.

Key Capabilities

Secret Detection products should:

• Help developers avoid making leaks in the first place.
• Enable quick responses to any leaks that are made.
• Deliver trustworthy, accurate findings, with appropriate priority, so that the right findings are remediated quickly.
• Automatically respond to leaks, without human intervention, when possible.
• Provide security users with overall visibility into exposures anywhere within their organization.

Roadmap

The plan described above reinforces our competitive standing.

In addition to those main themes, we will likely pursue additional detection techniques including:

• Checks for whether detected credentials are still active.
• Machine Learning or other solutions for identifying generic or lower-confidence secrets. These secrets, which include passwords and tokens that don't have an identifiable structure, are more difficult to detect while minimizing false-positive results.

Top Competitive Solutions

Secret Detection is available in a variety of packaging types:

• Dedicated products like GitGuardian or TruffleHog Enterprise. These products focus on credential leaks, so they typically offer more secret-specific workflows.
• Features in SAST products like Veracode, Fortify, or Snyk. These products typically add secret detection alongside other types of features, so their workflows are more limited.
• As an integrated part of a platform like GitHub. These platforms typically offer less advanced workflows, but may offer broader always-on protection. Platforms differ in the level of scanning they offer for private repositories, the level of customization organizations can apply, and the pricing tier in which such features are available.

We analyze our product against each of these different product types because we serve customers who are accustomed to each of them. Our approach emphasizes the value of the most comprehensive DevSecOps platform by:

• Protecting the entire DevSecOps lifecycle, including code, issues, and other content.
• Shifting security earlier in the development process, so everyone can contribute to security.

Target Audience

As with many security categories, Secret Detection is a bridge between different communities:

• Security teams, who are responsible for protecting their organization from credential leaks.
  • These teams often drive the implementation of tools like Secret Detection.
  • They're also often responsible for responding to alerts and incidents related to compromised credentials.
  • User personas include Alex, the Security Operations Engineer and Sam, the Security Analyst.
• Development teams, who are responsible for building software.
  • These teams may accidentally leak credentials in the course of their work.
  • They don't want to be the source of a security breach, but they also don't want to be blocked by unreliable tooling or onerous processes.
  • User personas include Sasha, the Software Developer, and Sasha's teammates and managers.

Pricing and Packaging

Secret Detection products vary in how they're provided:

• Some are integrated features within the platforms they protect.
• Others are standalone products.
• Others are modules within other products, like SAST scanners.

GitLab packages and prices Secret Detection primarily as part of Ultimate. Basic protection features are available in all tiers. We intend to expand the level of protection available in all tiers, while still delivering unique organization-level value in Ultimate.

Analyst Landscape

Analysts usually include Secret Detection as a secondary feature of Application Security Testing (AST) coverage. See Category Direction - Static Application Security Testing (SAST) for up-to-date analyst coverage.