Our analysis of 1,250+ codebases reveals trends in open source use, security, and license compliance that affect development, security, and legal teams.

On May 12, Synopsys released the fifth edition of our Open Source Security and Risk Analysis (OSSRA) report, which provides an in-depth snapshot of the current state of open source security, compliance, and code quality risk in commercial software.

Developed by the Synopsys Cybersecurity Research Center (CyRC), the 2020 OSSRA report examines findings from the anonymized data of commercial codebases reviewed by our open source audit services teams during 2019. For the OSSRA, we define a “codebase” as the source code and libraries that underlie an application, service, or library.

The 2020 OSSRA report contains detailed sections on:

–  The need for a software bill of materials (BOM)
– Open source composition of codebases audited in 2019
– The open source components we found in use
– The threat of unpatched open source vulnerabilities
– Vulnerabilities found in our audits
– Recommendations on setting vulnerability patching priorities
– Licensing legal developments in 2019
– Examining license risk in open source components
– Operational factors in open source use

If your organization develops or uses software, the software’s codebase will almost certainly include numerous open source components. As with all software, those components can cause security, licensing, and code quality issues if you’re not managing them properly. By “managing,” we mean that you’re tracking the source, age, licensing, and version information of any components in your software, as well as applying updates and security patches to those components as needed.

Takeaway #1: We need to better manage the open source we use

The first takeaway from this year’s OSSRA is that organizations need to do a much better job in maintaining what has become a crucial part of the software that they build or use—that is, open source. Virtually every one of the 1,250+ codebases we audited contained open source. In fact, 70% of the code in those codebases was open source

But 75% of those codebases also contained open source security vulnerabilities. Nearly half contained high-risk vulnerabilities. And 73% expose the codebase owners to possible legal problems because of components whose licenses appear to conflict with the overall license of the codebase or that have no license at all.

What’s more, an exceptionally high number of the codebases—91%—contained open source components that were more than four years out of date or had had no development activity in the last two years, with all the attendant security and maintenance issues of legacy software.

Takeaway #2: Look for a supplemental source to NVD data

Public sources, such as the National Vulnerability Database (NVD), are a good first step for getting information on publicly disclosed vulnerabilities in open source software. However, there can be significant lags in NVD data reporting, scoring, and actionability of the data in a CVE entry.

Timeliness has always been a factor impacting the NVD’s ability to publicize security vulnerabilities. Time lags present a huge window of opportunity for malicious actors to take advantage of vulnerabilities. For example, four of the top 10 vulnerabilities found in codebases audited for the 2020 OSSRA did not have CVEs associated with them at the time of the report’s publication.