Using open source software is not a security problem. Mismanagement of it is
If you use software — and today we all do — you use open source software. If you’re in business, no matter what your brand says or what your products are, you’re a software company, which means you’re also an open source software company.
That means you need to know what you’re using, where it came from, who made it, and how to take care of it.
And helping organizations sort all that out is the goal of the latest “Open Source Security and Risk Analysis” (OSSRA) report by the Synopsys Cybersecurity Research Center (CyRC). The report is based on analysis of more than 2,400 commercial codebases across 17 industries in 2021.
Among the questions the report answers is how much of it you likely use? The short answer — a lot. In a bit more detail, chances are close to 100% that there are open source software components in all your codebases and that it comprises the large majority — an average of 78% — of those codebases.
The report also provides guidance about how to find it, track it, maintain it, and manage it, to avoid the inevitable risks that come with any software. Those risks, from unpatched vulnerabilities or licensing conflicts, can result in damage that ranges from annoyance to legal liability to existential.
Which is why you need to grab a copy of the report — it’s free. (Disclosure: I write for Synopsys)
There is no good reason not to use open source. You couldn’t avoid it even if you wanted to — that ship has long since sailed. As the report puts it, “Open source is the foundation for every application we rely on today.”
Its overwhelming popularity is a good thing on many levels. It’s free and can be modified to suit the needs of those who use it as long as any obligations associated with its licenses are met.
Indeed, what’s not to like about something that essentially eliminates the need to invent digital raw materials or create fundamental building blocks? The creativity (and the profit) is in finding new and different combinations of existing (free!) raw materials.
And that’s what open source software provides — free building blocks that make development of software products faster, more efficient, and cheaper. It’s also why most software products today are assembled from existing components, rather than written from scratch.
Nothing is perfect
But no software is perfect — after all, it’s made by imperfect humans. Open source software is not inherently less secure than proprietary or commercial software, but it’s no more secure either. And since it now makes up a large majority of the components in software products, that matters — a lot.
According to the 2022 OSSRA, the 7th 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.”
That has been true for a while. Software is still eating the world, faster than ever. And open source software is doing almost all the eating. That can be both good and bad, since the benefits and risks of something that pervasive affect everybody.
Some of the trends this year’s OSSRA report found 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%.
Still, encouraging trends don’t mean things are under control — 81% is encouraging to hackers, not those trying to avoid them. And if half of all codebases have known vulnerabilities in them, that’s a massive attack surfaces for cybercriminals.
And some trends are less encouraging. One marker of how far organizations must go to make themselves more difficult targets for cybercrime is the report’s finding that two industries — IoT and aerospace, aviation, automotive, transportation, logistics — have 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) have vulnerabilities in 50% or more of their codebases.
Also, some known vulnerabilities are persisting, and in some cases increasing, in codebases year over year. Of the codebases examined, “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.”
Keep in mind, those are vulnerabilities that have been made public. That means the bad guys know about them. As the report put it, “a conclusion could be drawn that some DevSecOps teams are struggling to stay on top of open source risk.”
The long-game benefit
On the potential upside, however, and perhaps the most significant takeaway from the OSSRA report is that possibly, in a long-game way, one of the worst vulnerabilities of the past year might prompt more organizations to make the security of their open source software a higher priority.
Log4Shell, a group of vulnerabilities in the open source Apache logging library Log4j, was already present in hundreds of millions to billions of systems, services, websites, and devices when it became public in December 2021.
The Log4Shell defects are “remote code execution” vulnerabilities, which means they can allow cyberattackers to gain remote control over computers running applications in Java — one of the world’s most popular programming languages.
Worse, exploiting Log4Shell is easy. Michael White, technical director and principal architect with the Synopsys Software Integrity Group, wrote in a blog post that it’s “trivial to execute.”
But the OSSRA report notes that Log4Shell also prompted several necessary reminders, or realizations, about the use of open source within business.
- Open source projects are created and maintained by volunteers, not commercial vendors. Thus, patches and security updates are usually not “pushed” to users but have to be “pulled.” And sometimes projects are abandoned or no longer maintained, which means if defects are discovered in them, they don’t get patched.
- 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.
- Too many developers take a “trust-and-don’t-bother-to-verify” approach. Tim Mackey, principal security strategist within the Synopsys CyRC, who has been involved in producing the OSSRA report since its beginning, calls it the “WooHoo!” approach. Developers can be so dazzled by the things an open source software component can do that they ignore the risks that might come along with it and 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 group of volunteers who made it, what any licensing restrictions might be, whether it has any known vulnerabilities, and whether it relies on other software components, called dependencies, to function properly. 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 in the past 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 in the event of the disclosure of a major vulnerability. 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” (more bureaucratically known as EO 14028), issued May 12, 2021. If that exhortation becomes reality, federal agencies will be banned 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 not sufficient. Mackey noted in a recent episode of the Synopsys video blog AppSec Decoded 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 from Log4Shell — not to mention 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 said.