What breaks when CI/CD credentials are reused for package publishing?

Why This Matters for Security Teams

Reusing the same CI/CD credential for both build operations and package publishing erases a critical separation of duties. Once an attacker reaches the pipeline, the path from code execution to signed or published artifact becomes much shorter, and the blast radius extends from the build system into downstream consumers. That is why supply chain guidance increasingly treats package publishing as a distinct trust boundary, not just another pipeline step.

The risk is not theoretical. NHIMG’s CI/CD pipeline exploitation case study shows how pipeline compromise can be converted into release manipulation, while the Guide to the Secret Sprawl Challenge highlights how quickly credentials spread once they are embedded in routine developer workflows. The issue is amplified by weak hygiene across non-human identities: the 2024 Non-Human Identity Security Report notes that 88.5% of organisations say their non-human IAM practices lag behind or merely match their human IAM maturity. In practice, many security teams encounter package abuse only after a trusted pipeline has already published malicious artifacts, rather than through intentional release control.

How It Works in Practice

Build credentials and publishing credentials should be treated as different identities with different jobs. A build job needs limited access to fetch dependencies, compile code, run tests, and maybe write ephemeral logs. A publishing job needs tightly scoped authority to upload artifacts, ideally only after a successful gated step. When both jobs use the same token, the identity becomes overpowered: any build compromise can immediately become release authority.

Current guidance suggests separating these functions with distinct secrets, distinct service accounts, and distinct approval paths. The publishing identity should be short-lived where possible, issued just in time, and bound to the exact package, repository, environment, and release event it is meant to authorize. This aligns with the direction of the OWASP Non-Human Identity Top 10 and the identity assurance principles in the NIST SP 800-63 Digital Identity Guidelines, even though there is no universal standard yet for package publishing trust boundaries.

• Use one credential or workload identity for build-time actions only.
• Use a separate, narrowly scoped identity for publishing to registries.
• Require signed or approved release events before publishing is allowed.
• Prefer ephemeral tokens over long-lived static secrets for release automation.
• Log the publishing action with enough context to trace which pipeline and commit triggered it.

NHIMG’s Reviewdog GitHub Action supply chain attack illustrates the broader pattern: once an automation token has more authority than the task needs, a single compromise can cascade into secret exposure and trust abuse. These controls tend to break down in monolithic pipelines where build, test, sign, and publish all run under one service account because the environment makes granular separation harder to enforce.

Common Variations and Edge Cases

Tighter publishing controls often increase pipeline complexity, requiring organisations to balance release velocity against blast-radius reduction. That tradeoff becomes most visible in fast-moving open source projects, multi-repo release trains, and container image pipelines where teams want a single automation path for convenience. Best practice is evolving, but the direction is clear: convenience should not justify a reusable credential that can both verify code and publish it.

Edge cases matter. Some registries support trusted publishing, OIDC federation, or environment-bound release permissions, which reduces the need for long-lived secrets. Others still rely on static tokens, and those tokens should be rotated aggressively and isolated from build jobs. If the same secret must exist temporarily in a pipeline, its scope should still be narrowed to a single registry, a single namespace, and a single release action. For teams that cannot yet separate identities cleanly, compensating controls like manual approval gates, artifact signing, and protected branches can reduce risk, but they do not eliminate it.

Where this guidance gets weaker is in legacy CI systems that reuse runners across projects or in self-hosted environments with poor secret isolation, because a compromise of the runner can expose both build and publish paths at once. That is why practitioners should treat package publishing as a distinct NHI lifecycle event, not a routine extension of the build credential.

Related resources from NHI Mgmt Group

• What breaks when malicious npm packages execute during CI/CD installs?
• What breaks when CI/CD pipelines can list tables with long-lived credentials?
• Why do private container images increase NHI risk in CI/CD environments?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?