How do I implement secrets scanning in a CI/CD pipeline?

Why This Matters for Security Teams

Secrets scanning is not just a code hygiene task. It is a control for preventing credential reuse after exposure, because a leaked token often becomes an attacker’s easiest path into CI, cloud, source control, and downstream SaaS. GitGuardian’s The State of Secrets Sprawl 2026 found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation leaves organisations exposed. That is also why the OWASP guidance in OWASP Non-Human Identity Top 10 treats secret handling as an identity problem, not just a scanning problem.

For CI/CD, the real risk is speed. A developer can commit a secret, a pull request can reuse it, and an automated runner can exfiltrate it before a human reviewer notices. The blast radius grows further when build logs, artifacts, and environment variables preserve the secret after the original file is fixed. That is why mature programmes combine prevention at the workstation, enforcement in the pipeline, and historical repository sweeps with mandatory revocation and ticketed remediation. In practice, many security teams encounter leaked credentials only after an incident response call, rather than through intentional discovery.

How It Works in Practice

A practical secrets scanning programme starts with three controls that reinforce each other. First, pre-commit hooks catch obvious mistakes before code ever leaves a workstation. Second, CI/CD gates scan every pull request and commit, then block merges when a high-confidence secret is detected. Third, repository-wide scanning searches current branches, tags, and commit history so older exposed credentials are not left behind in dormant paths.

The implementation detail that matters most is enforcement. Scanners should alert and fail builds on confirmed secrets, while allowing only tightly controlled exceptions for false positives. Pair that with secret classification so the pipeline knows whether it found an API key, certificate, OAuth token, or cloud access key, because remediation urgency can differ. If the secret is real, treat it as compromised immediately: revoke it, rotate dependencies, inspect logs for use, and re-scan downstream systems that may have copied it.

For higher-value pipelines, combine scanning with runtime protections such as masked variables, short-lived credentials, and restricted runner permissions. This matters because build infrastructure itself is frequently targeted; NHIMG’s CI/CD pipeline exploitation case study shows how attacker access to pipeline components can turn a single secret into broader compromise. The OWASP model and NHIMG’s Reviewdog GitHub Action supply chain attack both underscore the same point: secret scanning only works when the pipeline is allowed to stop the release. These controls tend to break down in monorepos with noisy legacy history because false positives, large diffs, and unreviewed tooling changes can overwhelm the gate.

Common Variations and Edge Cases

Tighter secrets scanning often increases developer friction, requiring organisations to balance fast delivery against noisy enforcement. The strongest programmes therefore tune severity thresholds, separate low-confidence findings from confirmed credentials, and create an exception path that still mandates review. Current guidance suggests that exceptions should be time-bound and visibly owned, not left as permanent suppressions.

Legacy repositories are the hardest edge case. Historical branches, archived projects, and vendor-managed code may contain secrets that are no longer in active use but remain valid. In those environments, repository scanning should be paired with aggressive secret rotation, because scanning alone does not remove exposure. Another common blind spot is non-code collaboration tooling: incident data from the same research shows that secrets also appear in chat, tickets, and documentation, so pipeline scanning should be part of a wider discovery strategy rather than a standalone control.

For teams using generated code, bots, or AI-assisted commits, review expectations need to change. Automated contributors can leak secrets at different rates than human authors, so best practice is evolving toward stricter pre-merge checks and shorter-lived credentials for automation. The important operational rule is simple: if the pipeline finds a secret, assume the credential has already escaped the repository boundary and act on that assumption immediately.

Related resources from NHI Mgmt Group

• What is workload identity federation and why is it important for CI/CD security?
• What is secrets sprawl and why does it create security risk?
• What is a secrets vault and which tools are available?
• How do I find hardcoded secrets in my codebase?