Container Supply Chain Threats: The Attack Surface From Code to Cluster
After reading this guide
At a Glance
- Container supply chain threats target the pipeline (source, build, registry, deploy, runtime), not just the running container.
- Most incidents start long before deploy: poisoned dependencies, malicious base images, and tampered build steps.
- SBOMs (CycloneDX/SPDX) plus image signing (Sigstore/cosign) make tampering detectable.
- Admission control (OPA/Gatekeeper, Kyverno) blocks unsigned or non-compliant images at deploy.
- Runtime detection (Falco, eBPF) catches the threats that slip through.
- Hardening and shrinking images materially reduces the CVE count every other control must defend.
Container supply chain threats are attacks that compromise a container image or its pipeline before the image ever runs. They span five stages: source code, build, registry, deploy, and runtime. Each stage has a distinct attack surface and a set of controls - SBOMs, image signing, admission policy, and runtime detection - that reduces the risk.
What Are Container Supply Chain Threats?
Container supply chain threats are compromises introduced anywhere between when a developer writes code and when that code executes in a cluster. Unlike a runtime exploit that attacks a live service, a supply chain attack ships the malicious behavior inside the artifact itself, so it inherits the trust and privileges you already granted.
The distinction matters because the defense changes by stage. A web application firewall does nothing against a backdoored base image. You need controls that verify integrity at each handoff.
The pipeline has five stages, each with its own trust boundary:
| Stage | What moves through it | Primary trust boundary |
|---|---|---|
| Source | Application code and dependencies | Developer identity, dependency source |
| Build | Source compiled into an image | CI runner, build config |
| Registry | Image stored and distributed | Registry auth, image integrity |
| Deploy | Image admitted to the cluster | Admission policy, RBAC |
| Runtime | Container executing in the cluster | Kernel, namespace isolation |
How Does the Source Stage Become an Attack Surface?
The source stage is where most real-world compromises begin, because code pulls in far more third-party material than the team writes. A single malicious package in a dependency tree can execute at build or runtime with full project context.
Common threat classes at source:
- Dependency confusion or typosquatting: an attacker publishes a package with the same name as an internal dependency, and the resolver fetches the public, malicious copy.
- Compromised upstream libraries: a maintainer account is hijacked and a malicious version is pushed to a public registry.
- Malicious base images: a team builds FROM an untrusted image that already contains a backdoor or crypto-miner.
- Secrets in source: hardcoded credentials committed to a repo and later scanned by attackers.
Controls:
- Pin dependencies by hash (lockfiles) and use a private proxy or mirror for internal packages.
- Scan dependencies early with Trivy, Grype, or RapidFort Analyzer before they enter the build.
- Generate an SBOM (Syft or RapidFort Analyzer) as part of the source check-in so you always know what you ship.
- Treat the base image as a first-class dependency: use a vetted, minimal base.
What Threats Live in the Build and Registry Pipeline?
The build stage turns source into an artifact. If the build is not reproducible and unattested, an attacker who controls the CI runner or the build config can inject code that never appeared in your source repo.
Build-stage threat classes:
| Threat | How it works | Control |
|---|---|---|
| Poisoned build cache | Stale or tampered layers reused from cache | Invalidate caches, pin by digest |
| Compromised CI runner | Attacker runs code in the build context | Ephemeral runners, least privilege |
| Unattested build | No proof of how the image was made | SLSA provenance, in-toto attestations |
| Registry tampering | Image overwritten or pulled from wrong repo | Immutable tags, registry auth, signing |
The registry is the distribution chokepoint. If tags are mutable, an attacker who gains write access can push a malicious image over a good one without changing the reference. Signing the image with Sigstore/cosign and verifying the signature at pull time closes this: even if the registry is compromised, the signature check fails.
For provenance, SLSA defines a maturity model that moves builds from "builds identified" up to "hermetic, verifiable builds." in-toto attestations record exactly what steps produced an artifact, so a downstream consumer can verify the chain.
Where Do Deploy-Time Risks Appear?
Deploy is where policy meets the cluster. Even a clean, signed image can be deployed with dangerous configuration: privileged containers, mounted host paths, or excessive RBAC. These are not vulnerabilities in the image; they are vulnerabilities in how the image is run.
Deploy-time threat classes:
- Unsigned image admission: the cluster pulls and runs any image, signed or not.
- Privileged or host-namespace pods: a compromised container escapes to the node.
- Over-broad RBAC: a workload token can read secrets across namespaces.
- Missing network policy: lateral movement is unrestricted inside the cluster.
Controls:
- Enforce admission policy with OPA/Gatekeeper or Kyverno to require signed images and block privileged pods.
- Use a verifying image pull policy so only cosign-verified images are allowed.
- Apply CIS Benchmarks and NIST SP 800-190 guidance for pod security.
- Default to deny network egress and allow only what the workload needs.
A Kyverno-style requirement (conceptual) is to require a Sigstore signature and reject privileged: true. The policy is expressed as code and stored in git, so it is reviewable and auditable.
Which Runtime Threats Survive Into Production?
No pipeline control is perfect, so the runtime stage is your last line of defense. Threats that survive into production include a compromised image that passed every gate, a zero-day in a library, or a container that was deployed correctly but is now being abused.
Runtime threat classes:
| Threat | Signal | Detection |
|---|---|---|
| Container escape | Unexpected syscall to host kernel | Falco / eBPF rules |
| Crypto-mining | Spike in CPU, unknown binary | Process and network rules |
| Reverse shell | Outbound connection to unknown host | Network anomaly rules |
| Privilege escalation | Writing to sensitive paths | File and exec rules |
Runtime detection is behavioral. Falco uses eBPF to observe syscalls and fires rules on anomalous behavior, independent of whether the image was signed. Strong isolation runtimes such as gVisor or Kata Containers reduce the blast radius of an escape by placing the container in a sandboxed kernel or VM, complementing runc at the cost of some performance and compatibility.
How Do You Defend the Full Container Pipeline?
Defense is layered, and the goal is to make each stage verify the one before it. The patterns below map to the five stages:
- Source: generate an SBOM on every commit (Syft/RapidFort Analyzer), scan dependencies (Trivy/Grype/RapidFort Analyzer), pin and mirror dependencies.
- Build: use ephemeral, least-privilege runners; produce SLSA provenance and in-toto attestations.
- Registry: sign images with Sigstore/cosign, use immutable tags, enforce registry auth and audit.
- Deploy: require signature verification and policy checks via OPA/Gatekeeper or Kyverno; apply CIS Benchmarks.
- Runtime: run Falco or an eBPF-based detector; consider gVisor/Kata for high-risk workloads; use EPSS and KEV or CISA BOD 26-04 to prioritize what to patch first.
Prioritization matters as much as detection. CVE/CVSS tells you severity; EPSS estimates exploit probability; CISA KEV lists what is actively exploited. Triaging with all three keeps effort on the threats that are both severe and likely. Another option is to use CISA BOD 26-04 for your CVE prioritization.
On the image itself, shrinking what you ship is a force multiplier. Optimized/Hardened, minimal images remove packages and CVEs before they reach the cluster. RapidFort Optimizer strips unnecessary packages from images and builds a runtime bill of materials (RBOM®) from actual usage, which can eliminate the large majority of image CVEs and narrow the surface that every other control has to defend.
Container Supply Chain Threats FAQ
What Is the Difference Between a Supply Chain Attack and a Runtime Attack?
A supply chain attack inserts malicious or vulnerable code into the artifact before it runs, so the compromised code inherits the image's existing trust. A runtime attack targets a live, otherwise legitimate container - for example, exploiting a service over the network. Supply chain defenses verify integrity at build and deploy; runtime defenses detect behavior after start.
How Does an SBOM Help Against Container Supply Chain Threats?
An SBOM (Software Bill of Materials, in CycloneDX or SPDX format) lists every component in an image. With it, you can map a new CVE to the exact image that contains it, detect unexpected components, and prove what you ship. Without an SBOM, you learn about a vulnerable dependency only after an incident.
What Is SLSA and Why Does It Matter for Containers?
SLSA (Supply-chain Levels for Software Artifacts) is a framework that grades how verifiable and tamper-resistant your build process is. Higher levels require hermetic, isolated builds and signed provenance. For containers, SLSA helps prove that an image was produced by your pipeline and not altered after, which is what lets admission control trust it.
Which Tools Detect Container Supply Chain Threats?
Detection is split by stage. Syft or RapidFort Analyzer generates SBOMs; Trivy or Grype or RapidFort Analyzer scan for vulnerabilities; Sigstore/cosign verify signatures; OPA/Gatekeeper and Kyverno enforce deploy policy; Falco and eBPF tools detect runtime anomalies. No single tool covers all five stages, which is why the controls are layered.
Can Container Supply Chain Threats Be Fully Eliminated?
No. You can reduce the attack surface dramatically - signed images, verified provenance, policy-gated deploys, and minimal images remove most paths - but residual risk remains from zero-days and misconfiguration. The objective is to make compromise detectable and high-cost, not to claim perfect elimination.
Key takeaways
- Container supply chain threats span five stages: source, build, registry, deploy, and runtime; each has its own trust boundary.
- Verify integrity at every handoff: SBOMs, signing, provenance, and admission policy turn trust into something you can check.
- Defense is layered - no single tool covers all stages, so combine scanning, signing, policy, and runtime detection.
- Prioritize with EPSS, KEV, and CVSS together or with CISA BOD 26-04 so effort goes to threats that are severe and likely exploited.
- Shrinking and optimizing/hardening images reduces the CVE count and attack surface every other control must defend.
