2024 OSSRA: Rising concerns for open source management
Now in its ninth edition, the 2024 “Open Source Security and Risk Analysis” (OSSRA) report delivers an in-depth look at the current state of open source security, compliance, licensing, and code quality risks in commercial software. This report uses data from the Black Duck® Audit Services team’s analysis of anonymized findings from 1,067 commercial codebases across 17 industries during 2023, with the primary aim of identifying software risks during merger and acquisition (M&A) transactions. Industries represented in the report include automotive, big data, cybersecurity, enterprise software, financial services, healthcare, the Internet of Things, manufacturing, and mobile apps.
Open source is in everything, everywhere, all at once
As the OSSRA report findings show, open source components and libraries form the backbone of nearly every application in every industry. Ninety-six percent of the total codebases (the code and associated libraries that make up an application or service) contained open source. Seventy-seven percent of all code in the codebases originated from open source. Every industry codebase scanned contained open source—most at percentages from 99% to 100%.
Given the time-to-market, cost savings, and development advantages of leveraging open source components, it’s no surprise that companies rely so heavily on it as part of their software development process. But the large number of discrete open source components in any given application found by the audit teams speaks to the challenge of tracking it all.
An average 500+ open source components per app
The OSSRA report notes that the average number of open source components in a given application this year was 526—a practical example of the importance if not absolute necessity for automated security testing. Manual testing might be feasible for a small number of components, but it becomes virtually impossible at scale; it requires the use of an automated solution like software composition analysis (SCA). And unlike manual testing, automated security tests can be executed quickly and consistently, allowing developers to identify issues early in the development process without impacting delivery schedules or productivity.
The vulnerabilities and license compliance issues discovered in the codebases were almost as pervasive as open source itself. Over half (53%) contained license conflicts. Eighty-four percent of the codebases that included a risk assessment (933) contained at least one known open source vulnerability. Seventy-four percent of the risk-assessed codebases contained high-risk vulnerabilities, a significant increase from last year’s OSSRA report, when only 48% of the codebases were found to contain high-risk vulnerabilities.
One possible explanation for the increase may be the economic downturn and subsequent layoffs, which limited the number of resources available to locate and patch vulnerabilities. Further, nearly all—91%—of the codebases were found to contain components 10 versions or more behind the most current available version of the component. The obvious conclusion is that the majority of open source consumers aren’t updating the components they use, leading to higher risk.
A third of the codebases were found to be using a vulnerable version of jQuery
The OSSRA data clearly shows that development teams need to improve at open source management—keeping open source components up-to-date. The consequences of using older, more vulnerable versions of open source can be grim. For example, #2 of the top 10 vulnerabilities listed in the 2024 OSSRA is a cross-site scripting vulnerability in jQuery versions 1.2 to 3.5.0. The issue was patched in jQuery 3.5.0, but a third of the codebases scanned for security risks were still using a jQuery version vulnerable to it. An exploit of that vulnerability means malicious data could be used to breach a system, or sensitive data—passwords, credit information—could be exposed.
jQuery is not inherently insecure. In fact, it is a well-maintained open source library with a large community of users, developers, and maintainers. But according to the OSSRA data, jQuery was the component most likely to have vulnerabilities, even though all the jQuery vulnerabilities listed in the report have available patches. It is important for users of jQuery—and indeed users of all open source—to be aware of the potential security risks associated with older versions of software, and take steps to mitigate those risks.
Most maintainers (contributors who lead an open source project) are diligent about keeping projects they’re involved with up-to-date. The same diligence needs to be encouraged in open source consumers, who need to stay aware of the versions they have in use, establish a regular cadence for updates, and practice software hygiene—downloading only from projects with a healthy ecosystem of maintainers and contributors.
Know what’s in your code
Whether your organization develops or uses software, the 2024 OSSRA report shows that there’s a near certainty that software includes open source components. Do you know exactly what those components are and whether they pose security or license risks? Visibility into the open source in your code needs to be a priority. If your team hasn’t already done so, the first step is to create and maintain a Software Bill of Materials (SBOM) that details what you have in your code, including information on versions, licenses, and provenance.
Once you have that inventory, keep your open source up-to-date, especially when it comes to popular open source components that are a frequent target of attackers. Keeping open source updated should be treated with the same priority as the code your team develops. Set a regular cadence for upgrades, especially if you’re using open source libraries from popular projects that have frequent maintainer activity.
Stay informed. Look for newsfeeds or regularly issued advisories that provide actionable advice and details about issues affecting open source components in your SBOM. Use an automated SCA tool rather than trying to manage open source through spreadsheets, and let your developers focus their energies on writing code.
Continue Reading
A new identity for the Synopsys Software Integrity Group
Aug 12, 2024 / 2 min read
CyRC Vulnerability Advisory: CVE-2024-5184s prompt injection in EmailGPT service
Jun 04, 2024 / 1 min read