Credentials as attack paths: why patching alone is not enough

At a glance

What this is: This briefing argues that credentials turn access into attack paths and that exposed secrets remain dangerous long after the original vulnerability is closed.

Why it matters: It matters because IAM, IGA, and PAM programmes have to govern both human and non-human credentials as live attack surface, not static configuration.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read GitGuardian's briefing on why patching alone will not solve credential exposure

Context

Credentials are not just authentication material. In practice, they become reusable access paths whenever they are copied into code, shared across repositories, surfaced in AI coding assistants, or left valid after the original issue is fixed. That makes secret hygiene an identity governance problem, not just a vulnerability management problem.

The article’s core point is that patch cycles do not remove stolen or exposed keys from circulation. If a copied API key or service-account secret still works, the organisation has an access problem that continues independently of the software flaw that revealed it. For NHI governance, that means discovery, ownership, validation, and revocation have to be treated as one control loop.

The briefing is aimed at board-level risk framing, but the underlying issue is operational: security teams need to know where secrets live, who owns them, whether they are still valid, and how quickly they can be revoked. That is typical of modern environments where humans, AI agents, and workloads all generate credentials faster than manual remediation can keep up.

Key questions

Q: What breaks when exposed credentials are not revoked quickly?

A: Exposed credentials create a standing access window that attackers can exploit before defenders notice. The danger is not limited to the original leak. Any system that trusts the credential can become reachable until the secret is rotated, downstream access is closed, and the exposure path is fully removed.

Q: Why do exposed service account credentials create such broad risk?

A: Service account credentials often carry standing access into cloud, CI/CD, or SaaS systems, so one exposed secret can open multiple control paths at once. The risk is amplified when the credential has not been scoped tightly or tied to a clear owner. That is why secret exposure must be treated as identity governance, not just data leakage.

Q: What do teams get wrong about secrets scanning at scale?

A: They treat scanning as the control instead of one input to lifecycle governance. At scale, the harder problems are ownership, rotation, revocation, and central inventory. A tool that finds secrets but cannot support remediation prioritisation still leaves governance gaps unresolved.

Q: How should organisations budget for secrets security?

A: They should budget against reduced exposure time, lower revocation effort, and fewer high-reach credentials left in circulation. The business case is strongest when secrets security is treated as a control for valid account abuse, not as a narrow developer hygiene project. That framing makes the investment measurable in risk reduction and response speed.

Technical breakdown

Why valid credentials outlive the vulnerability that exposed them

A patch removes one exposure path, but it does not invalidate a credential that has already been copied or exfiltrated. That is why valid account abuse is more durable than exploit-based intrusion: attackers do not need to keep re-exploiting a flaw once they hold a working key, token, or service account. In identity terms, the problem shifts from vulnerability closure to credential lifecycle control. The risk persists until the secret is discovered, attributed to an owner, and revoked or rotated.

Practical implication: Treat exposed credentials as active identities that require lifecycle handling, not as incidental artefacts of a software bug.

Secrets spread through code, repositories, and AI coding assistants

Secret exposure now occurs across public GitHub, internal repositories, developer tooling, and AI coding assistants, which means the same credential can appear in multiple places before anyone notices. This creates a discovery problem, because the same secret may be duplicated, referenced, or cached in systems outside the security team’s direct view. The technical challenge is not just scanning for strings, but linking each exposed value to its owner, workload, and blast radius.

Practical implication: Build discovery and attribution workflows that cover source control, developer tools, and AI-assisted coding paths together.

Why secrets security is a control plane for NHI risk

For non-human identities, a credential is the identity. Service accounts, API keys, and tokens often carry persistent access, so exposure instantly becomes an authorisation problem. The briefing’s logic is that security programmes need to measure where credentials leak, whether they are still valid, and how quickly the organisation can remove them from circulation. That is the essence of NHI governance: inventory, ownership, validation, risk scoring, and revocation operating as one system rather than separate tasks.

Practical implication: Map every credential type to a named owner and a revocation path before exposure becomes a live attack path.

Threat narrative

Attacker objective: The attacker’s objective is to turn a stolen secret into durable trusted access that survives patching and enables continued abuse.

1. Entry begins when attackers obtain a valid credential from exposed code, repositories, AI tooling, or another leak path, rather than by exploiting a software flaw.
2. Escalation occurs when that credential remains usable across systems because it has not been rotated, revoked, or tied to a narrow access scope.
3. Impact follows as the attacker reuses trusted access to move through environments, abuse accounts, and extract value without triggering traditional exploit-based controls.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credentials are now the attack path, not just the payload. A patch can close the original flaw, but it cannot make a copied key stop working. That breaks the old assumption that remediation and exposure are the same problem. In NHI governance terms, the issue is valid account abuse by a credential that persists beyond the vulnerability that exposed it, which is why lifecycle control matters as much as detection.

Secret sprawl is an identity governance failure, not a tooling inconvenience. The article is really describing a programme gap where ownership, validation, and revocation are not unified across repositories, assistants, and workload identities. That is why the same exposed value can survive in multiple places long after the first alert. Practitioners should read this as a governance design problem, not just a scanning problem.

AI coding assistants widen the credential surface because they accelerate creation and propagation. Humans already leak secrets into code, but assistant-driven workflows can multiply the speed and reach of that leakage. The important implication is that identity programmes must account for every place a secret can be introduced, reused, or re-surfaced, including systems that were not designed as identity repositories. That changes how NHI inventory and risk scoring have to work.

Standing secret validity creates identity blast radius. If a key or token remains usable after exposure, the blast radius is determined by what the credential can reach, not by where it was found. This is why secrets security, PAM, and NHI governance now overlap operationally. Security teams need to reduce the time between exposure and revocation, because every minute of validity extends the attack window.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a wider view of root causes, see 52 NHI Breaches Analysis for recurring patterns in credential exposure, overprivilege, and failed offboarding.

What this signals

Standing secret validity is the real risk variable: once a credential leaks, the question becomes how long it remains usable, not whether the original software flaw has been patched. With 72% of organisations reporting or suspecting an NHI breach in our research, the programme implication is that exposure management has to sit alongside detection and response, not behind it.

The next governance step is to collapse secret discovery, ownership, and revocation into a single operational loop. Teams that still treat repositories, AI coding assistants, and workload identities as separate problems will keep finding the same class of exposure in different places. The better model is to treat every credential as a live identity with a measurable lifetime and a defined blast radius.

For teams building that model, the most relevant baseline is Guide to the Secret Sprawl Challenge, which helps frame where hidden credentials accumulate across development and delivery workflows. Pair that with OWASP Non-Human Identity Top 10 to align exposure handling with formal NHI risk categories.

For practitioners

• Inventory all secret-bearing identities Create a single inventory for API keys, tokens, certificates, service accounts, and AI-assisted code credentials, then assign an owner and revocation path to each one.
• Track exposure to revocation time Measure how long exposed secrets remain valid after discovery, and treat that interval as a board-reportable risk indicator for NHI governance.
• Extend scanning beyond source code Include public repositories, internal repositories, developer workstations, and AI coding assistants in secret discovery so exposed values do not stay hidden in adjacent workflows.
• Prioritise high-reach credentials first Rank exposed secrets by the systems they can access, then revoke the highest-reach credentials before lower-value findings so blast radius shrinks quickly.

Key takeaways

• Credentials should be treated as live identities because patching does not invalidate a copied key or token.
• The practical risk is not exposure alone but the time a secret remains usable after discovery, which determines breach reach.
• Secrets security becomes board-relevant when organisations can measure ownership, validity, and revocation speed across all NHI paths.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Valid Account Abuse: Valid account abuse occurs when attackers use legitimate credentials or tokens to enter systems and blend in with normal traffic. It is a preferred tactic because it sidesteps many exploit-based controls and inherits existing privilege. In NHI programmes, service accounts and API keys are common abuse paths when scope and rotation are weak.
• Standing secret validity: Standing secret validity is the period during which an exposed credential remains usable after it is discovered or copied. In NHI governance, that window defines the attack opportunity, because a valid token or key can keep working until someone rotates or revokes it.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

GitGuardian's full white paper covers the operational detail this post intentionally leaves for the source:

• Board-ready framing for why credential exposure remains a live security problem after patching
• A two-page explanation of how valid account abuse changes the cost profile of a breach
• The article's own discussion of exposure across public GitHub, internal repositories, and AI coding assistants
• The investment case for improving remediation speed and finding volume across secrets security workflows

👉 GitGuardian's full white paper covers the board-level cost case, remediation logic, and exposure trends in more detail.

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 building or maturing an IAM or identity security programme, it is worth exploring.