They should align them into a single admission model. If provenance checks and execution controls live in different processes, teams can approve software that was built or introduced through an unexpected path. Joining those decisions reduces the chance that trusted delivery pipelines become blind spots for malicious or unintended code.
Why a Single Admission Model Is the Right Boundary
When build provenance and execution policy are split, each control can appear correct on its own while still leaving a gap between “this artifact was built trustworthily” and “this artifact is allowed to run here.” A single admission model closes that gap by making one decision about what can enter the environment, based on both lineage and policy conditions.
That boundary matters because provenance without enforcement is only evidence, and enforcement without provenance can approve the wrong thing. Teams should treat admission as the place where supply-chain trust becomes an operational allow or deny decision, rather than letting separate processes drift into inconsistent outcomes.
For build integrity controls, the core question is whether the platform can evaluate the artifact, its provenance, and its intended execution context together. If those checks happen in different pipelines or by different owners, the organisation can end up trusting a package that passed one gate but bypassed the other.
What Breaks When the Checks Stay Split
Separated checks create blind spots in exactly the situations that are hardest to notice during normal delivery. A code path may satisfy provenance requirements but still enter through an unexpected repository, cluster, runner, or deployment lane that never sees the policy decision.
That is how trusted delivery systems become a bypass channel. If the policy engine cannot see provenance, or the provenance verifier cannot influence execution, teams may approve software that was introduced by an unintended path, with the wrong signer, or under conditions that should have failed review.
For practitioners, the practical failure mode is not only malicious tampering. It is also accidental policy drift, where one team updates provenance rules and another updates runtime controls later, leaving a period where neither control truly governs admission end to end.
How Teams Should Organize Admission, Provenance, and Policy
The cleanest approach is to make provenance checks and execution policy part of one admission decision, with one authoritative record of what was evaluated and why it was allowed. That can be implemented in different ways, but the operating principle is the same: no artifact should be admitted unless it satisfies both trust and policy conditions at the same checkpoint.
Teams should also keep the decision close to the execution boundary, because that is where the final context is known. If the environment distinguishes build-time trust from deploy-time control, admission logic should join them so that the runtime system can reject software that arrived through an unapproved path even if the build evidence looks acceptable.
This is one reason provenance systems align naturally with SLSA and with a pipeline-focused identity and trust model. The goal is not just stronger attestations, but a single place where those attestations influence whether code can actually execute, which is why NHIMG’s CI/CD Pipeline Identity Security Guide is a useful companion for delivery teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Covers integrity verification for software before it runs. |
| CM-3 — Configuration Change Control | Applies because admission policy and deployment controls need coordinated change governance. | |
| Recommendation — Bind admission to integrity checks so only verified artifacts can execute. Change provenance and execution policy together under one approved control process. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Directly addresses build provenance and artifact trust in delivery pipelines. |
| Recommendation — Require provenance evidence at admission before allowing deployment. | ||
Practitioner Guidance
What to prioritise: Define the admission point first, then decide which provenance checks and execution controls must be evaluated together at that point. If the answer is “not together,” the model is still split and the blind spot remains.
What to verify: Confirm that a denied provenance condition cannot be overridden by a separate runtime path, and that an approved build cannot skip execution policy by arriving through an alternate delivery lane. Test the exact failure cases, not just the happy path.
Common mistake: Treating provenance as a build-team concern and execution policy as an operations concern. That separation looks tidy on paper, but it usually creates inconsistent enforcement at the exact moment you need a single decision.
Practitioner takeaway: Admission should be the control point where trust evidence and runtime permission are inseparable, because any gap between them is a path for unintended code to look legitimate.
Related resources from NHI Mgmt Group
- How should security teams build resilience when identity, recovery, and operations are managed separately?
- How should security teams design access control when roles, object tags, and policy decisions are all managed separately?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?