Should teams treat container policy as a runtime issue or a build issue?

For most compliance objectives, it should be treated first as a build issue. Runtime controls matter, but they cannot correct a non-compliant artefact that has already been promoted. The stronger pattern is to stop bad images early, then use runtime monitoring as a second line of defence rather than the primary compliance mechanism.

Build-time controls set the compliance baseline

Container policy belongs first in the build pipeline because that is where you can prevent non-compliant artefacts from ever reaching a registry or cluster. Policy checks at build time are the right place to enforce image provenance, approved base images, package hygiene, and hard requirements such as no embedded secrets, no privileged defaults, and no disallowed configuration.

That matters because once an image is built, signed, tagged, and promoted, runtime controls can detect or contain abuse, but they cannot make the artefact itself compliant. If the image was already defective at build time, the operational problem becomes exposure management rather than true compliance.

Where runtime policy still matters

Runtime controls are still essential, but they serve a different purpose. They enforce deployment-time and in-use boundaries such as blocking privileged containers, restricting host access, limiting capabilities, and watching for drift from the approved runtime posture. In practice, runtime policy is the second line of defence that reduces blast radius when a bad image slips through or when a clean image is later abused.

For container teams, the useful distinction is between preventing bad supply into the platform and constraining behaviour after admission. The first is a build quality question, the second is an operational containment question. Treating them as the same control usually leads to gaps, especially when people assume that monitoring in production can compensate for weak build governance.

How to decide what to enforce where

The cleanest pattern is to make build policy the gate for artefact quality and runtime policy the gate for execution safety. Build-time checks should fail the pipeline when an image violates policy, while runtime should alert or block when the running workload attempts to exceed its allowed privileges or deviates from expected behaviour.

That separation is especially important for teams that use shared base images or frequent rebuilds. A single weak image can spread policy debt across many services, so the most efficient control point is the earliest one that can still stop promotion. Runtime controls then protect the cluster from residual risk, but they should not be treated as a substitute for fixing the image source.

Risk and Threat Considerations

Runtime-only enforcement leaves a gap where a non-compliant image can be promoted, replicated, and reused before anyone notices. That creates exposure not just to policy failure, but also to credential leakage, privilege misuse, and persistence inside containers that should never have been allowed into production.

Failure mechanism: A flawed image passes through build and promotion, then runtime controls see only the deployed workload and cannot undo embedded secrets, insecure defaults, or inherited trust that were baked into the artefact.

Impact: Teams may end up containing an incident while still carrying an untrusted artefact lineage, which complicates auditability, increases blast radius, and makes remediation slower because the underlying image source remains uncorrected.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply Chain Levels for Software Artifacts	Build-time image policy depends on artifact provenance and integrity.
Recommendation — Apply SLSA practices to attest and verify container build provenance before promotion.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Container policy here centers on preventing insecure images and configurations from shipping.
Recommendation — Enforce secure baseline configuration checks before container images are released.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	The question is about establishing compliance in build-time container baselines versus runtime drift.
	SI-7 — Software, Firmware, and Information Integrity	Runtime cannot fix a defective artefact, so integrity checks matter at build and promotion time.
Recommendation — Define and approve container baselines before deployment. Validate image integrity and reject tampered or unapproved artefacts.
OWASP ASVS	V13 — Configuration	Container policy is fundamentally about secure configuration enforcement before execution.
Recommendation — Verify container configurations are hardened before release.

Practitioner Guidance

What to prioritise: Put policy-as-code into the build pipeline first, and make promotion contingent on passing image, provenance, and configuration checks. Use runtime controls to narrow privileges, detect drift, and constrain impact, not to validate whether the image should have been admitted in the first place.

What to verify: Confirm that your build gate checks the exact artefact that will be deployed, not an upstream template or a later mutable tag. Also verify that runtime policy is aligned with the build decision, so you are not approving one posture in CI and enforcing a different one in production.

Practitioner takeaway: The strongest container control model is sequential, not either-or: stop bad images before they ship, then use runtime enforcement to contain anything that still gets through.