Open-Source Risk Continues to Challenge Organizations’ Software Security

The pressure on software development teams to produce more software, and faster, is greater than ever before. This demand has necessitated heavy adoption of open-source libraries and components, as they empower developers to reach production deadlines by adding functionality to their code without starting wholly from scratch.

Download the State of Software Security Volume 9 Software Composition Analysis Infosheet here

However, despite some high-profile breaches leading to an increased awareness around open-source risk, the data in SOSS Vol. 9 does not suggest these libraries and components — or the way they’re used — are becoming any more secure. Last year, Veracode’s scan data showed that roughly 88 percent of Java applications contained a component with at least one vulnerability, and this year, that figure dipped down only marginally to 87.5 percent in this year’s report.

Organizations May Not Be Aware They’re Vulnerable

Vulnerabilities in open-source components are highly likely to be exploited, and issues arise because attackers know that a single vulnerability can be found in a wide range of applications. There is a false sense of security across the industry when it comes to open-source libraries, because while there are “more eyes on the code,” no one is responsible for making sure that security fixes are disclosed or informing your development and security team that a vulnerability was patched. It’s up to the company using the open source library to ensure it’s safe, up-to-date on any known vulnerabilities in the library, and the known fixes available.

Open Source Risk Is Multi-Faceted and Complex

Simply having a library with vulnerabilities in it does not inherently mean you’re at risk — the vulnerability only compromises the larger application if it uses the part of the library with that vulnerability and has data and control flowing through that part of the code. By understanding the status of the component and if a vulnerable method is being called, organizations can prioritize fixes based on the riskiest use of components and maintain their speed-to-market. Without implementing a tool like Software Composition Analysis, maintaining an inventory of what components are in use, where they’re in use, and if they’re configured in such a way that’s easily exploitable is a major challenge.

As you’re looking to address these challenges, either by starting an application security program or maturing an existing program, consider your organization’s needs from an end-to-end perspective. Ensuring coverage for the entire software development lifecycle is the only way to implement effective security across your applications.