Over the past few years companies have been increasing their use of open source code to help them build more powerful applications faster.
Open source components cut down application development time by providing powerful features that developers do not have to write on their own, speeding up deployment of new releases. Forming the backbone of today’s software, open source components now comprise between 60-80% of modern applications.
Open Source Libraries and Tools – a Liability to Security
Development teams can easily take advantage of the different open source libraries and tools, which are updated and provided by the open source community, taking them from popular resources like GitHub.
Along with the clear advantages for developers, using open source components is not without risk. Keeping your software products secure can be a challenge and require the right tools to address the threats. In the case of open source components, as opposed to proprietary code that is written in-house by a company, the primary risk to products using open source software are known vulnerabilities. These are vulnerabilities that have been published online and are available for anyone to view and possibly use to exploit victims. The issue of using components with known vulnerabilities is probably already on your radar, having held a spot on OWASP’s infamous Top 10 since 2013.
As third-party software, open-source components can be used in thousands of products, and a vulnerability found in a single component can have an impact on a wide range of applications. Because open source components are maintained by the open-source community, we depend on them to alert us to new vulnerabilities when these security researchers find them.
In seeking to keep others secure, these researchers will post their findings on which open source components are vulnerable and how to perform the exploits to security advisories and databases like the U.S. government-backed National Vulnerability Database (NVD). While this can be useful for vigilant security teams who can use this information to quickly patch their applications, hackers are also watching here for free intelligence on what to target and how.
The challenge here is in staying a step ahead of the attackers. Unfortunately, the vast majority of development teams are simply unaware of how much their products rely on open source components, and do not keep a proper inventory of which ones they have in their products. This can be a significant issue since they can be targeted through a vulnerable component that they did not even know that they were using.
This is what happened in the Equifax case last September when the company was breached through a vulnerable version of Apache Struts 2 (CVE-2017-5638), leading to the theft of 145.9 million personally identifiable information records, including social security and credit card numbers. According to reports, the attack occurred two months after the vulnerability was disclosed, embarrassing the company for failing to take the necessary steps to keep their data secure.
Automation Is Critical for Securing Open Source Components
Due in part to the fast pace of development, and heavy reliance on open source components to stay on schedule, manual tracking of open source components is simply not an option for organizations that want to stay secure.
Scalability is key, and only automated solutions offer an answer for how to stay on top of every open source component that enters the development environment. Only Software Composition Analysis (SCA) tools are capable of identifying open source components and alerting security teams to risks.
In order to properly implement an open-source security process, especially in a DevOps model, security and development teams need to work together to catch issues early, adopting a shift left approach. When they integrate an SCA tool into their CI/CD server, the tools can identify vulnerable components before they make it into the build, preventing more expensive operations later when developers would have to tear and replace the vulnerable component before a release.
At the same time, it is essential to shift right with alerts when new vulnerabilities are discovered, giving security teams the warning they need to quickly patch their products before the hackers attempt to make their breach.
By implementing a continuous, automated SCA tool, organizations can enforce policies across their development and products, significantly mitigating the risks to known vulnerabilities in their open source component usage.
About the Author: Zev Brodsky
By day, Zev is the Community Manager at open source security management leader WhiteSource. By night, he is a taco enthusiast, so-so checkers player, and collector of rare stamps.
