The Hidden Security Risks in Open-Source Dependencies Nobody Talks About
None
<p>Virtually every application in today’s software world is built upon a series of layers of open-source code. While it may appear to be a good thing, as it allows developers to develop code swiftly and utilise tested code, this can expose security risks lurking in the background. Big <a href="https://securityboulevard.com/2024/12/log4shell-vulnerability-why-it-still-exists-and-how-to-protect-yourself-contrast-security/" target="_blank" rel="noopener">incidents like Log4Shell</a> also demonstrated that a single vulnerable library can bring thousands of systems to a standstill. While they may not make the news, they continually pose a serious threat if overlooked. Learning about the larger threats facing the open-source world of software security will help ensure your organisation is not caught off guard by a Trojan Horse.</p><h3><strong>The Ubiquity and Fragility of Open Source</strong></h3><p>Open-source code is all around us; a <a href="https://www.securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases">recent</a> <a href="https://www.securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases" target="_blank" rel="noopener">survey</a> <a href="https://www.securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases">of</a> <a href="https://www.securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases">the</a> <a href="https://www.securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases">industry</a> found that 86% of enterprise codebases had at least one vulnerable open-source software component. Modern applications rely on hundreds, or even thousands, of third-party libraries. A study found that the average application in 2024 had more than 16,000 open-source files, triple the number a few years ago.</p><p>The reality is that most of the code that comprises the application was written by someone else, perhaps even a stranger on the internet. It’s like a dependency avalanche. As Mike McGuire from Snyk describes it, blind spots abound in open-source dependency management. 61% of dependencies are transitive, meaning they’re included indirectly by other libraries.</p><p>It’s hard to know what is being delivered. The software supply chain is complicated and vulnerable. Most of us assume that if a library is popular, then it must be secure, as many eyes have seen the code. That’s not necessarily true. Open-source projects tend to be supported by volunteers. <a href="https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-open." target="_blank" rel="noopener">NIST</a> states that OSS projects tend to be diverse, numerous, and use a wide range of operating models.</p><p>The integrity or maintenance of OSS is not well understood or easily discoverable. Thousands of applications rely on libraries that are no longer supported. A 2025 security report found that 90% of codebases used libraries more than four years old, and 79% used components that had not been updated in two years or more. These outdated libraries increase the attack surface. The reality is that when a project is abandoned, even a small bug will persist indefinitely, as no one is left to fix it.</p><h3><strong>Hidden Vulnerability Chains and Unknown Code</strong></h3><p>Most teams will use tools such as SCA tools to scan their dependencies against known issues. However, it’s worth noting that third-party risks are not limited to known issues. While it is true that if all known issues were fixed as soon as they were known, then many problems would be averted, there are still two major issues that would arise. The first is the problem of transitivity, and the second is the problem of potentially malicious code. This is because most modern applications will have hundreds of dependencies, and each of those dependencies will have dozens of dependencies of their own.</p><p>You can always fix the direct ones you know of, but what about the ones you don’t? The <a href="http://v/">OWASP</a> Top 10 has noted that most problems arising from software supply chain issues arise from “vulnerabilities or malicious changes in third-party code, tools, or other dependencies.” This means the break could be from much further up the chain.</p><p>For example, if your application uses Library A, which uses Library B, Library C, and so on, then if Library A is clean—no known problems—then if Library B has a problem, your application is still broken because of Library B. This is not a hypothetical scenario. The <a href="https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html" target="_blank" rel="noopener">Google</a> SLSA framework has documented dozens of real-world attacks from different places in the supply chain.</p><p>In one case, dubbed “Event-Stream,” attackers modified an otherwise perfectly harmless dependency of an npm package, making it an attack vector for malware. There was no CVE, simply because this was not a bug, but rather an attack. SLSA suggests that end-to-end integrity checks might have prevented this attack. The bottom line is that any code that finds its way into your build path can become an attacker.</p><p>Things are made worse by the attackers’ ingenuity at finding new ways to smuggle code into your project without your knowledge. For example, dependency confusion and typosquatting attacks have become particularly sophisticated. In 2021, <a href="https://www.aikido.dev/blog/software-supply-chain-security-vulnerabilities">Alex</a> <a href="https://www.aikido.dev/blog/software-supply-chain-security-vulnerabilities" target="_blank" rel="noopener">Birsan</a> showed that an attacker could publish code to both npm and PyPI under an organisation’s internal namespace, thereby tricking their own build systems into ingesting attacker-controlled code.</p><p>Typosquatting is another notably pernicious attack. An attacker publishes code to a package manager under a namespace that is close to, but not quite, that of an existing, popular library, such as reactrouteer vs. react-router. These “impostor” packages often contain hidden payloads, such as a Trojan horse that executes during installation, exfiltrating credentials or corrupting code. A <a href="https://www.sonatype.com/press-releases/open-source-malware-reaches-778500-packages.">recent</a> <a href="https://www.sonatype.com/press-releases/open-source-malware-reaches-778500-packages.">study</a> found that millions of such malicious or squatter packages were found on public repositories. Sonatype found that over 778,500 “open-source malware” packages had been identified since 2019, with 98.5% of these found on npm.</p><p>According to Sonatype’s CTO, “<em>Open-source malware, in particular, is a big problem because it sits right between endpoint protections and traditional vulnerability scans. In fact, by the time a scanner detects it, the damage could already be done</em>.” Another problem with open-source software, according to <a href="https://plextrac.com/spooky-supply-chains-researcher-reality-a-conversation-with-jonathan-leitschuh/" target="_blank" rel="noopener">Leitschuh</a>, a veteran of the cybersecurity field, is that “these artefact repositories sat at the heart of the global SDLC without ever going through any enterprise-grade penetration testing or SOC audits.”</p><p>In a nutshell, it is about the critical infrastructure developed and maintained by the open source community, such as build tools and container images, which are mostly open source and rarely tested. So, as OWASP explains in its cheat sheet, “<em>a weak link in the entire supply chain, such as a third-party library or version control issue, can put the entire supply chain at risk.”</em> In other words, a hidden vulnerability, from a small library bug to a broken step in the build process, can eventually lead to a major breach.</p><h3><strong>Attacks on Maintainers and the Pipeline</strong></h3><p>The unseen threats are those individuals behind the code. Just like how hackers target CEOs through social engineering attacks, they are increasingly targeting developers and maintainers. But why are they doing this? Well, the reason is that most of the maintainers of these packages are volunteers who are working on these projects without any supervision or contract. So, what will a hacker do if he gains access to a maintainer’s account? He will be able to inject a backdoor into a package that users are already familiar with. In fact, a single <a href="https://aftra.io/blog/software-supply-chain-risk-youre-ignoring." target="_blank" rel="noopener">npm</a> maintainer’s compromise in 2024 resulted in 18 popular packages being backdoored, resulting in billions of downloads.</p><p>Even the most honest developers can inadvertently create problems down the chain. For instance, a security team at some organisation decided to rename their GitHub organisation as part of a routine update. But what they didn’t know was that the hacker had already taken the name they were trying to rename and had injected a backdoor into every CI workflow that hadn’t been updated to the new URL. As the researcher said, <em>“It was still the same software… with the added backdoor.”</em> The problem here is that the tools and workflows we are using have hidden vulnerabilities.</p><p>There are hidden threats, too, coming from the tools and workflows used for building and delivery. The Codecov breach in 2021 was a classic case of attackers exploiting weaknesses in build and delivery systems. Attackers used a CI token to upload a malicious package into a deployment bucket, and then users would simply pull a backdoored binary without prior knowledge.</p><p>Leitschuh points out that enterprise CI/CD systems are not built with strong security features, such as multi-factor authentication and audits, and attackers could therefore “break this part of the chain” too easily. In fact, attackers could break into a build system and then push their own code without compromising a dependency package. This form of stealth injection, in which attackers push a malicious build or a container, leaves almost no trace.</p><h3><strong>Mitigations and Best Practices</strong></h3><p>In today’s environment, the assumption that any link in the chain could be compromised should be made, and traditional perimeter defences, such as code review, are not sufficient. Layered defences are becoming the norm, and software composition analysis and SBOM generation are aiding the discovery of what exactly constitutes the software supply chain, including transitive dependencies.</p><p>This means that agencies, such as those mandated by NIST EO 14028, are required to strictly control their dependencies, ensuring that they are only obtained from trusted, known sources, that two-factor authentication is enabled for all maintainer accounts and that version control is used to avoid accidentally pulling in a malicious version of a dependency, for instance.</p><p>Tools such as Snyk and Dependabot can detect known vulnerabilities, but, as Brian Fox of Sonatype comments, we need to take a step forward and ensure that open-source malware does not even enter the pipeline in the first place.</p><p>New frameworks, such as Google’s SLSA, are filling this gap, providing a structure for these total protections. SLSA, or Supply-chain Levels for Software Artefacts, is “a set of guidelines on how to best preserve end-to-end build integrity.” The authors note that integrity attacks are on the rise and that, while specific solutions may be necessary, overall structural solutions may be necessary to counter this trend.</p><p>“By accumulating verifiable metadata around every build (e.g., SBOM, provenance), we provide ourselves with the ability to identify any kind of tampering or mismatching of dependencies.” The same zero-trust approach applies here, trusting every open-source library until verified, then implementing runtime protections such as anomaly detection to catch anything that might slip through.</p><p>In terms of specific actions, teams should “take care of the fundamentals, such as understanding the entire dependency tree, eliminating unmaintained libraries, and being quick to react to newly disclosed issues.” An expert’s advice is that rather than “blindly updating all packages,” teams should “add multiple levels of checks to make life harder for attackers.”</p><p>Collaboration between development and security teams is necessary, treating open-source libraries with the same level of scrutiny that you would other licensed software. After all, as</p><p>OWASP reminds us, “Your security is only as strong as its weakest link in your supply chain.”</p><h3><strong>Securing the Software Supply Chain Before it Secures You</strong></h3><p>Hidden threats in open-source dependencies have emerged as the new frontier of cybersecurity challenges. They range from the mundane, such as stale and unpatched code, to the sinister, such as unknown backdoors and misused packages. No longer can CEOs at the highest levels afford to dismiss these threats, as they are squarely on the boardroom agenda today.</p><p>As a cybersecurity expert succinctly puts it: “<em>Your software supply chain is already more intricate and fragile than you think… The packages your systems rely on could vanish or turn hostile at any moment. That’s not fear-mongering. That’s the reality.” </em></p><p>But there’s good news too: awareness and tools are on the rise. The key, however, lies in vigilance and preparedness; every open-source dependency is treated as an attack surface, and detection tools are always at the ready. In a world where software supply chain cybersecurity only seems to get tougher, the cost of preparedness and transparency far outweighs the cost of being caught off guard.</p><div class="spu-placeholder" style="display:none"></div><div class="addtoany_share_save_container addtoany_content addtoany_content_bottom"><div class="a2a_kit a2a_kit_size_20 addtoany_list" data-a2a-url="https://securityboulevard.com/2026/03/the-hidden-security-risks-in-open-source-dependencies-nobody-talks-about/" data-a2a-title="The Hidden Security Risks in Open-Source Dependencies Nobody Talks About"><a class="a2a_button_twitter" href="https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2026%2F03%2Fthe-hidden-security-risks-in-open-source-dependencies-nobody-talks-about%2F&linkname=The%20Hidden%20Security%20Risks%20in%20Open-Source%20Dependencies%20Nobody%20Talks%20About" title="Twitter" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_linkedin" href="https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2026%2F03%2Fthe-hidden-security-risks-in-open-source-dependencies-nobody-talks-about%2F&linkname=The%20Hidden%20Security%20Risks%20in%20Open-Source%20Dependencies%20Nobody%20Talks%20About" title="LinkedIn" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_facebook" href="https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2026%2F03%2Fthe-hidden-security-risks-in-open-source-dependencies-nobody-talks-about%2F&linkname=The%20Hidden%20Security%20Risks%20in%20Open-Source%20Dependencies%20Nobody%20Talks%20About" title="Facebook" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_reddit" href="https://www.addtoany.com/add_to/reddit?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2026%2F03%2Fthe-hidden-security-risks-in-open-source-dependencies-nobody-talks-about%2F&linkname=The%20Hidden%20Security%20Risks%20in%20Open-Source%20Dependencies%20Nobody%20Talks%20About" title="Reddit" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_email" href="https://www.addtoany.com/add_to/email?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2026%2F03%2Fthe-hidden-security-risks-in-open-source-dependencies-nobody-talks-about%2F&linkname=The%20Hidden%20Security%20Risks%20in%20Open-Source%20Dependencies%20Nobody%20Talks%20About" title="Email" rel="nofollow noopener" target="_blank"></a><a class="a2a_dd addtoany_share_save addtoany_share" href="https://www.addtoany.com/share"></a></div></div>