They often treat scanning as the primary control when it is really a last line of defence. Secret scanning can detect exposed values, but it cannot prevent developers, contractors, or automation from creating reusable secrets in the first place. The right design choice is to minimise the number of secrets that can be scanned at all.
Why This Matters for Security Teams
Secret scanning and push protection are valuable, but they are often misunderstood as the primary defence instead of detection and interruption layers. That mindset leaves organisations with too many long-lived secrets in code, CI/CD variables, and automation paths. NHIMG research shows 96% of organisations still store secrets outside dedicated secrets managers, while 79% have experienced leaks and 77% of those incidents caused tangible damage. Secret sprawl is the real problem, and scanning only sees the symptoms.
Security teams also overestimate how much push protection can stop in practice. It can block obvious commits, but it cannot redesign workflows that issue reusable credentials to developers, contractors, service accounts, or agents. The better control is to reduce standing secrets and prefer dynamic alternatives wherever possible. That is why guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both push teams toward prevention, governance, and continuous control rather than reactive clean-up.
In practice, many security teams discover secret exposure only after a repository, pipeline, or integration has already been abused, rather than through intentional secret-minimisation design.
How It Works in Practice
Effective design starts with reducing the number of secrets that exist at all. That means replacing static API keys and shared tokens with workload identity, short-lived credentials, and JIT issuance tied to a specific task or session. For human workflows, that may mean brokered access through PAM and RBAC. For automation, it increasingly means intent-based authorisation and ephemeral credentials that expire automatically after use. The point is not to scan harder, but to make leaked material less reusable.
This is where Guide to the Secret Sprawl Challenge is especially relevant: teams usually find that the hardest part is inventory and ownership, not tooling. NHIMG analysis also shows that 30.9% of organisations still store long-term credentials directly in code, which explains why push protection becomes a recurring firefight rather than a true control. A practical workflow usually includes:
- Issuing dynamic secret per workload, per deployment, or per session rather than embedding reusable values.
- Treating push protection as a guardrail, not a substitute for secret lifecycle management.
- Using scanning to find residual exposure in code, tickets, logs, and CI/CD output.
- Rotating and revoking exposed credentials immediately, then removing the path that created them.
That operating model aligns with modern guidance in the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the NIST Cybersecurity Framework 2.0, which both emphasise continuous protection and identity-aware control. These controls tend to break down when legacy applications require hard-coded credentials and cannot support token exchange or short-lived identity flows.
Common Variations and Edge Cases
Tighter secret controls often increase implementation overhead, requiring organisations to balance reduced exposure against developer friction and legacy compatibility. That tradeoff is real, especially in estates with older scripts, vendor integrations, or batch jobs that were never built for ephemeral credentials. Current guidance suggests preserving push protection as a safety net while migrating the most sensitive paths first, rather than attempting a big-bang removal of every static secret.
There is no universal standard for when push protection alone is enough, because the answer depends on whether the secret is human-issued, machine-issued, or embedded in an automated delivery chain. The risk rises sharply in environments with high release frequency, third-party tooling, and broad CI/CD access, which is why NHIMG case studies such as Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign matter. They show how quickly secrets propagate once they are available to automation.
In higher-risk environments, teams should also review whether a detected secret is actually the best indicator of exposure. Sometimes the larger issue is over-privileged access, poor rotation, or vendor connectivity that should never have existed in the first place. For that reason, secret scanning should feed into incident response, identity governance, and pipeline hardening, not sit apart as a standalone hygiene task.
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 address the attack and risk surface, while NIST CSF 2.0 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 | Secret rotation and lifecycle gaps are central to preventing reusable exposure. |
| NIST CSF 2.0 | PR.AC-1 | Access control should limit where secrets exist and who can use them. |
| NIST AI RMF | AI RMF helps govern autonomous workloads that should not rely on static secrets. |
Define governance for workload identity and runtime authorisation before enabling automation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
