While open source software enabled profound advances and IT developments, it also created security risks. Companies often don’t know how much open source they use or where it lives.

So, when hacked or breached, how do they fix the mess? 

Open source uncertainty now demands scrutiny of software bills of materials (SBOM) down to the morsels of code that make up a software product. 

A May 2021 Executive Order focused on SBOMs to improve supply-chain security and called on companies to include SBOMs when selling software to the federal government. 

The effort has spilled into other sectors, including auto manufacturing and critical infrastructure, even if the companies do not directly sell to the federal government. 

CIO Dive spoke to Dale Gardner, senior director, research analyst at Gartner, about why the open source revolution sparked innovation and critical vulnerabilities, and how business can close the gap.

(This interview has been edited for length and clarity.)

CIO DIVE: We know open source is a key part of software we use daily. Do we really understand how far its tenacles reach?

DALE GARDNER:  [Building software is] like baking a cake at home. You know what’s in it because you did it.

Commercial software is exceptionally opaque. There isn’t really a good way to find out what’s inside. 

The analogy there might be like buying a cake from the store. It looks good, but you have no idea how they actually put it together. If you have food allergies, that’s a problem.

What security risks does this present? 

Open source is like any other software … It contains vulnerabilities and weaknesses. 

It’s important to understand what those are, first off, so that we can avoid them if we know that they’re there. But secondly, so we can rapidly identify where open source is located within the organization when a vulnerability arises. 

A good example of that: the Log4j incident … it’s an incredibly common piece of software. …

There’s no way to scan for it, no list of what’s inside, so you have to wait for the vendor, or try to contact the vendor of your software. Is this inside, what are you doing to fix it? When can I expect remediation? 

Go back to the cake: If you’ve got a food allergy and you find out maybe there’s peanuts inside, you could have lots of problems if you didn’t know they were there.

How does a SBOM work?

The idea is that when you build software, it’s a combination of things. Developers who are writing code … are including open source libraries, and in some cases you may be including commercial libraries. That all goes through a process with other software where a completed package comes out [at] the end.

So, you might think of an application, let’s say Microsoft Office, where it’s [a] combination of Microsoft’s code, open source, and commercial libraries. 

At the end, you get the actual executable install[ed] on your computer or phone and run the program, and do whatever it does. With the SBOM, one of the things that would happen, along with the actual executable, is … you would get a file … you can think of it as a list of ingredients. 

[The SBOM] has all the different packages that are included within that particular version of the software as well as any dependencies those packages have. 

It starts to get quite complicated. I may be writing a program and include Log4j for whatever reason. Log4j also includes other open-source packages. Transitive dependencies can build up in these chains that are quite long. 

The SBOM details the first-order packages that are included, and then any dependencies that they call, and on down the line, so that you’ve got quite a comprehensive list. 

What will enterprises do with SBOMs?

Some organizations have policies about particular software they’re going to allow or not, and those could be based on lots of different things.

It could be there are known vulnerabilities, maybe the particular package is not well maintained, or has been abandoned. There could be import or export controls, like foreign country software, or export limitations. None of that is in my software so I don’t inadvertently violate some regulation or law.

The idea is that you can scan for that. It looks good, or if there’s a problem, you go back to [the] vendor and ask them to make a change or look for alternative solutions.

When the next incident arises, I can go to the database and say, 'Well, package ABC has this vulnerability, do I have that anywhere within my software?' You can do a search and say: ‘Okay great I’ve got it in this software and in that package and in this package over here.’ It greatly simplifies the process of remediation and mitigation. 

What more can organizations do to better understand the components of their technology?

The thing to keep in mind about SBOMs themselves is that, at the end of the day, it’s an artifact. I get this file and I’ve got the ability to look at it, but right now there isn’t really a lot of infrastructure for me to store or examine this information. 

That’s one of the next steps. There are places in the organization where this might go, particularly in larger organizations that have things like software asset management systems. Today those get used for keeping track of what software I’ve licensed, and what terms are, and when does it expire … Those vendors could add support, and I would expect them to, in addition to maintaining the repository of all the software they have. The SBOMs can live there as well. 

Updating [them is the] other challenge. Each time you get a new version of the software, you should expect a new SBOM. …

Organizations have to have the tools to be able to store it, manage it, process it, and then also say okay great, I got an update, and I need to mark this one as deprecated, and here’s the new version. Maybe I have to keep both of those around since I’ve got new versions in some parts of [the] organization and old version[s] in other parts. 

A lot that goes along with it, but it is a key part of the solution by being able to describe the software and what’s in it.