Validity Checks for Secret Detection findings

Summary

Verify the validity and liveness of Secret Detection findings by programmatically checking them against their issuing services. This enables security teams to prioritize remediation of active secrets over revoked or inactive credentials.

See the Verify validity/liveness of Secret Detection findings epic for more details.

Motivation

Goals

What is it trying to achieve?

• Provide token validity status of detected GitLab and partner tokens to Ultimate customers

How will we know that this has succeeded?

• Security teams will spend less time remediating inactive credentials

What are other less tangible opportunities here?

Non-Goals

What is out of scope for this blueprint?

• Cross Scanner Integration (extend to DAST)
• Extending support to other target types

Proposal

We will automate the verification process for tokens discovered during security scans. This feature will:

• Verify token status (Active, Inactive, Unknown) and display results on vulnerability pages
• Enable sorting and filtering findings by token status
• Support GitLab and partner platform tokens
• Work for cloud and self-managed/air-gapped instances
• Include telemetry to measure usage and effectiveness

Customers can opt in using Security Configurations. Once enabled, discovered tokens will be automatically verified against issuing services, with status information displayed in the Vulnerability details page and Security Dashboard, allowing security teams to prioritize remediation of active credentials.

Decisions

• 001: Use Sidekiq worker approach for token status checking
• 002: Use REST over gRPC for SDRS communication

Challenges

• Authentication to Secret Detection Response Service (SDRS): Secure authentication mechanism needed for token status requests to SDRS
• Refresh endpoint abuse protection: Manual token status refresh functionality must be protected against malicious or excessive usage
• Feature-level abuse prevention: Overall validity checks feature requires safeguards to prevent abuse, particularly around partner token status checking volume and frequency

Design and implementation details

The validity checks capability relies on a three-phase rollout: Experiment, Beta, and GA. Each phase builds upon the previous to deliver a comprehensive token status checking experience.

Experiment Phase - GitLab Token Status Display

The experiment phase focuses on GitLab tokens only and implements token status checking using a Sidekiq worker approach. When a Secret Detection scan is executed and its report is ingested, a Sidekiq worker will be triggered automatically. This worker will:

• Process all GitLab tokens discovered during the scan
• Check each token’s current status in the Database
• Assign one of three status values to the corresponding vulnerability finding:
  • Unknown: Status check could not be completed
  • Active: Token is currently active
  • Inactive: Token is no longer active

sequenceDiagram
    participant SD as Pipeline SD Scan
    participant RW as Report Ingestion Worker
    participant TW as Token Status Worker
    participant DB as Database
    Note over SD: gl-secret-detection-report.json
    SD->>RW: Trigger report ingestion
    RW->>TW: Trigger token status check
    TW->>DB: Query token status in Database
    DB-->>TW: Return status
    TW->>DB: Update finding in Database

Beta Phase - Enhanced User Experience and Controls

The Beta phase focuses on improving user experience and providing customer controls for the validity checks feature.

GA Phase - Partner Integration

The GA phase expands token status verification to include partner platform tokens, providing comprehensive visibility across GitLab and partner services.

View page source - Edit this page - please contribute.