Attacking the OSS supply chain is a no-brainer for malicious actors: protecting it is hard.

Open source software (OSS) has become a major threat vector over the last decade. The reason is simple mathematics. “There are over 5 million OSS packages available,” explains Mehran Farimani, CEO at RapidFort. 

Chris Hughes, chief security advisor at Endor Labs, adds, “Adoption [of OSS] has grown exponentially in the last decade and shows no signs of slowing down. It is now found in nearly 90% of modern code bases and makes up 70-80% of those code bases.”

Nick Mistry, CISO and SVP at Lineaje, says, “On average, most companies work with 11 third parties. Of those 11 third parties, 98% have experienced a breach. Research found that an average of 250 components with unknown origins lurk within every application, creating significant points of exposure for the software supply chain – sometimes even years later.”

Raj Samani, SVP and chief scientist at Rapid7

Raj Samani, SVP and chief scientist at Rapid7, continues, “With supply chain attacks increasing by 431% since 2021, it’s clear that in 2025, this will remain an area where organizations will be exposed through vulnerabilities in open-source software. Instead of being directly targeted, many organizations may find themselves compromised via their suppliers, partners, or third-party dependencies.”

OSS offers a one-to-many opportunity – one compromised OSS package can result in multiple company breaches. Since cybercrime is a business, return on effort is important to the criminal: compromising one target to lead to multiple victims is a no-brainer. The mathematics of OSS shows the size of the opportunity, while the mathematics of supply chain breaches shows the criminal success rate in targeting OSS. 

Criminals will continue, increasingly, to target this vector in 2025. The only real question is whether the success rate will grow (through new opportunities), level off (through a form of equilibrium between attack and defense), or decrease through industry and regulatory efforts.

OSS developers are not required to produce SBOMs (see the SBOM section below). Federal agencies and some critical industries are required to demand them. Private industries are not required to demand them, although regulations (such as DORA) require open source testing (which would benefit from the provision of an open source SBOM).

In short, OSS SBOMs are urged and helpful, but not guaranteed. This all contributes to a lack of governance and visibility into a massive source of code used in most applications produced and / or consumed by the majority of companies.

“OSS projects vary in levels of maintenance and updates. Many OSS libraries are funded by free or personal time of the maintainer(s), which can be a risk to the project as updates and changes are likely to be made less frequently,” comments Anthony Tam, manager of security engineering at Tigera. “Open Source Software will continue to be a risk to software supply chain security because software vendors will always require OSS libraries to build their products.”

It is, adds Jamie Scott, founding product manager at Endor Labs, “a nine-trillion-dollar public resource that has dramatically accelerated innovation. Making the choice to not use open source would be a choice to set yourself at a competitive disadvantage. [But] there is no shared responsibility model for open source. You use it, you own it.” Including the risks.

The open nature of OSS allows easy auditing by both good guys and bad guys – but the bad guys seem to put in more effort. “Malicious actors know how widely OSS is adopted and how opaque and vulnerable its ecosystem is,” adds Hughes. “This is due to poor governance by organizations using open source, as well as a lack of transparency for consumers purchasing products and services with little to no insight into what open source is powering those products.”

Chris Hughes, chief security advisor at Endor Labs

The very nature of the OSS ecosphere explains why it plays such a great part in supply chain attacks. The question here is whether this will continue through 2025, or whether we have already borne the brunt. The general feeling is that it will continue.

“OSS will always be a threat to the software supply chain,” says Scott.

“Attackers will continue to take advantage of this lack of governance and use a combination of social engineering such as in the case of XZ Utils and technical attacks to compromise widely used OSS components,” says Hughes.

It will worsen because “Foreign entities are increasingly exploiting the OSS ecosystem to introduce malicious code,” says Farimani. Think of the Polyfill incident.

“Major vulnerabilities like Log4j, Heartbleed, and Shellshock have always been unpredictable by nature. Another significant event is almost inevitable, though pinpointing a specific timeframe, such as 2025, is difficult,” says Michael Skelton, VP of operations and hacker success at Bugcrowd. “As long as we continue to rely heavily on OSS with deep-rooted dependencies, which seems impossible to avoid, similar large-scale vulnerabilities are likely to surface.”

Samani finishes, “While we can hope to avoid another crisis like Log4j, we must recognize the significant resources and advanced techniques that threat groups are dedicating to exploiting weaknesses within the software supply chain. These groups are more sophisticated than ever, and their focus on supply chain vulnerabilities will only intensify in the coming year.”

He suggests, “Organizations must prepare for a challenging threat landscape, as adversaries increasingly capitalize on vulnerabilities in widely used open-source software embedded within interconnected supply chains.”

The big disruptor to cybersecurity in 2025 will be artificial intelligence. Frankly we don’t know how things will pan out, but we can be certain that OSS security will be affected.

“There are definitely aspects of AI threats to open source,” says Hughes. “Some examples include developers using co-pilots and gen-AI tools that may use insecure libraries and components when producing code and developers inherently trusting gen-AI developed code without proper code review.”

AI plus OSS registries help bad actors create malicious but attractive OSS code; and company developers and inherent trust can create a supply chain threat. Scott expands on the process: “Gen-AI platforms, such as ChatGPT, are being used more than ever for code generation,” says Scott. “The latest attack vector exploiting this trend is called an AI Package Hallucination attack.”

Jamie Scott, founding product manager at Endor Labs

The attack starts with a malicious actor prompting an LLM to ‘hallucinate’ a non-existent but plausible package name, which is registered. The attacker then uses the LLM to generate code and suggest dependencies, but also adds malicious code. The result is a highly plausible but subtly malicious package which is included within an OSS registry like npm or PyPI.

“Attackers can now publish malicious packages under these hallucinated names, leading unsuspecting company developers into using them, perhaps under recommendation from their own use of AI,” continues Scott. “Many gen-AI coding users execute gen-AI code to test it without verifying the legitimacy of the code created. ‘Trust but verify’ applies to software created by AI, and we need to train a new age of developers to verify the packages recommended to them by AI systems.”

Skelton adds, “Gen-AI introduces new threats to OSS, including the possibility of AI-driven code synthesis inserting subtle vulnerabilities. Additionally, AI models can expedite vulnerability detection in OSS code bases, potentially identifying exploitable patterns more rapidly than traditional methods.”

However, there are also large and growing collections of open source AI models that can be downloaded from platforms such as Hugging Face and others. “Open source AI has risks just as any open source software has risks: by being community driven and developed,” warns Tam. Compromising open source AI models, rather than using AI to introduce malicious OSS packages, is a new threat similar in concept but different in detail to the traditional OSS supply chain threat.

Two areas worth monitoring for future success in defending OSS and the supply chain in 2025 are SBOMs, and the new tea protocol.

SBOMs

The federal government started pushing for the use of software bills of materials (SBOMs) as part of Biden’s Executive Order on Improving the Nation’s Cybersecurity (EO14028, May 2021). 

There is no direct mandate for OSS to include an SBOM; however, federal agencies are effectively required to demand one before using OSS. The EO states, “Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.”

OSS developers wanting their software libraries to be used by the federal government need to provide SBOMs to do so. But nearly four years after the EO was published, opinions on the current and future value of the SBOM for the security of OSS and its supply chain still vary.

Anthony Tam, manager of security engineering at Tigera, is clear: they are working now and will be better in the future. “SBOMs are working for OSS because they provide software vendors and OSS users visibility into the libraries that are used, and vulnerabilities found in those libraries,” he says. “SBOMs will become more effective over time…”

Michael Lieberman, CTO and co-founder of Kusari, is also hopeful that SBOMs will be more beneficial in the future. “SBOMs are starting to work for open source software,” he says. “As generating SBOMs gets easier and more integrated into the tools folks are already using like the ‘npm sbom’ command we’ll see wider adoption in open source.” The ‘npm sbom’ command, introduced in npm version 9, automatically generates an SBOM with a list of all dependencies for Node.js projects.

Hughes is a bit more guarded. Are they working? “Well, sort of,” he suggests. “The real question is if we will see widespread adoption and use of SBOM’s by commercial product companies to be transparent with the OSS in their products, and the answer is likely no.”

This may partly be caused by ongoing concerns with the use of SBOMs. “There are challenges with SBOMs when it comes to the disparate formats, quality of SBOM’s produced among the variety of tools, and also when dealing with specific types of software, such as SaaS,” he adds.

The general feeling and hope is that the industry is slowly solving the OSS SBOM problem. “SBOMs are increasingly effective for OSS, thanks to native support for dependency graphing and SBOM export within platforms like GitHub,” says Skelton. “These tools streamline SBOM management, making it easier for teams to track dependencies and vulnerabilities, boosting SBOM adoption. As more organizations integrate SBOMs into their workflows, we can expect them to become even more effective.”

Steve Wilson, CPO at Exabeam

But – and there’s always a ‘but’ in cybersecurity – SBOMs cannot stand still. We now have an additional type of OSS: open source AI models. “In 2025, the adoption of SBOMs will expand beyond traditional software,” comments Steve Wilson, CPO at Exabeam, “with AI and ML applications driving demand for more advanced BOM frameworks. Concepts like ML-BOMs (as defined by CycloneDX) will need rapid evolution to address the intricacies of modern LLM applications.” These models rely on dynamic and often opaque supply chains, where each ML component, data set, and algorithm may introduce unique vulnerabilities. 

“For government and defense organizations,” he continues, “effectively managing this complexity will require an expanded ML-BOM standard that can account for continuous updates, complex dependencies, and provenance tracking across AI and ML systems. Achieving interoperability across ecosystems will remain critical, but automation, coupled with emerging regulatory standards, will play a pivotal role in maintaining compliance and security across increasingly complex AI supply chains.”

Hughes calls the concept an AI BOM, but it’s the same thing. “AI BOM’s are a bit unique given the complexity of AI, involving not just code but models, training data, pre-training and the entire AI supply chain, much of which isn’t transparent to consumers and customers using AI services and platforms that are commercially available. That said, AI BOMs will encounter similar challenges as SBOMs in terms of adoption, use, being required or not, formats, and completeness and quality.”

The tea protocol

The tea protocol is an attempt to enhance the sustainability (and security) of the OSS ecosphere. It uses blockchain technology and TEA tokens (an ERC-20 token) to support developers and reward vulnerability reporting – simultaneously improving both OSS quality through sustainable funding and OSS security by promoting secure development practices.

The tea website describes it as “a decentralized technology framework that aims to enhance the sustainability and integrity of the software supply chain. The tea mission is to enable open-source software contributors to capture the value that they create.”

tea is new, probably beginning conceptualization in 2021 and emerging in early March 2024 – and driven by Max Howell who developed the Homebrew open source package manager – but only really seeing the light of day in early 2024. 

Its lineage is solid, but its progress is yet to be confirmed. Ax Sharma, security researcher Sonatype, already has some concerns. “New protocols like the tea protocol with its blockchain rewards for developers, are already driving some users to abuse open source registries to test self-reward mechanisms,” he comments.

Ax Sharma, security researcher Sonatype

“The trend of flooding open source registries with crypto-stealers and bogus packages will likely intensify in 2025. This mass-publishing activity threatens to throttle registries and disrupt legitimate usage, creating potential DoS risks for developers worldwide.”

Open source software is a known, major, and fluid threat. The content is continuously changing, and expanding, and the value to industry is enormous. As long ago as the early 2000s, the European Union began officially recommending its internal use, 

But as the use of OSS has grown, so too have the threats from it. Without any central authority, there is no way to impose any formal oversight or governance. That doesn’t mean there have been no attempts, but their success is questionable. Efforts must continue to prevent OSS resulting in evermore frequent and evermore disruptive breaches in the future.

Where authorities cannot define and specify what must be done, the traditional route is to enforce sanctions against failure to deliver what they cannot define. “This all points to more regulation and compliance around software supply chain security in 2025, including further developments of EO14028 when it comes to mandatory SBOM implementation,” says Mistry. “We’ve already seen sectors like the Army require SBOMs with more branches expected to do so as well. With the rapid adoption of AI, I also anticipate more guardrails on AI security when it comes to securing the AI supply chain.”

The problem here is that nationwide regulations are problematic in the US because of the natural legal autonomy and the (sometimes) partisan nature of the individual states. The traditional route for overarching regulation (as opposed to sector-specific) has been to allow the EU to develop them (such as GDPR) and for individual US states to build from them (such as CCPA and CPRA). 

This process is likely to continue, with the EU’s NIS2, DORA and ECRA requiring security and transparency from commercial organizations (including the use of open source software), and the US encouraging OSS security through SBOMs, and CISA’s Secure by Design initiative.

Greater regulation may, however, have unintended consequences. “I can imagine a scenario where concern over the security of open-source causes reactive regulations around the world; the costs and liabilities of compliance puts pressure on sponsoring companies; and companies loosen their commitment to ‘pure’ open source and instead choose source-available and fair source licensing to bolster and de-risk their revenue streams for the products,” warns Jonathan Marsh, VP strategy at WSO2. 

“The result,” he continues, “will be the disappearance of some products with poor or unknown security standards but with a side effect of a reduced breadth of quality enterprise-grade open-source options remaining on the market.”

2025 will be characterized by continuing attempts to solve the OSS supply chain problem – but they won’t be solved this year. SBOMs are not reliable, and regulations may improve cybersecurity but do not prevent breaches. Frankly, we need to prepare ourselves for a continuing and, for the foreseeable future at least, a continuously bumpy ride.