Synopsys report reveals state of open-source vulnerability

Open-source software is the cornerstone of modern applications and a crucial part of our everyday lives. Without effective management and tracking while using this technology, software security can be significantly compromised. To protect them from malicious threats, effective identification and control measures must be taken as these forms an integral piece in any successful security program.

The 2023 “Open Source Security and Risk Analysis” (OSSRA) report, based on the data provided by the Synopsys Cybersecurity Research Center (CyRC), offers an in-depth look at the current state of open source security, compliance, licensing, and code quality risks in commercial software. Security, legal, risk and development teams can benefit from insights into the open-source security and license risks they face. The below findings will assist them in making informed decisions on related issues within their organization.

84% of open-source codebases contain at least one vulnerability

Of the open-source codebases evaluated, 84% contained at least one known vulnerability – an increase of 4% from last year. 48% of the codebases had high-risk vulnerabilities. In order to adequately address these security issues on such a large scale it is necessary to use automated solutions for monitoring and maintenance activities.

Every year, the percentage of codebases containing open-source increases. This year, even the industries with the least amount of open-source use like manufacturing, industrials, and robotics had open-source in 92% of their codebases. 100% of the codebases in Aerospace, Aviation, Automotive, Transportation, and Logistics contained open-source code and it made up 73% of all the code in this sector. 63% of these codebases had high-risk vulnerabilities (with a score of 7 or higher).

Similarly, the Energy and Clean Tech sector comprised open-source in 78% of the total code and 69% of it contained high-risk vulnerabilities.

Considering the rise of vulnerabilities in open-source code used in industries over the last five years, it was found that since 2018, high-risk vulnerabilities in the Marketing Tech sector increased by a minimum of 42%. The number of high-risk vulnerabilities in the Retail and eCommerce sector has jumped as much as 557% during the last five years. The Aerospace, Aviation, Automotive, Transportation, and Logistics verticals saw a massive 232% increase in high-risk vulnerabilities.

Looking at the Internet of Things (IoT) vertical, 100% of the scanned codebases contained open-source. The total amount of open source in each codebase has increased to 35% since 2018, with 89% of the total code being open-source code. The IoT vertical saw a 130% rise in high-risk vulnerabilities since 2018. In 2022, 53% of its audited applications had high-risk vulnerabilities.

54% of audited codebases contained open source with license conflicts

54% of codebases audited in 2022 contained open source with license conflicts, an increase of 2% from last year, but down by 17% from 2020. This year, 22% of the audited codebases had a problem with a license called Creative Commons ShareAlike 3.0 (CC BY-SA 3.0). This was the most common type of license conflict.

CC BY-SA 3.0 license numbers help remind us of an important thing to watch out for when using open-source licenses. Developers often use code, like functions and methods, from other projects in their software. This is called a “dependency” because the project depends on that code. Sometimes the code used has different licensing terms than the main project and this can cause issues or conflicts in what you can do with it.

The number of open-source license conflicts in the computer hardware and semiconductor industry went down from 93% last year to 75% this year. This is a significant decrease. The industry with the highest percentage of open-source license conflicts this year was the Internet of Things, with 78%. This may be because people are worried about supply chain risks and economic uncertainty.

91% of codebases had open-source with no development activity in the last two years

Developers should choose open-source components with strong and active communities. But 91% of the open-source components have not been updated or had security fixes in the last two years. This means that the project might not be maintained anymore, especially if it is a small project.

There may be many reasons for not updating software. A DevSecOps team may decide that the risks of updating are not worth it. Embedded software might be safe from outside threats, so updating may not make sense. Or teams may have too much work and do not have time or resources to update existing software, so they only update for very important things.

Organizations typically enjoy the convenience of using commercial software, which is regularly patched and updated without user involvement. Open-source solutions however require users to exercise control over component security and stability; seeking out new versions or patches as they become available.

Securing the supply chain

Organizations are still struggling to understand and establish full visibility into their software supply chains, with pressures for increased transparency.

The first step in securing the software supply chain is managing open-source and third-party code in applications. This process entails attaining full visibility of dependencies, assessing risk levels, and implementing tooling/practices to manage or remediate them.

Communicating this information to key stakeholders is also key to the visibility and support of risk management efforts.

Automation should be included when building these capabilities and practices into the existing development pipelines.

Security and verification of all product inputs are essential in today’s highly digitalized world. Open-source software, third-party integrations, components – everything involved must be securely managed to ensure the overall security of your supply chain’s final output. To safeguard against trust in weakened links within a complex network, “Trust, but Verify” should become an integral part of everyone’s operations strategy.

Source: Synopsys