PS Product SecurityKnowledge Base

🚦 Secret Scanning in Quality Gates

Intro: Secret scanning should not be a side report that nobody reads. It should participate in the same release decision logic as SAST, SCA, DAST, and policy checks.

What this page includes

  • how to turn secret scanning into a gate
  • example gate thresholds
  • sample GitLab aggregation pattern
  • director-level metrics to track

Gate design principles

A useful secret gate is:

  • strict on verified or obviously real findings;
  • tunable on low-confidence findings;
  • fast enough to run on every merge request;
  • paired with a response process so developers know what to do next.
Signal Suggested policy
Verified secret fail immediately
High-confidence cloud credential fail immediately
New secret in modified line fail merge request
Historic secret during onboarding warn and create remediation ticket
Known false positive with approved allowlist pass but keep logged
Old finding reopened fail after grace window

Example GitLab gate aggregation stage

security_gate:
  stage: verify
  image: python:3.12-alpine
  needs:
    - job: gitleaks_scan
      artifacts: true
    - job: trufflehog_scan
      artifacts: true
  script:
    - python snippets/secrets/secret-gate-aggregate.py
  allow_failure: false

Example aggregation logic

The aggregation script should:

  1. load JSON artifacts from Gitleaks and TruffleHog;
  2. count verified findings and untriaged findings;
  3. optionally map detector types to business severity;
  4. exit non-zero when blocking thresholds are exceeded.

See secret-gate-aggregate.py.

Metrics that belong on the dashboard

  • repositories with secret scanning enabled;
  • median time to revocation;
  • number of verified secret leaks per quarter;
  • repeat leaks by team or service;
  • mean time from finding to merge-fix;
  • ratio of false positives to real findings.

Footer