Across all industry sectors, open source software continues to pose a challenge for software security. We’re all aware that vulnerabilities in commercial and open source software, applications, and operating systems can result in software supply chain breaches, but now we’re seeing attackers who are targeting Web applications, API servers, mobile devices, and the software components required to build them.
The latest edition of Synopsys’ annual study on open source security has just been released. The “Open Source Security and Risk Analysis” (OSSRA) study from Synopsys looks at the findings of more than 1,700 commercial codebase audits,.
Of the 1,703 codebases that Synopsys audited in 2022, 96% of them contained open source. Aerospace, Aviation, Automotive, Transportation, and Logistics; EdTech; and Internet of Things were three of the 17 industry sectors included in the 2023 OSSRA report that had open source in 100% of their audited codebases. In the remaining verticals, over 92% of the codebases contained open source.
High-Risk Vulnerabilities Persist in Code
Since 2019, high-risk vulnerabilities have increased by at least 42% across all 17 OSSRA businesses, with surges soaring to +557% in the retail and e-commerce sectors and +317% in the computer hardware and semiconductors sector.
A five-year retrospective, new to the OSSRA report this year, gives a more comprehensive picture of open source and security trends. Despite variations by industry, the overall open source content of audited codebases grew across the board. Several industries also showed alarming increases in the number of vulnerabilities found in their codebases, indicating a concerning lack of vulnerability mitigation.
One significant area that continues to be a challenge is patch management. Of the 1,703 codebases audited, 89% contained open source that was more than four years out of date (a 5% increase from 2022’s report). And 91% used components that were not the latest available version. That is, an update or patch was available but not applied. Along with patch management, license conflicts continue to pose security problems. This year, 54% of audited codebases contained codebases with license conflicts, up 2% from last year.
There are valid reasons for not updating software, but a significant portion of the 91% figure is probably attributable to development teams not being aware that a newer version of an open source component is available. If a company doesn’t maintain a precise and current inventory of the open source utilized in its code, a component may go unnoticed until it is exposed to a high-risk exploit.
That’s exactly what happened with Log4j, and it’s still an issue more than a year later. Despite the public attention it garnered and the many steps businesses may take to verify and fix Log4j’s presence in their codebase, it persists in 5% of all codebases and 11% of audited Java codebases.
Establish Open Source Best Practices for Security
Establishing software governance best practices can help you launch an open source software management program to protect your resources and data from zero-day vulnerabilities.
1. Define your policy.
Building an open source policy for your organization minimizes your legal, technical, and business risks. You want to identify your key stakeholders, then define your organization’s open source software goals, existing utilization, and target usage. The policy should cover open source patches and licenses as well as identifying who will be responsible for maintaining them.
2. Create an approval process.
Establish an approval process to assess if a software package fulfills your organization’s needs and quality standards. Consider code quality, support, project maturity, contributor reputation, and vulnerability patterns. An approval process that considers these criteria will prevent teams from having multiple versions of the same software package in your organization’s code, some of which may not have been patched or upgraded.
3. Audit for open source software.
Audits reveal your open source software and ensure compliance with company regulations. This can help you locate components for open source license compliance and vulnerability disclosure. You should perform open source scans throughout the software development life cycle (SDLC), but you should ensure that a final scan is done every time an application is built into a release candidate that utilizes open source software, especially if you rely on components from third parties.
4. Build an SBOM
A software bill of materials (SBOM) is a list of all the open source and third-party components present in a codebase. An SBOM also lists the licenses that govern those components, the versions of the components used in the codebase, and their patch status, which allows security teams to quickly identify any associated security or license risks. Automating this operation eliminates manual, inaccurate open source inventories.
By putting in place the proper security practices, you can stay on top of your open source vulnerability risk and build a robust system for managing it.
About the Author
Charlotte Freeman has been writing about tech and security for over 20 years. She’s currently a senior security writer for the Synopsys Software Integrity Group.
