Every major breach post-mortem of the last decade tells some version of the same story: a vulnerability that was public, patched, and searchable in the National Vulnerability Database sat inside a production dependency for weeks or months before anyone noticed. Equifax had 76 days between the Apache Struts patch (CVE-2017-5638) and the breach disclosure. The Log4Shell vulnerability (CVE-2021-44228), disclosed December 10, 2021, was still being actively exploited against unpatched systems more than a year later. These aren't detection failures in the sense of "no tool existed" — SCA scanners have existed since the mid-2010s. They're triage failures: teams got the alert and didn't act on it fast enough, or acted on the wrong one first. With over 40,000 CVEs published in 2024 alone and the average application pulling in 180+ transitive dependencies, "detection" was never the hard part. Knowing which of the thousand open findings will actually get you breached is.
What Actually Counts as a "Known Vulnerability" in a Dependency?
A known vulnerability is a publicly disclosed weakness in a piece of third-party code your application depends on — directly or transitively — that has been assigned an identifier (typically a CVE) and cataloged in a database like NVD, GitHub Advisory Database, or OSV. The key word is "known": unlike a zero-day, the vulnerability, its severity, and often a proof-of-concept exploit are all public information the moment it's disclosed. That's exactly what makes these vulnerabilities both easier and harder to deal with than novel bugs — easier because a fix usually already exists, harder because attackers are reading the same advisory you are, often within hours.
Modern applications rarely vendor code you wrote. Sonatype's 2024 State of the Software Supply Chain report found the average application has 148 dependencies, and Snyk's research puts 86% of known vulnerabilities in indirect (transitive) dependencies — packages your package pulled in, that you never explicitly chose. This is why "known vulnerabilities in dependencies" has become its own OWASP Top 10 category (A06:2021 — Vulnerable and Outdated Components): the vulnerable code isn't in your diff, so your normal code review never sees it.
How Do Known Vulnerabilities Actually Get Exploited in Production?
They get exploited through the gap between disclosure and remediation, and that gap is measured in days while exploitation starts in hours. Mandiant's 2023 data showed time-to-exploit for newly disclosed vulnerabilities had shrunk to a median of about 5 days, down from 32 days in 2021 — and for high-profile CVEs like Log4Shell, mass scanning began within 24 hours of disclosure. Attackers don't need to find the bug; they read the same GitHub Security Advisory, CVE entry, or Metasploit module your security team does, then run automated internet-wide scans for unpatched instances.
The xz backdoor (CVE-2024-3094), discovered in March 2024, is the inverse case worth knowing: a malicious maintainer spent over two years gaining commit access to a widely-used compression library before inserting a backdoor into the build scripts, nearly landing in major Linux distributions. It's a reminder that "known vulnerability" management also has to cover supply-chain tampering, not just accidental bugs — both end up as a CVE, and both are exploited the same way: silently, at scale, through code nobody re-reviewed after the initial dependency decision.
Why Does Scanning Alone Fail to Stop These Breaches?
Scanning alone fails because it produces volume, not judgment, and most teams drown in the former. A typical mid-size codebase running a standard SCA tool for the first time generates hundreds to low-thousands of findings; GitLab's 2023 Global DevSecOps survey found 42% of security professionals say vulnerability backlogs are unmanageable, and a majority of teams report fewer than half of critical findings get remediated within SLA. The CVSS score alone is a poor prioritization signal: roughly 60% of CVEs published in NVD carry a "High" or "Critical" base score, because CVSS measures theoretical severity, not real-world exploitability or whether the vulnerable code path is even reachable in your application.
This is the well-documented gap between "vulnerable" and "exploitable." Research from Chainguard and others has repeatedly found that 80-90%+ of vulnerabilities flagged in container images live in code paths that are never actually invoked at runtime. A CVE in a logging library's XML parser only matters if your application calls that parser with attacker-controlled input — Log4Shell was catastrophic precisely because that condition was true almost everywhere Log4j 2 was deployed, which is the exception, not the rule. Teams that triage purely by CVSS score end up patching unreachable code while an EPSS-high, CVSS-medium finding with active exploitation sits untouched.
How Should Teams Prioritize Which CVEs to Fix First?
Teams should prioritize using a layered signal — exploitability, reachability, and exposure — instead of CVSS score in isolation. The Exploit Prediction Scoring System (EPSS), maintained by FIRST.org, estimates the probability a given CVE will be exploited in the next 30 days based on real-world telemetry; it routinely shows that a large share of "Critical" CVSS findings have an EPSS score under 1%, while some "Medium" findings sit above 50% because they're being actively weaponized. CISA's Known Exploited Vulnerabilities (KEV) catalog, which crossed 1,300 entries by mid-2025, is the other essential filter: if a CVE is in KEV, it has confirmed real-world exploitation and federal agencies are mandated to patch it on a fixed timeline (often 2-3 weeks under Binding Operational Directive 22-01).
A workable triage order looks like: (1) Is it in CISA KEV, or does it have a high EPSS score? (2) Is the vulnerable function actually reachable from your application's call graph? (3) Is the affected component internet-facing or handling untrusted input? Only after those three filters should CVSS severity break ties. This is also why remediation SLAs tied purely to severity ("fix all Criticals in 15 days") routinely fail — they don't account for the fact that a fix isn't always a version bump; it can require a breaking API change, and 21% of dependency updates in Sonatype's research introduce at least one breaking change, which is precisely why teams delay them.
What Does Mature Detection-to-Triage Workflow Look Like?
A mature workflow treats detection as the start of a measured process, not the end of one, with defined ownership and SLA at every stage. That means: continuous SCA scanning on every build (not just quarterly audits), automatic enrichment of every CVE with EPSS score and KEV status at ingestion time, reachability analysis to suppress findings in dead code paths, and routing that assigns each surviving finding to the team that owns the affected service — not a central security queue that becomes a graveyard. Google's 2023 DORA report and multiple vendor benchmarks converge on the same number: organizations with automated, enriched triage close critical vulnerabilities roughly 3-5x faster than those relying on manual severity review.
Equally important is tracking the metric that predicts breach risk best: not "number of open vulnerabilities" but "mean time to remediate for KEV-listed or high-EPSS findings." A backlog of 2,000 low-exploitability findings is a much smaller risk than 5 unpatched KEV entries on an internet-facing service.
How Safeguard Helps
Safeguard is built for exactly this gap — the space between "we found 1,400 CVEs" and "here's the one that will actually hurt you this week." Our software composition analysis runs continuously across every build and container, mapping every direct and transitive dependency and matching it against CVE, GitHub Security Advisory, and OSV feeds in near real time, so newly disclosed vulnerabilities like a future Log4Shell surface within minutes of publication rather than at the next scheduled scan.
Every finding Safeguard surfaces is automatically enriched with EPSS exploitation probability, CISA KEV status, and reachability analysis against your actual call graph — so a Critical-CVSS finding in unreachable code is visibly deprioritized below a Medium-CVSS finding with confirmed active exploitation, instead of both landing in the same undifferentiated queue. Findings route directly to the owning service team with suggested fix versions and compatibility notes, and Safeguard tracks mean-time-to-remediate specifically for KEV and high-EPSS findings as a first-class SLA metric, not buried in an aggregate count.
For teams under SOC 2 or similar compliance obligations, Safeguard also maintains the audit trail auditors ask for automatically: when each vulnerability was detected, how it was triaged, who owned the fix, and when it was resolved — turning what's usually a scramble through spreadsheets into a report generated in minutes. The goal isn't a longer list of known vulnerabilities in dependencies; it's a shorter list of the ones that matter, fixed before an attacker reads the same advisory you did.