In-Depth Guide
What Is Container Scanning?
Container scanning is the automated process of analyzing container images to identify known vulnerabilities, misconfigurations, malware, and software composition risks. It is a foundational practice in modern DevSecOps.
Understanding Container Images
A container image is a lightweight, standalone, executable package that includes everything needed to run an application: the code, runtime, system tools, system libraries, and settings. Images are built from a series of instructions in a Dockerfile, where each instruction creates a new layer in the image filesystem.
Consider a typical Node.js application image. The first layer might be the base OS (e.g.,
node:20-bookworm-slim, based on Debian). The next layer installs system packages. Then npm install adds application dependencies. Finally, the application code is copied in. Each of these layers can introduce vulnerabilities.The base OS layer carries the Debian package ecosystem. The npm install layer pulls in your direct and transitive JavaScript dependencies. Even small images routinely contain hundreds of individual packages across OS and application layers. Container scanning examines all of them.
How Container Scanners Work
At a high level, every container scanner follows the same core process: pull the image, decompose it into layers, extract package manifests, and match installed versions against vulnerability databases.
1
Image Acquisition
The scanner pulls the image from a container registry (Docker Hub, AWS ECR, GCR, Azure ACR, or any OCI-compliant registry) or reads a local image archive. Some scanners can also analyze Dockerfiles before building, catching issues at the specification level.
2
Layer Decomposition
Container images are stored as a stack of filesystem layers. The scanner unpacks each layer and builds a merged view of the filesystem. This reveals all installed files, including package manager databases (dpkg, rpm, apk), language lock files, and binary artifacts.
3
Package Identification
The scanner identifies installed software by reading OS package manager databases (for system packages) and language-specific manifests: package-lock.json for npm, go.sum for Go modules, requirements.txt or Pipfile.lock for Python, Gemfile.lock for Ruby, pom.xml for Java/Maven, and so on. This step produces the software inventory.
4
Vulnerability Matching
Each identified package and version is cross-referenced against vulnerability databases. The primary source is the National Vulnerability Database (NVD), but scanners also consult the GitHub Advisory Database, vendor-specific advisories (Debian Security Tracker, Red Hat CVE Database, Alpine SecDB), and community-maintained feeds. A match means a known CVE affects the installed version.
5
Severity Classification
Matched vulnerabilities are scored using the Common Vulnerability Scoring System (CVSS). Scores range from 0.0 to 10.0 and map to severity levels: Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0). Many scanners also incorporate exploitability data: a critical CVE with a known public exploit is treated more urgently than one that is only theoretical.
6
Reporting and Policy Evaluation
The scanner outputs a report listing every vulnerability found, its severity, affected package, installed version, and fixed version (if available). Advanced scanners evaluate the results against configurable policies: for example, "fail the build if any critical CVE is found" or "warn on high-severity CVEs older than 30 days."
The Vulnerability Lifecycle
Understanding how vulnerabilities flow from discovery to remediation is essential for setting up an effective scanning program. The lifecycle has distinct stages, and scanning plays a role in several of them.
Discovery
A security researcher, vendor, or automated tool discovers a flaw in a software component. The issue is reported to the vendor or directly to a CVE Numbering Authority (CNA).
CVE Assignment
The vulnerability is assigned a CVE identifier (e.g., CVE-2024-12345). Initial details and a CVSS score are published in the NVD and vendor advisories.
Database Update
Vulnerability databases incorporate the new CVE. Scanner vendors update their vulnerability feeds, sometimes within hours of disclosure. Speed here matters: the window between disclosure and patching is when exploits are most dangerous.
Detection
Container scanners running against registries, CI/CD pipelines, and runtime environments detect that an installed package version is affected. Teams are notified via alerts, dashboard updates, or failed pipeline checks.
Triage
Security and development teams assess the impact. Is the vulnerable component actually reachable in the application? Is there a known exploit in the wild? What is the blast radius if exploited? This context determines remediation priority.
Remediation
The fix is applied: updating the base image, upgrading the affected dependency, or applying a vendor patch. The image is rebuilt, rescanned to confirm the fix, and promoted through the deployment pipeline.
What Scanners Detect
Container scanners have evolved beyond basic CVE matching. Modern scanners detect multiple categories of risk.
OS Package Vulnerabilities
Flaws in system-level packages installed by the base image distribution. These include the Linux kernel (if present), C libraries (glibc, musl), OpenSSL/LibreSSL, and hundreds of other packages that form the OS foundation layer.
Application Dependency Vulnerabilities
Flaws in libraries installed by package managers: npm, pip, Maven, Go modules, NuGet, Cargo, Composer, and others. Supply chain attacks often target these transitive dependencies, which developers may not even know they are using.
Misconfigurations
Dockerfile and image misconfigurations: running as root, using the latest tag (unpinned base images), exposing unnecessary ports, storing secrets in environment variables or build args, and granting unnecessary Linux capabilities.
Embedded Secrets
API keys, database credentials, certificates, and tokens accidentally baked into image layers. Even if the secret is deleted in a later layer, it persists in the image history and can be extracted by anyone with access to the image.
Malware and Trojans
Some scanners check for known malware signatures in image binaries. This catches images that have been tampered with in the supply chain or base images from untrusted sources that contain backdoors.
License Compliance
SBOM-based analysis can flag open-source components with licenses incompatible with your organization's policies (e.g., GPL in a proprietary product). While not a security vulnerability, license violations create legal risk.
Software Bill of Materials (SBOM)
An SBOM is a structured inventory of all software components inside an artifact. For container images, an SBOM lists every OS package, application library, and embedded binary along with its version, source, and license. Think of it as a nutrition label for your container.
SBOMs have become a cornerstone of software supply chain security. The U.S. Executive Order 14028 (Improving the Nation's Cybersecurity) mandated SBOM generation for software sold to the federal government. NIST, CISA, and industry groups have published SBOM guidance and minimum elements.
Two standard SBOM formats dominate the container security landscape:
SPDX
The Software Package Data Exchange format, developed by the Linux Foundation. SPDX captures package identity, version, licensing, and relationships. It is an ISO standard (ISO/IEC 5962:2021) and is widely supported across the ecosystem.
CycloneDX
An OWASP project designed specifically for security use cases. CycloneDX supports not only software components but also vulnerability data, service metadata, and hardware components. It is increasingly popular in DevSecOps pipelines due to its security-first design.
Container scanning tools like Syft (from Anchore), Trivy, and Snyk can generate SBOMs as part of the scan output. The SBOM can then be stored alongside the image in the registry, shared with customers as part of a software delivery, or fed into vulnerability management platforms for continuous monitoring.
The key benefit of SBOMs for container security: when a new CVE is disclosed (like Log4Shell was in December 2021), organizations with SBOMs can immediately query their inventory to determine which images are affected. Without SBOMs, that same triage process requires re-scanning every image, which can take hours or days at scale.
Vulnerability Databases
The accuracy of a container scanner depends directly on the quality and freshness of its vulnerability data sources. No single database is comprehensive. Effective scanners aggregate data from multiple feeds.
| Database | Coverage | Notes |
|---|---|---|
| NVD (NIST) | All CVEs | The canonical CVE database. Comprehensive but can lag on initial scoring. |
| GitHub Advisory Database | Open-source deps | Covers npm, pip, Maven, Go, Cargo, NuGet. Community-curated with fast updates. |
| Debian Security Tracker | Debian/Ubuntu | Tracks CVE status for every Debian package. Essential for Debian-based images. |
| Red Hat CVE Database | RHEL/CentOS | Red Hat's own severity ratings, often different from NVD. Includes backport info. |
| Alpine SecDB | Alpine Linux | Tracks fixed versions in Alpine's minimal package set. |
| OSV (Google) | Multi-ecosystem | Open Source Vulnerabilities database. Aggregates advisories across ecosystems. |
| VulnDB / Exploit-DB | Extended | Commercial databases with exploit intelligence and zero-day tracking. |
Ready to Put This Into Practice?
Learn how to integrate container scanning into your development workflow with our best practices guide.