Container security scanning has matured significantly since the early days of Docker, but the landscape remains fragmented and confusing. In 2024, organizations can choose from dozens of scanning tools, each with different detection capabilities, data sources, and approaches. The challenge is not finding a scanner; it is understanding what your scanner actually catches and what it misses.
What Container Scanners Actually Do
Container image scanners examine the contents of a container image and identify known vulnerabilities in the packages and libraries installed within it. The basic process is:
- Extract the image filesystem layers
- Identify installed packages (OS packages, language-specific packages, binaries)
- Match identified packages against vulnerability databases
- Report matches with severity information
This sounds straightforward, but each step involves decisions that affect detection accuracy.
Package Identification: The Foundation
The quality of a scanner's package identification determines its ceiling for vulnerability detection. If the scanner cannot identify a package, it cannot find vulnerabilities in that package.
OS package managers (apt, rpm, apk) are generally well-supported by all scanners. The package manifests are standardized, and mapping packages to vulnerability advisories is relatively straightforward.
Language-specific package managers (npm, pip, Maven, Go modules, Cargo) have varying levels of support across scanners. Some scanners only identify packages installed through OS package managers and miss language-level dependencies entirely. Others parse lock files and manifest files for multiple language ecosystems.
Compiled binaries present the hardest challenge. If a Go binary or a statically linked C application is included in a container image without corresponding package metadata, most scanners cannot identify the specific libraries or versions it was compiled against. Some advanced scanners use binary analysis or hash matching, but coverage is inconsistent.
Base image inheritance adds another dimension. A container image built FROM ubuntu:22.04 inherits all the packages in that base image. Scanners need to account for both the base image packages and the packages added in subsequent layers.
Vulnerability Database Coverage
Scanners are only as good as their vulnerability databases. The primary databases used by container scanners include:
National Vulnerability Database (NVD): The most comprehensive public database, but as discussed in the NVD slowdown article, enrichment delays in 2024 have reduced its timeliness.
OS vendor advisories: Red Hat, Debian, Ubuntu, Alpine, and other distributions maintain their own vulnerability advisories. These are often more timely and accurate than NVD data for OS-level packages because they reflect the actual patch status of distribution-specific package versions.
GitHub Security Advisories / OSV: Increasingly important for language-level packages, these databases provide vulnerability information with precise affected version ranges that map directly to package manager versions.
Vendor-proprietary databases: Commercial scanners like Snyk, Grype, and others maintain their own vulnerability research and databases that supplement public sources.
The differences in database coverage explain much of the variation in scanner results. A scanner that only uses NVD data will miss vulnerabilities that are documented in distribution-specific advisories. A scanner that does not cover a particular language ecosystem will miss all vulnerabilities in packages from that ecosystem.
What Scanners Miss
Understanding what scanners do not catch is as important as understanding what they do:
Zero-day vulnerabilities. Scanners identify known vulnerabilities. If a vulnerability has not been assigned a CVE and added to a vulnerability database, no scanner will find it.
Configuration issues. Running a container as root, exposing unnecessary ports, using insecure environment variable patterns, and other configuration problems are not identified by vulnerability scanners. Configuration scanning (CIS benchmarks, Dockerfile linting) is a separate capability.
Runtime vulnerabilities. Some vulnerabilities only manifest at runtime based on how the software is configured and used. Static image scanning cannot identify these.
Custom and proprietary code. Scanners identify vulnerabilities in known packages. Vulnerabilities in your own application code require SAST/DAST tools, not container scanners.
Supply chain integrity. Scanners verify that known-vulnerable packages are not present. They do not verify that packages are genuine, untampered, or from expected sources. Backdoors like the XZ Utils compromise would not be detected by vulnerability scanning.
Practical Recommendations
Based on real-world experience with container security programs, here are practical recommendations:
Use multiple scanners. No single scanner has complete coverage. Running two scanners with different vulnerability databases catches significantly more issues than running one. Trivy (open source, maintained by Aqua Security) and Grype (open source, maintained by Anchore) are strong choices that complement each other.
Scan at multiple points. Scan images during the build process, before pushing to a registry, and continuously in the registry. Vulnerabilities are discovered after images are built, so a clean scan today does not mean the image is clean tomorrow.
Prioritize by reachability. Not every vulnerability in a container image is exploitable. Prioritize vulnerabilities in packages that are actually used by the application at runtime, not just present in the image. Tools that provide reachability analysis (Endor Labs, Snyk) can help with this.
Minimize base images. Smaller base images (Alpine, distroless, scratch) have fewer packages and therefore fewer vulnerabilities. A distroless image that only contains your application binary and its runtime dependencies is dramatically easier to secure than a full Ubuntu image.
Fix vulnerability sources, not symptoms. If your base image consistently introduces vulnerabilities, update the base image or switch to a more minimal one. Chasing individual CVE patches in downstream images is an endless game.
Track your scanning coverage. Know which of your container images are being scanned and which are not. Shadow container registries, developer workstation images, and CI/CD tool images are often outside the scanning scope.
How Safeguard.sh Helps
Safeguard.sh provides comprehensive container security scanning as part of its broader supply chain security platform. Our scanning capabilities cover OS packages, language-level dependencies, and binary analysis across container images in your registries. Safeguard.sh aggregates vulnerability data from multiple sources to maximize detection coverage and provides continuous monitoring that catches newly discovered vulnerabilities in previously scanned images. Policy gates can enforce vulnerability thresholds before images are promoted to production, and our SBOM tracking provides the audit trail needed for compliance requirements. The result is a container security program that goes beyond point-in-time scanning to provide continuous, policy-driven security assurance.