In 2017, attackers breached Equifax through a single unpatched Apache Struts library — CVE-2017-5638 — exposing the Social Security numbers of 147 million people. The patch had been available for two months before the breach was discovered. This is what "use of components with known vulnerabilities" means in practice: shipping software that depends on a library, framework, or package for which a public CVE already exists, often with a fix already released. It's category A06:2021 in the OWASP Top 10, and it hasn't gone away — Log4Shell (CVE-2021-44228), the xz utils backdoor (CVE-2024-3094), and thousands of quieter dependency-chain findings show the pattern repeats across ecosystems and years. The problem isn't a lack of CVE data; it's that most organizations can't tell which of their thousands of flagged components are actually reachable, exploitable, and worth fixing first.
What does "use of components with known vulnerabilities" actually mean?
It means running code — directly or transitively — that has a publicly disclosed CVE with a known fix, exploit, or advisory already available. This differs from a zero-day: the vulnerability is documented in the National Vulnerability Database (NVD), which has cataloged more than 240,000 CVEs as of 2025, and in most cases a patched version already exists. The risk isn't discovery — it's inaction. A 2023 Synopsys Open Source Security and Risk Analysis (OSSRA) report found that 74% of scanned codebases contained at least one high-risk open source vulnerability, and the median time between a CVE's publication and its remediation in production code frequently stretches into months, not days. OWASP's own scoring for this category cites average exploitability and detectability as "3" (on a 0-3 scale), meaning both are trivial for an attacker with access to a CVE feed and a Shodan-style scanner.
Why is this still a top-10 risk after Equifax, Heartbleed, and Log4Shell?
Because the software supply chain has grown faster than the tooling most teams use to police it. A single modern web application can pull in hundreds of transitive dependencies from one npm install or pip install, and each of those packages carries its own dependency tree. Heartbleed (CVE-2014-0160, disclosed April 2014) sat in OpenSSL — arguably the most audited cryptographic library on the internet — for over two years before discovery. Log4Shell (CVE-2021-44228), disclosed December 9, 2021, scored a maximum CVSS of 10.0 and affected Log4j versions 2.0-beta9 through 2.14.1, a library embedded in an estimated hundreds of thousands of Java applications, from Minecraft servers to enterprise SIEM platforms. Three years later, security teams were still finding vulnerable Log4j instances in production during routine audits. Scale, not negligence, is the root cause: nobody manually tracks 500 transitive packages across 40 microservices.
How did the Equifax and xz utils incidents actually happen?
Both started with a known-vulnerable or maliciously modified component that shipped into production because nobody was verifying dependency integrity at the point it mattered. Equifax's breach traced to CVE-2017-5638, an Apache Struts 2 remote code execution flaw disclosed in March 2017; Equifax's internal scan reportedly missed the vulnerable instance, and the flaw sat exploitable until attackers used it starting in mid-May 2017, with the breach detected July 29, 2017. The xz utils case (CVE-2024-3094) was different in mechanism but identical in lesson: a backdoor was deliberately inserted into a widely used compression library by a trusted-looking maintainer account over roughly two years of social engineering, and it was caught only because Microsoft engineer Andres Freund noticed a 500-millisecond SSH login delay on March 29, 2024 — days before the compromised version would have shipped broadly into major Linux distributions. Neither incident required a novel attack technique. Both required someone to have visibility into what was actually running and whether it mattered.
How many of the vulnerabilities flagged in a typical scan are actually exploitable?
Industry data consistently shows the number is small — often cited around 5-10% of flagged CVEs are reachable in a way an attacker could actually trigger. Traditional software composition analysis (SCA) tools flag a component as vulnerable the moment a CVE is published against its version string, regardless of whether the vulnerable function is ever called by the application, whether it's reachable from an untrusted input, or whether the affected code path is even compiled into the deployed artifact. This is why security teams drowning in CVE backlogs often triage by CVSS score alone — a proxy that ignores actual reachability and has repeatedly been shown to correlate poorly with real-world exploitation likelihood. A library flagged for a deserialization CVE in an unused admin utility class carries materially different risk than the same CVE reachable from an internet-facing API endpoint, yet both show up identically on a dependency inventory report.
How can teams find and prioritize vulnerable components before attackers do?
The reliable path is combining a complete software bill of materials (SBOM) with reachability analysis, not just a CVE feed lookup. An SBOM — in CycloneDX or SPDX format — establishes the full inventory of direct and transitive dependencies, which is the prerequisite step; you cannot remediate what you haven't cataloged, and CISA has required SBOM capability for federal software vendors since a 2021 executive order (EO 14028) set the expectation. From there, reachability analysis determines whether the vulnerable function in a flagged package is actually invoked by the application's call graph, cutting a typical CVE backlog by an order of magnitude in terms of what genuinely needs a hotfix this week versus what can wait for the next scheduled dependency bump. Pairing that with automated patch or upgrade generation closes the loop — the Equifax lesson wasn't that the CVE existed, it was that a known fix sat unapplied for two months.
How Safeguard Helps
Safeguard addresses "use of components with known vulnerabilities" by replacing CVE-count noise with exploitability signal. Our reachability analysis traces flagged CVEs through the actual call graph of your codebase, so teams see which vulnerable functions are invoked from untrusted input paths versus which sit dormant in unused code — the same distinction that separates a Log4Shell-scale incident from a non-event. Griffin AI, Safeguard's contextual triage engine, correlates that reachability data with exploit maturity and asset exposure to rank remediation work the way an attacker would prioritize targets, not the way a CVSS score alone would. Safeguard generates and ingests SBOMs (CycloneDX and SPDX) automatically on every build, giving security and engineering teams a continuously current inventory instead of a point-in-time snapshot. And where a fix exists, Safeguard opens auto-fix pull requests with the minimal version bump or patch needed, so the gap between "CVE disclosed" and "fix merged" shrinks from months to hours.