What breaks when package publishing is not separated from build and runtime identities?

When publishing is not separated from build and runtime identities, any process that reaches the registry can turn into an exfiltration path. Attackers can package collected data inside valid archives, publish them with a reusable token, and retrieve them later. The control failure is not the package format, but the absence of lifecycle-scoped publishing privilege.

Why This Matters for Security Teams

When package publishing uses the same identity as build and runtime, the registry becomes an extension of the build pipeline instead of a controlled release boundary. That collapses separation of duties, makes provenance harder to prove, and turns a routine publish into a potential exfiltration channel. The risk is especially visible in supply chain incidents like the LiteLLM PyPI package breach, where package distribution and credential exposure intersected. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains clear that access and release functions should be bounded by least privilege, but package ecosystems often blur those boundaries in practice.

For security teams, the core issue is not whether the archive format is trusted. The issue is whether the identity used to publish can also read, stage, sign, or transmit data outside the intended release path. When those permissions are combined, a compromised build step or developer token can quietly become a covert export mechanism. In practice, many teams discover this only after a malicious publish, token leak, or suspicious package version has already moved data out of the environment.

How It Works in Practice

The safer model is to split identities by lifecycle stage: one identity for build, one for publish, and a different identity for runtime. Build identities should assemble artifacts and validate dependencies, but they should not have direct registry write rights unless the workflow is explicitly promoting a vetted release. Publish identities should be tightly scoped, short-lived, and issued only when the artifact has passed policy checks. Runtime identities should consume packages and call services, but not create or overwrite distributable artifacts.

This pattern is strongest when paired with ephemeral credentials and workload identity rather than long-lived secrets. Current guidance suggests using JIT issuance for publishing, backed by signed attestations and policy checks at release time. That is consistent with broader NHI governance: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the condition that makes a publish token dangerous when reused beyond its intended scope.

Operationally, teams should align package publishing with these controls:

• Use separate workload identities for build, publish, and runtime.
• Issue publish credentials just in time and revoke them immediately after release.
• Restrict registry write access to a single, policy-gated release path.
• Log provenance, artifact hash, and publisher identity for every release.
• Block direct publishing from developer machines and generic CI runners.

Where possible, pair policy-as-code with registry checks so that a publish is allowed only when the request matches the expected artifact, environment, and signer. These controls tend to break down in shared CI pipelines that reuse one token across multiple repositories because a compromise in any job can inherit publish authority.

Common Variations and Edge Cases

Tighter publishing controls often increase pipeline complexity, requiring organisations to balance release speed against stronger isolation. That tradeoff is real, especially in small teams that want a single CI secret for simplicity. Best practice is evolving, but there is no universal standard for how much privilege a publish job should inherit from build automation. The deciding factor is whether the identity can be reused to move data or artifacts outside the intended release scope.

Edge cases appear when package managers support pre-release hooks, post-install scripts, or mirrored registries. A build identity that can invoke those paths may still leak data even if it cannot directly overwrite a package. The same concern applies when runtime containers reuse build tokens, or when a release process signs artifacts in one step and publishes them in another without separating trust domains. The Code Formatting Tools Credential Leaks research is a reminder that tooling convenience often hides secret sprawl, while the JetBrains GitHub plugin token exposure shows how quickly a reusable token can become a supply-chain issue.

For organisations with mature release engineering, the practical test is simple: if a compromised build job can publish, then build and release are not separated enough. If a runtime workload can access publish credentials, then the boundary has already failed.

Related resources from NHI Mgmt Group

• What breaks when package publishing identities are compromised?
• What breaks when a Go typosquat preserves the same API as the real package?
• What breaks when a malicious package can run install-time scripts in CI?
• How should organisations respond when a package ecosystem attack exposes machine identities?