Why do package publishing workflows create supply chain risk even when code reviews exist?

Why This Matters for Security Teams

Package publishing is a trust boundary, not just a developer convenience. Code review can reduce risky source changes, but it does not stop a stolen token, compromised maintainer account, or abused CI/CD release job from pushing a malicious artifact with a clean-looking history. That gap is why supply chain risk persists even in mature engineering teams.

The issue becomes more serious when package registries, build systems, and release automation are treated as separate controls. A workflow may approve source changes while still allowing direct publication from a trusted identity, which means the attacker only needs publishing access once. NHI governance and release policy must therefore cover the identity that publishes, not just the code that was reviewed. NHIMG analysis of breaches such as the LiteLLM PyPI package breach shows how quickly credential compromise turns into downstream exposure.

Current guidance from OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward stronger identity control, provenance, and least privilege across the delivery chain. In practice, many security teams encounter package compromise only after a trusted release process has already published the malicious version.

How It Works in Practice

Secure package publishing starts by separating code approval from release authority. A pull request can be fully reviewed, yet the published artifact can still be altered later if the publisher identity is not tightly controlled. The practical control set includes short-lived publishing credentials, branch and tag protections, signed builds, provenance attestation, and explicit release approvals. Where possible, the build system should create artifacts from source and publish them from an isolated, ephemeral workload identity rather than a developer laptop or long-lived personal token.

This is where NHI governance matters. Publishing tokens, API keys, and CI/CD secrets are non-human identities and should be managed like privileged access, not like convenience credentials. The strongest pattern is to make publication a JIT action: a workflow requests permission, receives a narrowly scoped credential for one release, and the credential is revoked immediately after use. That reduces the value of a stolen secret and limits the blast radius if a runner, package hook, or automation account is compromised.

• Require provenance for releases so consumers can verify how the package was built and signed.
• Restrict direct publication to trusted automated workflows, not ad hoc human uploads.
• Use ephemeral, task-scoped tokens instead of reusable registry credentials.
• Store release secrets in a central secret manager and rotate them aggressively.
• Review CI/CD runners as first-class attack surface, especially for package ecosystems.

NHIMG research on the GitHub Action tj-actions Supply Chain Attack and the Shai Hulud npm malware campaign shows why publishing credentials and CI/CD runners are high-value targets. These controls tend to break down in self-hosted runner estates with broad network reach and persistent credentials because compromise can move from a single pipeline into multiple registries.

Common Variations and Edge Cases

Tighter release control often increases operational overhead, so organisations must balance developer velocity against publication risk. That tradeoff is most visible in open-source projects, multi-package monorepos, and teams that publish from third-party CI services where policy enforcement is uneven.

There is no universal standard for every package ecosystem yet, but current guidance suggests treating direct publishing as an exception and requiring stronger evidence for release authenticity. In ecosystems that support signed provenance, consumers should validate both artifact integrity and the identity of the workflow that produced it. In ecosystems without mature provenance support, the fallback is stricter token governance, manual release approvals, and monitoring for anomalous publish events.

Edge cases also matter. Some teams allow maintainers to publish manually during emergencies, but that process should still use short-lived credentials and an auditable approval trail. Internal package registries are not inherently safer than public ones if the same publishing token can be reused across environments. NHIMG’s broader breach analysis in the 52 NHI Breaches Analysis reinforces a simple lesson: trusted automation becomes a supply chain weakness when identity, provenance, and revocation are not enforced together.

Related resources from NHI Mgmt Group

• Why do CI and package-maintainer secrets create outsized supply chain risk?
• Why do AI-generated package choices create more supply chain risk than normal developer workflows?
• Why do hallucinated packages create supply-chain risk even when the model is not directly compromised?
• Why do stale package publishing rights increase supply chain risk so much?