What Is Poisoned Image? Definition & Examples

A poisoned image is a container image that has been tampered with so it contains malicious or unauthorized changes. In practice, this can mean an attacker replaces a trusted build artifact with code that steals data, opens access, or undermines downstream systems that deploy the image.

What Makes a Poisoned Image Different from a Normal Container Image

A poisoned image is not just a vulnerable image, it is an image whose contents have been intentionally altered or corrupted so the artifact itself becomes the attack vehicle. The danger sits in the trusted package, not only in how it is later used.

That distinction matters because teams often focus on runtime hardening while assuming the image is trustworthy. Once a malicious layer is published, mirrored, or reused, every deployment that consumes it can inherit the compromise.

How Poisoned Images Enter the Software Supply Chain

Poisoning usually happens before deployment, during build, storage, transfer, or registry handling. An attacker may tamper with a build pipeline, replace an approved image tag, abuse weak registry permissions, or inject a backdoored base layer that later propagates into downstream images.

The attack is attractive because container ecosystems encourage reuse and automation. A single compromised artifact can spread quickly through CI/CD systems, orchestration platforms, and developer workflows if integrity checks are weak or missing.

For container-specific guidance on image, registry, and runtime protection, see NIST SP 800-190 Container Security.

Security Consequences of a Poisoned Image

The security impact depends on what the attacker inserted, but the pattern is consistent: the image can steal secrets, weaken telemetry, create persistence, or open an unexpected path into the environment. Because the artifact is trusted by default, the malicious change may bypass normal scrutiny until it is already running in production.

Poisoned images also undermine incident response. If the same image hash, tag, or base layer has been widely reused, responders may need to trace exposure across many clusters, accounts, and environments rather than treating it as a single-host event.

At the control level, integrity, access restriction, and configuration discipline matter together, which is why the broader control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to this problem.

Why Provenance and Verification Matter

Poisoned images are best understood as a provenance failure. If teams cannot prove where an image came from, what was signed, what was scanned, and whether the artifact changed after review, then trust in the image becomes a guess rather than an assurance.

That is why signed artifacts, digest pinning, registry controls, and build provenance checks are not optional ceremony. They are the practical mechanisms that separate a known-good image from one that has been tampered with after the fact.

Supply-chain controls such as SLSA are especially relevant because they focus on build provenance and artifact integrity, while OWASP API Security Top 10 can help where poisoned images expose backend interfaces or service trust boundaries.

Risk and Threat Considerations

Poisoned images create a high-impact supply-chain risk because one compromised artifact can be replicated many times before anyone notices. The most damaging cases are those where the image is pulled automatically into production and the malicious payload blends into normal container operations.

Failure mechanism: The attacker alters a trusted image, replaces a tag, or compromises the build-and-publish path, then relies on automation and reuse to distribute the tainted artifact widely.

Impact: Downstream workloads may inherit malware, data theft, persistence, or unauthorized access, and defenders may have to treat many deployments as suspect even when only one artifact was modified.

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, SLSA and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Poisoned images are integrity failures in trusted software artifacts.
	CM-5 — Access Restrictions for Change	Image poisoning often follows unauthorized changes to build or registry content.
	IA-5 — Authenticator Management	Registry and pipeline credentials often determine who can publish or replace images.
Recommendation — Validate image integrity and block deployment when artifact trust is not established. Restrict who can modify image build and publish paths. Protect and rotate credentials that can publish or override images.
SLSA	Supply-chain Levels for Software Artifacts	SLSA directly addresses build provenance and artifact integrity for images.
Recommendation — Adopt stronger provenance requirements before promoting container images.
OWASP ASVS	V15 — Secure Coding and Architecture	Image tampering is a software supply-chain integrity problem that affects deployed application trust.
Recommendation — Design deployment paths to verify artifact integrity before release.

Practitioner Guidance

Why practitioners should care: Treat image trust as a deployment gate, not a documentation exercise. If an image can change after review or be referenced only by a mutable tag, then the runtime estate is only as trustworthy as the weakest publishing control.

Common misunderstanding: Scanning an image for vulnerabilities is not the same as proving it has not been poisoned. A clean scan can still miss a malicious change that was introduced intentionally and is structurally valid.

Practitioner takeaway: Anchor deployment decisions to verified provenance, immutable digests, and tightly controlled publishing paths so the image consumed in production is the image that was actually approved.

Poisoned Image