2023 OSSRA: A deep dive into open source trends

by Fred Bals on April 13, 2021

Open source is everywhere, as is the need to properly manage it. Get the latest open source trends from the 2022 OSSRA report.

It’s the time of the year when Spring is springing, and we release the annual Synopsys Open Source Security and Risk (OSSRA) report, with the 7th edition of OSSRA out this week. This year’s report, produced by the Synopsys Cybersecurity Research Center (CyRC), examines the results of more than 2,400 audits of commercial codebases performed by the Black Duck® Audit Services team primarily for merger and acquisition (M&A) transactions. The OSSRA report highlights trends in open source usage and provides insights to help developers better understand the interconnected software ecosystem that they are part of. OSSRA also details the pervasive risks posed by unmanaged open source, including security vulnerabilities, outdated or abandoned components, and license compliance issues.

Download the 2022 OSSRA report

Open source trends uncovered in OSSRA 2022

The 2022 OSSRA report’s findings underscore the fact that open source is used everywhere, in every industry, and is the foundation of every application built today.

Sponsorships Available

Open source audits have increased

2,409 codebases in total were audited by Synopsys in 2021, of which 97% contained open source. The increase in the number of Black Duck Audits—64% above 2020—reflects the corresponding increase in M&A throughout 2021.

Acquirers in M&A deals want to understand what risk may be associated with the software they’re acquiring—specifically, risk around licensing, security, and the quality of the open source used in that software. The OSSRA audit numbers indicate that sellers have also become more sensitive to potential issues with their software that might undermine a deal, driving them toward mitigating possible issues before the M&A is underway.

All industries studied contained a high percentage of open source

Four of the 17 industry sectors represented in the 2022 OSSRA report—Computer Hardware and Semiconductors, Cybersecurity, Energy and Clean Tech, and Internet of Things—contained open source in 100% of their audited codebases. The remaining verticals had open source in 93% to 99% of their codebases.

Open source really is everywhere. A January 2022 White House briefing statement described software as “ubiquitous across every sector of our economy and foundational to the products and services Americans use every day. Most major software packages include open source software… [which] brings unique value but has unique challenges.”

Substantial decrease in codebases containing licensing conflicts

Over half—53%—of the codebases contained license conflicts, a substantial decrease from the 65% seen in 2020. In general, specific license conflicts decreased across the board between 2020 and 2021.

One increase we did see in the audits concerned the Creative Commons Share Alike 3.0 (CC-SA 3) license. CC-SA 3 license conflicts illustrate an overlooked issue when it comes to open source licenses. Developers often introduce code snippets, functions, methods, and operational pieces of code into their software, generally termed dependencies, as the software is dependent on that code. However, the dependencies themselves may utilize sub-dependencies containing license terms and conditions that the developer or end user is not aware are there. For example, some versions of the popular node.js component include a dependency that leverages code licensed under the CC-SA 3 license that might place undesirable requirements on the licensee and require legal evaluation for possible IP issues.

Patch management is still a challenge

2,097 of the codebases included security and operational risk assessments, with 81% of those codebases containing at least one vulnerability, a minimal decrease of 3% from the findings of the 2021 OSSRA. There was a more dramatic decrease in the number of codebases containing at least one high-risk open source vulnerability. Forty-nine percent of the audited codebases contained at least one high-risk vulnerability, down 11% from last year.
From an operational risk/maintenance perspective, 85% of the 2,097 codebases contained open source that was more than four years out of date. Eighty-eight percent utilized components that were not the latest available version.

While the decreases in license conflicts and high-risk vulnerabilities are encouraging, the fact remains that more than half of the codebases audited contained license conflicts and nearly half contained high-risk vulnerabilities. Even more troubling was that of the 2,097 codebases we examined that included risk assessments, 88% contained outdated versions of open source components. That is, an update or patch was available but not applied.

There are justifiable reasons for not keeping software up to date, but it’s likely that a large percentage of the 88% is due to DevSecOps teams not being aware that a newer version of an open source component is available. Unless an organization keeps an accurate and up-to-date inventory of the open source used in their code, the component can be forgotten until it becomes vulnerable to a high-risk exploit, and then the scramble to identify where it’s being used and to update is on.

And that’s precisely what occurred with Log4j, but somewhat lost in the uproar around the Log4j vuln(s)was the fact that the panic was often a result of organizations not knowing where Log4j was located within specific systems and applications, or in fact, if it was there at all. The problem was then multiplied across thousands of IT groups, which scrambled to answer questions like, “Are we vulnerable to Log4Shell? Is our vendors’ software vulnerable? Are the customers using our software vulnerable?”

Steps toward smarter open source management

In the world of 2022, where 97% of commercial code contains open source, a software Bill of Materials (SBOM) of the open source components used in an application needs to be considered mandatory for any effective DevSecOps or AppSec effort.