When the first Open Source Security and Risk Analysis (OSSRA) report was published in 2015, the software landscape looked very different. Security teams were just beginning to grasp the implications of open source vulnerabilities, spurred by high-profile ones like the Heartbleed bug in OpenSSL which hit the front pages in 2014.

Developers, meanwhile, were continuing to use more and more open source to accelerate innovation, often without formal processes or visibility in place while their employers were just catching on and trying to get their arms around the issue.

A decade later, and really since the beginning, the OSSRA report has become a widely referenced benchmark for understanding how open source is used, where risks emerge, and how the industry is evolving. The 2025 edition marks its 10th anniversary with a deep dive into thousands of codebases across industries, highlighting trends reflecting progress and persistent challenges.

Open source: from niche to norm

One of the most dramatic shifts revealed by a decade of data is just how central open source has become to modern software development. As of 2015, the portion of open source code in the average audited application had grown to 35 percent. That number has since doubled to 70%. While the percentage has plateaued in recent years, the volume of open source components used has surged along with application complexity.

Ten years ago, a typical application might contain around 100 open source components. This year’s figure has climbed to 981 per codebase on average, an almost tenfold increase. This reflects in part the rise of package managers like NPM and PyPI, which make it easier to import third-party code, a fundamental change in how software is assembled.

The average application now includes hundreds of dependencies, direct and indirect (where one open source component utilizes another) each with its own potential for vulnerabilities, outdated versions, or licensing complications. This increased complexity has made open source management a central issue for development and security teams alike.

License compliance: some progress, some gaps

Early OSSRA reports showed a greater prevalence of license compliance issues, as few organizations were set up to effectively manage the legal obligations associated with open source use. In 2015, three-quarters of audited codebases included license conflicts, situations where software was used in ways that violated open source license terms.

That figure has improved, now standing at 56%, indicating more corporate awareness and policies and better oversight and tooling. The shift to cloud and SaaS delivery models has also played a role, sidestepping some distribution-triggered license requirements. SaaS applications are not immune from license conflicts but the risk is less. Yet compliance remains a challenge, particularly for organizations without robust governance processes.

Notably, the 2025 report finds that 30% of applications include code with no clear license or any explicit permission for use. Copyright law says that using software in any way requires the permissions afforded by a license and most lawyers caution against using unlicensed code.

Misuse of third-party code can lead to significant legal exposure, and often becomes a discussion point during M&A due diligence as acquirers assess their target’s code vis a vis their own corporate policies and standards.

Vulnerabilities: volume Is outpacing control

While license issues remain a concern, security continues to dominate headlines, and OSSRA data shows how open source contributes to the risk. In 2015, 67% of applications contained at least one known open source vulnerability. A decade later, that number has ramped to 86%. Even more striking is the average number of vulnerabilities per application, which has increased from 22 to 154. Part of this can be explained by the ballooning size of codebases, but the report demonstrates that organizations still struggle to manage known risks effectively.

One key challenge for companies incorporating open source into the code estate is to keep up with the latest version as patches. The 2025 OSSRA shows that 90% of codebases contain components that are more than four years out of date. This lag gives attackers a wide window of opportunity, as many of these components are known to be exploitable and patches, in most cases, already exist. In the well-publicized Equifax breach, they were only a few months behind, applying a security patch to Apache Struts, but that was enough for a hacker to purloin the personal information of over 100 million people.

There has been some progress. A decade ago, the average vulnerability found in code was five years old. That number has dropped to 2.8 years, indicating faster response times and better awareness. However, that’s still a lifetime with respect to application security and given the scale and complexity of today’s software, the overall risk surface has grown.

Data-driven decisions

OSSRA’s impact lies in making these patterns visible. Before its first publication, discussions around open source use were largely theoretical and anecdotal. The report continues to raise eyebrows over how much open source is being used. It has helped shift the conversation from “What problems could using open source cause?” to “Wow, how do we effectively manage this?”

That shift has only grown more urgent with the rising focus on software supply chains and increased regulatory scrutiny. Open source is no longer a few obscure pieces of an application; it is the very foundation. And while tools and awareness have improved, many organizations are still playing catch-up when it comes to continuous monitoring, patching, and licensing oversight.

Looking ahead: AI, automation, and a more complex landscape

As the software ecosystem and development processes evolve, the next decade of OSSRA reports will likely track a new set of challenges. Use of package managers will continue to allow development teams to build ever larger, more complex systems. The increasing use of generative AI in software development too will escalate and introduce new forms of open source integration. Developers are already incorporating code suggestions from AI assistants, many of which are trained on public codebases, mostly open source and which raise questions of copyright and licensing.

At the same time, open source large language models are being embedded into applications, raising fresh questions about attribution, governance, and security.

Meanwhile, AI-powered tools may offer hope, helping developers and security teams to manage software development in general and specifically identify and remediate vulnerabilities faster.

The common thread? Complexity. Whether it’s AI-generated code, containerized environments, or sprawling dependency trees, managing open source effectively demands deliberate attention. As part of software due diligence in an M&A transaction, a one-time audit by a trusted third party fits the bill. For an organization to comprehensively manage open sources risks in its own software, demands ongoing diligence, transparency, and a recognition that open source, while free to use, comes with real responsibilities.

Ten years of OSSRA data paints a clear picture: open source is indispensable but far from risk-free. Security and legal risks remain widespread and thus requires managing those issues to be a core part of modern software development. As the ecosystem grows in size and complexity, the OSSRA and reports like it are more essential than ever in helping organizations benchmark their practices and plan and evolve their defenses.

We’ve featured the best online cybersecurity course.

This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro