DevSecOps Practice Hub

Secret Detection

Find credentials, API keys and tokens committed to repositories, history, and CI configuration.

BeginnerSecret DetectionApplicationIdentity

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Code Static analysis, secret detection and secure coding practices.

Overview

Secret scanners use entropy heuristics and provider-specific patterns to spot credentials in code, configuration and git history. Detection is only half the practice — rotation and prevention complete it.

Why it matters

A leaked long-lived credential is directly exploitable and history rewrites rarely happen quickly. Automated detection shortens exposure time dramatically.

How it works

  1. 01Regex and entropy rules run over the diff or the full history.
  2. 02Provider-specific patterns reduce false positives for known key formats.
  3. 03Verified scanning optionally calls the provider to check if the key is live.
  4. 04Findings trigger rotation, not just removal from the branch.

Common tools

GitleaksTruffleHogdetect-secretsGitHubGitLabVault

Implementation examples

bashScan a working tree
gitleaks detect --source . --redact --report-path gitleaks.json
`--redact` keeps the secret value out of the report so the report itself is not a leak.
yamlPre-commit hook
repos:  - repo: https://github.com/gitleaks/gitleaks    rev: v8.18.0    hooks:      - id: gitleaks
Blocking at commit time is the cheapest place to stop a secret.

Security considerations

  • Assume any detected secret is compromised and rotate it, even in a private repository.

Best practices

  • Scan full history once, then scan diffs continuously.
  • Pair detection with a secrets manager so developers have a correct alternative.
  • Automate rotation runbooks per credential type.

Common mistakes

  • Deleting the commit without rotating the credential.
  • Storing scan reports containing plaintext secrets as build artefacts.

Hands-on labs