Why do CI and package-maintainer secrets create outsized supply chain risk?

Why This Matters for Security Teams

CI and package-maintainer secrets are high-value because they sit at the intersection of identity, automation, and software distribution. A single token can sign releases, publish packages, trigger builds, or access artifact stores, so compromise is rarely confined to one repository. That is why this is an NHI governance problem as much as an application security problem, and why the OWASP Non-Human Identity Top 10 is a useful lens for thinking about blast radius, rotation, and trust boundaries.

Supply chain incidents increasingly show that attackers do not need to break code if they can take over the identities that move code. NHIMG’s GitHub Action tj-actions Supply Chain Attack and Reviewdog GitHub Action supply chain attack show how CI abuse can turn one exposed secret into many downstream exposures. The operational risk grows when secrets are reused across pipelines, kept valid for long periods, or granted broader permissions than the task requires. In practice, many security teams discover the true blast radius only after a package publish, build job, or release workflow has already been abused.

How It Works in Practice

The practical problem is that CI and maintainer secrets are often treated like ordinary credentials, even though they behave more like non-human identities with production reach. A publish token, signing key, or CI credential may authenticate a machine workflow that runs continuously, touches multiple repositories, and has access to multiple environments. Once stolen, it can be replayed at machine speed across build systems, registries, and deployment steps.

Current guidance suggests reducing that risk with short-lived, task-scoped credentials, workload identity, and strict environment separation. For CI, that often means replacing static secrets with OIDC-based federation, trusted runner identity, and just-in-time issuance tied to a specific job. For package maintainers, it means narrowing publish rights, protecting signing material, and separating release authority from day-to-day development access. The NIST Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both support the underlying control idea: limit privilege, reduce exposure time, and verify before access is granted.

• Use separate identities for build, test, release, and signing workflows.
• Issue secrets per task, not per team, and revoke them automatically after completion.
• Bind publish permissions to protected branches, trusted runners, and release approvals.
• Monitor for credential reuse across repositories, forks, and third-party actions.

NHIMG’s The State of Secrets Sprawl 2026 highlights why this matters operationally: 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners, which shows that automation infrastructure itself is now a primary target. These controls tend to break down when older pipelines still depend on long-lived tokens and shared maintainer accounts because the secret becomes portable beyond the intended workflow.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance release speed against revocation discipline and trust minimisation. That tradeoff becomes sharper in open source, multi-tenant CI, and hybrid release pipelines where different teams own different stages of the same delivery chain.

One common edge case is emergency release access. Best practice is evolving here, but current guidance suggests that break-glass access should be time-boxed, heavily logged, and separated from normal publish credentials rather than shared as a permanent fallback. Another edge case is third-party automation, where package maintainer secrets are handed to bots, external CI, or marketplace actions. That should be treated as delegated non-human identity, not as a convenience exception.

There is also a limit to detection-only programs. NHIMG notes in The State of Secrets in AppSec that the average time to remediate a leaked secret is 27 days, which is too slow for release keys and CI tokens that may still be valid immediately after exposure. The same lesson appears in real-world supply chain cases such as the Shai Hulud npm malware campaign: if revocation is not automatic, exposure becomes durable. For this reason, many teams now pair secret scanning with runtime rotation, workload-bound identity, and least-privilege release workflows.

Related resources from NHI Mgmt Group

• Why do supply chain worms create a secrets management problem as well as a malware problem?
• Why do service tokens in CI pipelines create more risk than ordinary application secrets?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• Why do developer identities create outsized supply chain risk?