Open Source Vulnerabilities Are Still a Challenge for Developers
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.
Synopsys has released the latest edition of its annual report on open source security, Open Source Security and Risk Analysis (OSSRA). Created by the Synopsys Cybersecurity Research Center (CyRC), this report looks at the findings of more than 1,700 commercial codebase audits conducted by the Black Duck audit services team.
Synopsys publishes OSSRA findings every year to help the industry understand the open source security and license risk landscape. By examining open source usage trends and market insights, developers can get a deeper understanding of their role in the linked software ecosystem.
Of the 1,703 codebases that Synopsys audited in 2022, 96% of them contained open source. Aerospace, aviation, automotive, transportation, logistics; EdTech; and Internet of Things are three of the 17 industry sectors included in the 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, soaring to 557% in the retail and e-commerce sectors and to 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 codebases audited, 89% contained open source that was more than four years out of date (a 5% increase from the 2022 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 the audited codebases contained 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 DevSecOps 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 used in its code, a component may go unnoticed until it is exposed to a high-risk exploit. The race to find out where it’s being used and to update it then begins.
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. This includes defining policy, setting up an approval process, doing a thorough software audit and building an SBOM.
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, and 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. Ideally, your strategy should define acceptable sources for obtaining open source software and how to determine if a package is suitable. It should also state who can obtain open source software and if permission is needed to use or distribute it.
2. Create an Approval Process
Establish an approval process to assess whether 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. Any approval process needs fast request processing. A preapproved open source list can help.
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 uses 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. It also helps identify vulnerable components and detect emerging vulnerabilities fast. If you don’t realize you have it, you can’t patch it.
How Synopsys Can Help
Synopsys has a number of tools that can help. From powerful software composition analysis (SCA) tools such as Black Duck to our two new SaaS offerings, Polaris fAST Static and fAST SCA, Synopsys can help your organization generate a complete open source SBOM. SCA tools like these can provide open source information on a continuous basis, ensuring that you have the most up-to-date picture of your open source risks and allowing you to inventory the open source and third-party components in your code.
