How should teams combine admission control and runtime integrity for supply chains?

Why Admission Control and Runtime Integrity Need to Work Together

Admission control and runtime integrity address different failure points in the supply chain, so treating them as substitutes leaves a gap. Admission control is about deciding whether an artefact is trustworthy enough to enter the environment; runtime integrity is about preserving that trust after launch. Teams get the strongest outcome when the approval decision and the enforcement layer are both present.

That split matters because supply chain compromise can happen before deployment, during deployment, or after an approved artefact is already running. A clean admission process stops obvious bad packages, unsigned builds, and unapproved dependencies, but it cannot guarantee that a running workload stays unchanged. runtime control are the backstop when the approved state is altered through tampering, drift, or post-deploy abuse.

The practical question is not which control is better, but where each one draws its boundary. If admission control checks provenance, signature, policy, or allow-list status, it answers “may this run?” If runtime integrity checks hashes, file state, process state, configuration, or attestation, it answers “is this still what we approved?” Used together, they close the common false assumption that a trusted start implies a trusted runtime.

What Each Control Should Enforce

Admission control should be strict enough to stop unverified artefacts before they reach production, but narrow enough to avoid becoming a manual bottleneck. In practice that means requiring known provenance, validated signatures, policy-compliant dependencies, and release artefacts that match the expected build path. SLSA is a useful external reference point for this build-provenance side of the problem, because it focuses on whether the artefact was produced and verified in a way teams can trust.

Runtime integrity should be configured to detect or prevent drift after launch, not merely to log it after damage has occurred. That includes watching for modified binaries, altered containers, unexpected processes, changed startup arguments, tampered libraries, and configuration drift that invalidates the original approval decision. For containerised environments, NIST SP 800-190 Container Security is directly relevant because it addresses image, registry, orchestrator, and runtime risk as a continuous control problem.

Admission and runtime also need separate evidence trails. If a release was approved, teams should be able to show what was verified at the gate and what was monitored after deployment. That distinction makes investigations faster, because a failure can be localised to source provenance, build integrity, deployment policy, or runtime tampering instead of being treated as a single vague “supply chain” issue.

Where Teams Usually Get the Design Wrong

The common mistake is to over-invest in one layer and assume it covers the other. Some teams rely on admission checks and never verify that the running artefact still matches the approved state. Others add runtime detection but allow weak admission, which means they are continuously monitoring software that should never have entered the environment in the first place. Both patterns create avoidable exposure.

Another failure mode is policy drift between the gate and the runtime baseline. If the admission rule approves one artefact hash, one signer, or one dependency set, but runtime integrity is keyed to a different record, teams get noisy exceptions that nobody trusts. When the approval record and runtime baseline are not aligned, people start bypassing controls instead of improving them.

It also matters that supply chain compromise is often a sequence, not a single event. Attackers may first exploit a developer token, CI system, or upstream package, then rely on weak runtime monitoring to stay hidden after deployment. A useful supply chain control design assumes that one layer may fail and makes the next layer independent enough to still detect the problem.

Practitioner Guidance

What to prioritise: Put the admission rule on the artefact itself, then make runtime integrity prove that the artefact and its execution environment still match what was approved. If one control exists without the other, treat the gap as a design defect rather than a maturity issue.

Decision rule: If the question is “should this be allowed to deploy?”, use admission control; if the question is “has this changed since deploy?”, use runtime integrity. If teams cannot answer both questions with different evidence, the control boundary is too weak.

What good looks like: The approved artefact, its provenance record, and its runtime baseline should all be linkable so that a drift alert or failed attestation points back to a specific release decision. That linkage is what turns supply chain assurance from a paperwork exercise into an operational control.

Practitioner takeaway: The strongest supply chain posture treats admission as the trust gate and runtime integrity as the trust guardrail, with each control designed to fail independently and surface different classes of compromise.

Related resources from NHI Mgmt Group

• When should cloud teams combine admission control with runtime allowlisting?
• How should teams combine SAST and DAST in a secure development programme?
• How should security teams reduce zero-day risk in software supply chains without relying on a single control?
• Should teams prioritise supply chain integrity or runtime isolation for AI systems?