In March 2021, researchers scanning public Docker Hub repositories found that roughly 51% of the 4 million images they analyzed contained at least one critical or high-severity vulnerability, and over 6,000 images were hosting active cryptomining malware. Five years later, the registry has only grown — Docker Hub alone now serves north of 15 million repositories — and every one of them is a potential entry point into a production cluster. Container registry scanning is the control that sits between "someone built an image" and "that image is running in your environment," and it has become one of the most contested product categories in software supply chain security, with Aqua Security's Trivy anchoring the open-source side of the market.
This post breaks down what registry scanning actually needs to do in 2026, where tools like Trivy fall short once you're operating at fleet scale, and how Safeguard approaches the problem differently.
What Is Container Registry Scanning, Exactly?
Container registry scanning is the automated process of inspecting every image stored in a registry — Docker Hub, Amazon ECR, Google Artifact Registry, GitHub Container Registry, or a self-hosted Harbor instance — for known vulnerabilities, malware, exposed secrets, and misconfigurations before (and after) that image is pulled into a runtime environment. A scanner unpacks each image layer, builds a software bill of materials (SBOM) by identifying OS packages (via APK, DEB, or RPM databases) and language dependencies (npm, pip, Maven, Go modules), then cross-references every component against vulnerability feeds like the National Vulnerability Database, GitHub Security Advisories, and vendor-specific advisories such as Alpine's secdb or Red Hat's OVAL feeds.
The output sounds simple — a list of CVEs per image — but the hard part is scope. A typical node:18 base image alone carries 300-plus packages before an engineering team adds a single line of application code. Multiply that by hundreds of application images and dozens of tags per repository, and a registry scanner is often the single largest source of findings any security team receives.
Why Did Aqua Security's Trivy Become the Default Scanner?
Trivy became the default because Aqua Security open-sourced it in 2019 and it solved a genuinely annoying problem: a single static binary that scanned a container image for OS and language-level vulnerabilities in seconds, with no server or database setup required. That simplicity drove adoption — Trivy has accumulated over 24,000 GitHub stars and is embedded as the scanning engine inside GitLab, Harbor, Docker Scout's early tooling, and countless CI pipelines.
But "default" and "sufficient" are different claims. Trivy's core scanning loop is fundamentally a CVE database lookup: it identifies package versions and matches them against known-vulnerable version ranges. It does not, out of the box, tell you whether a vulnerable function is actually reachable from your application's code paths, whether the image is even exposed to untrusted input, or whether a "critical" CVE in a logging library your image imports but never initializes is worth an engineer's afternoon. Aqua's commercial platform layers additional context — runtime protection, some prioritization — on top, but that pushes teams toward a full platform commitment (and its associated per-node/per-image pricing) just to get past raw CVE counts.
How Many Vulnerabilities Does a Typical Registry Actually Contain?
A typical enterprise registry with a few hundred actively maintained repositories will surface somewhere between 8,000 and 30,000 raw CVE findings once every tag is scanned, and the overwhelming majority of them are not exploitable in practice. Sysdig's 2023 cloud-native security report found that 87% of container images in production contained at least one high or critical vulnerability, yet separate research from teams building reachability analysis has repeatedly found that fewer than 10-15% of those flagged vulnerabilities sit in code paths the running application actually executes.
This is the gap that turns registry scanning from a security win into an organizational liability. When a scanner reports 22,000 findings across a registry and offers no way to distinguish the 200 that matter from the 21,800 that don't, the realistic outcome is one of two failure modes: teams either ignore the backlog entirely, or they burn weeks patching low-risk CVEs in unreachable dependencies while an actual exploitable path — say, a critical deserialization bug in a library the app instantiates on every request — sits at position 4,000 in a severity-sorted list.
What Happened With the XZ Utils Backdoor, and Why Does It Matter for Registries?
In March 2024, a Microsoft engineer named Andres Freund discovered that xz-utils versions 5.6.0 and 5.6.1 — a compression library present in the vast majority of Linux base images — contained a deliberately planted backdoor (CVE-2024-3094) that would have given an attacker remote code execution via SSH on affected systems. The backdoor had been inserted by a contributor who spent roughly two years building trust in the open-source project before landing the malicious commit.
The incident mattered enormously for registry scanning because it exposed a blind spot shared by nearly every CVE-database-driven scanner: xz-utils 5.6.1 was, for the several weeks before disclosure, a "clean" package with no known vulnerabilities. Any image built and pushed to a registry during that window would have passed a standard scan with zero findings. Detecting this class of threat requires registries to track package provenance, build reproducibility, and behavioral anomalies — not just CVE lookups — and it's a large part of why the industry conversation shifted from "vulnerability scanning" to "software supply chain security" almost overnight.
Does Scanning at Push-Time Catch Everything, or Do You Need Continuous Rescanning?
Push-time scanning alone does not catch everything, because the vulnerability landscape underneath an already-pushed image keeps changing every day. An image scanned clean on a Tuesday can have a new critical CVE disclosed against one of its dependencies on Thursday — NVD published roughly 40,000 new CVE records in 2024 alone, averaging well over 100 per day — and that image will still be sitting in the registry, and possibly still running in production, with zero new findings unless something rescans it.
This is why mature registry scanning programs run on two cadences: scan on every push (blocking the pipeline for critical, exploitable issues) and continuously rescan the existing registry contents against updated feeds, typically daily. Teams that only implement the first cadence build a false sense of security around images that were compliant on day one and silently drift out of compliance over the following months — often the exact images still tagged latest and pulled by dozens of downstream services.
How Should Teams Prioritize Findings Across a Large Registry?
Teams should prioritize by combining exploitability, reachability, and exposure rather than relying on CVSS base score alone, because CVSS was never designed to answer "should I fix this today." A CVE with a 9.8 CVSS score in a dependency that's never loaded at runtime is objectively less urgent than a CVSS 7.2 finding in a package that parses untrusted user input on an internet-facing service. CISA's Known Exploited Vulnerabilities (KEV) catalog — which as of mid-2026 lists more than 1,300 CVEs confirmed as actively exploited in the wild — is one useful cross-reference, since a finding that appears on both your registry scan and the KEV list deserves same-day attention regardless of its raw score.
The practical prioritization stack that works at scale looks like: (1) is this package actually reachable from application entry points, (2) is there a public exploit or KEV listing, (3) is the image internet-facing or handling untrusted input, and (4) is a patched version available without a breaking dependency bump. Registries that can answer all four automatically routinely cut actionable findings by 90% or more compared to a raw CVE count.
How Safeguard Helps
Safeguard treats registry scanning as the entry point to a supply chain security program, not the end of one. Every image pushed to a connected registry — Docker Hub, ECR, GCR, Harbor, or a private OCI-compliant registry — is scanned on push and continuously rescanned against updated CVE, KEV, and malware feeds, so drift between "scanned clean" and "actually still safe" never goes unnoticed.
Where Safeguard diverges from a CVE-list scanner like Trivy is in what happens after the match. Safeguard builds a full SBOM per image, correlates each finding against reachability analysis so teams can see which vulnerabilities sit on an actual execution path, and cross-references every match against known-exploited and actively-weaponized vulnerability intelligence rather than relying on CVSS alone. That turns a 20,000-line CSV of raw findings into a short, ranked list an engineering team can realistically clear in a sprint.
Safeguard also scans for the class of threat that CVE databases miss entirely: unexpected binaries, suspicious build-time network calls, and package provenance anomalies of the kind the xz-utils backdoor relied on. Combined with policy gates that block non-compliant images at push time — configurable per registry, per repository, or per compliance framework including SOC 2 and FedRAMP controls — Safeguard gives teams a registry scanning program that produces a smaller, more trustworthy set of findings instead of a larger one.
For teams currently running Trivy or Aqua's open-source scanner as their only line of defense, the fastest way to see the difference is to connect a registry and compare the raw finding count against Safeguard's prioritized output directly.