In September 2017, Equifax disclosed a breach that exposed the personal data of 147 million people. The root cause wasn't a novel zero-day or a nation-state exploit chain — it was Apache Struts CVE-2017-5638, a vulnerability with a patch available two months before attackers walked in. That gap between "patch exists" and "patch applied" is where most software supply chain damage actually happens, and it happens far more often than most engineering teams assume.
Outdated components aren't an edge case in modern software — they're the default state. The average commercial application now pulls in hundreds of open-source dependencies, most of which nobody on the team is actively watching. This post quantifies just how large that exposure is, walks through what happens when it's exploited, and looks at why "just update it" is harder than it sounds. Then we cover how Safeguard closes the gap between vulnerability disclosure and remediation.
How Common Are Outdated Components in Production Codebases?
Nearly universal. Synopsys's Open Source Security and Risk Analysis (OSSRA) report has found for several years running that 96%+ of commercial codebases contain open-source code, with an average of 500+ open-source components per application. The same research consistently finds that roughly 74–84% of codebases contain at least one known, publicly disclosed vulnerability in a dependency, and a large share of those vulnerabilities are rated high or critical severity.
This isn't because engineering teams are careless. It's structural: a typical Node.js or Java service pulls in a handful of direct dependencies, each of which pulls in its own dependencies, several layers deep. A single package.json can resolve to a dependency tree of 1,000+ transitive packages. Nobody manually reviews that tree, and once a component is wired in, it tends to sit untouched until something breaks or a security scanner flags it — if a scanner is running at all.
What Actually Happens When an Outdated Component Gets Exploited?
It goes from "background risk" to "front-page breach" within days, because attackers move faster than most patch cycles. The clearest case study is Log4Shell (CVE-2021-44228), disclosed on December 9, 2021. Log4j, a logging library embedded in an enormous share of Java applications, had a remote-code-execution flaw with a maximum CVSS score of 10.0. Within 24 hours, security researchers were tracking mass internet scanning for vulnerable endpoints. Within a week, Check Point reported over 800,000 exploitation attempts. Because Log4j was buried three or four dependency layers deep in countless applications, many organizations couldn't even produce a reliable list of where they were affected — some spent months on discovery alone.
The Equifax breach followed the same pattern on a longer timeline: Apache Struts' CVE-2017-5638 was disclosed and patched in March 2017; Equifax was compromised in May and didn't detect it until July. The component wasn't obscure, the patch wasn't hard to find — the vulnerability simply outlived the organization's ability to notice it applied to them and act.
Why Don't Teams Just Update Vulnerable Components Immediately?
Because updating isn't free, and most organizations have no reliable signal telling them which updates matter. In Snyk's State of Open Source Security research, a majority of developers admitted they knowingly ship known vulnerabilities because of deadline pressure, and a comparable share said they don't believe fixing vulnerabilities is a top priority for their organization at all. That's not negligence — it's a rational response to a system that gives them a flood of low-context CVE alerts with no severity triage, no reachability analysis, and no clear owner.
There's also real technical friction: a major-version bump in a core dependency can break APIs, change default behaviors, or conflict with other dependencies pinned to older versions. Without automated testing and a clear understanding of whether a vulnerable function is actually reachable from your code paths, "just update the library" can mean days of regression testing for a fix that might not have been exploitable in your specific usage anyway — or worse, teams skip it because they can't tell, and the truly exploitable case goes unpatched right alongside the harmless one.
How Long Do Vulnerable Components Stay Exposed After a Fix Ships?
Far longer than the window attackers need. Research from Kenna Security (now part of Cisco) and the Cyentia Institute has repeatedly found that organizations take a median of several weeks to months to remediate high-severity vulnerabilities, while working exploit code for high-profile CVEs typically appears within days of disclosure. CISA's Known Exploited Vulnerabilities (KEV) catalog — which by policy only lists vulnerabilities with confirmed active exploitation — has grown to well over 1,100 entries since its 2021 launch, and a significant share of federal agencies subject to CISA's binding remediation deadlines still miss them.
The pattern holds across incidents: the 2017 Equifax patch existed 60+ days before exploitation; Log4Shell exploitation began before most organizations had even inventoried their exposure; the 2020 SolarWinds and 2023 MOVEit incidents both involved software components that stayed in trusted production environments for extended periods after risk indicators existed. The lesson is consistent — the danger window isn't "is a patch available," it's "how long until someone with visibility acts on it."
What Does an Outdated-Component Breach Actually Cost?
More than the patch would have. IBM's Cost of a Data Breach Report has put the global average cost of a data breach at roughly $4.45–4.88 million in recent years, and breaches attributed to known, unpatched vulnerabilities consistently rank among the more expensive categories because they combine direct incident response costs with the reputational cost of "this was preventable." Equifax alone settled for over $700 million with the FTC, CFPB, and state regulators — a bill directly traceable to a single unpatched web framework component. Beyond direct breach costs, outdated components increasingly carry compliance exposure: SOC 2, ISO 27001, and frameworks aligned with NIST SSDF and the White House's software supply chain executive order all expect demonstrable vulnerability management, meaning stale dependencies can now block deals and audits even before they're exploited.
Is This Risk Getting Better or Worse Over Time?
Worse, by volume, even as tooling improves. The National Vulnerability Database logged over 28,000 new CVEs in 2023 alone, up sharply from prior years, and open-source package ecosystems (npm, PyPI, Maven Central, RubyGems) continue to grow at double-digit annual rates, expanding the attack surface every organization inherits by default. At the same time, supply chain attacks are shifting upstream — instead of waiting to find a vulnerability in a popular package, attackers are increasingly injecting malicious code directly into dependencies (as seen in incidents affecting npm and PyPI packages throughout 2023–2025), meaning "outdated" and "compromised" are converging into the same risk category. The math is not in favor of manual tracking: more components, more CVEs, more transitive depth, and a shrinking window between disclosure and exploitation.
How Safeguard Helps
Safeguard is built around the assumption that no team can manually track hundreds of dependencies across dozens of services in real time — so it doesn't ask them to. Safeguard continuously inventories every direct and transitive component across your codebase and generates a living software bill of materials (SBOM), so "what are we running, and where" is always answerable in seconds, not weeks.
When a new CVE drops, Safeguard doesn't just flag that a vulnerable version exists somewhere in your dependency tree — it correlates disclosure data (including CISA KEV status and exploit-availability signals) against your actual codebase to show which instances are reachable and exploitable versus which are dormant, so your team can triage by real risk instead of raw CVE count. That single change is what collapses the Equifax-style gap: instead of a security bulletin sitting in an inbox, Safeguard surfaces a prioritized, actionable list tied directly to the services and teams that own the affected code.
Safeguard also tracks remediation over time, giving security and compliance teams the audit trail that SOC 2 and NIST SSDF assessments increasingly require — proof that known vulnerabilities were identified, prioritized, and closed within a defined window, not just that a scanner ran once. For engineering teams, that means fewer noisy alerts and clearer ownership; for security and compliance teams, it means the difference between hoping your components are current and being able to demonstrate it.
If your organization can't currently answer "which of our production services are running a component from this week's CVE list, and are any of them actually exploitable," that's the gap Safeguard is built to close — before it becomes next year's breach disclosure.