Secret scanning tools expose a deeper NHI governance gap

At a glance

What this is: This is an analysis of secret scanning tools and their limits, showing that detection alone does not fix the standing privilege and NHI governance problems that make leaked credentials dangerous.

Why it matters: It matters because IAM, PAM, and NHI programmes need to treat secret discovery as only one control layer, not the control strategy itself, especially where service accounts and workload credentials carry durable access.

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, many of which are tied to long-lived secrets that are difficult to manage.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Apono's analysis of secret scanning tools and NHI risk

Context

Secret scanning is the practice of finding exposed credentials in code, pipelines, infrastructure files, containers, and logs before they are abused. The governance gap is that discovery does not change the access a leaked secret can already exercise, which is why NHI control and least-privilege design remain central to the problem.

For identity teams, this is not just a developer hygiene issue. Secret exposure becomes an IAM, PAM, and NHI risk the moment a credential maps to standing permissions, third-party access, or a workload identity that can still authenticate after the leak is found.

Key questions

Q: How should security teams handle leaked secrets in cloud and CI/CD environments?

A: They should treat every leaked secret as a live access decision, not just a detection event. The priority is to identify what the credential can reach, revoke or rotate it automatically where possible, and reduce the standing privileges attached to the underlying identity. Secret scanning is useful only when it is paired with rapid containment and access scope reduction.

Q: Why do service accounts with standing privilege increase breach risk?

A: Because a leaked secret tied to standing privilege remains usable long after discovery. In practice, that means an attacker can authenticate as the workload or integration and move through trusted systems without breaking authentication. The longer the access lasts and the broader the scope, the more likely a credential leak becomes a real incident.

Q: What breaks when secret scanning is used without automated revocation?

A: The control chain breaks at containment. You may find the credential quickly, but if it remains valid, the attacker still has a usable path into the environment. That is why detection without revocation only shortens the time to awareness, not the time to exposure.

Q: Who should own leaked credential response in an identity programme?

A: Ownership should sit across IAM, PAM, and NHI governance, because the same secret can be a code problem, a privilege problem, and a lifecycle problem at once. Security teams need a shared process for triage, revocation, rotation, and review so that no team assumes another one has already closed the exposure.

Technical breakdown

Why secret scanning is detection, not access control

Secret scanners inspect repositories, build artefacts, images, and logs for patterns that look like credentials, then raise alerts or remediation workflows. They are valuable because they shorten discovery time, but they do not change the entitlement model behind the secret. If the token, key, or certificate still works, the organisation is relying on speed of detection instead of reducing the authority attached to the credential. That is why scanning belongs in secrets management, but cannot replace it.

Practical implication: treat scanner findings as triggers for revocation, not as a substitute for access governance.

Standing privilege turns leaked secrets into usable attack paths

A secret becomes materially dangerous when it is tied to persistent permissions. Standing privilege means the credential can be used repeatedly without reauthorisation, so a leak creates a durable access path into cloud resources, CI/CD systems, or data stores. In NHI environments, the problem is compounded by service accounts and workload identities that are rarely reviewed with the same discipline as human accounts. The result is a credential that is both valid and overpowered.

Practical implication: right-size secret scope before leakage occurs, especially for service accounts and pipeline identities.

JIT access changes the value of exposed credentials

Just-in-Time access reduces the period during which a credential can be used, and Just Enough Privilege narrows what it can do. In practical terms, this shifts the control objective from finding every secret to ensuring that any secret in circulation has minimal blast radius. For cloud and data access, that usually means short-lived access brokering, automatic revocation, and policy-based approval rather than permanent keys embedded in applications or pipelines.

Practical implication: pair secret scanning with time-bound access so exposed credentials do not remain high-value assets.

Threat narrative

Attacker objective: The attacker wants authenticated access that looks legitimate to the target system, so they can operate inside trusted workflows instead of breaking in noisily.

1. Entry begins when an attacker finds an exposed API key, token, or password in source code, CI/CD artefacts, logs, or cloud configuration.
2. Escalation occurs when that credential still has standing privilege and can be used to authenticate directly into cloud, data, or build systems.
3. Impact follows as the attacker reuses valid access to read data, alter pipelines, or move into higher-value workloads without needing to bypass authentication controls.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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 has become a visibility control, not a governance answer. The tool class is useful because it surfaces exposed credentials across code, pipelines, and cloud resources before attackers use them. But the field keeps overstating what detection can do: it identifies a problem after the credential already exists in the wrong place. The practitioner conclusion is that scanning must sit inside a broader identity control model, not be treated as the model itself.

Standing privilege is the failure mode that turns leaked secrets into breaches. A secret that maps to persistent access is not just exposed, it is operationally live. That is why the most dangerous credential is often the one attached to an NHI that was never right-sized, reviewed, or bounded by time. The implication is that teams must stop measuring success by the number of secrets found and start measuring how much authority each secret can still exercise.

Ephemeral credential trust debt: modern pipelines accumulate trust assumptions faster than they retire them. Secret scanning exposes the symptom, but the underlying debt is a design that allows long-lived credentials to survive across repos, runners, and workloads. Practitioners should read every leak as evidence that the trust model is out of sync with delivery velocity, especially where NHIs are reused across environments.

JIT access is the control that changes the economics of a leak. When access is time-bound and context-bound, a stolen secret loses most of its value quickly. That is why secret scanning and JIT are complementary, not competing, controls. The governance lesson is to treat exposure reduction and blast-radius reduction as a single programme rather than two separate initiatives.

IAM, PAM, and NHI teams now share the same risk surface. A leaked service account key, a cloud access token, and an overprivileged automation credential all create the same business problem: unauthorised work can begin inside trusted systems. The practical conclusion is that these teams need shared ownership of detection, rotation, revocation, and access review workflows.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Guide to the Secret Sprawl Challenge shows why discovery without lifecycle control leaves the exposure window open.

What this signals

Secret scanning will keep expanding, but programme maturity will be judged by what happens after a leak is found. Teams that can only report exposed credentials will not be seen as having strong control posture. The next maturity step is tying detection into revocation, short-lived access, and lifecycle review so leaked secrets lose value before they can be reused.

Machine identity growth is forcing IAM and PAM teams to converge on the same operational model. As more workloads and integrations rely on long-lived secrets, the boundary between secret management and access governance disappears. Practitioners should expect audit pressure to shift from whether leaks are detected to whether access can be bounded and automatically removed when exposure occurs.

Secret sprawl creates trust debt faster than manual governance can repay it. That is why the operational question is no longer how many secrets exist, but how many of them still have standing authority. Teams should anchor their response in the OWASP Non-Human Identity Top 10 and the identity lifecycle controls that limit reuse across systems.

For practitioners

• Inventory every secret-bearing identity Map which service accounts, tokens, API keys, and certificates can still authenticate after a leak. Prioritise identities that can reach production data, build systems, or cloud control planes.
• Bind scanner alerts to automatic revocation Connect detection workflows to secrets managers, cloud IAM, and pipeline automation so high-confidence leaks trigger revocation or rotation without waiting for manual triage.
• Remove standing privilege from machine identities Replace persistent permissions with short-lived access for workloads, CI/CD runners, and integrations. Where the credential must exist, narrow scope to the minimum resource set and usage window.
• Review exposed secrets by blast radius first Triage leaked credentials based on what they can reach, not just whether they are syntactically valid. The fastest way to reduce risk is to fix the identities that can touch production systems or cross trust boundaries.

Key takeaways

• Secret scanners are necessary, but they only find exposed credentials after the trust model has already failed.
• Leaked machine credentials remain dangerous when they retain standing privilege, which is why revocation and scope reduction matter as much as detection.
• The strongest response is a combined secrets and identity programme that shortens credential life and constrains what every NHI can do.

Key terms

• Secret Scanning: Secret scanning is the automated detection of exposed credentials in code, pipelines, logs, and cloud artefacts. It finds API keys, tokens, passwords, and certificates that should not be present, but it does not by itself reduce the authority those secrets still carry if they remain valid.
• Standing Privilege: Standing privilege is access that remains continuously available without needing a fresh approval or time limit. In NHI environments, it makes leaked secrets far more dangerous because the credential can keep authenticating until someone manually revokes it or the system removes the entitlement.
• Just-In-Time Access: Just-In-Time access grants permissions only for the period needed to complete a task. For machine and human identities alike, it reduces the usefulness of stolen credentials by shrinking the window in which access exists and by limiting the scope of what the identity can do.
• Non-Human Identity: A non-human identity is any machine- or workload-based identity used by software instead of a person. That includes service accounts, API keys, tokens, certificates, and automation accounts, and it becomes a governance issue whenever those identities can authenticate with persistent authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Apono: Top 7 Secret Scanning Tools for 2026. Read the original.