The recently released 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC), found that of more than 1,250 codebases analyzed in 2019, not only did virtually 100% have some open-source components, but also that an average of 70% of the code was open source, nearly double the 36% found by the first OSSRA report. Another measure of the dramatic increase in open source use is that the OSSRA found an average of 445 open-source components per codebase in 2019, up nearly 50% from 298 just a year earlier.

What open-source software provides to developers is a foundation that makes application development faster, more efficient and cheaper. It’s why the majority of software products today are “assembled” from existing components rather than written from scratch.

If your organization builds or simply uses software, you can assume that software will contain open source. If you’re a member of a security team, and don’t have policies in place for identifying and patching known issues with the open-source components your organization builds or uses, you’re not doing your job.

RELATED CONTENT: Organizations are taking too long to apply open-source security patches

Open source comes with the same security risks that plague all software — bugs or other defects that could be exploited by hackers. While larger open-source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors — thanks to thousands of “eyes” on the code — keeping open source current and secure is not as simple as auto-updates, as is done for much commercial software. Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open-source component first need to be aware that the patch is out there and then need to “pull” it from a repository in order to accomplish the needed update.

But an alarming number of companies consuming open source aren’t applying patches, opening themselves to the risk of attack and their applications to potential exploits. In fact, many organizations are startlingly behind in using the latest version of any given open-source component. 

As the OSSRA report details, 82% of the open-source components found in the audits were out of date and 75% contained at least one known vulnerability. The most common high-risk vulnerability, CVE-2018-16487, a high-risk Lodash prototype pollution vulnerability affecting versions prior to 4.17.11, appeared over 500 times in the OSSRA scans. Yet another high-risk Lodash prototype pollution vulnerability frequently found in the 2019 scans (495 instances) was CVE-2019-10744, affecting all versions prior to 4.17.12. The dangers of both vulnerabilities range from property injection to code injection and denial of service. Given that Lodash was the fourth most commonly found open-source component—used in a third of the 1,250+ codebases scanned for the OSSRA report—those vulnerabilities should be of concern. In both cases, an upgrade to a later version of Lodash addresses the security issues. 

Many outdated open-source components are the result of an “insert and forget” mindset. Developers typically don’t add version information about a component to the inventory spreadsheet before moving on to other work. Then, as long as the code continues to function as it’s supposed to, it’s ignored and eventually forgotten—until it breaks or is exploited.

Without policies in place to address the risks that outdated versions of open-source components can create, organizations open themselves up to the possibility of issues in their software. Security and development teams need to work together to create and maintain an up-to-date, accurate software inventory—a.k.a. a software BOM or “bill of materials.” A comprehensive BOM will include all open source and third-party components, versions in use, and download locations for each project. The BOM should also include all dependencies, or the libraries the code is calling to, as well the libraries those dependencies are linked to. Armed with the BOM, you can now identify and manage the risks of the open source you’re using—whether those risks entail license compliance, operational factors, or security issues.