Secrets attacks expose the governance gaps behind data breaches

At a glance

What this is: This is an analysis of seven famous secrets attacks and the recurring pattern behind them: exposed credentials, tokens, keys, and misconfigurations leading to data theft and operational risk.

Why it matters: It matters because IAM, PAM, and NHI programmes fail when secrets are treated as static assets instead of governed identities with ownership, context, and revocation.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Entro Security's analysis of seven famous secrets attacks and their outcomes

Context

Secrets attacks happen when credentials, tokens, keys, or certificates are exposed or misused and then become a shortcut into systems, data, or trust relationships. In identity terms, the problem is not just leakage but ownership: once a secret is treated as a reusable access path, the organisation has already lost track of who can use it, where it is used, and when it should stop working.

This topic sits squarely in NHI governance because secrets are non-human identities in practice, even when teams describe them as infrastructure artefacts. The article's examples show the same governance failure repeating across cloud, source control, vendor access, and application signing, which is typical rather than exceptional in modern estates.

The deeper issue is that many security programmes still protect secrets as static values instead of governed access instruments. That mindset fails when secrets are copied, embedded, shared, or left valid long after the original business need has changed.

Key questions

Q: How should security teams govern secrets that function as non-human identities?

A: Security teams should govern secrets as identities with ownership, scope, and lifecycle rules, not as static values stored in a vault. Each secret should have a business purpose, an accountable owner, and a defined retirement path. That approach reduces orphaned access, makes revocation faster, and ties secrets to the systems they actually serve.

Q: Why do exposed secrets create lateral movement risk even when the initial leak seems minor?

A: A leaked secret often carries the exact permissions needed to authenticate into other systems without further exploitation. That means a small exposure can become broad access if the credential is valid, reused, or shared across environments. The risk grows when teams fail to rotate quickly or do not know where the secret is accepted.

Q: What breaks when secrets are protected only by a central vault?

A: A vault solves storage, but not ownership, usage tracking, or revocation discipline across all places secrets travel. If secrets are copied into pipelines, chat, tickets, or build artefacts, the vault no longer represents the full trust surface. Teams then lose visibility into actual exposure paths and cannot prioritise remediation accurately.

Q: How do organisations decide which secrets incidents need immediate action?

A: Prioritise secrets that are still valid, linked to privileged access, or embedded in high-reach systems such as CI/CD, code signing, and vendor integrations. A credential with broad trust and no current owner should be treated as urgent even if the leak appears small. The key is to measure exploitability, not just volume.

Technical breakdown

Why exposed secrets become identity paths

A secret is not just a value. In practice it is a credentialed identity assertion that can be replayed until revoked, rotated, or invalidated. When attackers obtain a token, API key, or signing key, they inherit the permissions attached to that secret rather than breaking in through a traditional user login. That is why secrets exposure often produces faster impact than password theft. The control failure is usually not one bad database or one leaked file. It is the absence of a system that knows where each secret exists, who owns it, and whether the privilege still matches current business need.

Practical implication: treat every secret as a governed identity with ownership, scope, and revocation requirements.

Secrets sprawl across code, collaboration tools, and cloud assets

Secrets now move far beyond source code. They appear in CI/CD runners, shared documents, ticketing systems, chat platforms, configuration files, and third-party integrations. That spread matters because each location creates a different monitoring and containment problem, and most teams still focus on repositories only. The article's examples illustrate this spread clearly: leaked tokens, embedded signing keys, and exposed databases all produce the same outcome through different storage paths. The technical issue is not only discovery. It is that the organisation lacks consistent lifecycle control across every place the secret can exist.

Practical implication: extend secrets discovery and control to collaboration tools, pipelines, and application dependencies, not just Git repos.

Why metadata and context matter for secrets governance

Context turns a raw secret into something governable. Knowing who created it, where it is used, what system owns it, and when it was last rotated helps teams distinguish dormant noise from active exposure. Without that metadata, response teams have to investigate every alert as if it were equally urgent, which slows containment and inflates operational burden. The article points toward this need when it describes context around secret origin, ownership, and exposure. In NHI terms, context is what allows entitlement decisions, rotation priorities, and offboarding actions to be made intelligently instead of blindly.

Practical implication: enrich secrets inventories with ownership, last-used, and last-rotated context before building response workflows.

Threat narrative

Attacker objective: The attacker wants to turn a leaked secret into trusted access that can be reused for theft, impersonation, or broader system compromise.

1. Entry occurs when a secret is exposed through unsecured storage, code repositories, vendor access, or application signing material.
2. Escalation follows when the attacker reuses that secret as a valid identity path to reach data, infrastructure, or privileged functions.
3. Impact occurs when the secret enables data theft, impersonation, malicious signing, or downstream compromise of connected systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Secrets management is ultimately NHI governance, not storage management. The article's examples show that a secret becomes a living access path the moment it can authenticate a workload, signing process, or integration. That means the real governance question is whether the organisation can name the identity behind the secret, define its scope, and retire it when the business use ends. Practitioners should stop treating secrets as inert objects and manage them as non-human identities.

Secrets sprawl creates identity blast radius. Once secrets live in code, chat, ticketing, and CI/CD systems, the attack surface expands faster than central vaulting can contain it. This is the named concept this article surfaces: the blast radius is not only where the secret is stored, but where it can be replayed with trust. Teams need to understand that a single exposed credential can map to multiple systems, multiple owners, and multiple failure domains.

Fine-grained access control matters only when paired with ownership and context. The article points to controls such as access restrictions and metadata, but the deeper lesson is that visibility without accountable ownership still leaves gaps. A secret that is visible but not owned will not be rotated, and a secret that is owned but not contextualised will not be prioritised correctly. Practitioners should make ownership and usage context first-class governance data.

Standing secrets should be treated as accumulated trust debt. The longer a credential remains valid, the more likely it is to survive personnel change, architecture change, or vendor change without being revisited. That is why old secrets often outlive the system assumptions that justified them. Security teams should recognise that the debt is structural, not merely procedural, and govern it accordingly.

Secrets incidents cross human, machine, and supply-chain identity boundaries. The same exposure pattern can begin with a developer mistake, continue through a machine token, and end in a vendor or cloud compromise. That cross-domain behaviour is exactly why narrow IAM silos miss the real risk. Practitioners should align lifecycle, PAM, and workload identity controls so that one leaked secret does not become a multi-domain incident.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• The same report found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly identity risk follows new integration surfaces.
• For a broader view of breach patterns and root causes, see 52 NHI Breaches Analysis, which traces how exposed access paths turn into incidents.

What this signals

Secrets governance is moving from repository hygiene to enterprise identity control. Once secrets appear in collaboration tools and automation systems, the programme boundary has already widened beyond code review. Teams that still treat secrets as a developer problem will miss the highest-risk exposures, especially where human workflows and machine access intersect.

Identity blast radius is the right way to think about secret exposure. A single credential can now span chat, tickets, pipelines, and production services, which means the practical risk is cumulative rather than isolated. That is why secrets inventories need ownership, usage context, and revocation logic before they can support operational decision-making.

With 64% of valid leaked secrets still exploitable after discovery, according to The State of Secrets Sprawl 2026, detection-led programmes will keep underperforming unless they collapse the gap between finding a secret and disabling it.

For practitioners

• Inventory secrets as governed identities Assign an owner, business purpose, system scope, and expiry expectation to every credential, token, key, and certificate. Do not allow orphaned secrets to remain outside a named lifecycle process.
• Expand discovery beyond source code Scan collaboration tools, ticketing systems, CI/CD runners, infrastructure templates, and application configuration files for exposed secrets. Repositories are only one leakage channel, not the whole problem.
• Prioritise revocation over detection alone Build workflows that invalidate exposed secrets automatically when discovery triggers. Detection without revocation leaves valid credentials exploitable after the alert is closed.
• Attach context to every secret Track who created the secret, where it is used, when it was last rotated, and whether the owning application still needs it. Context turns response from guesswork into triage.
• Separate signing keys from general-purpose credentials Treat code-signing and certificate material as higher-risk identities with stricter controls, review gates, and offboarding requirements than routine application secrets.

Key takeaways

• Secrets attacks succeed because credentials behave like identities, not inert data. Once exposed, they can be replayed to reach systems, sign artefacts, or impersonate trusted processes.
• The strongest evidence in the article is the repeated use of leaked secrets across cloud, source control, and vendor-facing systems. That pattern shows why single-location controls do not contain the actual risk.
• Practitioners should govern secrets with ownership, context, and revocation discipline, or accept that exposure will keep turning into access.

Key terms

• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials, tokens, keys, and certificates across systems, code, and collaboration tools. It turns a manageable access inventory into a fragmented trust surface where ownership, rotation, and revocation become inconsistent and often delayed.
• Standing secret: A standing secret is a credential that remains valid beyond the moment it was issued or last needed. In practice, it creates persistent access that can be reused until someone rotates or revokes it, which increases exposure when business context changes faster than governance processes.
• Identity blast radius: Identity blast radius is the amount of access, systems, and trust relationships that a compromised identity can reach before containment occurs. For secrets, it measures how much damage a single token or key can enable once it is exposed, reused, or embedded in multiple workflows.
• Secrets metadata: Secrets metadata is the contextual information attached to a credential, such as owner, purpose, creation date, usage scope, and last rotation time. It makes secrets governable by helping security teams decide what to revoke first, what still matters, and what has already outlived its purpose.

What's in the full article

Entro Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Detailed incident-by-incident narratives for the seven secrets attacks, including breach context and outcomes
• The vendor's recommended secrets management approach for reducing exposure and improving response
• Examples of how metadata, access controls, and rotation support faster investigation and containment
• Additional related articles on secrets risk in GitHub, Azure, and supply-chain environments

👉 Entro Security's full post covers the individual attack stories, secret types, and mitigation themes 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.