Because scanning only finds exposure after the fact, while the underlying creation habits remain in place. Developers paste values into code, configs, chats, and pipeline files when workflows make that path easy. Real reduction comes from guardrails, validation, and automated remediation across the whole delivery chain.
Why Secrets Keep Reappearing After Leak Scans
Leak scanning is useful, but it is fundamentally reactive. It detects exposure after a secret has already been written somewhere that should not contain it, which means the real problem is upstream in how values are created, shared, and deployed. The pattern is familiar in NHIMG research such as the Guide to the Secret Sprawl Challenge: developers and operators keep using the fastest path available, even when it is unsafe. Once that habit exists, scanners become a backstop rather than a control.
This is why the issue persists even in mature environments. Secrets are copied into code, CI logs, chat tools, ticket comments, and pipeline files because delivery systems still tolerate those behaviours. GitGuardian reported that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without revocation leaves organisations exposed. OWASP’s Non-Human Identity Top 10 treats credential lifecycle failures as a core issue, not a side effect. In practice, many security teams discover that leaks are recurring only after an attacker, a build log, or a public commit has already made the secret operationally useful.
How Leakage Repeats Across the Delivery Chain
Secrets keep resurfacing because multiple systems encourage them to move. Developers often need credentials to test locally, automate builds, or call upstream APIs, and each handoff increases the chance of persistence. Current best practice is to reduce the number of places a secret can exist, then shorten its lifetime wherever it must exist. That means using Ultimate Guide to NHIs — Static vs Dynamic Secrets as a design reference for replacing long-lived values with ephemeral alternatives, and pairing that with request-time controls.
Operationally, the most effective programs combine three layers:
- Prevention: secrets are blocked from entering source, tickets, and chat through validation and developer tooling.
- Containment: CI/CD runners, build agents, and deployment jobs receive short-lived credentials just for the task they perform.
- Response: exposed values are revoked automatically, not queued for manual cleanup hours later.
This is where the difference between a scan and a control becomes obvious. Scanning finds the symptom; guardrails change the workflow that creates the symptom. The 2024 State of secrets management Survey from Akeyless found that only 44% of organisations use a dedicated secrets management system, which helps explain why ad hoc handling still dominates. NIST guidance on digital identity and zero trust also points toward shorter-lived, context-aware access rather than standing credentials. These controls tend to break down when legacy pipelines require shared service accounts, because one static secret often supports too many jobs to rotate safely.
Where the Standard Answer Breaks Down
Tighter secrets controls often increase operational overhead, requiring organisations to balance stronger containment against developer friction and release speed. That tradeoff matters because some environments do not fit clean rotation patterns. Long-running batch jobs, shared integration environments, and third-party services with weak token support can make full automation difficult, so current guidance suggests prioritising the highest-risk paths first rather than demanding perfection everywhere.
The main edge case is that not every “secret” should be handled the same way. API keys, certificates, OAuth tokens, and NHI credentials all have different rotation and revocation behaviour, so one universal policy is rarely enough. AI-assisted development also changes the exposure profile. NHIMG research on the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign shows that secrets exposure often starts in automation and supply-chain tooling, not just in repositories. The practical takeaway is that leak scanners should be treated as detection support, while the real fix is policy, automation, and revocation across the full delivery path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret lifecycle weakness that causes repeated exposure and reuse. |
| NIST CSF 2.0 | PR.AC-1 | Least-privilege access limits where secrets can spread and persist. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust reduces reliance on long-lived secrets and implicit trust paths. |
| NIST AI RMF | GOVERN | Governance is needed to assign accountability for secret handling failures. |
| OWASP Agentic AI Top 10 | A01 | Agentic systems amplify secret leakage through tool use and autonomous actions. |
Replace standing secrets with short-lived credentials and enforce automated rotation and revocation.
Related resources from NHI Mgmt Group
- Should organisations scan Docker images for secrets if they already secure the source code?
- Why do access risks keep reappearing even when organisations have a risk plan?
- When should organisations prioritise Zero Standing Privilege for non-human identities?
- Why do secrets create disproportionate risk in NHI environments?
