Open source software can make or break you. The OSSRA report can help ensure it makes you

Software may not be as universal as the air we breathe but it’s getting close. Everybody and every organization depends on it in multiple ways — for work, play, shopping, banking, travel, entertainment, communication, household appliances — the list goes on.

And most of that software is what’s called open source — components built by volunteers creating what amounts to free raw material for building software products. So if you’re in business, you’re not just a software business, you’re an open source software business.

That brings both benefits and risks, which is why you need the “Open Source Security & Risk Analysis”(OSSRA), an annual report by the Synopsys Cybersecurity Research Center (CyRC). (Disclosure: I write for Synopsys)

The OSSRA report, now in its eighth iteration, is dedicated to “helping security, legal, risk, and development teams better understand the open source security and license risk landscape.” Its findings are based on analysis of more than 1,700 commercial codebases across 17 industries in 2022.

CyRC researchers found open source in 96% of the codebases (the code and associated libraries that make up an application or service) they analyzed, and it comprised the large majority — an average of 76% — of the components in those codebases. The average number of open source components in a codebase was 595, up 13% from 528 the previous year.

That means virtually every organization relies on a lengthy and complex open source software supply chain. Which should make it obvious that protecting an organization and its customers requires tracking and securing that supply chain. One major goal of the OSSRA report is to help organizations do that.

It’s foundational

Some key messages of the report haven’t changed over the years. The first is that there are many good reasons to use open source. You can’t avoid it anyway. As the report puts it, “Open source is the foundation for every application we rely on today.”

Its overwhelming popularity is no mystery either. Open source is free and can be modified to suit the needs of those who use it. So it eliminates the need to reinvent basic software building blocks. The creativity (and the profit) is in finding new and different combinations of those existing raw materials 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.

But, as noted, it comes with risks. Open source is no more or less vulnerable than any other software, but vulnerabilities in the open source supply chain can’t be managed in the same way as the software an organization creates itself or buys from a commercial vendor, for several reasons.

• Open source projects are created and maintained by volunteers, which means patches and security updates are not “pushed” to users but have to be “pulled.” If an organization doesn’t know it’s using a vulnerable component, it won’t know it needs to apply a patch, even if one is available. This year’s OSSRA report found that 91% of the codebases examined by the audit team had outdated — as in, unpatched — versions of open source components.
• Many popular open source projects have large numbers of volunteers helping to maintain the code, but millions of less popular projects have fewer than 10 people maintaining them. Some have been abandoned. According to the report, 91% of the codebases analyzed had components with no development for two years. And 89% had components that were more than four years out-of-date.
• Some developers don’t bother vetting open source components before adding them to a codebase. Tim Mackey, head of software supply chain risk strategy with the Synopsys Software Integrity Group, has called it the “WooHoo! syndrome” — developers so dazzled by what an open source software component can do that they fail to test it adequately for the risks that might come along with it.
• While using an open source component doesn’t cost money, it’s not free of obligation — users have to comply with any licensing provisions. And while the percentage of licensing conflicts in the codebases analyzed decreased from 65% to 54% from 2020–22, that improvement still means that more than half contained violations of license terms, which could cause legal liability or possibly require proprietary code in an application to be made public.

In short, managing open source risks is a complex task, illustrated by the report’s findings. The researchers cited a report cosponsored by Synopsys that found increased interest in open source risk management — 73% of organizations surveyed said they had “significantly increased their efforts to secure open source software, container images, and third-party software components as a result of recent software supply chain attacks.”

Struggling with the basics

But interest doesn’t automatically yield results. Nearly two years out from President Biden’s executive order on “Improving the Nation’s Cybersecurity” (EO 14028), which included a section on software supply chain security, the OSSRA report found that organizations are “still struggling with supply chain basics — understanding the breadth of their software supply chain, establishing visibility into the software they depend on, and satisfying growing transparency pressures for the software they distribute and sell.”

That is likely because the average of 695 open source components per codebase, with many organizations having hundreds to thousands of applications, makes managing it more than complicated — it’s impossible to do manually.

What to do? Again, that’s where the OSSRA report can help.

As the report notes, managing open source risk doesn’t have to be a major struggle, because an automated tool is available to help with two of the most fundamental and necessary tasks: Find all your software components and create an inventory of them.

An automated testing tool called software composition analysis (SCA) will not only find open source components in your software supply chain, but it will also tell you of known vulnerabilities in any of them. Without that information you can’t maintain their security, which puts you and your customers at risk. As Mike McGuire, senior software security solutions manager at Synopsys and a member of the team that created the OSSRA report, put it, “you can’t secure what you don’t know exists. If you don’t know what’s in your codebases, you can’t monitor it for any type of risk.”

An SCA tool will also help create a software Bill of Materials (SBOM), a detailed inventory of every component in a codebase, including information on each of those components: Who made it and when, who is maintaining it (or not), what version you’re using, if it has any licensing restrictions, and if it has any known vulnerabilities.

Know your dependency chain

That includes tracking whether a given component relies on other software components, called dependencies, to function properly.

A good SBOM will plumb the depths of dependency chains. Mackey has in the past used the example of a simple application with eight “declared” dependencies. While that sounds like a manageable number, each of those had dependencies of its own. One had eight, while another had 15. And most of those also had dependencies. Ultimately that single application had more than 130 dependencies that ran several levels deep.

As the report puts it, “the concept of an SBOM derives from manufacturing, where the classic Bill of Materials is an inventory detailing all the items included in a product. When a defective part is discovered, the manufacturer knows which of its products is affected and can begin the process of repair or replacement.”

In short, an SBOM flips the old wartime slogan “trust, but verify” into a process that lets you verify your software so you can trust it.

It’s encouraging security news that SBOM has become one of the hottest acronyms in cybersecurity, perhaps partially in response to the Biden EO, which calls for federal agencies to be banned from buying any software products that don’t include an SBOM.

There is an important caveat to all this, however. The “SB” in SBOM doesn’t stand for “silver bullet.” An SBOM is essential, but not sufficient. It won’t make your security perfect — nothing will. So it’s important to know what it will and won’t do. As noted, an SBOM will tell you what’s in your software, which will help you know if there is a vulnerable component that needs to be patched, but it won’t tell you how to patch it or if it has been patched.

“An SBOM is going to give you that first step of visibility, but it doesn’t tell you what to make of what it’s telling you,” McGuire said. “It doesn’t give you any insights about risk — how or if those components are actually implemented by an application. It doesn’t tell you if there are vulnerabilities related to it or if they’re being addressed. It’s left up to an organization to connect the dots between the inventory and the risk that inventory is presenting to my applications.”

But its value is significant. Cybercriminals are looking for easy targets. And as the OSSRA report notes, using an SCA tool to find your open source software and creating an SBOM will make you a much more difficult target.