In March 2024, a Microsoft engineer named Andres Freund noticed SSH logins on a Debian system taking 500 milliseconds longer than usual. That anomaly led to the discovery of CVE-2024-3094, a backdoor deliberately planted in the XZ Utils compression library — a dependency baked into countless container base images. It was caught by luck, not tooling. Most container images shipped today are never inspected that closely. A typical production image bundles an OS layer, language runtimes, and dozens of third-party packages, any one of which can carry a known CVE, a malicious typosquat, or a hardcoded secret. Container image scanning is the practice of inspecting these layers — before and after deployment — for vulnerabilities, misconfigurations, and supply chain tampering. Vendors like Aqua Security built entire product lines around this problem starting nearly a decade ago. This post breaks down what image scanning actually catches, where established tools fall short, and how Safeguard approaches the same problem differently.
What Is Container Image Scanning, and Why Does It Matter in 2026?
Container image scanning is the automated inspection of a container image's filesystem layers, package manifests, and metadata to identify known vulnerabilities (CVEs), exposed secrets, license issues, and malware — typically before the image is pushed to a registry or deployed to production. It matters because containers have become the default unit of deployment: most cloud-native workloads today run in containers, and a single popular base image, such as a common Node.js or Python runtime, can be pulled millions of times across an organization's fleet. Docker Hub alone hosts several million public repositories, and independent research from cloud security teams has repeatedly found thousands of them repurposed for cryptomining, credential theft, or typosquatting attacks on legitimate package names. Without scanning, a vulnerable OpenSSL or glibc version baked into a base image two years ago silently propagates into every service built on top of it. Scanning turns that invisible inheritance into a queryable, fixable inventory.
How Do Scanners Like Aqua's Trivy Actually Detect Vulnerabilities?
Scanners detect vulnerabilities by matching the packages and binaries found inside an image against vulnerability databases such as the National Vulnerability Database (NVD), OS-specific advisories (Debian DSA, Alpine secdb, RHEL OVAL), and language-ecosystem feeds like GitHub Advisory Database or OSV. Aqua Security's open-source scanner, Trivy, popularized this approach and has been downloaded well over 500 million times since its 2019 release, making it a de facto standard embedded in countless CI pipelines. The mechanics matter more than they appear: a scanner has to parse package managers (apt, apk, rpm, pip, npm, go modules), reconcile version strings against advisory ranges, and de-duplicate CVEs that apply to multiple layers. This is where accuracy diverges sharply between tools. NVD itself fell badly behind starting in February 2024, when NIST's enrichment backlog spiked past 15,000 unanalyzed CVEs at its peak, meaning scanners relying solely on NVD metadata missed or delayed severity scoring for a large share of newly disclosed vulnerabilities for months. Scanners that layer in OSV, vendor advisories, and their own research pipelines catch more, faster — but that also means two scanners pointed at the identical image can legitimately report different CVE counts.
What Do False Positives Actually Cost Security Teams?
False positives cost security teams the thing they have least of: engineer attention, and studies of vulnerability management workflows have repeatedly found that a majority of flagged CVEs in a typical scan are not actually exploitable in the deployed context. A classic example is a CVE affecting a shared library function that exists in the image but is never called by the running application — technically present, practically inert. Traditional scanners report it anyway because they only check for the presence of a vulnerable package version, not whether the vulnerable code path is reachable at runtime. When a team's backlog balloons to hundreds of "critical" findings per week, triage fatigue sets in and real issues get lost in the noise. This is the core complaint enterprise teams have voiced about first-generation scanning tools, including Aqua's platform when deployed at scale across large image fleets: comprehensive detection without reachability or exploitability context turns a security tool into a ticket-generation machine rather than a risk-reduction one.
How Did the Log4Shell and XZ Utils Incidents Change Image Scanning Requirements?
Log4Shell (CVE-2021-44228), disclosed on December 10, 2021, and the XZ Utils backdoor (CVE-2024-3094), disclosed on March 29, 2024, changed image scanning requirements by proving that scanning has to look inside nested dependencies, not just top-level packages. Log4Shell was buried several layers deep inside Java application JARs — a dependency of a dependency — and organizations spent weeks just inventorying which of their container images even contained the affected log4j-core versions, because most scanning tools at the time didn't unpack nested JAR-in-JAR structures reliably. XZ Utils went further: it wasn't a coincidental bug but a multi-year, deliberately planted supply chain attack targeting SSH authentication, hidden inside a compression library's build scripts and test files rather than its visible source code. Both incidents pushed the industry toward Software Bills of Materials (SBOMs) as a baseline requirement — a machine-readable inventory of every component in an image — and toward provenance verification (was this artifact built by the pipeline it claims to be, from the source it claims to be) rather than trusting a package's stated version number at face value.
Where Does Aqua Security's Approach Fall Short for Modern Teams?
Aqua Security's approach falls short for modern teams primarily on integration depth and pricing structure once organizations scale past a few hundred images. Aqua built its platform around CSPM and container runtime protection first, adding image scanning (via its 2021 Argon acquisition, folded into what's now Aqua's supply chain security module) as one module among many in a broad, agent-heavy platform. That breadth is a selling point for large enterprises that want a single vendor for cloud posture, runtime, and scanning, but it also means image scanning results live inside a dashboard optimized for a much wider surface area — teams report friction getting scan data into developer-facing tools like pull request checks without significant configuration. Licensing is typically scoped by workload or node count, which can make cost unpredictable for organizations with large, elastic image registries and frequent CI builds. And because Trivy, the open-source engine underneath Aqua's commercial product, is widely embedded elsewhere too, differentiation increasingly comes down to the paid platform's triage and reporting layer rather than raw detection capability.
What Does a Modern Container Image Scanning Workflow Actually Require?
A modern container image scanning workflow requires coverage at three distinct points — the developer's local build, the CI/CD pipeline before registry push, and the registry itself on a recurring basis — because a base image scanned as clean today can have a new CVE disclosed against it tomorrow without any code change on your side. It also requires SBOM generation in a standard format (CycloneDX or SPDX) attached to every build artifact, signature verification so a deployed image can be cryptographically tied back to its build provenance (the practice Sigstore and SLSA formalized after Log4Shell and the 2020 SolarWinds incident), and severity scoring that accounts for reachability rather than raw CVSS. Finally, it requires fast feedback loops: a scan that returns results in over ten minutes gets skipped or ignored by developers under deadline pressure, so scan speed at the pull-request stage is not a nice-to-have, it's what determines whether the tool gets used at all.
How Safeguard Helps
Safeguard was built to close the specific gaps that first-generation, breadth-first platforms leave open. Instead of bolting scanning onto a runtime protection suite, Safeguard treats container image scanning as a supply-chain-first problem: every scan produces a full SBOM, cross-references CVEs against multiple advisory sources beyond NVD to avoid the enrichment-backlog blind spot that hit the industry in 2024, and prioritizes findings using reachability analysis so a vulnerable function that's never called doesn't outrank a critical issue in code your application actually executes. Scans run directly in CI and at the registry, with results surfaced natively in pull requests rather than a separate dashboard teams have to remember to check. For provenance, Safeguard verifies build attestations against Sigstore and SLSA standards so a team can answer "was this image built from the source we think it was" with cryptographic evidence, not trust. Pricing is scoped to actual scanning volume rather than broad platform seat licensing, which keeps costs predictable as image fleets and CI frequency grow. The goal isn't a longer CVE list — it's a shorter, accurate one that engineering teams actually act on before the next XZ Utils-style incident gets caught by luck instead of by design.