Is ‘secure open source component use’ an oxymoron?

Asking developers to stop using components would be like asking writers to stop using word processing and go back to typewriters.

Components are a technological advance that enables productivity and innovation, and have simply become a standard tool of the trade.

But with these benefits comes some risk. They can, and often do, contain vulnerabilities. And the nature of their use – the functionality in one component is used again in multiple other components – means they spread risk like wildfire.

In our 2016 State of Software Security report, which is based on customer data collected on our platform, we followed the path of one vulnerable component, Apache Commons Collection 3.2.1, to get a sense for just how far and wide this one code snippet would spread its vulnerability.

As this component’s functionality was used again and again in other components, frameworks, libraries and projects, we tracked its vulnerability out to a whopping 80,323 additional components, and that was only where we stopped counting. One piece of vulnerable code, tens of thousands of risky components.

We have to stop assuming components are safe or simply not thinking about security when we use them. What does that even look like?

It starts with education and awareness. Make sure your developers understand the risks in open source and third-party components. Some developers may be unaware that they need to monitor the open source components they use for new security patches, or that the components they use may rely on other components that may not be secure.

Back up the awareness with policy. Create a security policy and allow developers to draw upon known, validated and approved software components while at the same time preventing them from including potentially malicious components from the wider Internet.

For further policy governance, there are also various commercial products that provide local, cached versions of popular open source repositories, allowing the security team to closely control which components (and hence which vulnerabilities) are being included in the final product. Additionally, the judicious use of local repositories ensures that only a single approved version of a component is used, rather than a myriad of different (and potentially vulnerable) versions.

Awareness and policies are a start, but the real key to securely using open source and third-party components is visibility. You can’t secure (or patch) what you don’t know about. Security teams need to know what components their developers are using, and where they are using them.

Software composition analysis technologies enable you to keep a dynamic inventory of which versions of which components are in use, and their locations. With this information in your back pocket, you’re prepared. When a big vulnerability hits the news, you’ll know what you need to patch and where it is. You can also manually blacklist certain components, leading to an automatic policy audit fail for any application that uses it.

The bottom line is that components are a critical part of modern software development. With the pace developers are now required to churn out code, asking them to re-invent the wheel for every piece of functionality would be unfeasible and unrealistic. But they’ve also become cyberattackers’ target of choice. And although collecting personal data seems to be the goal thus far, the stakes could get higher quickly. Is it critical infrastructure next? Its time to make peace with component use, and risk, and start creating solid, effective plans for ensuring that they are used in a smart, secure way.