TL;DR: Secret scanning tools help teams find exposed API keys, tokens, and passwords across code, CI/CD, and cloud systems, but they only reduce exposure after the leak occurs, according to Apono. The deeper problem is that standing privileges and unmanaged NHIs turn a discovered secret into a live access path, so detection must be paired with time-bound authorization.
At a glance
What this is: This article argues that secret scanning is useful for finding exposed credentials, but it does not address the standing privileges and unmanaged NHI conditions that make those secrets exploitable.
Why it matters: For IAM, PAM, and NHI teams, the message is that secret discovery must be paired with time-bound authorization and offboarding controls, or leaked credentials remain usable.
By the numbers:
- In 2024, abuse of valid account credentials was the initial access vector in roughly 30% of incidents investigated.
- Machine identities now outnumber humans by more than 80 to 1.
Context
Secret scanning is the practice of detecting exposed credentials in code, configuration, CI/CD, and cloud-adjacent systems before those secrets are abused. The governance gap is that discovery happens after a credential has already been created, stored, or committed in a place it should never have been.
For NHI programmes, the harder problem is not only locating secrets but controlling what those secrets can do if they leak. Standing privilege, long-lived tokens, and unmanaged service accounts make secret exposure a live access problem rather than a simple detection problem.
This article treats secret scanning as a visibility layer, not a complete control plane. That is the right starting position because the teams most exposed are usually the ones with the widest machine identity sprawl and the weakest lifecycle controls.
Key questions
Q: What breaks when secret scanning is the only control in place?
A: Scanning breaks down when teams assume finding a secret is the same as neutralising the access it grants. A discovered key can still authenticate a service account, workload, or integration with standing privilege. The practical failure is not detection. It is that the underlying identity remains active, so exposure still equals usable access.
Q: Why do leaked API keys and tokens create such a large security risk?
A: They authenticate actions directly, so anyone who finds them can act as a trusted caller. If the secret is long-lived or broadly scoped, the attacker gains standing access that may bypass normal user controls, making the leak a privilege and identity problem as much as a data exposure issue.
Q: How do security teams measure whether secret scanning is actually reducing exposure?
A: Security teams should measure the time from secret creation to detection, the percentage of repositories and build artifacts scanned, and the time from detection to rotation or revocation. Strong programmes also track how many exposed secrets remain valid after discovery. Those signals show whether scanning is finding risk early or only after exposure has spread.
Q: What should teams do first after discovering that a CI pipeline may have exposed secrets?
A: The first response is to revoke and reissue any credentials, tokens, or keys that may have been exposed in the affected CI process. Teams should also verify the authenticity of build scripts and review repositories, docker images, and pipeline logs for hard coded secrets. Rapid secret rotation reduces the window for reuse while investigation continues.
Technical breakdown
Why secret scanning is only a detection layer
Secret scanning tools search repositories, build artefacts, logs, containers, and cloud stores for exposed credentials such as API keys, tokens, passwords, and connection strings. That is valuable because it shortens the time between exposure and discovery, but it does not prevent the leak or revoke the credential by itself. The control is reactive: it tells you where a secret lives and whether it has been committed or surfaced in the wrong place. In practice, that means scanning must be treated as an early-warning signal rather than as a governance control for access scope or credential lifecycle.
Practical implication: Use scanning to detect exposure, but do not mistake detection for permission control or secret lifecycle management.
How standing privileges turn leaks into usable access
A leaked secret becomes dangerous when it is tied to standing privilege. If the credential authenticates a service account, workload, or API integration with broad rights, the attacker inherits those rights immediately after use. This is why secret scanning and access governance solve different problems: the scanner finds the secret, while the authorisation model determines blast radius. Without just-in-time access and short-lived permissions, even a quickly discovered secret can remain valid long enough to support lateral movement, data access, or pipeline abuse.
Practical implication: Tie every exposed credential to its effective permissions so you can reduce blast radius before revocation is complete.
Why unmanaged NHIs create persistent secret sprawl
Non-human identities often accumulate across development pipelines, cloud resources, and integration layers faster than teams can inventory them. When those identities are not owned, offboarded, or recertified, secrets remain active long after the business need changes. That creates a structural mismatch between discovery and governance: scanning reveals the symptom, but unmanaged NHI lifecycle is the root cause. Long-lived keys, orphaned service accounts, and ad hoc integrations are what make secret sprawl persistent rather than episodic.
Practical implication: Map each leaked secret back to an owned NHI lifecycle so unowned credentials cannot persist indefinitely.
Threat narrative
Attacker objective: The objective is to turn a leaked secret into authenticated access that preserves the original account's permissions and access scope.
- Entry occurs when a credential is exposed in a repository, CI/CD pipeline, configuration file, or cloud store and is then discovered by an attacker or abuse workflow.
- Credential abuse follows when the exposed secret is used to authenticate as the underlying service account, token, or API client with its existing permissions.
- Impact emerges when those permissions allow cloud access, pipeline manipulation, data retrieval, or further movement through trusted integrations.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secret scanning is not a governance control, it is an exposure detector. The article is right to position scanners as a way to find credentials in code, CI/CD, and cloud systems before abuse. But the deeper identity problem is that the scanner only tells you the secret exists. It does not change the permissions behind the secret, and it does not retire the identity that owns it. Practitioners should treat scanning as the first half of a control, not the control itself.
Standing privilege is the real blast-radius multiplier. A leaked API key or token matters most when it maps to an identity that can still do meaningful work. That is why the article's core point is stronger than a simple secrets hygiene message. The governance lesson is that secret discovery must be paired with time-bound authorization, otherwise exposure remains operational access. For NHI teams, the decisive question is not just where secrets are found, but how much authority they carry when found.
Unmanaged NHI lifecycle is the root cause behind recurring secret sprawl. Secrets do not keep appearing in the wrong places by accident alone; they persist because service accounts, integrations, and workload credentials are created faster than they are owned and retired. This is the same lifecycle failure pattern that drives other NHI governance gaps. If the account behind the secret is not inventoried, recertified, and offboarded, scanning only documents the symptom while the access path stays alive.
Ephemeral credential trust debt: the article exposes a pattern where teams rely on secret discovery after the fact while leaving long-lived trust relationships intact. That debt accumulates whenever credentials are easier to issue than to constrain, and it is paid when exposed secrets remain usable long enough to matter. Practitioners should read this as a warning that visibility without lifecycle enforcement merely delays the breach window.
Detection without entitlement reduction is an incomplete security model. The article shows why organizations can have mature scanning workflows and still carry excessive risk. When the same identity can be re-used, overprivileged, or left active across systems, exposure turns into repeatable access. The practical conclusion is that NHI governance must measure the authority attached to a secret, not just the presence of the secret itself.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Secret scanning becomes materially more useful when it is treated as an input to entitlement reduction rather than as a stand-alone detective control. Teams that stop at finding exposed credentials still leave the underlying trust relationship intact, which means the same leak can remain exploitable until the identity itself is constrained or retired.
Machine identity sprawl is what turns credential leakage into a recurring programme problem. The Apono article's central lesson is that the volume of non-human access has outgrown manual lifecycle management, so governance now has to track ownership, scope, and expiry across pipelines, workloads, and cloud resources.
Access blast radius is the right design lens for secret governance. If a leaked credential still grants broad production reach, the organisation has not solved the real problem. Scanning, just-in-time access, and least privilege have to be coordinated as one control pattern, not three separate initiatives.
For practitioners
- Separate detection from revocation Route every high-confidence secret finding into a revoke-and-rotate workflow so discovery is immediately followed by credential invalidation and replacement.
- Inventory the identity behind each secret Require ownership, system context, and effective permissions for every service account, token, or API key so leaked secrets can be traced to a named NHI lifecycle.
- Convert standing access to time-bound access Replace always-on permissions with just-in-time and least-privilege access so a leaked credential cannot retain broad operational reach after exposure.
- Scan the places secrets actually drift to Include CI/CD variables, build artefacts, IaC templates, logs, and cloud stores in the scanning scope because those are the places exposed credentials often persist.
Key takeaways
- Secret scanning finds exposed credentials, but it does not by itself remove the permissions those credentials unlock.
- The article links secret leakage to standing privilege and unmanaged non-human identities as the underlying governance failure.
- The effective control is to pair discovery with revoke, rotate, and time-bound authorisation so leaked secrets stop being usable.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on exposed API keys, tokens, and passwords found in code and pipelines. |
| NHI-05 — Overprivileged NHI | The article argues leaked secrets remain dangerous because the underlying identities carry excessive permissions. | |
| NHI-07 — Long-Lived Secrets | The piece repeatedly ties risk to long-lived keys and tokens that persist after exposure. | |
| Recommendation — Scan for exposed NHI secrets and revoke any credential that appears outside approved storage. Reduce NHI entitlement scope so leaked credentials cannot grant broad operational access. Replace long-lived secrets with short-lived credentials and enforce expiry by default. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly covers the lifecycle of authenticators, including rotation and revocation. |
| Recommendation — Apply IA-5 to enforce rotation, revocation, and managed lifecycle for machine credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's core risk is the access that remains after a secret leaks, not just the leak itself. |
| Recommendation — Align leaked-secret response to PR.AA-05 by revalidating entitlements and removing excess access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets enable credential access and can then support movement across connected systems. |
| Recommendation — Map secret-leak findings to credential-access and lateral-movement tactics in detections and response. | ||
Key terms
- Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Non-Human Identity Lifecycle: The Non-Human Identity Lifecycle is the full sequence of creation, use, control, review, and retirement for identities that are not tied to a person. It covers service accounts, API keys, certificates, tokens, bots, and AI agents, including issuance, rotation, monitoring, revocation, and secure decommissioning across systems and environments.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org