What breaks when a CI/CD workflow can publish packages and access secrets at the same time?

A single workflow compromise can become a full trust collapse. If the same pipeline can read secrets, mint tokens, sign artifacts, and publish releases, an attacker only needs one foothold to spread malicious packages and harvest downstream credentials. Separation of duties, least privilege, and short-lived credentials are what stop that shortcut.

Why This Matters for Security Teams

When a CI/CD workflow can both access secrets and publish packages, the pipeline stops behaving like a bounded build system and starts acting like a high-trust operator. That combination turns one compromised runner, token, or action into a direct path for source tampering, credential theft, and malicious release propagation. The issue is not just leakage. It is that the same trust boundary now covers confidential inputs and externally visible outputs.

NHIMG has documented how supply chain compromise and secret exposure amplify each other in real incidents, including the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack. The control problem is not whether the workflow is “trusted” at deploy time. It is whether any single job can accumulate enough privilege to cross from build integrity into secret exposure and release control. NIST guidance on access control and separation of duties remains relevant here, especially in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams encounter the blast radius only after a pipeline token has already been used to both exfiltrate secrets and publish a poisoned artifact.

How It Works in Practice

The safer model is to split the workflow into distinct trust zones. One job can build and test with minimal read-only inputs. A different job, triggered only after validation, can sign or publish using tightly scoped, short-lived credentials. Secrets should be injected only into the smallest possible step, never into the whole pipeline context. That is the practical meaning of least privilege for build systems.

Current guidance suggests three concrete patterns:

• Use separate identities for build, sign, and publish stages so compromise in one stage does not unlock the others.
• Issue just-in-time credentials with narrow TTLs, then revoke them immediately after the task completes.
• Prefer workload identity and ephemeral tokens over long-lived static secrets stored in repositories or runner images.

This is where NHI discipline becomes operational. The pipeline itself is the non-human identity, and its privileges should be explicit, short-lived, and request-bound. The same logic appears in NHIMG’s Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets, where static credentials are shown to create durable footholds that attackers can reuse long after the initial compromise. The OWASP Non-Human Identity Top 10 also reinforces this risk model, especially around secret lifecycle and overprivileged machine identities, as described in the OWASP Non-Human Identity Top 10.

In practice, this guidance breaks down in monolithic pipelines where build, test, sign, and deploy are all executed by the same runner account and every step inherits the same secret store.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance delivery speed against stronger trust boundaries. That tradeoff is real, especially in small teams or legacy CI systems that were never designed for identity isolation.

There is no universal standard for this yet, but current best practice is evolving toward environment-aware permissions, approval gates for publish steps, and repository-level controls that limit which workflows can access production secrets. In some cases, a workflow may need read access to package registries but not write access, or publish access but only through a dedicated signing job. That is where intent matters: a job should receive the minimum capability required for the current action, not a reusable credential that can be repurposed later.

Edge cases include self-hosted runners, shared build infrastructure, and reusable workflow templates. These environments increase the chance that a single compromise can cross repository boundaries or survive between jobs. They also make revocation harder if tokens are cached or if secrets are injected at the runner level rather than the step level. NHIMG’s 52 NHI Breaches Analysis shows how often machine identities become the shortcut attackers use once a pipeline is trusted too broadly.

Controls tend to break down when shared runners, reusable workflows, and long-lived publish tokens combine in the same automation path because one compromise can persist across multiple repositories and release cycles.

Related resources from NHI Mgmt Group

• What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
• What breaks when CI/CD workflow actions or build credentials are tampered with?
• Why do CI/CD service accounts and publishing tokens need the same governance as human access?
• What breaks when developer accounts can publish packages and expose credentials at the same time?