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.
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.
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.
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.”
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.
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?”
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.
Fred is a senior technical writer at Synopsys. He is a Mini Cooper fanboy and has worked for both Google and Bob Dylan at various points in his career.