Open source components are the building blocks of the application economy. According to recent research, open source components make up 60 to 80 percent of the code base in modern applications.
Developers depend on components that are written and maintained by the open source community to work faster and more efficiently, and to keep up with rapid demand for new versions and updates.
What’s Driving the Rise of Open Source?
According to a WhiteSource survey titled “The State of Open Source Vulnerabilities Management,” 96.8 percent of developers reported that they use open source components “all the time,” “very often” or “sometimes.” Only 3.2 percent of developers reported that they did not use open source at all, likely due to policies that do not allow them to do so in their organizations. Interestingly enough, developers who use open source components rely on them significantly, which can explain why none of the respondents described their usage as “rarely.”
However, despite the technology industry’s dependence on these components, there is an unfortunate lack of understanding regarding how to properly manage risk when utilizing them. To get a real handle on how to uphold best practices when it comes to using open source components securely, organizations must first realize how much of this code they are using.
Why It’s Important to Track Your Open Source Components
Open source components face risks from threat actors who can exploit vulnerabilities in popular open source projects to potentially target thousands of organizations, many of which are unaware they are even using these vulnerable components in their products.
Tracking inventories and managing security — especially if there is no practice in place for directing how open source components should be handled — is no small feat. Companies looking to harness the power of open source components in their products have a responsibility to use them securely.
In far too many organizations, developers don’t effectively track which open source components they are using in their code. In other cases, they are expected to make manual records in spreadsheets or notify colleagues via email about the components they use. Neither option is truly viable at scale, nor do they satisfy the security need to identify components with known vulnerabilities.
What Are the Potential Risks of Using Open Source Components?
As opposed to proprietary code that is written in-house — where the main concern is that an attacker might uncover a previously unknown vulnerability — open source faces different risks.
When a vulnerability is discovered by a security researcher in the open source community, it is reported to one of the many databases and security advisory organizations, such as the National Vulnerability Database (NVD). Vulnerability disclosures help inform organizations that they could be using flawed components.
Potential attackers monitor these databases and use them to target organizations that are deploying vulnerable components, hoping to prey on victims that are too slow to remediate the flaws right away. Therefore, the challenge for organizations is to stay on top of which open source components they are using and know which ones are vulnerable to exploitation. To put it simply, you can’t patch what you don’t know.
Another challenge is that it’s virtually impossible to manage a continuous inventory of open source components used in your products and match them to newly discovered vulnerabilities through manual tracking. It is certainly not scalable for any organization that has teams of developers, which is commonplace today.
It’s also extremely difficult to collect all the open source vulnerability information that originates from the NVD and other resources. We’ll review this topic in a future post.
Take Control of Open Source Application Security Testing
Getting a handle on the vulnerability status of your open source components is the first step toward improving the security of your applications. When managed correctly, open source code is a valuable asset in the hands of developers.
However, with great power comes great responsibility. For leadership, this means making sure your team has the tools it needs to effortlessly maintain a proper inventory of open source components — and using this information to create actionable steps to keep your products secure.