Open source now makes up 70-90% of the code in modern applications, according to Synopsys's 2024 Open Source Security and Risk Analysis report — but the average project still ships with hundreds of dependencies nobody on the team has ever read. That gap between "we use it everywhere" and "we understand what's in it" is where breaches start. Log4Shell (CVE-2021-44228) scored a 10.0 CVSS and was actively exploited by ransomware crews and state-sponsored actors for more than a year after a patch existed. The XZ Utils backdoor (CVE-2024-3094), discovered by chance on March 29, 2024, came within weeks of shipping in major Linux distributions. These weren't edge cases; they're the pattern. Below are five concrete, well-documented risks of relying on open source software, with the incidents and numbers that prove each one, followed by how Safeguard closes the gap between adoption and understanding.
What are the biggest risks of using open source software?
The five biggest risks are unpatched known vulnerabilities, intentionally planted malicious code, uncontrolled transitive dependencies, maintainer abandonment, and license non-compliance. Each has caused real incidents in the last decade, not hypothetical ones: Heartbleed (CVE-2014-0160) exposed private keys across roughly 500,000 servers in April 2014; the 2017 Equifax breach traced back to an unpatched Apache Struts vulnerability (CVE-2017-5638) and cost the company $1.4 billion in settlements and remediation; and the 2024 XZ Utils incident showed that even a trusted maintainer relationship, built over two years of legitimate-looking commits, can be a supply chain attack in slow motion. Open source isn't inherently less secure than proprietary code — a lot of it is more scrutinized than commercial software — but its transparency, reuse, and maintainer economics create attack surface that closed, vendor-controlled software doesn't have in the same way.
How often are open source vulnerabilities exploited before organizations patch them?
Frequently, and often for years, not days. Log4Shell was disclosed on December 10, 2021, patched within days, and yet CISA's advisory in February 2022 confirmed Iranian state-sponsored actors were still exploiting unpatched instances months later; Conti ransomware affiliates were observed using it into 2022 as well. CISA's Known Exploited Vulnerabilities (KEV) catalog, which only lists CVEs with confirmed active exploitation, has grown to over 1,300 entries as of 2025, and a large share are open source components — Apache, OpenSSL, Spring, and similar widely-embedded libraries recur across multiple years of the list. The problem isn't that patches don't exist. It's that organizations don't know which of their running services actually call the vulnerable function, so patching gets deprioritized against a backlog of CVEs that look identical in severity score but aren't identical in actual exposure.
Can attackers plant malicious code directly inside open source projects?
Yes, and it has happened at the infrastructure level, not just in obscure packages. On March 29, 2024, Microsoft engineer Andres Freund noticed a 500-millisecond SSH latency anomaly and traced it to a backdoor deliberately inserted into XZ Utils (CVE-2024-3094, CVSS 10.0) by a contributor named "Jia Tan" who had spent over two years building commit history and community trust before shipping the payload. It was already present in Debian testing and Fedora 40/41 pre-releases. In November 2018, the popular npm package event-stream was compromised when its maintainer handed control to an unknown party who added a dependency, flatmap-stream, designed to steal Bitcoin wallet credentials from apps that used the Copay wallet. And in January 2022, the maintainer of colors.js and faker.js — both downloaded millions of times weekly — deliberately sabotaged his own libraries with infinite loops as a protest, breaking builds for thousands of downstream projects overnight. Trust in a maintainer's identity or track record is not a security control.
Why do transitive dependencies multiply the risk?
Because most of the code you depend on, you never chose directly. Synk's 2020 State of Open Source Security report found the average JavaScript project pulls in 683 dependencies, and 79% of those are transitive — dependencies of your dependencies, several layers deep, that your team never explicitly reviewed or approved. A single compromised or vulnerable package three levels down in that tree can affect an application whose developers have never heard of it. This is also the mechanism behind typosquatting attacks: threat actors publish packages with names like python3-dateutil or requessts betting on a developer's typo, and Sonatype's research has repeatedly catalogued tens of thousands of such malicious packages uploaded to npm and PyPI in a single year. The deeper the dependency tree, the harder it is to answer a simple question after a CVE drops: "are we actually affected, and where?"
What happens when a maintainer disappears or abandons a project?
Critical infrastructure can break instantly, and it has. In March 2016, developer Azer Koçulu unpublished left-pad, an 11-line npm package, after a naming dispute — and because thousands of projects (including Babel and React tooling) depended on it transitively, builds broke across the JavaScript ecosystem within hours until npm reinstated the package. Log4j itself, despite running inside an estimated hundreds of thousands of applications globally, was maintained largely by a small volunteer team; lead maintainer Volkan Yazıcı has spoken publicly about the team fielding the Log4Shell response essentially unpaid and under-resourced while enterprise users worth billions in market cap depended on their unpaid nights and weekends. Tidelift and the Linux Foundation's own research has flagged maintainer burnout and single-maintainer projects as a structural, ongoing risk category — not a one-off event — because there's no SLA on volunteer labor.
Does open source licensing create real legal risk?
Yes — license non-compliance has produced enforceable court rulings, not just cease-and-desist letters. The Software Freedom Conservancy sued Vizio in 2021 for failing to release GPL-licensed source code used in its smart TVs; in February 2024, a California appellate court ruled that GPL license terms are enforceable as third-party beneficiary contract rights, a decision that materially raised the legal exposure of shipping GPL code without complying with its terms. Beyond copyleft obligations, license proliferation itself is a risk: a single application can pull in MIT, Apache-2.0, GPL, LGPL, and AGPL-licensed components simultaneously, each with different obligations around attribution, source disclosure, and patent grants, and most engineering teams have no automated way to track which license terms apply to which shipped binary. For companies doing M&A due diligence or selling into regulated industries, an unresolved license audit can delay or kill a deal.
How Safeguard Helps
Safeguard is built to close exactly the gap these five risks share: knowing a vulnerable or malicious component exists somewhere in your stack isn't the same as knowing whether it's actually exploitable in your running application. Our reachability analysis traces whether vulnerable code paths — like the JNDI lookup at the heart of Log4Shell — are actually called by your application logic, so teams can separate the CVEs that need action this week from the ones that are technically present but functionally dormant. Griffin, our AI security analyst, continuously reasons over SBOMs, CVE feeds, and your actual codebase to explain in plain language why a finding matters (or doesn't) and prioritize accordingly. Safeguard generates and ingests SBOMs across your build pipeline so you have a real, current inventory of every direct and transitive dependency — including the ones nobody on the team remembers adding — and when a fix is available, Safeguard opens auto-fix pull requests that update the vulnerable dependency and run your existing CI checks, turning a multi-day patching cycle into a one-click merge.