CI controls reduce the number of bad artefacts that ever exist. Runtime admission is still necessary, but it only catches what reaches the cluster. If build pipelines can create non-compliant images freely, the organisation ends up using admission control as a late filter instead of a preventive governance layer.
Why cluster admission does not replace pipeline control
Kubernetes admission is a last gate, not a creation control. It decides what can start in the cluster, but it does not stop a flawed build from producing an image with a baked-in secret, a dangerous dependency, or an unwanted binary that may later be used elsewhere. CI controls reduce the supply of bad artefacts before they become reusable risk.
That distinction matters because runtime policy only sees what reaches the cluster. If the build stage is permissive, teams can accumulate untrusted images, leak secrets into layers, or publish artefacts that later move into other clusters, registries, or environments. Preventive controls therefore shape the artefact population, while admission limits blast radius.
Good CI controls include source, dependency, and image checks that fail the pipeline when policy is not met. They are strongest when the organisation treats image creation as part of security governance, not as a purely developer convenience step. A runtime deny rule is useful, but it is not a substitute for preventing non-compliant artefacts from existing in the first place.
What CI controls change in the attack and failure model
Without pipeline controls, the security team is left to detect problems after artefacts have already been built, tagged, and potentially promoted. That shifts effort from prevention to triage. It also creates a common failure mode where a cluster is well policed, but the registry and build system quietly continue to generate images that violate policy or carry hidden credentials.
This is especially important for container supply-chain hygiene. Secrets in Docker Hub images (RWTH Aachen study) shows why runtime-only defence is too late when secrets are already embedded in image layers. A build-time gate can stop that artefact from being published, scanned, promoted, or reused.
Pipeline enforcement also reduces dependency on perfect runtime inspection. NIST SP 800-190 Container Security treats the image, registry, orchestrator, and runtime as separate risk points, which is the right mental model here. If one layer is weak, the others may still fail safely, but only if the earlier layer is doing real preventive work.
How to balance build-time policy with runtime admission
The practical answer is to use both. CI should validate what is allowed to be built, signed, stored, and promoted, while admission should reject anything that slips through or arrives from an untrusted path. The two controls solve different problems: CI reduces the volume of bad artefacts, and admission reduces the chance that a bad artefact becomes an active workload.
For teams operating multiple clusters or shared registries, this layered model is easier to govern than relying on cluster-by-cluster enforcement alone. Kubernetes Security Guide covers the relationship between admission control, runtime security, and supply chain hardening, which is exactly the control stack this question depends on.
Where organisations struggle is in assuming that “blocked at deploy time” equals “secure.” It does not. A blocked image can still indicate that the build process is producing forbidden output, and that should trigger correction upstream, not complacency downstream. The cluster is the enforcement point, but the pipeline is where governance becomes scalable.
Risk and Threat Considerations
If CI is weak, the organisation can end up with a hidden inventory of bad artefacts, including images with secrets, unsafe packages, or unreviewed changes. Runtime admission limits where those artefacts can execute, but it does not erase the exposure created by producing them, storing them, or reusing them in another environment.
Failure mechanism: A permissive pipeline allows non-compliant images to be built, tagged, and distributed before any cluster policy sees them. Attackers and careless changes alike can exploit that gap by moving from build artefact to registry to deployment, or by harvesting embedded secrets from image layers.
Impact: Organisations may overestimate the protection provided by admission control, while still exposing registries, developers, and downstream environments to secret leakage, policy drift, and repeated release of untrusted artefacts.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | CI policy gates changes to container artefacts before release. |
| SI-7 — Software, Firmware, and Information Integrity | Build controls help prevent tampered or non-compliant images from entering use. | |
| SA-10 — Developer Configuration Management | Pipeline governance depends on controlled build inputs and outputs. | |
| Recommendation — Enforce approval and testing before container images are built or promoted. Validate artefacts before release and block untrusted image content. Control source, dependency, and build artefacts across the CI pipeline. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Software delivery controls are central to preventing bad container artefacts. |
| Recommendation — Add security checks into CI so unsafe images never reach deployment. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | Image signing and validation support artefact integrity before runtime. |
| Recommendation — Verify container artefact integrity before allowing promotion or deployment. | ||
Practitioner Guidance
What to verify: Confirm that the CI pipeline fails closed on policy violations, not just warns, and that the same image policy is enforced before promotion as well as at cluster admission. If the pipeline can still publish a non-compliant image to a trusted registry, the control is incomplete.
What good looks like: A compliant build produces a signed, reviewed artefact; a non-compliant build is stopped before it can be reused; and any admission denial creates an upstream corrective action, not a one-off deployment exception.
Practitioner takeaway: Admission control is a necessary backstop, but mature governance starts earlier, where bad artefacts are created, because preventing risky images is more scalable than filtering them after they already exist.