Open Source News from the 2022 OSSRA Report
The world got another reminder at the turn of 2022 about the ubiquity of open source software when a group of vulnerabilities in the open source Apache logging library Log4j were made public. These Log4Shell remote code execution defects affected computers running applications in Java, one of the world’s most popular programming languages.
Exploiting Log4Shell was easy. Michael White, technical director and principal architect with the Synopsys Software Integrity Group, wrote in a blog post that these vulnerabilities were “trivial to execute.” This meant a lot of overtime hours for security teams just as they were looking forward to a break for the holidays.
Open source vulnerability issues are nothing new, and the recently released Open Source Security and Risk Analysis (OSSRA) report by the Synopsys Cybersecurity Research Center (CyRC) provides guidance about how to find, track, maintain and manage open source code so organizations can avoid the inevitable risks that come with any software.
The OSSRA report is based on analysis of more than 2,400 commercial codebases across 17 industries in 2021. According to the 2022 OSSRA, the seventh annual iteration of the report, “open source is everywhere, as is the need to properly manage its use. Identifying, tracking, and managing open source is critical for effective software security.”
Some of the trends identified this year were encouraging. The percentage of codebases with at least one open source vulnerability dropped slightly, from 84% in 2020 to 81%. The decline in the percentage of codebases with at least one high-risk open source vulnerability was more significant — from 60% to 49%.
Some trends are less encouraging. The aerospace, aviation, automotive, transportation and logistics category and the IoT category — had vulnerabilities in 60% or more of their codebases. Another eight industries (internet and mobile apps; ed tech; marketing tech; energy and clean tech; financial services and FinTech; retail and eCommerce; manufacturing, industrials, robotics; and enterprise software/SaaS) had vulnerabilities in 50% or more of their codebases. Another persistent issue is unpatched components: “88% contained outdated versions of open source components,” according to the report. “That is, an update or patch was available but had not been applied.”
The Log4Shell Wake-up Call
Log4Shell was a serious vulnerability — and one that cost organizations a lot of money and resource hours. The OSSRA report notes that it also prompted organizations to revisit the challenges inherent to open source components and how they’re managed.
Since open source projects are created and maintained by volunteers, patches and security updates are usually not “pushed” to users; they have to be “pulled.”
Popular open source projects may have large numbers of volunteers helping to maintain the code, but there are millions of less popular projects with fewer than 10 people maintaining them. In some cases, projects haven’t had updates or maintenance for years.
In addition, too many developers take a “trust-and-don’t-bother-to-verify” approach. Tim Mackey, principal security strategist within the CyRC and part of the team that produces the OSSRA report, calls it the “WooHoo!” approach. Developers can be so dazzled by the things an open source software component can do that they don’t perform the security reviews required for commercial or proprietary software.
Open source components are no more or less secure than commercial or proprietary code, but the mismanagement of them can create major business risk. How should organizations address those realities?
The best way to start is with a software bill of materials (SBOM), which is a detailed inventory of every component in a codebase, plus information on the volunteers who made it, licensing restrictions, known vulnerabilities and the software components it requires to function properly (dependencies). It’s essentially an ingredients list in a software supply chain.
An SBOM can help with a task that would be impossible to do manually — plumbing the depths of the dependency chain. Mackey has used the example of a simple application with eight “declared” dependencies. While that may seem like a manageable number, each of those had dependencies of its own. One had eight more, while another had 15. Ultimately the app had more than 130 dependencies that ran several levels deep.
According to the OSSRA report, “These dependencies are where the greatest risk exposure exists within a software supply chain. The only way to minimize this risk is with a comprehensive and exhaustive SBOM that tracks dependencies and their associated risk, allowing you to take prioritized and informed action when needed.”
Indeed, an SBOM can be a major asset when a vulnerability is disclosed. In the case of Log4j, an organization with an up-to-date SBOM could just conduct a simple database search to find out if that library is anywhere in its software supply chain. If so, it knows it needs to get and apply the patch.
The good news is that SBOM has become one of the hottest acronyms in cybersecurity over the past year. President Joe Biden explicitly called for it in his executive order on “Improving the Nation’s Cybersecurity” (EO 14028), issued May 12, 2021. That order bans federal agencies from buying any software products that don’t include an SBOM.
No Silver Bullets
The caveat is that the “SB” in SBOM doesn’t stand for “silver bullet.” An SBOM is essential, but it’s not sufficient. In a recent episode of the Synopsys video blog AppSec Decoded, Mackey noted that “The SBOM will tell you what’s in the software, but it won’t tell you how to patch it, it won’t tell you if it has been patched, and if you’re not careful, it could potentially give you misleading information.”
Still, an SBOM could have eliminated much of the panic around Log4Shell — not to mention the sleepless nights for thousands of development and security teams right before Christmas. As the OSSRA report puts it, “This round-the-clock remediation effort was often a result of organizations not knowing where Log4j was located within their systems and applications, or in fact, if it was there at all.”
“As we’ve said before, it’s important to distinguish between a lack of open source management and the fact that open source itself is not the problem,” the report concluded.
