What fails when CI/CD workflows can access secrets and publishing tokens?

Why This Matters for Security Teams

When CI/CD workflows can read secrets and publish artifacts, the pipeline stops being a helper and becomes a high-trust non-human identity. That matters because build systems often span source, test, release, and deployment, so a single compromised runner can inherit privileges that would never be granted to a human operator. The result is not just credential theft, but trusted delivery of malicious code, poisoned packages, and unauthorized release activity.

This is a recurring theme in the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study: once secrets and publishing authority converge in automation, blast radius expands faster than most access reviews can track. OWASP also frames this as a core NHI risk in the OWASP Non-Human Identity Top 10, where exposed or overprivileged machine identities are treated as first-class attack surfaces. In practice, many security teams encounter the failure only after a pipeline has already signed, published, or deployed something it should never have touched.

How It Works in Practice

The secure pattern is to separate what the workflow can do from what it can hold. A CI/CD runner should not carry long-lived publishing tokens if a narrower, short-lived exchange is possible. Current guidance suggests treating the runner as an ephemeral workload identity, then issuing just-in-time credentials only for the exact task being executed. That means short TTLs, automatic revocation, and request-time policy checks rather than static permissions baked into YAML.

In practice, this often looks like workload identity plus runtime authorization. The runner proves what it is through cryptographic identity, such as OIDC-based federation or SPIFFE-style workload identity, then requests narrowly scoped access to a package registry, artifact store, or signing service. Policy engines can evaluate context at request time, including branch, environment, approver status, and the specific action being attempted. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here for mapping least privilege and separation of duties, but the implementation detail is that the pipeline should never need broad standing access just to build safely.

• Give build jobs ephemeral tokens per task, not reusable release credentials.
• Split read, write, sign, and publish duties across separate identities.
• Store secrets in a vault and inject them only at execution time.
• Revoke credentials automatically when the job completes or fails.

These controls tend to break down in monolithic release pipelines where one runner is expected to test, sign, publish, and deploy across multiple environments.

Common Variations and Edge Cases

Tighter pipeline controls often increase operational friction, requiring organisations to balance release speed against blast-radius reduction. There is no universal standard for this yet, especially in multi-repo or multi-cloud delivery systems where tooling expects broad token reuse. Best practice is evolving, but the direction is clear: static secrets and “one token for everything” workflows are a liability.

Some environments still rely on long-lived registry tokens because older package managers or signing tools do not support workload federation cleanly. In those cases, the safer interim step is to narrow scope aggressively, isolate publishing jobs, and monitor for anomalous use of release credentials. The 2025 State of NHIs and Secrets in Cybersecurity highlights how often NHI tokens are duplicated or left active after they should have been removed, which is exactly the failure mode that turns CI/CD into a persistence channel. The broader lesson is reinforced by the Shai Hulud npm malware campaign: once automation can both steal and reuse secrets, the supply chain becomes the attacker’s delivery path, not the defender’s control plane.

Related resources from NHI Mgmt Group

• How should teams respond when CI or developer secrets are exposed?
• What breaks when CI/CD workflows can run untrusted code with privileged tokens?
• What breaks when malicious workflows can read repository secrets in CI/CD pipelines?
• What breaks when a CI/CD workflow can access secrets from untrusted pull requests?