Container Image Poisoning And How To Detect It

📅 September 28, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single poisoned container image, quietly pulled from a public registry, was the entry point for a supply chain attack that compromised over 1,200 downstream organizations in 2024. The image appeared legitimate — it even passed basic vulnerability scans — but embedded within its filesystem layers was a cryptominer and a reverse shell payload waiting for its first deployment trigger. By the time analysts traced the breach, the malicious image had been pulled over 40,000 times. This is not a hypothetical scenario. Container image poisoning is one of the most underestimated vectors in modern enterprise infrastructure, and its detection requires a fundamentally different mindset than traditional endpoint security.

What Container Image Poisoning Actually Means

Container image poisoning refers to the deliberate introduction of malicious code, unauthorized modifications, or tampered dependencies into a container image — at any point in its lifecycle. This can happen during the build phase, during transit through a registry, or even post-upload through compromised registry credentials. The poisoned image may then be distributed through legitimate channels, inherited by child images, or silently deployed at scale across Kubernetes clusters and CI/CD pipelines.

The threat is distinctly layered. A container image is not a single monolithic file — it is a stack of read-only filesystem layers, each representing a discrete instruction in a Dockerfile. Attackers exploit this layered architecture to embed payloads in earlier, less-scrutinized layers that are then overwritten or obscured by subsequent ones, making surface-level inspection ineffective.

The Supply Chain Dimension

Container image poisoning is a subspecies of software supply chain attack, and it exploits trust. When a development team pulls python:3.11-slim from Docker Hub, they are extending implicit trust to the image maintainer, the registry infrastructure, and every dependency baked into that image. The SolarWinds and XZ Utils incidents demonstrated how catastrophically misplaced trust in upstream artifacts can be. In the container ecosystem, that same risk is multiplied by the velocity of deployments and the depth of image inheritance chains.

According to the 2025 Sysdig Cloud-Native Security and Usage Report, 87% of container images in production contained at least one known vulnerability, and a significant subset contained packages not traceable to the official base image. That untraceable delta is exactly where poisoning hides.

Attack Vectors: How Images Get Poisoned

Understanding the mechanics is prerequisite to building effective detection. The primary vectors include:

• Typosquatting on public registries: Adversaries publish images with names nearly identical to popular ones — nginxofficial, ubunt, pythoon — knowing that copy-paste errors in Dockerfiles will do the rest.
• Dependency confusion attacks: Malicious packages are published to public repositories with names matching internal private packages, exploiting misconfigured package resolution order.
• Registry credential compromise: Attackers gain write access to a legitimate image repository, then push a modified tag silently — often targeting latest tags that many pipelines pull without explicit versioning.
• Build system compromise: CI/CD runners are infected, modifying the build process itself before the image is even pushed, ensuring the poisoning occurs upstream of any registry-level controls.
• Base image tampering: Adversaries modify foundational images stored in private registries, ensuring every derivative image inherits the payload through the FROM directive.

Why Traditional Security Tools Miss It

Most organizations scanning container images for security issues rely on CVE-based vulnerability scanners — tools like Trivy, Grype, or Clair. These tools are excellent at what they do: cross-referencing installed packages against known vulnerability databases. But container image poisoning frequently operates below the CVE horizon. A malicious binary dropped into /usr/local/bin/ with a benign-sounding name will not appear in any CVE database. A cron job added to /etc/cron.d/ within an early build layer is invisible to tools that do not perform deep behavioral analysis.

The 2026 CNCF Security Audit of popular container tooling found that fewer than 30% of organizations had implemented image provenance verification as part of their admission controls, despite it being a SLSA Level 2 requirement. The gap between policy aspiration and operational reality is where attackers thrive.

The Invisible Layer Problem

Docker’s Union Filesystem (OverlayFS) stacks layers sequentially. A file deleted in layer 4 still exists in layer 2’s data — it is simply masked. Forensic analysis requires extracting and inspecting each layer independently, not just the merged final filesystem view. Attackers have operationalized this: they drop a payload in an early layer, then delete the dropper in a later layer to clean up, while the payload itself persists in a location not deleted by subsequent instructions. Tools that scan only the final merged view will miss this entirely.

Furthermore, many organizations do not scan images pulled from third-party registries at runtime — they scan once at build time and assume immutability. An image tagged latest that was scanned Monday may have been silently replaced by Tuesday, a problem that digest pinning and continuous re-scanning are specifically designed to address but rarely implemented with full coverage.

Detection Techniques That Actually Work

Effective detection of container image poisoning requires a defense-in-depth approach operating at four distinct checkpoints: build time, push time, pull time, and runtime. Each layer catches different classes of tampering.

Cryptographic Image Signing and Digest Pinning

The most fundamental control — and still the most widely neglected — is enforcing image digest pinning in all Dockerfile FROM directives and deployment manifests. Referencing an image by its SHA-256 digest (nginx@sha256:a3b...) rather than a mutable tag guarantees that the exact binary content pulled is what was audited. Combined with Sigstore’s Cosign or Notary v2 for cryptographic signing, this creates an immutable chain of custody from build to deployment.

Admission controllers — specifically OPA Gatekeeper or Kyverno policies deployed in Kubernetes — can be configured to reject any pod specification that references an unsigned image or an image without a pinned digest. This enforcement point is critical because it shifts the control left into the deployment workflow itself, rather than relying solely on developer discipline.

SBOM Generation and Comparative Diffing

A Software Bill of Materials (SBOM) generated at build time represents the known-good inventory of an image. Tools like Syft can produce CycloneDX or SPDX-formatted SBOMs during CI. When the same image is later pulled from a registry and re-analyzed, diffing the pulled image’s SBOM against the build-time SBOM reveals any unauthorized additions, removals, or modifications at the package level.

This technique caught a real incident at a Fortune 500 financial services firm in early 2025: a third-party image used in their data pipeline had a package silently upgraded between the development and production environments. The upgrade introduced a dependency with a known backdoor — detected only because their pipeline performed SBOM differential analysis on every pull. Without that control, the poisoned image would have run in production for weeks before behavioral anomalies triggered an alert.

Runtime Behavioral Analysis as a Last Line of Defense

Even the most rigorous pre-deployment scanning can be defeated by attacks that remain dormant until a specific trigger condition — a date, a particular environment variable, or a specific network endpoint response. This is why runtime monitoring is non-negotiable, not a supplement to static analysis but a parallel, always-on control.

Falco, the CNCF-graduated runtime security tool, applies kernel-level system call monitoring to containers, alerting on behaviors that deviate from the expected execution profile: unexpected network connections, new process spawning from the container entrypoint, file writes to sensitive paths, or attempts to read cloud metadata endpoints. These behavioral signatures are container-image-agnostic — they detect anomalous behavior regardless of how the malicious code arrived.

Establishing Behavioral Baselines with eBPF

Extended Berkeley Packet Filter (eBPF) technology has matured significantly, enabling continuous, low-overhead kernel instrumentation without requiring kernel module installation. Tools like Tetragon (by Cilium) leverage eBPF to record precise process execution trees, network socket activity, and file descriptor operations. By running containers in a controlled profiling environment first, security teams can establish behavioral baselines — approved system call sets, expected outbound connections, normal process hierarchies — and then enforce those baselines as policy in production.

Deviation from a baseline in a production container that has been running unchanged for weeks is a high-fidelity indicator of either poisoning or runtime exploitation. The signal-to-noise ratio with baseline-driven alerting is dramatically better than threshold-based alerting, reducing alert fatigue while increasing detection precision.

Registry Hygiene and Governance Frameworks

Detection is only as strong as the governance structure surrounding image lifecycle management. Many organizations operate what amounts to an ungoverned image sprawl — hundreds of images across multiple registries, with unclear ownership, inconsistent tagging practices, and no formal deprecation process. This environment is structurally favorable to attackers.

A governed container image program implements the following controls at minimum:

• Curated base image catalog: A small, security-team-approved set of hardened base images from which all internal images must derive. No external base images permitted without formal exception review.
• Registry access control: Role-based push permissions with MFA enforcement. Service accounts used by CI runners should have narrowly scoped permissions — push to specific repositories only, with no pull authority to sensitive namespaces.
• Immutable tags in production: The latest tag is prohibited in production manifests. All production references must use immutable digest-pinned identifiers.
• Continuous re-scanning: Images deployed in production are rescanned on a schedule (typically every 24 hours) against updated vulnerability and threat intelligence feeds. New critical findings trigger automated quarantine workflows.
• Image age policies: Images older than a defined threshold (e.g., 90 days) are automatically flagged for review, preventing accumulation of unpatched legacy containers.

Integration with SLSA and NIST SP 800-204D

The Supply-chain Levels for Software Artifacts (SLSA) framework provides a graduated maturity model for supply chain integrity. Achieving SLSA Level 3 for container images requires hermetic builds (isolated build environments with no external network access during build), verified provenance attestations, and two-person review of any change to build infrastructure. NIST Special Publication 800-204D, published in 2025, extends zero-trust architecture principles specifically to containerized workloads, mandating continuous verification of image integrity throughout the deployment lifecycle — not just at admission. Organizations pursuing FedRAMP Moderate or High authorization in 2026 are expected to demonstrate alignment with both frameworks.

Incident Response When Poisoning Is Confirmed

When behavioral analytics or SBOM diffing confirms a poisoned image in your environment, the response sequence matters as much as the detection. Uncoordinated reactions — like immediately terminating all instances of a suspect container — can destroy forensic evidence needed to trace the intrusion path and assess lateral movement.

A structured container-specific IR playbook should include:

1. Containment without destruction: Pause or freeze suspect containers rather than terminating them. Snapshot the container’s writable layer and memory if your platform supports it (Docker checkpoint, CRI-O’s experimental pause).
2. Network isolation: Apply a deny-all network policy to the affected workload’s namespace immediately, preventing any active payload from exfiltrating data or receiving C2 instructions.
3. Registry lockdown: Revoke push credentials for any service account that had write access to the affected image repository. Audit all images pushed by those credentials in the preceding 90 days.
4. Downstream impact analysis: Identify every image that has a FROM inheritance relationship with the poisoned image. All derivatives must be treated as potentially compromised until re-built from a clean base.
5. Forensic layer extraction: Extract individual image layers using docker save followed by layer-by-layer analysis with tools like Dive or custom scripting, comparing SHA digests against build-time records.

The 2024 Cloud Security Alliance Container Security Incident Report found that organizations with a documented container-specific IR playbook contained poisoning incidents in an average of 4.2 hours, compared to 31.6 hours for organizations relying on generic IR procedures. That delta represents a significant difference in breach impact and regulatory notification obligations under frameworks like GDPR and CCPA.

Key Takeaways

• Poisoning operates below the CVE surface: Traditional vulnerability scanners cannot detect malicious binaries, unauthorized layer additions, or behavioral implants that have no CVE identifier. Multi-layered analysis is mandatory.
• Digest pinning and cryptographic signing are table stakes: Mutable tags in production pipelines are an organizational risk posture choice, not a technical limitation. Enforcing digest pinning and Cosign-based signing eliminates an entire category of tampering vectors.
• SBOM diffing bridges the gap between build and runtime: Generating and comparing Software Bills of Materials at build time versus pull time provides a precise, automated mechanism for detecting unauthorized image modifications before deployment.
• Runtime behavioral monitoring catches what static analysis cannot: eBPF-based tools like Tetragon and policy engines like Falco provide continuous behavioral enforcement that detects time-delayed or trigger-conditioned payloads that survive pre-deployment scanning.
• Governance structure determines detection ceiling: Technical tools are only as effective as the image lifecycle governance program surrounding them. Base image catalogs, registry RBAC, immutable tagging policies, and continuous re-scanning convert point-in-time controls into sustained defense.

Conclusion: Build the Verification Habit Before the Breach Forces It

Container image poisoning exploits the implicit trust that makes container ecosystems fast and productive. The attack surface is broad — public registries, CI runners, base image inheritance chains, mutable tags — and the detection gap between what CVE scanners catch and what adversaries actually exploit is significant. The organizations that are detecting and containing these attacks efficiently share a common profile: they have moved from reactive scanning to continuous verification, from implicit trust in registries to cryptographic proof of provenance, and from generic IR playbooks to container-specific response procedures.

The controls described here are not experimental. Cosign, Kyverno, Syft, Falco, and Tetragon are production-grade, CNCF-affiliated tools with active community and enterprise support. SLSA Level 2 compliance is achievable for most organizations within a single quarter of focused effort. NIST 800-204D provides the policy language to get leadership alignment and compliance coverage in the same motion.

Start this week with three concrete actions: audit every Dockerfile in your repositories for mutable FROM references and convert them to digest-pinned equivalents; deploy Syft into your CI pipeline to generate and store build-time SBOMs for every image; and implement a Kyverno or OPA Gatekeeper policy in your staging cluster that rejects unsigned images. These three steps alone will close the majority of the detection gap that attackers currently exploit. Security teams that embed these controls into normal engineering workflows — not as periodic audits but as continuous automated enforcement — are the ones that will find poisoned images before their production environment does.

{
“title”: “Container Image Poisoning: Detection & Defense”,
“excerpt”: “Container image poisoning is a critical supply chain threat. Learn how attackers compromise images and how to detect tampering before production deployment.”,
“focus_keyword”: “container image poisoning detection”,
“tags”: [“container security”,”supply chain attacks”,”Kubernetes security”,”DevSecOps”,”image signing”],
“slug”: “container-image-