Assign each stage its own policy, identity checks, and review requirements. Source governance should control who can change code, build governance should prove how artifacts were produced, and publish governance should control who can release. When those stages are merged in practice, the weakest one becomes the bypass path.
Separate the trust boundaries before you assign the controls
Source, build, and publish trust answer different questions, so they should fail independently. Source trust is about who may change code and under what review. Build trust is about whether the artifact was produced by the expected process. Publish trust is about who may release that artifact into the consumable channel. Treating them as one control makes it easy for a single compromise to cover the whole path.
The practical benefit of separation is that each stage gets its own decision point, evidence, and owner. That lets teams distinguish a code review failure from a build integrity failure or a release authorization failure, instead of collapsing all three into a vague “trusted pipeline” statement. It also makes it easier to spot when a control is present but attached to the wrong stage.
In mature teams, the source stage is usually where change authority is narrowest, the build stage is where provenance is strongest, and the publish stage is where blast radius is largest. The controls should reflect that progression, not blur it.
How stage-specific governance works in practice
Source governance should focus on change control: branch protection, peer review, commit signing where appropriate, and clear rules for who can merge. Build governance should focus on provenance and reproducibility: controlled builders, signed artifacts, traceable dependencies, and evidence that the artifact matches the approved source. Publish governance should focus on release authority: who can promote, who can sign off, and which environments or registries are eligible for release.
Those stages are related, but they are not interchangeable. A strong source review does not prove the build was clean, and a clean build does not prove the wrong artifact cannot be published. A useful way to test the design is to ask whether each stage can be bypassed without automatically bypassing the others. If the answer is yes, the separation is working.
Teams often get the most value when the controls are enforced with different identities or roles for each stage. That does not mean adding bureaucracy for its own sake. It means ensuring that compromise or misuse in one stage does not silently grant authority in the next.
Why weak-stage merging becomes the bypass path
When source, build, and publish trust are merged, the weakest control tends to inherit the authority of the strongest one. A release process that depends on one shared approver, one shared system, or one shared signing step gives attackers and mistaken insiders a single place to concentrate their effort. The same problem appears when a CI system can both build and publish without a separate release decision.
That pattern creates a high-value trust bridge: if the build system is compromised, publication may follow automatically; if a release identity is overpowered, it can also alter source or build inputs. Separating the stages forces an attacker to cross multiple checkpoints, and it forces defenders to see which checkpoint failed first.
It also improves incident response. If the artifact is suspicious, teams can ask whether the issue came from source tampering, compromised build infrastructure, or unauthorized release promotion. Without separation, that root-cause question becomes much harder to answer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Source, build, and publish trust are core software supply-chain integrity concerns. |
| Recommendation — Use SLSA to separate provenance, build integrity, and release trust across the pipeline. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Source governance depends on controlled code changes and approved modification flow. |
| SA-10 — Developer Configuration Management | Build and publish trust rely on controlled construction of artifacts and traceability to source. | |
| CM-5 — Access Restrictions for Change | Publish governance needs explicit restriction on who can promote or release trusted artifacts. | |
| Recommendation — Apply CM-3 to require review and approval before source changes are merged. Use SA-10 to manage build inputs, artifact provenance, and configuration traceability. Apply CM-5 to limit release authority to approved roles and paths. | ||
Practitioner Guidance
What to prioritize: Start by defining the trust decision that belongs to each stage, then assign the minimum identity and approval model needed for that decision. The point is not to duplicate controls, but to make each stage independently defensible.
What to verify: Confirm that a code reviewer cannot publish directly, a build system cannot silently self-authorize release, and a release approver cannot alter source history without a separate path. If any one of those is true, the boundary is too soft.
Common mistake: Teams frequently invest in strong artifact signing and assume the whole pipeline is trusted. Artifact integrity helps, but it does not replace source governance or release governance.
Practitioner takeaway: The best test is simple: if one stage is compromised, the other two should still force a new decision before trust is extended further.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org