5 key takeaways from the 2020 Open Source Security and Risk Analysis report

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:

Sponsorships Available

Sponsorships Available

Sponsorships Available

• 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.

It’s clearly unwise to rely solely on the NVD for vulnerability information. It’s better to look to a secondary source, such as Black Duck Security Advisories, that provides earlier notification of vulnerabilities affecting your codebase and, ideally, delivers security insight, technical details, and upgrade and patch guidance.

Takeaway #3: Having no license can be as problematic as a license conflict

Declared license conflicts arise when a codebase contains open source components whose licenses appear to conflict with the overall license of the codebase. For example, code under the GNU General Public License v2.0 (GPLv2) will generally pose a conflict issue when compiled into a normally distributed piece of commercial software. But the same code is not a problem in software that is considered software-as-a-service, or SaaS.

In the U.S. and many other jurisdictions, creative work is under exclusive copyright by default—including software code. Unless a license specifies otherwise (or the creators grant permission), no one else can legally use, copy, distribute, or modify that work without incurring the risk of litigation. Organizations that use unlicensed code are at greater risk of violating copyright law than those using licensed components.

Takeaway #4: Legacy open source can cause issues

One of the reasons behind the popularity of open source is that viable open source projects usually have strong communities improving, updating, and patching vulnerability issues as they become known. But many developers don’t bother to vet the health of a community before downloading an open source component. And even if a developer takes care to initially download components from robust open source communities, there’s no guarantee the community will remain active in maintaining that component or the specific version downloaded.

All software ages. As it ages, it loses support. With open source, the number of developers working to ensure updates—including feature improvements, as well as security and stability updates—decreases over time. And at some point, as that open source component ages, it’s likely to break—or open a codebase to exploit. Without policies in place to address the risks that legacy open source can create, organizations open themselves up to the possibility of issues in their software.

Takeaway #5: Inventory your open source now

You can’t possibly address any issues without an up-to-date, accurate software inventory—a.k.a. a software BOM—that includes all open source components, the versions in use, and download locations for each project in use or in development. The BOM should also include all dependencies, or the libraries your code is calling to, as well the libraries those dependencies are linked to.

The concept of a BOM derives from manufacturing, where the classic bill of materials is an inventory detailing all the items included in a product. In automobile manufacturing, when a defective part is discovered, the manufacturer knows precisely which vehicles are affected and can begin the process of repair or replacement. Similarly, maintaining an accurate, up-to-date software BOM that includes an inventory of third-party and open source components is necessary for organizations to ensure their code is high quality, compliant, and secure. And as in manufacturing, a BOM of open source components allows you to pinpoint vulnerable components quickly and prioritize remediation efforts appropriately.

This first step of creating a BOM is often the most daunting for many organizations, who worry that manually creating and maintaining such an inventory will have an impact on developer productivity and development costs. If that’s of concern to your organization, consider the advice of analyst Dale Gardner in the 2019 Gartner paper Technology Insight for Software Composition Analysis: “A BOM generated by an SCA tool provides more comprehensive information (specific versions, license, etc.), and potentially a more advanced understanding of dependency mapping among various components and frameworks.”