Why do developer and CI credentials increase supply chain blast radius?

Because they are already trusted by package registries, source control, and cloud services. If a malicious dependency steals those credentials, the attacker can commit, publish, or exfiltrate through legitimate channels, which is far harder to distinguish from normal automation than obvious malware traffic.

Why This Matters for Security Teams

Developer and CI credentials are dangerous because they are not just access tokens, they are trusted production paths into the software factory. A compromised build token can sign releases, fetch private dependencies, alter source, or publish malicious packages under an organisation’s own automation. That turns one leaked secret into a supply chain event, which is why NHI governance treats these credentials as blast-radius multipliers rather than ordinary login artifacts.

NHIMG’s research on The State of Secrets in AppSec shows the gap between confidence and reality: the average time to remediate a leaked secret is 27 days, even though 75% of organisations say they are confident in their secrets management. In practice, that delay is long enough for attackers to reuse CI tokens, pivot across registries, and hide inside legitimate automation. The risk is amplified when secrets are embedded in workflows, runners, or dependency scanners that are assumed to be harmless. Current guidance from the OWASP Non-Human Identity Top 10 treats these exposures as identity compromise, not merely hygiene failures. In practice, many security teams discover the blast radius only after a build system has already been used as an attacker-controlled distribution channel.

How It Works in Practice

The blast radius grows because developer and CI credentials typically sit at the intersection of source control, package registries, artifact stores, and cloud control planes. If one of those secrets is stolen from a laptop, pipeline log, dependency hook, or malicious action, the attacker can often operate through the same trusted channels as automation. That makes detection harder than with obvious malware traffic, because the activity may look like a normal deploy, release publish, or dependency sync.

The practical defence is to reduce how much authority any single credential carries. Best practice is evolving toward short-lived, task-scoped credentials, workload identity, and explicit policy checks at request time. For example, a CI job should authenticate as a workload, not as a person, and only receive the minimum access needed for one build or one publish step. That is consistent with the identity model in NIST SP 800-63 Digital Identity Guidelines, but current guidance suggests extending those principles to non-human workloads rather than applying human session assumptions directly.

• Use ephemeral credentials for each job or release stage instead of shared long-lived secrets.
• Separate build, test, sign, and publish privileges so compromise of one step does not expose all others.
• Bind workload identity to the runner, pipeline, or service account so the token is only valid in the expected context.
• Log and alert on unusual publishing, branching, or registry access patterns from automation identities.

NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets makes the core tradeoff clear: static credentials expand the time window and scope of misuse, while dynamic secrets narrow both. These controls tend to break down when legacy build tooling requires persistent registry tokens because the pipeline cannot rotate credentials without manual intervention.

Common Variations and Edge Cases

Tighter credential scoping often increases operational overhead, so organisations have to balance release velocity against containment. That tradeoff is especially visible in mono-repos, polyglot pipelines, and third-party build runners, where different tools expect different auth methods and secret lifetimes.

There is no universal standard for every CI environment yet, but current guidance is clear that shared credentials, reusable publishing tokens, and broad cloud roles are high-risk defaults. A common edge case is open-source release automation: maintainers often need broad registry access, yet the same token can be abused if a dependency or action is compromised, as seen in incidents like the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. Another edge case is secret sprawl across parallel environments, where rotation is technically possible but operationally slow; NHIMG’s Guide to the Secret Sprawl Challenge highlights how fragmentation weakens central control.

For highly automated delivery systems, the right question is not whether a credential is valid, but how far it can move before it expires or is revoked. That is why CI and developer credentials increase blast radius: they are already trusted by the systems that can do the most damage, and they often remain valid long enough for an attacker to convert one theft into many downstream compromises.

Related resources from NHI Mgmt Group

• Why do generative AI credentials increase the blast radius of a leak?
• Why do NHI credentials increase blast radius in supply-chain attacks?
• Why do static service credentials increase supply chain blast radius?
• Why do standing NHI credentials increase supply chain blast radius?