Editor’s brief: Software integrity and security is paramount these days, with software supply chain taking centerstage amidst global instability today. The leading vendor in software integrity and security, Synopsys, has released the 2022 Open Source Security and Risk Analysis (OSSRA) report. While an analysis of more than 2,400 commercial and proprietary codebases showed decreases in open source license and vulnerabiltiy risks, the report cautioned that 88% of organizations still lag behind in keeping open source updated. The report revealed 20% of assessed codebases contained open source with no license or with a customized license. Read more below.
SINGAPORE – Synopsys, Inc. (Nasdaq: SNPS) today released the 2022 Open Source Security and Risk Analysis (OSSRA) report. The report, produced by the Synopsys Cybersecurity Research Center (CyRC), examines the results of more than 2,400 audits of commercial and proprietary codebases from merger and acquisition transactions, performed by the Black Duck® Audit Services team. The report highlights trends in open source usage within commercial and proprietary applications and provides insights to help developers better understand the interconnected software ecosystem. It 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 findings underscore the fact that open source is used everywhere, in every industry, and is the foundation of every application built today.
- Outdated open source remains the norm—including presence of vulnerable Log4j versions. From an operational risk/maintenance perspective, 85% of the 2,097 codebases contained open source that was more than four years out-of-date. 88% utilized components that were not the latest available version. 5% contained a vulnerable version of Log4j.
- Assessed codebases show open source vulnerabilities are decreasing overall. 2,097 of the assessed codebases included security and operational risk assessments. There was a more dramatic decrease in the number of codebases containing high-risk open source vulnerabilities. 49% of this year’s audited codebases contained at least one high-risk vulnerability, compared to 60% last year. Additionally, 81% of the assessed codebases contained at least one known open source vulnerability, a minimal decrease of 3% from the findings of the 2021 OSSRA.
- License conflicts are also decreasing overall. 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.
- 20% of assessed codebases contained open source with no license or with a customized license. Since a software license governs the right to use it, software with no license presents the dilemma of whether use of the open source component entails legal risk. Additionally, customized open source licenses might place undesirable requirements on the licensee and will often require legal evaluation for possible IP issues or other implications.
“Users of SCA software have focused their attention on reducing open source license issues and addressing high-risk vulnerabilities, and that effort is reflected in the decreases we saw this year in license conflicts and high-risk vulnerabilities, said Tim Mackey, principal security strategist with the Synopsys Cybersecurity Research Center. “The fact remains that over half of the codebases we audited still contained license conflicts and nearly half still contained high-risk vulnerabilities. Even more troubling was that 88% of the codebases [with risk assessments] contained outdated versions of open source components with an available update or patch that was not applied.”
“There are justifiable reasons for not keeping software completely up-to-date,” Mackey continued. “But, unless an organization keeps an accurate and up-to-date inventory of the open source used in their code, an outdated 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 it is on. This is precisely what occurred with Log4j, and why software supply chains and Software Bill of Materials (SBOM) are such hot topics.”