The OSSRA report offers a few key points about the wide adoption of open source software and the security risks it poses. The report investigated 17 industry sectors, four of which—computer hardware and semiconductors, cybersecurity, energy and clean tech, and Internet of Things—contained open source in 100% of their audited codebases. The remaining verticals had open source in 93% to 99% of their codebases.
The report noted that although license conflicts were down—they were found in 53% of codebases as compared to 65% in 2020—there was an increase in instances of unexamined dependencies. That is, when developers introduce open source dependencies, they’re often unaware of subdependencies containing license terms and conditions. For example, some versions of the popular node.js component include a dependency that leverages code licensed under the CC-SA 3 license, which might place undesirable requirements on the licensee and require legal evaluation for possible IP issues.
While the decreases in license conflicts and high-risk vulnerabilities are encouraging, the fact remains that more than half of the codebases audited contained license conflicts, and nearly half contained high-risk vulnerabilities. Even more troubling, of the 2,097 audited codebases that also had risk assessments performed, 88% contained outdated versions of open source components. That is, an update or patch was available but not applied.
There are justifiable reasons for not keeping software up-to-date, but unless an organization keeps an accurate and up-to-date inventory of the open source used in its code, an unupdated component can be forgotten until it becomes vulnerable to a high-risk exploit.
That’s precisely what occurred with Log4j. While the exploit itself was a danger, the panic and churn that ensued when organizations tried to fix it was largely caused by organizations not knowing where Log4j was located in their systems and applications. Many organizations had to scramble to see if it was there at all.