Container Security

Container Supply Chain Defence: Build To Run

An end-to-end view of container supply chain controls from source through registry to runtime, covering signing, attestation, admission policy, and runtime drift, with concrete checkpoints at each stage.

Nayan Dey
Senior Security Engineer
7 min read

The phrase "supply chain security" started in containers as a slogan and ended up as a checklist. Every cloud-native vendor has a story about signing. Every conference talk references SLSA levels. The lived experience inside engineering organisations is messier. Signing is wired up but not enforced. Attestations are generated but never read. Admission controllers are installed in audit mode and quietly forgotten. The result is a supply chain that looks defended on a slide and is mostly performative on the cluster.

This post walks the chain end to end and names a defensible control at each stage. The goal is not maximalism. The goal is a defence that survives the first incident.

Source: The Earliest Useful Boundary

Source control is where supply chain risk begins. Most organisations protect main branches with required reviews and status checks. Fewer protect the build configuration itself. Dockerfiles, build scripts, and CI workflow files are where attackers prefer to inject, because changes there propagate to every artifact built afterwards.

Three controls pay off here. Branch protection on build configuration files, enforced through a CODEOWNERS entry that routes any change through the platform team. Signed commits required on the protected branch, with verification that the signing key is registered to a current employee. And a static check that catches the easy patterns: a curl bash pipe, a download from a non-allowlisted registry, a pip install of a wheel from a public S3 bucket.

These do not stop a determined adversary. They do filter out the common script-kiddie attempts and the legitimate engineer who has a deadline and a laptop and a stack overflow tab open.

Build: Determinism And Provenance

Build is where the supply chain story most often breaks down. A reproducible build matters less than a verifiable build. Reproducibility is hard. Verifiability is achievable.

The minimum bar in 2026 is that every container image produced by the organisation carries an in-toto provenance attestation describing what was built, where, and from which source. The attestation should be signed by a build-system identity that cannot be assumed by any single human. GitHub Actions OIDC tokens, GitLab Sigstore integration, and ephemeral keyless signing all work fine. The point is that the signature traces to the build system, not to a long-lived service account whose key sits in a HashiCorp vault.

The provenance should record at minimum the source commit hash, the builder identity, the build command, and the materials consumed. Most modern builders emit something like SLSA level three by default. The job is to verify it downstream rather than to discard it.

Registry: The Single Choke Point

The registry is the most powerful single point of control in the entire chain. Everything has to pass through it, and everything that does pass through can be inspected, signed, and attested. Treating the registry as a passive blob store wastes that leverage.

Practical registry policy looks like this. Push requires authentication tied to a build identity. Push triggers a synchronous scan against a vulnerability database and an SBOM emission. The image manifest gets a Sigstore signature attached, and the SBOM gets attached as a referrer. Tags become advisory; digest references become canonical.

Public registries are mirrored, never pulled directly. Mirror sync is a scheduled job that fetches by digest, verifies provenance if available, and stores the result internally. Direct pulls from the public internet from a build runner is a finding, full stop.

Admission: The Policy Gate That Actually Holds

Cluster admission is where the supply chain story gets enforced or quietly abandoned. The pattern that fails is installing an admission controller, putting it in warn mode, and waiting for someone to flip the switch. The switch never flips because the warning queue is full of legitimate workloads that do not yet meet the policy.

The pattern that works is to enforce admission progressively, namespace by namespace, with a clear list of policy clauses and a clear waiver process. The clauses we run today are: image must be from an allowlisted registry, image must be referenced by digest, image must have a verifiable Sigstore signature whose subject matches a known build identity, image must have a recent SBOM available, and image must not be on the quarantine list.

Each clause has a structured exception path. The exception requires an issue, a justification, an expiry date, and a named owner. Permanent exceptions do not exist; expiring ones renew on quarterly review. This sounds bureaucratic until the first time a quarantined image gets pulled and the system stops it without a human being in the loop.

Runtime: The Last Honest Witness

Runtime is the only stage where you observe what the workload is actually doing rather than what it claims it will do. Supply chain attacks that survive the earlier gates show up here, usually as anomalous outbound network connections, unexpected child processes, or modifications to the container filesystem.

Two controls deliver most of the value. Per-pod baseline of expected processes and network destinations, generated automatically during a calibration period and locked down afterwards. And drift detection that compares the running container filesystem to the image manifest, flagging any modification that did not come from a controlled volume mount.

Runtime drift in particular is a high signal indicator. Legitimate workloads generally do not modify their own filesystems. When they do, it is almost always a misconfigured init container or an attacker who pulled in a tool after the fact. Either way, the security team wants to know.

Evidence Loop: Closing The Audit

The chain is only as defensible as its evidence trail. Each stage should produce structured evidence that a human or a regulator can examine without reverse-engineering log lines.

The minimum evidence set per image is a signed provenance attestation, an SBOM, a vulnerability scan result, an admission decision record, and a runtime baseline. All five are stored together, keyed by image digest, and queryable. When an auditor asks for the supply chain controls applied to the image running in production at a specific moment, the answer is a single query, not a forensic exercise.

This is also where most organisations underinvest. The controls are wired up, but the evidence is scattered across five tools that do not share keys. A unified evidence store turns supply chain defence from a series of point controls into a coherent posture.

The Failure Modes To Watch

Three failure modes recur. Signature theatre, where signing is configured but admission does not verify it. Attestation rot, where attestations are generated but never read because no policy references them. And gate fatigue, where engineers learn the waiver process well enough that exceptions become the default path.

The countermeasure to all three is the same. Audit the gates as carefully as you audit the workloads. Run a quarterly review that picks ten random production images and walks every gate they passed through, looking for clauses that were skipped, exceptions that lingered, or evidence that was missing. The first quarter of that review will be embarrassing. The second will be informative. By the fourth, the gates will hold.

How Safeguard Helps

Safeguard implements the chain as a single coherent product rather than a stack of point tools. The build attestation collector ingests SLSA provenance from the major CI systems and stores it keyed by image digest. The registry integration scans on push, emits and signs SBOMs, and feeds the policy engine. The admission webhook enforces signature, provenance, SBOM, and quarantine clauses with structured exceptions and expiry. The runtime agent watches for filesystem drift and process anomalies. And the unified evidence store ties all of it together so that a single query against an image digest returns its provenance, its SBOM, its scan results, its admission decisions, and its runtime baseline. That is what closes the audit and what makes the chain defensible in front of an auditor or a board.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.