A software bill of materials lists the “ingredients” in a software product, making it easier to identify and avoid security risks

Unless you’ve been living under a rock the past few years, you’ve likely at least heard of Log4j. This is an Apache open source library that’s commonly used in just about everything Java-related online. Unfortunately, in late 2021 the logging package was discovered to be critically vulnerable to remote code execution attacks, meaning an attacker could exploit it to install malware (e.g., ransomware) onto vulnerable systems and inject larger networks.

Cloudflare CEO Matthew Prince reported on Twitter that there were 400 confirmed exploit attempts per second. But that’s just one estimate — according to The Washington Journal, Akamai Technologies said it observed 10 million such exploit attempts per hour. Research from Check Point also showed that the attackers were rolling out new variants of the exploits — more than 60 in under 24 hours.

That’s a lot of exploits and a lot of variations to boot. Considering that the Log4j vulnerability affected major companies like Amazon, Apple, and IBM, it’s no surprise that it had companies globally worried.

But what makes the situation particularly concerning is that many companies weren’t aware that the products they use contained such vulnerable elements. If only there was a way that organizations could know exactly what components are part of the software they use… Oh, wait, there is: they could use products that come with a software bill of materials (SBOM).

But what is a software bill of materials and how can it help organizations mitigate some of the cyber risks facing their organizations and networks?

Let’s hash it out.

What Is a Software Bill of Materials (SBOM)?

A software bill of materials is a list of the base elements (such as code libraries) used to create a product. Basically, it provides details and information that outline the relationships between the various elements of the software in your supply chain. The National Telecommunications and Information Administration (NTIA) has a bit more technical definition for an SBOM, describing it as “a nested inventory for software, a list of ingredients that make up software components.” It includes everything from version information and what companies created those elements.

Putting it more simply, SBOMs enable companies to know exactly what goes into their software — ideally, so they can keep a close eye on any dependencies. So, going back to the Log4j example, if you’re using software that includes the vulnerable library, you would know instantly because Log4j would be listed in the SBOM. You could reach out to your vendor to ensure they’re providing a patch using an updated version of Log4j. But you can’t assess or mitigate specific cybersecurity risks if you don’t know they exist. This is where an SBOM can help.

An analogy that’s commonly used to describe these lists of components is the ingredient labels on packaged food items. (We’ll speak more to that in a minute.) The purpose of an SBOM is to create transparency and help companies identify dependencies in their software supply chains. This is because, as a purchaser, you’re supposed to receive or be able to access SBOMs for products you purchase. This way, you know a good amount of information about your supply chain.

SBOMs are something that can be used to address a wide variety of security issues for everything from software to IoT devices.

Even the U.S. Government Encourages Using SBOMs to Improve Security

In fact, the May 2021 U.S. Executive Order (EO 14028) on Improving the Nation’s Cybersecurity calls upon the use of SBOMs to help strengthen the defenses of U.S. federal information systems. (Government agencies are now required to collect them from software suppliers.) The National Institute of Standards and Technology (NIST) developed the Secure Software Development Framework (SSDF) to aid this initiative, and it requires software bill of materials information to be included.

NIST says that SBOMs are complementary to other software security processes; they’re not meant to replace other security-related functions such as cybersecurity supply chain risk management (CSCRM) activities.

What Types of Information SBOMs Should Include

In its 2021 Multistakeholder Process on Software Component Transparency document, NTIA explains that an SBOM typically includes specific information about a product’s baseline components:

• Author’s Name
• Supplier name
• Component name
• Version string
• Component hash (yup! Cryptographic functions play a key [excuse the pun] role here, too)
• Unique identifier
• Dependency Relationship
• Timestamp

For a complete list of minimum requirements, check out NTIA’s SBOM Minimum Elements Report. It breaks down the minimum elements that should be addressed in an SBOM into three main categories:

1. Data fields,
2. Automation support, and
3. Practices and Processes.

Do SBOMs have to be created at the time you’re developing your software? Not necessarily. You also can create SBOMs retroactively. The only thing to note about that is that it might not be as complete as an SBOM that’s generated as part of your software development life cycle (SDLC) process.

SBOMs Are Typically Meant to Be Read By Machines, Not People….

An SBOM isn’t something that just anyone can look at and read easily; it’s presented in one of a few standardized formats that are readable by computers (but not human beings, unless you know what to look for) to improve integration and automation. These three standards (listed in alphabetical order) include:

• CycloneDX, which also works for software-as-a-service (SaaSBOM), hardware bill of materials (HBOM), and other uses. The file format for this type of SBOM is .xml.
• Software Identification (SWID), which is also an international open standard (ISO/IEC 19770-2:2015, updated 2021). Acceptable file formats are .json and .xml.
• Software Package Data eXchange (SPDX), which is an international open standard (ISO/IEC 5962:2021). Acceptable file formats include .json, .spdx, .rdf .xls, .xml, and .yml.

Who a Software Bill of Materials Benefits (Spoiler Alert: Everyone)

According to the White House’s Executive Order, SBOMs benefit virtually everyone who develops, manufactures, purchases, or operates software or devices that use said software. But the truth is that a software bill of materials also indirectly benefits the consumers who are served by these companies and service:

“An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.”.

Yup. While SBOMs are typically promoted as being good for software buyers and operators, the truth is that they’re also useful for broader audiences. So, you see, it’s good for your organization regardless of where you fall in the supply chain.

But now that we know what an SBOM is in a general sense, let’s take a closer look at this security tool and how it aids your organization’s software supply chain.

A Look at How a Software Bill of Materials Breaks Things Down Within the Supply Chain

Your software supply chain comprises everything from where the individual components came from that are used to create the products you use and how they’re manufactured, distributed, and supported. Some categorizations of the supply chain talk about custom code, third-party components, development and building environments, delivery, etc. Basically, it’s all about sourcing your components (internal or third-party dependencies), building your software, storing and deploying it, and providing ongoing support (via patches) while it’s being used by the intended users.

However, to simplify things a bit more, we’re going to look at what the software supply chain ecosystem looks like based on a traditional supply chain (based on information shared in NTIA’s SBOM explainer video):

Let’s imagine, for a moment, that you’re an IoT device manufacturer that uses third-party software as part of your supply chain. This is how the above breakdown would play out with regard to you and your business:

• Source parts refer to all the base elements used to create the product.
• Compound components refer to any elements in the final product that are created using other elements (e.g., a third-party’s library or open source code). Not all software manufacturers provide information about what these components are.
• The final assembled product (your software) is the end product created when you combine all of the parts.
• Operator(s) or vendor(s) is the term that refers to your direct customers or service providers that use your product.
• Consumer(s) refers to the people that your customers use your product to provide services to.

An SBOM Is Like the List of Ingredients You’d Find in Your Favorite Foods…

When you’re at the grocery store, do you stop to read product nutrition labels and ingredient lists? If you’re like me, you do because you want to know exactly what you’re putting into your body.

It’s a good idea to take a similar approach when adding software and devices to your network. If you want to keep your network secure, then you’ll want to check every device, software, or system carefully you connect to it for known vulnerabilities. Knowing what libraries, drivers, operating systems and open source resources are used goes a long way in helping you assess and mitigate vulnerabilities.

Let’s consider a quick example with one of my favorite special occasion meals: Fettucine alfredo. Say, a friend is having a small get-together at her house and I decide to bring over a dish of homemade fettuccine alfredo for the occasion to share. Sounds great, right? It is, so long as no one has any food allergies to any of the ingredients I’m using in my dish.

But how can someone tell whether there might be something in my fettuccine alfredo that might cause an issue? Let’s first consider the list of ingredients. My fettuccine alfredo recipe is pretty simple as it contains several basic ingredients:

• Heavy whipping cream
• Homemade salted butter
• Freshly grated Parmesan-Reggiano cheese
• Freshly grated Pecorino-Romano cheese
• Garlic
• Salt
• Black pepper
• Italian parsley
• Homemade gluten free fettuccine pasta

If I were to break up this item, we’d be looking at the following breakdown of items:

Looks simple enough, right? Not quite… There’s more to it because of the “hidden ingredients” that people might not know about if they aren’t disclosed.

Some Ingredients Are Made Up of Other Unknown Ingredients

A few of these items — the two cheese and the gluten free flour — are created through manufacturers whose products I like and trust. So, knowing this, let’s consider the supply chain for these items — particularly the compound components. These items may have other additives that I might not be aware of unless I stop to read the product label. Let’s consider a quick example using parmesan cheese.

The ingredients for the brand of parmesan cheese I typically use contains cultured cow’s milk, enzymes, and salt. (Note: If I bought the pre-grated variety, additional components would be added, such as cellulose and natamycin — this is why I buy the blocks of cheese and grate them myself!) So, in this case, that means the enzymes and cultured milk need to be added to my list of ingredients.

Likewise, if I looked at the ingredient list for the Pecorino-Romano cheese or the gluten free flour I’d use, there would be several additional items I’d need to add to my list of components. And it would also be important to know where the ingredients the manufacturers used actually came from. For example:

• The Pecorino-Romano cheese I use is imported from Italy and it contains sheeps milk and rennet.
• The flour includes multiple other ingredients — sweet white rice flour, whole grain brown rice flour, potato starch, whole grain sorghum flour, tapioca flour, and xantham gum.

This means my ingredient list now looks more like this:

Why You Need to Know Which Ingredients Are Included in Your Software

See how much longer the list of ingredients became now that we’ve added all of these “hidden” ingredients? Now, ask yourself what would happen if one of your friends was allergic to milk, tapioca flour, or eggs but you didn’t know it. If they didn’t know those ingredients were included in the meal, it could lead to a potentially serious medical emergency, depending on the severity of their allergic reaction.

Likewise, similar concerns apply to your software and hardware devices. While the concern isn’t a food allergy or medical concern necessarily, not knowing what’s included in your software supply chain leaves your organization, network, and customers at risk. Knowing the A-Z of your software supply chain helps you stay abreast of any potential vulnerabilities and exploits you need to address before bad guys use them to attack your network and organization. This is crucial for risk analysis and mitigation activities, where you need to know how and where your systems are vulnerable.

The truth is that it’s rare to find a company that builds its software or hardware components entirely from scratch. (Doing so is just too complex, costly, and time consuming.) Instead, they integrate third-party and open source elements such as frameworks and libraries. When you consider that these components often operate with the same permissions as the software they’re a part of, it means the risk can be significant.

SBOMs help you have a better understanding of your supply chain and everything involved in it. They also help you better manage and mitigate risks by using them to analyze known vulnerabilities. This is why it’s best for them to be stored in a centralized repository that applications and systems can easily access and use.

Can’t a Software Bill of Materials Be Faked?

As with any electronic file, yes, there’s always a risk of that happening. However, there are safeguards that could be used to prevent digital tampering and to prove something is legitimate. One such method is to digitally sign your file before releasing it with your software. A digital signature is a way to simultaneously show that your file is authentic and hasn’t been tampered with since it was signed.

Is a digital signature required for use with SBOMs? No. But as Dean Coclin (CISSP) points out, one good option is to “use a cloud-based code signing service, which allows for uploads of code (or the hash) to be signed by the service and returned to the developer.”

Final Thoughts on SBOMs (And Why They Should Be Part of Your Risk Management Strategy)

Trying to mitigate risks for your software without knowing all the different components nested within it is like going to a dinner party when you have a severe peanut allergy and not bothering to ask if any of the dishes contain nuts. It’s not a smart practice and puts you at risk of a severe medical — err, cybersecurity episode. Instead, ask those questions and avoid the potential headaches, non-compliance issues, financial penalties, and lawsuits that you otherwise may face.

Nowadays, it’s uncommon for software developers to write all of their code from scratch. It’s far more common for devs to integrate open source code into their products because it’s cheaper and easier. As the saying goes: Why reinvent the wheel?

Making software bills of materials a standard component of every piece of software is a smart move. SBOMs provide the added layer of transparency organizations need to keep their data and networks secure and aid in making the vulnerability assessment and mitigation process a lot easier.

The next time you’re shopping for new software, be sure to speak with your vendor to see if their products have SBOMs available. Don’t be surprised if they don’t but be sure to ask anyway to make it clear that this is something you want to see as a software purchaser or operator.