Most engineering teams don't have a vulnerability management program — they have a vulnerability reaction process. A scanner fires off 400 alerts on a Friday, someone triages them by CVSS score alone, half get dismissed as "not exploitable," and the backlog quietly grows. Meanwhile, vendors like Chainguard have popularized a different pitch: rebuild your base images from scratch and the CVE count drops to zero. It's an appealing story, and it solves a real problem. But a zero-CVE base image is one input to a vulnerability management program, not the program itself. The National Vulnerability Database logged over 40,000 new CVEs in 2024 — a record, and roughly triple the volume from a decade earlier. Engineering teams shipping code against that backdrop need a system: consistent discovery, risk-based prioritization, ownership, SLAs, and proof that remediation actually happened. This post breaks down what that looks like in practice, and where image-hardening alone falls short.
What does a real vulnerability management program actually cover?
A real program covers five things: discovery, prioritization, ownership, remediation SLAs, and verification — and most teams have only built the first one. Discovery is the easy part now; SCA tools like Trivy, Grype, and Snyk will happily hand you a list of every vulnerable package in your SBOM. The gap shows up immediately after: who owns CVE-2024-XXXX in the payments service, is it actually reachable from an attacker-controlled input, what's the deadline to fix it, and how does anyone confirm it got fixed rather than just marked "resolved" in a spreadsheet. Gartner's research on vulnerability management consistently finds that organizations without a documented risk-based prioritization process take 60-100+ days longer to remediate critical issues than those with one, not because the fixes are harder, but because nobody owns the decision to act. A vulnerability management program for engineering teams has to assign that ownership at the service or team level, not centralize it in a security team that has no context on the code.
Why isn't rebuilding base images enough to fix vulnerability debt?
Rebuilding base images isn't enough because most CVE exposure lives in application dependencies, not the OS layer, and those still need triage after the rebuild. Chainguard's core product — minimal, distroless-style images rebuilt daily — genuinely reduces OS-package CVE noise, and for teams drowning in glibc and openssl alerts that never affected them, that's real value. But a 2023 analysis by the Cloud Native Computing Foundation found that in a typical containerized application, 70-85% of scanned vulnerabilities trace back to language-level dependencies (npm, PyPI, Maven, RubyGems packages) layered on top of the base image, not the base OS itself. Swapping node:20 for a Chainguard equivalent won't touch the 340 transitive npm packages your package-lock.json pulls in, several of which are statistically likely to have a known CVE at any given time. Teams that adopt hardened base images and stop there often see their scanner's CVE count drop by 60-90% on day one, declare victory, and then get surprised eight months later when a dependency like xz-utils (CVE-2024-3094, the backdoor discovered in March 2024) or a transitive library shows up in an audit they weren't tracking.
How should engineering teams decide which CVEs to fix first?
Engineering teams should prioritize using reachability and exploitability signals, not raw CVSS scores, because CVSS alone flags far more "critical" issues than any team can realistically fix. CISA's Known Exploited Vulnerabilities (KEV) catalog — the list of CVEs with confirmed active exploitation — held around 1,300 entries as of mid-2024, out of a total NVD population north of 240,000. That's roughly half a percent of all known vulnerabilities accounting for essentially all real-world exploitation activity your team needs to worry about urgently. Layering in EPSS (Exploit Prediction Scoring System) probability data narrows the list further: a 2023 study backing EPSS v3 showed that the top 1% of EPSS-scored CVEs accounted for over 80% of vulnerabilities later observed being exploited in the wild. A vulnerability management program for engineering teams should triage in this order: is it in the KEV catalog, is it reachable in your actual call graph (not just present in the dependency tree), does it have a high EPSS score, and only then does CVSS severity break ties. Log4Shell (CVE-2021-44228, disclosed December 9, 2021) is the textbook case — CVSS 10.0, but the organizations that survived it fastest were the ones who could immediately answer "is log4j-core actually loaded and reachable in our services" rather than starting from a list of every artifact that merely contained the JAR.
What SLAs should a modern program actually enforce?
A modern program enforces SLAs tied to exploitability and exposure, typically 24-72 hours for actively exploited internet-facing issues, 15 days for other criticals, and 30-90 days for high/medium findings — and then measures whether teams actually hit them. This roughly mirrors what CISA's Binding Operational Directive 22-01 requires of federal agencies: KEV-listed vulnerabilities get 2 weeks, others get 6 months, with agencies required to report remediation status. Commercial teams that adopt similar tiering see materially different outcomes than teams working an undifferentiated backlog — the difference isn't effort, it's that SLA-tiered programs stop treating a CVSS 9.8 in an unreachable dev-only dependency the same as a CVSS 7.5 actively being scanned for by botnets, as happened within days of the MOVEit Transfer vulnerability (CVE-2023-34362) becoming public in May 2023. The SLA only works, though, if there's a system tracking age-of-open-finding per team and escalating automatically — otherwise it's a policy document nobody checks against reality.
Where does Chainguard's model fall short for engineering teams running the whole program?
Chainguard's model falls short because it optimizes one artifact type — container base images — while a vulnerability management program has to span source code, dependencies, containers, and infrastructure as a single risk surface. Chainguard, founded in 2021 by former Google and Grafeas engineers and having raised over $250M as of its 2024 Series C, built a strong niche business around hardened, minimal, frequently-rebuilt images distributed through its own registry. That's a supply-chain hardening play, and it's genuinely useful for cutting OS-layer noise. But it doesn't give engineering teams a way to triage the application-layer CVEs that dominate real exposure, doesn't provide cross-repo SLA tracking or ownership routing, and locking into a proprietary image registry introduces its own dependency and migration cost that many platform teams are wary of. Teams that adopt Chainguard images still need a separate system to answer "which of our 200 services have an unpatched critical CVE that's been open more than 30 days, and who owns it" — that's a program question, not an image question.
How Safeguard Helps
Safeguard is built around the program, not just one layer of it. Instead of asking teams to rebuild their base image inventory around a proprietary registry, Safeguard ingests SBOMs and scan results from the tools already in your pipeline — Trivy, Grype, Syft, GitHub, GitLab, container registries — and correlates them across source repos, dependencies, containers, and cloud infrastructure into one risk view. Every finding gets automatically enriched with KEV status, EPSS score, and reachability analysis, so engineering teams see the 1-2% of findings that actually matter instead of a raw CVSS-sorted list of thousands.
From there, Safeguard applies configurable SLA policies by severity and exploitability tier, routes each finding to the owning team or service based on your existing repo and org structure, and tracks age-of-open-finding with automatic escalation when SLAs slip — the same discipline behind CISA's BOD 22-01, applied to your engineering org instead of a federal agency. Compliance and security leaders get a real-time view of program health (mean time to remediate, SLA adherence by team, KEV exposure) without chasing spreadsheets, while engineers get findings inside the tools and workflows they already use, with the context needed to act in minutes rather than escalate to a ticket queue.
If you're currently choosing between "rebuild everything on hardened images" and "build an actual vulnerability management program," it doesn't have to be either — Safeguard works alongside hardened base images and layers the triage, ownership, and SLA enforcement on top that makes the whole program measurable. Teams that plug Safeguard into an existing scanning stack typically cut mean-time-to-remediate on critical findings by more than half within the first quarter, simply because the right person finds out about the right vulnerability on day one instead of day forty.