Use different identities for compiling, testing, and releasing software, and make release rights short-lived and task-scoped. That way, a compromised build environment cannot independently publish trojanised packages or alter the software supply chain under a trusted maintainer identity.
Separate build authority from release authority
Build and test identities should be able to compile, validate, and produce artifacts, but not publish them. Release authority should sit with a different identity that is short-lived, task-scoped, and tied to a specific promotion step. That separation reduces the chance that a compromised CI runner, developer workstation, or dependency job can act as the trusted maintainer for the package.
Practically, this is a provenance and trust-boundary decision as much as an access-control decision. If the same principal can both create artifacts and push them to a registry, the registry no longer distinguishes an approved release from a poisoned one. Teams should treat the publish action as a separate security event with its own approval path, credentials, and audit trail.
A useful way to think about the control is that the build system proves the software can be produced, while the release system proves the software is allowed to leave the trust boundary. That distinction becomes especially important when packages are consumed by many downstream projects, because one over-broad identity can turn a single compromise into a supply-chain event.
What authority needs to be split in practice?
The split is not just between people, it is between operational roles. A compiler, test runner, or packaging job may need read access to source, dependency mirrors, and internal build services. The publisher needs write access to the package registry, signing material, or release automation, but it should not inherit unrestricted build privileges. Keep those permissions separate even when the workflow is automated end-to-end.
Different identities also make it easier to scope credentials to the smallest viable action. Build identities can be rotated aggressively and discarded after use, while release identities can be constrained to one repository, one environment, or one release window. If your platform supports it, use ephemeral credentials and approval gates so the release step cannot be replayed outside the intended pipeline state.
This is where release integrity depends on identity hygiene. A package registry, signing service, or deployment workflow may be technically reachable from the build system, but reachability is not the same as authority. The question is whether the same actor can both introduce and bless the artifact; if yes, the control is too weak.
How to keep the separation meaningful over time
The separation only works if teams preserve it across automation changes, emergency fixes, and local exceptions. A common failure mode is gradually reusing a convenient maintainer token in build jobs because it shortens the pipeline. Another is granting publish rights to a shared service account so multiple teams can ship faster. Both patterns collapse accountability and make compromise harder to contain.
Teams should also review whether package publishing depends on long-lived secrets stored in build systems. That creates a second path around the intended separation, because the build environment can become the release identity through credential theft. Open source supply chain guidance from OpenSSF and build provenance models such as SLSA both reinforce the same principle: the entity that assembles software should not be the one that unilaterally vouches for and publishes it.
Risk and Threat Considerations
This control matters because package publishing authority is a high-value trust boundary. If attackers steal build credentials or compromise a CI runner, they may be able to publish malicious packages under a legitimate maintainer path unless release rights are separated and tightly constrained. The risk is not only compromise, but also silent persistence through trusted software distribution.
Failure mechanism: A build identity that can also publish packages, or can reuse a maintainer secret, allows a compromised pipeline to convert normal build access into trusted release authority.
Impact: Malicious artifacts can be released with the apparent legitimacy of an approved maintainer, increasing downstream blast radius, incident scope, and recovery effort.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Build and release separation is central to artifact provenance and trusted publishing. |
| Recommendation — Separate build and release identities to preserve artifact provenance and prevent unauthorized publishing. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Release identities with build and publish rights are overprivileged by design. |
| Recommendation — Limit release identities so they can publish only the intended package or environment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived release authority depends on tightly managed credentials and rotation. |
| Recommendation — Rotate and expire publishing credentials so build access cannot be reused for release. | ||
| CIS Controls v8 | CIS-5 — Account Management | Separating build and publish authority requires distinct accounts and controlled privileges. |
| Recommendation — Use separate accounts for build, test, and publish steps with narrowly assigned privileges. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about separating access rights for different delivery functions. |
| Recommendation — Define distinct access rights for build and publishing workflows and enforce least privilege. | ||
Practitioner Guidance
What to verify: Confirm that the identity used for compilation has no direct write path to the package registry, signing key, or release automation. If a pipeline token can both build and publish, the separation is not real.
Decision rule: If release access is needed to ship software, make it ephemeral, environment-specific, and bound to one task or promotion step. If the same credential would still be valid after the job completes, it is too durable for release authority.
Common mistake: Teams often protect the registry but leave the build system as an implicit publisher through cached secrets, shared service accounts, or manually copied tokens. That defeats the purpose of role separation even when the permission model looks clean on paper.
Practitioner takeaway: Treat publishing as the most privileged part of the delivery chain, and design the pipeline so a successful build still cannot become an unauthorized release without a separate, auditable authority step.