Cisco breach exposes how public NHI secrets break DevOps trust

At a glance

What this is: This is an analysis of the Cisco DevHub incident in which exposed non-human identity secrets enabled unauthorised access to data and underscored how public development surfaces can turn into trust failures.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat exposed secrets as identity governance failures, not only incident response work, especially when developer tooling and third-party access are involved.

Context

Cisco's DevHub incident is a non-human identity exposure problem, not simply a cloud housekeeping issue. When credentials, API tokens, certificates, or private keys are published where they can be downloaded, the security boundary shifts from access control to secret lifecycle control, inventory, and ownership.

In an NHI programme, the critical question is not whether a secret was intended for production use, but whether it was ever visible outside governed scope. That is why public developer portals, build environments, and shared artifact stores have to be treated as identity-bearing surfaces.

The starting position in this case is not unusual. Many organisations still assume exposed secrets will be discovered and cleaned up before abuse, but the article shows how quickly that assumption can fail once the material is public-facing.

Key questions

Q: What breaks when exposed NHI secrets are left in public DevOps environments?

A: Publicly exposed NHI secrets break the assumption that internal trust boundaries still protect machine credentials. Once tokens, keys, or certificates are readable outside intended control, attackers can authenticate directly, move into adjacent systems, and copy data without exploiting a software flaw. The result is faster compromise, wider blast radius, and harder containment.

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 are the signs that NHI governance is failing in an enterprise?

A: Common warning signs include unclear ownership for service accounts, secrets stored in code or configuration instead of managed vaults, infrequent rotation, and weak offboarding of API keys. Other red flags are excessive permissions, third-party exposure without controls, and low visibility into where non-human identities exist or how they are used across the stack.

Q: Should teams prioritise secret discovery or rotation first after exposure?

A: Discovery comes first because you cannot safely rotate what you cannot identify. But once the secret is mapped to its owner and use case, rotation must follow immediately. The right sequence is exposure discovery, ownership mapping, then controlled revocation or replacement.

Technical breakdown

How public DevHub exposure turns into NHI compromise

A public-facing developer portal can unintentionally act as a secret distribution channel when files, images, or configuration artefacts include embedded credentials. The compromise is not the portal itself, but the identity material it exposes: hard-coded credentials, API tokens, certificates, and private keys. Those artefacts can be copied instantly and reused outside the intended environment, often before the owner realises they were published. In practice, this creates a trust inversion: content meant to support developers becomes a live authentication surface for attackers. The technical failure is therefore inventory and publication control, not just file exposure.

Practical implication: treat every externally reachable build, docs, and developer workspace as a potential NHI secret exposure path.

Why hard-coded secrets break DevOps trust assumptions

Hard-coded secrets collapse the separation between code, configuration, and identity. Once a secret lives inside a file or image, it loses the lifecycle controls that normally govern issuance, rotation, revocation, and ownership. That matters because secrets are often reused across environments, so a single exposure can unlock more than one system. The article also points to a common DevOps pattern: artefacts created for convenience become persistent trust anchors. When those artefacts are public, the organisation is no longer managing access, it is managing the consequences of uncontrolled disclosure.

Practical implication: move secrets out of code and artefacts, then inventory where embedded credentials have already spread.

What ownership and context change in NHI remediation

Discovery alone is not enough when an exposed secret is found. Teams need to know which workload, developer workflow, or third-party integration the secret belongs to, because rotation without context can break legitimate services. That is the core NHI governance problem in this incident: the secret existed, but its business and technical ownership were not governed tightly enough to support safe response. This is where lifecycle controls and identity mapping matter most. The question is not simply whether a secret is live, but whether anyone can prove what it governs and who can revoke it safely.

Practical implication: attach ownership and usage context to every NHI secret so rotation can happen without guesswork.

Threat narrative

Attacker objective: The attacker sought to monetise stolen data and reuse exposed NHI secrets to expand access beyond the public-facing portal.

1. Entry occurred through a public-facing DevHub environment where sensitive files were inadvertently published for download.
2. Credential access followed when the attacker obtained hard-coded credentials, certificates, API tokens, and private keys from those files.
3. Escalation and reuse were possible because the exposed NHI secrets could be applied against related DevOps systems and downstream resources.
4. Impact included unauthorised access to Cisco data and customer data, with the stolen material later offered for sale.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.

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

NHI Mgmt Group analysis

Public NHI secret exposure is a governance failure, not a cleanup issue. When credentials, certificates, API tokens, and private keys are published in a public-facing environment, the organisation has already lost control of the identity boundary. The breach is created at publication time, not at the moment of attacker use. Practitioners should therefore treat secret exposure as an identity lifecycle failure that must be governed before any incident response begins.

Developer portals now need identity-grade controls, not just content controls. A DevHub, build repository, or shared artefact store can carry live trust material, which means publication rules alone are insufficient. The article illustrates a broader NHI pattern: access paths designed for collaboration often outlive the governance model that was supposed to protect them. The practitioner implication is that every externally reachable developer surface must be assessed as a potential identity-bearing system.

Secret ownership is the missing control plane in most NHI programmes. Rotation is only safe when the organisation can map each secret to a workload, integration, or owner quickly enough to act. This incident shows the cost of treating discovery, context, and revocation as separate tasks rather than one governance motion. Teams need to know what the secret does, who owns it, and what breaks if it is revoked.

Ephemeral publication windows create identity blast radius that conventional review cycles do not catch. The article reinforces a named concept: public secret blast radius. Once an NHI secret is visible outside governed scope, the question is not whether it is compromised, but how far that compromise can travel through reused credentials and connected systems. Practitioners should use that lens to prioritise exposed secrets by reachable trust radius, not by file count alone.

The market signal is moving from secret storage toward secret governance. This kind of incident shows that vaulting alone does not solve the problem if discovery, mapping, ownership, and offboarding remain fragmented. Identity programmes that stop at storage miss the operational reality that secrets are active credentials, not inert data. The implication for practitioners is to measure secret governance by revocation readiness and ownership clarity, not by vault adoption.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 61% of organisations still define privileged users as humans only, overlooking the role of non-human identities in privileged access, according to KPMG.
• Read next: Top 10 NHI Issues

What this signals

Public secret blast radius: once a credential or token appears in a public developer surface, the governance problem becomes how far that trust material can travel through reuse, automation, and undocumented ownership. The control question shifts from discovery alone to whether the organisation can revoke the secret without breaking production dependencies.

NHI teams should expect more incidents where the initial exposure is mundane but the consequence is broad because the same secret was embedded in multiple places. That is why secret ownership, environment mapping, and rotation readiness matter more than counting exposed files.

According to the Ultimate Guide to NHIs, NHIs outnumber human identities by 25x to 50x in modern enterprises, which is why secret sprawl is now an enterprise governance problem rather than a niche DevOps issue.

For practitioners

• Audit public developer surfaces Review DevHub sites, documentation portals, sample repositories, and build artefacts for embedded credentials, tokens, and private keys. Treat every externally reachable file store as part of the identity attack surface, not a content repository.
• Map each secret to an owner Create a minimum ownership record for every NHI secret that includes workload, environment, and revocation authority. If you cannot name the owner, you do not yet have control over the secret.
• Separate convenience artefacts from live trust material Remove secrets from code, container images, and shared configuration files before those artefacts are published or reused across environments. Keep deployment artefacts free of credentials that could be copied outside governed scope.
• Use rapid rotation with service-impact checks When an exposed secret is found, rotate it immediately after confirming the affected application path and fallback credentials. If the secret supports a production workflow, validate the blast radius before revocation.
• Monitor for unauthorized reuse of exposed secrets Hunt for the same credential material appearing in logs, source repositories, and downstream environments after disclosure. Reuse across systems is what turns a leak into a broader access problem.

Key takeaways

• This incident shows how public-facing developer environments can become identity compromise points when live secrets are published outside governed scope.
• Exposed credentials, tokens, certificates, and keys create broad reuse risk because one file can unlock multiple connected systems.
• The practical fix is not just faster cleanup, but stronger ownership, discovery, and rotation controls tied to NHI lifecycle governance.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Secret Ownership: Secret ownership means assigning responsibility for a credential to a specific person or team that can validate its purpose and approve remediation. Clear ownership speeds up investigation, rotation, and decommissioning. Without it, exposed credentials often linger because nobody is confident enough to act.
• Public Secret Blast Radius: Public secret blast radius is the range of systems, workflows, and identities that become reachable once a secret is exposed outside governed scope. The wider the reuse and the weaker the ownership, the larger the blast radius becomes and the harder it is to contain after disclosure.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management 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.