Most engineering teams already run a scanner. Trivy in CI, Grype on a cron job, maybe Docker Scout in the registry. Yet the same organizations still get paged at 2 a.m. because a base image shipped a critical CVE, or spend a week reconciling three tools that each report a different vulnerability count for the identical container. Pull up each tool's scanning report side by side and the discrepancy is immediate: same image, three different counts, no agreed source of truth. That gap — between "we scan everything" and "we actually know our risk" — is the real problem in 2026, not the absence of tooling.
It's also the gap competitors like Chainguard have built a business around, by shrinking the attack surface before a scanner ever runs. That's a legitimate strategy, but it's not the whole picture: hardened base images don't eliminate the need to scan application code, third-party dependencies, IaC, and runtime behavior. This guide breaks down how modern vulnerability scanning actually works, why tool output disagrees, how to prioritize what scanners find, and where Safeguard fits into that stack.
What Is Vulnerability Scanning in a Modern Software Supply Chain?
Vulnerability scanning is the automated process of matching the components in your software — OS packages, language dependencies, container layers, IaC templates, and running workloads — against known-vulnerability databases like the National Vulnerability Database (NVD), OSV, and vendor advisories. In a 2021-era pipeline, that usually meant one tool scanning one artifact: a container image before it shipped. In a 2026-era pipeline, it means scanning at four or five distinct points — source repo (SCA), build (SBOM generation), registry (image scanning), IaC (misconfiguration), and runtime (drift detection) — because a vulnerability introduced at any one of those layers can reach production undetected by the others.
The scale problem is real: NVD published roughly 40,000 CVEs in 2024, up from about 29,000 in 2023, and CISA's Known Exploited Vulnerabilities (KEV) catalog has grown past 1,300 entries. No human triage process scales to that volume without automated prioritization layered on top of raw scanning.
Why Do Scanners Report Different Results for the Same Image?
Scanners disagree because they use different vulnerability databases, different package matching logic, and different definitions of "affected." Trivy, Grype, Snyk, and Docker Scout can each scan the same node:20-slim image and return counts that differ by 20-40%, not because one is wrong, but because NVD, the GitHub Advisory Database, OSV, and distro-specific feeds (Debian Security Tracker, Alpine's secdb) don't always agree on whether a given package version is vulnerable, especially for backported patches.
This got materially worse starting February 2024, when NIST's NVD sharply slowed CVE enrichment — the process of attaching CPE (product) identifiers and CVSS scores to new entries. By mid-2024, more than 18,000 CVEs sat unanalyzed in NVD's backlog, meaning any scanner relying primarily on NVD metadata either produced incomplete matches or silently fell back to secondary sources. Teams that only ran one scanner during that window had a real, measurable blind spot — a good argument for correlating multiple sources rather than trusting a single feed.
What's the Difference Between SCA, Container Scanning, and "Zero-CVE" Image Hardening?
They solve different problems and none of them substitutes for the others. Software Composition Analysis (SCA) tools like Snyk or OWASP Dependency-Check scan your application's direct and transitive dependency tree — the layer that mattered when Log4Shell (CVE-2021-44228) shipped in December 2021 buried four dependency levels deep in countless Java applications. Container scanning tools like Trivy, Grype, and Docker Scout inspect the OS packages and libraries baked into image layers, which is where most "critical vulnerability" alerts still originate today.
Chainguard's approach is different: rather than scanning a general-purpose base image after the fact, it ships minimal, distroless "Wolfi"-based images rebuilt continuously so that known CVEs are patched before they're ever published, aiming for images with zero known CVEs at build time. It's a genuinely effective way to reduce base-image noise, and it's why many teams pair Chainguard images with their existing scanners. But it addresses one layer — the base image — not your application code, your CI/CD pipeline configuration, your Terraform, or your third-party SaaS integrations. A zero-CVE base image can still sit under a vulnerable dependency you added on day two. Hardening and scanning are complementary, not substitutes.
How Should Teams Prioritize the Thousands of CVEs Scanners Surface?
Teams should prioritize by exploitability and reachability, not CVSS score alone, because CVSS measures theoretical severity, not real-world risk. A CVSS 9.8 in a library function your code never calls is lower priority than a CVSS 7.5 that's on CISA's KEV list and reachable from an internet-facing endpoint. This is why EPSS (Exploit Prediction Scoring System), maintained by FIRST and rebuilt as EPSS v3 in March 2023, has become a standard second signal: it estimates the probability a CVE will be exploited in the next 30 days based on real observed activity, and typically flags fewer than 5% of all published CVEs as high-probability targets.
A useful triage sequence looks like this:
- Is it on CISA KEV? If yes, patch on a compliance-driven SLA (often 15-21 days for federal contractors, sooner for anyone under CMMC or FedRAMP).
- Is EPSS above roughly 0.1 (10% predicted exploitation probability)? Treat as high priority even if CVSS is moderate.
- Is the vulnerable function actually reachable in your call graph? Reachability analysis (via SBOM plus call-graph tooling) routinely eliminates 70-85% of "critical" findings that are present but unreachable.
- Everything else goes into a scheduled patch cycle, not an incident.
The xz-utils backdoor (CVE-2024-3094), discovered by a single engineer on March 29, 2024, is the counter-example worth remembering: it had no CVSS score and no exploitation telemetry at discovery, yet it was a near-catastrophic supply chain compromise. Automated scoring is necessary but not sufficient — provenance verification and human review still matter.
What Does a Modern Vulnerability Scanning Stack Look Like in 2026?
A modern stack generates an SBOM at build time, scans it against multiple correlated vulnerability sources, enriches findings with KEV and EPSS data, and gates deployment on reachability-adjusted risk rather than raw CVE count — producing one consolidated scanning report instead of three conflicting ones a team has to reconcile by hand. In practice that means: SBOM generation with Syft or a build-native equivalent, scanning with at least two independent engines (to cover the database-disagreement problem above), automatic enrichment against CISA KEV and EPSS feeds, and a policy engine that blocks builds on "critical + KEV-listed + reachable" rather than "critical" alone.
The organizations still getting burned in 2026 are usually the ones running exactly one scanner against exactly one artifact type, with no reachability context and no continuous re-scanning — meaning a package that was clean at build time but got a new CVE disclosed three weeks into production sits unnoticed until the next scheduled scan.
How Safeguard Helps
Safeguard is built for the reality described above: no single scanner or hardened base image eliminates supply chain risk on its own, so we correlate findings across the layers that matter instead of asking teams to stitch five tools together manually.
Concretely, Safeguard:
- Generates and tracks SBOMs continuously across source, build, and registry, so a new CVE disclosed against a component you shipped six months ago is flagged automatically instead of waiting for your next manual scan.
- Correlates multiple vulnerability sources — NVD, OSV, GitHub Advisories, and distro-specific feeds — so you get a single de-duplicated finding instead of reconciling conflicting counts from Trivy, Grype, and Snyk by hand.
- Enriches every finding with KEV status and EPSS score, and layers in reachability analysis against your actual call graph, so triage starts from "is this exploitable and reachable" instead of a raw CVSS list that's 95% noise.
- Works alongside hardened base images, including Chainguard's, rather than competing with them — you still need visibility into application dependencies, IaC misconfigurations, and runtime drift that a minimal base image doesn't cover.
- Ties scan results to compliance evidence, mapping remediation timelines to the SLAs your SOC 2, FedRAMP, or CMMC program actually requires, so vulnerability management output doubles as audit-ready documentation.
The goal isn't another dashboard with a bigger CVE count. It's fewer, better-prioritized findings that map to real exploitability, so your team spends its patching hours on the handful of vulnerabilities that matter and not the thousands that don't.