On this page
Container image scanning and provenance
The automated process of inspecting container images for known vulnerabilities (CVEs) and cryptographically verifying their origin to prevent supply chain attacks.
Reference Card
- Origin/Prior Art: Static Application Security Testing (SAST), Checksums.
- Related Practices: Software Bill of Materials (SBOM), SLSA Framework.
- Key Concepts: CVE matching, Base image vulnerabilities, Cryptographic signing.
- Primary Failure Modes: Alert fatigue from thousands of “Low” severity CVEs, Deploying unsigned images from compromised registries.
Introduction
A modern Docker image is a stack of dependencies: it relies on an OS base image (like Debian or Alpine), runtime libraries (like Node.js or Python), and hundreds of third-party open-source packages. If any one of those layers contains a known security vulnerability (a CVE), the resulting container exposes the entire production cluster to attack.
Container image scanning is the operational practice of dissecting an image layer by layer, generating a complete inventory of every package installed, and cross-referencing that inventory against global vulnerability databases. Image provenance takes this a step further by cryptographically signing the image, ensuring that what runs in production is exactly what was built by the CI pipeline, and not a malicious payload injected by an attacker who compromised the container registry.
Mental Model
Think of an image scanner as a customs inspector at a border. When a container arrives, the inspector unpacks every box (layer), logs every single item on a clipboard (the SBOM), and checks the clipboard against a global “Wanted List” of known criminals (the CVE database). Provenance is the wax seal on the shipping container. The inspector verifies that the wax seal is unbroken and matches the exact stamp of the authorized factory. If the seal is missing or forged, the container is rejected, regardless of what is inside.
Operational Pattern
1. The SBOM (Software Bill of Materials)
Before scanning can occur, tools (like Trivy or Syft) generate an SBOM. This is a machine-readable JSON file (often in SPDX or CycloneDX format) that exhaustively lists every library and OS package inside the image, including exact version numbers.
2. CI/CD Blocking
Scanning must happen during the build pipeline. If a developer builds an image that contains a “Critical” severity CVE with a known fix, the CI pipeline should intentionally fail, blocking the image from ever reaching the registry.
3. Cryptographic Provenance (Signing)
Once the image passes the scan, the CI pipeline uses a tool (like Cosign) to cryptographically sign the image digest. In Kubernetes, a mutating admission controller (like Kyverno) intercepts every request to launch a pod. It verifies the cryptographic signature attached to the image. If the image is unsigned or the signature is invalid, the cluster refuses to boot the container.
Failure Modes
Alert Fatigue and the “Zero CVE” Fallacy
The most common failure mode in image scanning is configuring the CI pipeline to block on any vulnerability. Base OS images (even minimal ones) often carry dozens of “Low” or “Medium” severity CVEs that have no known exploit, no available patch, or only apply to obscure hardware configurations. If the pipeline blocks on these, developers will be paralyzed, unable to deploy code for weeks while waiting for OS maintainers to release patches. Operational policy must define actionable thresholds (e.g., “Block only on High/Critical vulnerabilities that have a published fix available”).
Stale Images
A container image is only secure on the day it is scanned. If a critical vulnerability (like Log4j) is discovered on Tuesday, an image that passed all security scans on Monday is now a catastrophic risk. Organizations fail when they only scan images during the build phase. You must implement continuous registry scanning to monitor images that are already running in production against daily updates to the CVE database.
Security
Image scanning and provenance are the core defenses against Supply Chain Attacks. If an attacker compromises an upstream dependency (like a popular npm package) or steals credentials to your Docker registry and pushes a malicious image tagged latest, cryptographic provenance ensures your Kubernetes cluster will reject the payload because it lacks the internal CI pipeline’s cryptographic signature.
Operational Guidance
Minimize your attack surface by aggressively stripping down base images. Avoid generic images like node:latest or ubuntu:latest, which contain hundreds of unnecessary utilities (like curl, wget, and compilers) that hackers use to establish reverse shells. Transition to “Distroless” images or alpine, which contain only the absolute bare minimum required to run the application, massively reducing the SBOM size and the resulting CVE count.