Who should control the final package upload decision?

Why the release decision must be separated from the build path

The control point should not live inside the same build job that creates the package. If the build environment can also approve and publish, then any compromise of the compiler, dependency install step, or CI runner can turn into an authorised release. A separate publishing identity forces a second trust boundary, so verification must complete before anything can be uploaded.

That separation is less about process purity and more about reducing blast radius. The build job can prepare artifacts, but it should not hold the privilege that turns an artifact into a published release. A dedicated publishing identity, scoped only to the release action, preserves a clean separation between creation, verification, and distribution.

What the publishing identity is responsible for

The publishing identity should be the only actor allowed to perform the final upload after policy checks pass. In practice, that means it acts as a release gate, not a general-purpose automation account. It should receive only the minimum permissions needed to upload a verified package, and nothing that helps it alter source, rebuild artifacts, or bypass review.

This model works best when the identity is treated as a release credential rather than a build credential. The build system produces the candidate package, verification checks its integrity and provenance, and the publishing identity completes the last mile. That design makes it much harder for a compromised build step to quietly promote its own output.

Why this matters for package integrity and supply-chain trust

Package publishing is a supply-chain control point, because it determines what downstream users will trust and install. If an attacker can reach the upload step from inside the build path, they can replace or poison the package before it is released. That is why the final decision belongs to a separate actor that can only publish after verification succeeds.

Strong supply-chain programmes also rely on upstream hygiene and provenance assurance. Resources such as OpenSSF and the SLSA framework help teams think about build integrity, trusted provenance, and release confidence as separate controls. The practical takeaway is that upload authority should confirm trust, not create it.

Risk and Threat Considerations

If the build path can also publish, a single compromise can become an immediate supply-chain incident. Attackers look for exactly that shortcut, because release authority lets them move from code execution in the pipeline to durable distribution of malicious or tampered artifacts.

Failure mechanism: a compromised build runner, dependency step, or CI secret is reused to authenticate the upload, so the attacker can ship a package without needing a separate release approval.

Impact: users may install a poisoned package, downstream environments inherit the compromise, and rollback becomes harder because the bad release appears legitimate.

Practitioner Guidance

What to verify: confirm that the publishing identity is distinct from the build identity and that build credentials cannot be reused in the upload stage. The clean test is whether a successful build compromise would still fail to publish without a separate release action.

Decision rule: if the account can both create and publish, split it. If it can publish only after a verifiable gate, keep it tightly scoped to that single release privilege.

Common mistake: teams often protect source control well but leave the package registry token in the same workflow as the build. That collapses the control boundary and makes approval a formality rather than a barrier.

Practitioner takeaway: treat publishing as a privileged release act, not a build convenience, because the safest package pipeline is the one where the final upload can only happen after an independent trust check.

Related resources from NHI Mgmt Group

• How do security teams know whether package installation risk is under control?
• How can organisations know whether package-related secret exposure is actually under control?
• What breaks when teams treat OAuth scope as the final authorization control?
• How should organisations govern access control when decision-making moves to the edge?