How Third-Party and Open Source Components Build Hidden Risk Into Software

Whenever there’s a major data breach announced in the news, I think about how there must be other breaches happening that we don’t even know about. Because, although cyberattackers frequently target known vulnerabilities in software, the victims are unlikely to know they were vulnerable until it is too late. As today’s software is increasingly assembled from bits and pieces of open source and third-party code, vulnerabilities lurking in these components have become an enormous blind spot and pose a growing threat to all kinds of software and systems — from e-commerce sites to embedded systems in critical infrastructure.

Earlier this year we saw a perfect case study of the hidden risk of components: a critical vulnerability in Apache Struts 2, a Java library that’s widely used in enterprise web applications. Veracode warned about the potential risk of this highly exploitable vulnerability when it was first reported in March 2017. But we also recognized that many organizations would have trouble patching their vulnerable applications because it can be very difficult to know exactly which applications are using the vulnerable component.

Components are an essential part of software development, allowing developers to move quickly and spend more time on innovation, rather than reinventing the wheel for a piece of existing functionality. But the cost of greater speed is increased risk. Because components like Struts 2 are popular with developers, they are also an attractive target for cybercriminals.

There are many other examples in recent years of vulnerable open source and third-party components causing widespread risk, including some that were exploited by opportunistic cybercriminals. The Heartbleed bug is perhaps the best known. It was present in a version of OpenSSL that was used by an estimated 20 percent of websites and many other software products.

More recently, a deserialization vulnerability in the Apache Commons Collections (ACC) open source library that affected up to 25 percent of Java applications, and was linked to a ransomware attack on the San Francisco Municipal Transportation Agency. As Veracode’s Tim Jarrett explained in a blog post about the San Francisco ransomware attack, components provide functional code for “free.” But developers frequently don’t have a complete bill of materials of all the components they are using, and consequently developers rarely apply security updates when they become available.

It can be difficult and costly for companies with multiple code repositories to pinpoint all the applications where a risky component is used. And just one vulnerable component can spread exponentially. When Veracode analyzed another vulnerability in ACC, we discovered that a critical vulnerability in one component had spread to more than 80,000 other software components, which were in turn then used in the development of potentially millions of software programs. (You can see how this vulnerable component spread through offshoots into other components, like branches of a tree, in the video below).

How to Reduce Risk of Vulnerable Components

In the end, enterprises can’t stop using open source components, or rely on the open source community to keep components vulnerability-free. But unless your company has visibility into the components used by developers, you will be unable to remediate or mitigate the risk of newly discovered vulnerabilities.

Veracode recommends five ways you can reduce risk from open source and third-party components.

1. Set a policy. Security and compliance teams should set a corporate security policy that explicitly lays out which component vulnerabilities require action, and in what timeframe.

2. Keep an up-to-date inventory. There are several ways to build an inventory, including looking at source control or component repositories. But one of the most reliable methods may be leveraging security testing you are already doing. Some static analysis providers, like Veracode, may already be creating an inventory of components for you through software composition analysis.

3. Educate developers. Some developers may be unaware that they need to monitor the components they use for security patches, or that the components they use may rely on other components that may not be secure. Learn more about developer education.

4. Integrate security testing into the SDLC. As development teams make more changes to their applications, it’s important to keep the inventory of components, and the security picture, up to date. View the Veracode Integrations datasheet.

5. Shift the mindset. Open source isn’t free like the air you breathe. The functionality it delivers can be an asset to a development team, but keep in mind that the asset is offset by technical debt that requires regular payments, in the form of applying regularly released updates to the open source library.

For a more information on how to manage your component risk, download the whitepaper Components: Increasing Speed and Risk.

[nid-embed:26706]