When attackers can mint valid publish tokens from CI/CD workflows, signed provenance no longer guarantees trust. Malicious packages can enter the software supply chain with legitimate-looking credentials, which raises the risk of widespread contamination. Security teams should treat workflow permissions, OIDC exposure, and package publishing paths as high-value controls, then monitor for unexpected build provenance, unauthorized releases, and unusual maintainer activity.
Why This Matters for Security Teams
A supply chain worm that can forge publish tokens from CI/CD workflows turns build infrastructure into a credential factory. The issue is not just package tampering. It is that the workflow identity itself becomes a trusted path into registries, signing systems, and downstream consumers. Once attackers can mint tokens that look legitimate, signed provenance can be contaminated at the source, and ordinary release approvals no longer provide meaningful assurance.
This is why current guidance increasingly treats CI/CD OIDC exposure, workflow permissions, and publishing paths as high-value controls. The OWASP Non-Human Identity Top 10 frames this as an NHI problem, not a conventional appsec bug. NHIMG research on the Miasma and Hades Supply Chain Worms shows how quickly token abuse can propagate when automation is overtrusted. In practice, many security teams discover forged publish paths only after a malicious release has already been accepted as trusted provenance.
How It Works in Practice
Modern CI/CD pipelines often issue short-lived OIDC-backed tokens so automation can authenticate to package registries, cloud services, and signing endpoints without storing long-lived secrets. That model is sound only when the workflow identity, issuer constraints, branch protections, and audience claims are tightly bound. If an attacker compromises a workflow, injects malicious steps, or abuses overly broad permissions, they may be able to request publish tokens that the registry accepts as valid.
The practical control set is narrower than many teams expect:
- Bind publish rights to specific repositories, branches, tags, and workflow files rather than to generic runner trust.
- Use just-in-time, short-lived credentials and revoke them automatically when the task completes.
- Validate OIDC claims at runtime, including issuer, audience, subject, and environment context.
- Separate build, sign, and publish duties so one compromised workflow cannot complete the whole chain.
- Monitor for unusual provenance, sudden maintainer changes, and release activity outside normal change windows.
This is also where GitHub Action tj-actions Supply Chain Attack and the Shai Hulud npm malware campaign are instructive: once the workflow boundary is crossed, attackers can reuse trust already embedded in automation. The response is not to rely on provenance alone, but to harden the identity chain that produces it. These controls tend to break down in multi-tenant runners and loosely governed self-hosted CI environments because token issuance, job isolation, and artifact signing are no longer tightly coupled.
Common Variations and Edge Cases
Tighter CI/CD token controls often increase release friction, requiring organisations to balance automation speed against the need for verifiable identity and constrained publishing authority. That tradeoff becomes especially visible in fast-moving open source projects, monorepos, and multi-tenant build farms, where maintainers expect broad pipeline reuse but attackers only need one weak workflow.
Best practice is evolving, but the core pattern is consistent: use workload identity, not static secrets, as the basis for publish authorization. In environments with federated build systems, ephemeral runners, or nested reusable workflows, a token can be valid yet still inappropriate if the context does not match the intended release path. That is why Guide to the Secret Sprawl Challenge matters here: secret reduction is necessary, but it does not solve workflow abuse by itself. Organisations should also watch for anomalous maintainer activity, package namespace drift, and publish events that bypass normal code review. There is no universal standard for this yet, but the direction of travel is clear: evaluate authorisation at request time, not just at pipeline design time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AI-07 | Covers agentic workflow trust and runtime misuse of autonomous actions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses short-lived credential issuance and rotation for non-human identities. |
| CSA MAESTRO | MAESTRO-IDENTITY-1 | Applies to workload identity, trust boundaries, and agentic access paths in automation. |
| NIST AI RMF | GOVERN | Relevant because governance must account for autonomous, context-sensitive release actions. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust demands request-time authorization for high-value publish actions. |
Restrict workflow actions to verified runtime context and deny publish steps outside approved intent.
Related resources from NHI Mgmt Group
- What breaks when CI/CD workflows can run untrusted code with privileged tokens?
- How should security teams govern software supply chain risk when CI/CD identities can publish code?
- Why do CI/CD workflows make supply chain worms harder to contain?
- Why do CI/CD tokens and maintainer credentials matter so much in supply chain security?
