Why do developer secrets make supply chain incidents much harder to contain?

Why This Matters for Security Teams

Developer secrets are not just configuration artifacts. In modern delivery pipelines, they frequently function as operational identities with permission to publish packages, reach cloud APIs, invoke CI/CD jobs, and touch production services. That is why a single exposed token can turn a code leak into a multi-system incident. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s research on real-world breaches shows that the blast radius is driven less by where the secret was found and more by what it can do after reuse.

This is also why supply chain containment fails so often in practice. Attackers do not need to move in a straight line from source code to production. They can reuse the same credential across build systems, artifact registries, SaaS tools, and automation hooks, then pivot wherever trust already exists. NHIMG’s The State of Secrets Sprawl 2026 reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong indicator that detection without revocation leaves an incident open far too long. In practice, many security teams encounter lateral spread only after the attacker has already chained multiple systems together.

How It Works in Practice

Containment becomes difficult because the exposed secret usually maps to a workload trust boundary, not a single application function. A leaked deployment token may let an attacker push modified code, but it may also sign artifacts, access container registries, or trigger privileged pipeline steps. Once the secret is valid, the compromise is no longer limited to the original repository. That is why current guidance increasingly treats secrets as NHI assets that require lifecycle controls, not just storage controls.

Practitioners usually need four controls working together:

• Short-lived credentials for each task, rather than long-lived static tokens.
• Workload identity for the pipeline or service, so access is tied to what the system is and what it is doing.
• Runtime policy checks that evaluate context before a token is used.
• Automatic revocation when a secret is exposed, rotated, or no longer needed.

That model aligns with emerging NHI governance and agentic workload guidance in the 52 NHI Breaches Analysis and with supply chain attack patterns documented in the Reviewdog GitHub Action supply chain attack. It also fits the direction of travel in the Anthropic report on AI-orchestrated intrusion, where automated systems can rapidly chain permissions once they obtain a valid credential. Best practice is evolving toward least-privilege issuance at runtime, with policy-as-code deciding whether a secret should exist at all for that request.

These controls tend to break down when secrets are embedded in many CI/CD runners, SaaS integrations, and developer tools because revocation must reach every live consumer before an attacker reuses the token.

Common Variations and Edge Cases

Tighter secret controls often increase delivery overhead, requiring organisations to balance rapid automation against the cost of more frequent rotation, pipeline refactoring, and access review. That tradeoff is real, especially where legacy build systems expect durable credentials or where vendors do not support short TTLs cleanly.

There is no universal standard for this yet. Some environments can move to ephemeral tokens and workload identity quickly; others must phase in controls around the highest-risk secrets first, such as signing keys, cloud admin tokens, and package-publishing credentials. Secrets stored outside code repositories are another common edge case. NHIMG notes that 28% of incidents now originate in Slack, Jira, and Confluence, which means containment must extend beyond Git history and into collaboration systems. Teams should also plan for secret reuse across environments, because a token meant for test can still unlock production-adjacent services if the scopes were copied during setup.

For supply chain teams, the practical question is not only whether a secret leaked, but whether the leaked secret can still authenticate, authorize, and move laterally before rotation completes. The Code Formatting Tools Credential Leaks research is a good reminder that seemingly low-risk developer tooling can expose high-impact credentials. In environments with fragmented secret managers, long-lived service accounts, or build runners that share trust domains, containment often fails because the same identity is accepted in too many places at once.

Related resources from NHI Mgmt Group

• Why do non-human identities make supply chain attacks harder to contain?
• Why do supplier management credentials matter so much in supply chain risk?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How should teams respond when CI or developer secrets are exposed?