SBOMs: The Accurate Guide to Software Supply Chain Security

The software bill of materials (SBOM) is a document that lists all the components and subcomponents of your software code. Some regulated industries require these documents as part of their software supply chain security efforts, and as third-party liability policies emerge, SBOMs are becoming a popular defense in the fight against cyber threats.

Cybercrime is currently one of the largest causes of criminal money damages in the world, costing individuals, companies, and governments more than $6 trillion USD in reported damages in 2021. This trend is on the rise, with large companies reporting cybercrime as the largest threat in terms of fraud in PwC’s 2022 Global Economic Crime and Fraud Survey.

Much of this crime involves exploiting third-party vulnerabilities: instead of outright hacking governments and enterprise organizations, hackers target the smaller code libraries that these larger entities license or build their applications upon. Because of this, governments are imposing new regulations to secure the software supply chain in certain critical industries.

Perhaps the most notable example of this is US President Biden’s 2021 executive order calling for heightened software supply chain security. This order includes the need for software vendors to provide key purchasers with a software bill of materials.

It is a relatively new concept, and practices haven’t become normalized yet. Because of this, we’ve put together a guide to help you understand what it is, what it is for, and how to use it—whether you’re a software vendor or a customer.

NOTE: In addition to being an advanced SCA solution, Finite State can help you produce and verify SBOMs documents. If you’re not already using Finite State, book a demo with us to see how we can help you secure your software supply chain today!

In this article:

Software Bill of Materials Defined

According to the US Cybersecurity and Infrastructure Security Agency, a software bill of materials is “a nested inventory, a list of ingredients that make up software components.”

Sounds a tad vague, doesn’t it? 

That’s because we know that in order to secure the software supply chain, both vendors and customers need to understand the components of the software applications they’re buying and selling. At the bare minimum, a software bill of materials should include a list of every third-party code library you implement in your application.

To use the CISA’s “list of ingredients” metaphor, your software bill of materials should at least mention everything that you can “buy off the shelf”—or download for free, in the case of open source components. 

What does a minimum-viable SBOM include?

The US National Telecommunications and Information Administration (NTIA) lays out the required baseline attributes that a software bill of materials must entail, including information on third-party code as well as metadata on the software bill of materials itself.

Required SBOM metadata

Your software bill of materials should include the following attributes describing itself:

• Author name: This is the person responsible for compiling the SBOM.
• Timestamp: This marks when the SBOM was published.

Required third-party code attributes

It should list all the third-party software you’ve built your application on, whether it’s paid or open source. For each of these software components, your software bill of materials should include:

• Component name: This is the name of the third-party code package as specified by the supplier.
• Supplier name: This credits the organization that supplied the third-party code (unless it’s already covered by the component name attribute).
• Version string: This specifies which version of this third-party library you’re using.
• Component relationship: This describes how the component fits into the entire software bill of materials. Your application has the “primary” relationship type, while the third-party components will have the “included in” relationship type. (Components may be included in other components.)
• Unique identifiers: This provides any information that further identifies the component, helping your SBOM readers look up the component in relevant databases.

Commonly used formats

As of September 2021, SPDX is an internationally recognized ISO standard for creating software bills of materials, and the format is widely supported in the world of software supply chain security. 

In addition, CycloneDX (from OWASP) is often used by organizations whose operations involve SBOM generation and consumption. Some organizations prefer CycloneDX for its specificity, which makes it much easier for machines to read SBOMs in CycloneDX—while others prefer the more generally accepted SPDX standard. 

How SBOMs help software supply chain security efforts 

A comprehensive software bill of materials brings a host of benefits to both customers and vendors. By creating this document (and keeping it up to date), you can improve how you manage your software supply chain, vulnerabilities, sales, procurement, and quality assurance.

When done well, an SBOM creates a shared understanding between customers and vendors, allowing both parties to respond to vulnerabilities together quickly.

Software customers benefit from transparency

Because an software bill of materials lists all the ingredients in a vendor’s application, customers can streamline their due diligence processes when selecting a vendor. Customers can compare SBOMs, check for vulnerabilities using the right software composition analysis (SCA) tool, and better manage risks involved in selecting vendors.

A good SBOM also allows customers to more easily stay compliant with software supply chain security regulations. The transparency provided in a software bill of materials means that customers can monitor their vendors’ SBOMs with their own SCA tools, making it much easier for them to know when they’re vulnerable.

Furthermore, it gives customers more focus when patching vulnerabilities. Because their security teams have a well-defined set of components to keep secure, they can more easily stay focused on patching known vulnerabilities.

Software vendors can streamline enterprise sales

As regulations surrounding software supply chain security come into play, software companies will face more and more compliance barriers when selling to regulated entities (or even when selling to companies who feed into regulated entities). Sales conversations with enterprise prospects will always involve some security concerns, and having a software bill of materials ready to present can cut down on valuable sales time—either by proving that you’re a compliant vendor sooner or by surfacing a dealbreaker early in the conversation.

How to create an SBOM

If you are generating a software bill of materials as a vendor, the NTIA has provided a thorough playbook for SBOM generation to get you started. You can expect to follow these basic steps in building your SBOM:

1. Make a list of third-party components implemented in your software. Your primary source of information for this step will be your own engineering team—but you can also use a software composition analysis (SCA) tool like Finite State to generate this list.
2. Gather the information required to fill out the baseline attributes listed above.
3. Import this component data into a structured SBOM format.
4. Validate: check that the format works and all the information is correctly structured. 
5. (Optional) Publish your software bill of materials so your customers and salespeople can reference it. 

Remember: You will need a software bill of materials for each version of your product—and every time you update one of your components, you will also need to update your SBOM.

How to obtain a software bill of materials from a vendor

If you’re required to obtain an SBOM from a vendor (or a hopeful vendor), you will need to follow these steps:

1. Request an up-to-date SBOM from your vendor. Your vendor may have this publicly available, but it’s always good to double-check that you’re dealing with the correct software bill of materials for the application you’re using.
2. Verify the SBOM by using your SCA tool—our customers tell us that Finite State is especially useful for double-checking this!

Remember: A single vendor may be managing many SBOMs. Not only does each software version require its own software bill of materials, but any custom builds will require their own SBOMs as well. A single vendor may have multiple SBOMs for the same product—and if they’re working with a large enterprise organization, they might even need several SBOMs for the same customer.

How to consume SBOMs in any format

As we’ve mentioned, the discipline of generating and consuming SBOMs is still immature. This means consuming it is a bit difficult today—most software bill of materials readers can only consume these documents if they were generated within the same system.

If you’re a software customer, we recommend using a system-agnostic SBOM reader. This will allow you to ingest SBOMs no matter what tool generated them. You could use a standalone reader, but an advanced SCA will take care of this for you.

Common software supply chain security concerns about SBOMs

Supply chain security regulations will make SBOMs a norm in regulated industries—but because this is a new discipline, it’s understandable that some vendors have raised concerns about generating and publishing them. However, the prevailing belief is that the benefits of a good software bill of materials far outweigh the risks.

We’ve listed a few commonly voiced concerns people have regarding software bills of materials below, as well as our thoughts on how to address these concerns. If these concerns come up in supply chain security conversations at work, these responses can help put the concerned parties at ease.

“An SBOM will tell hackers exactly where to attack us!”

Third-party vulnerabilities are the easiest way for hackers to infiltrate your otherwise secure system. Because an SBOM lists every single component and subcomponent used in your software, some are concerned that cybercriminals will simply target the weakest links in the supply chain.

However, most of the cybersecurity community agrees that the transparency an SBOM provides raises the accountability for both customers and vendors. Once a vulnerability is known, the whole supply chain can quickly patch it.

This level of transparency also incentivizes vendors to source third-party code from the most secure suppliers they can, which in turn motivates the producers of subcomponents and sub-subcomponents to increase their own levels of security.

As an analogy, imagine an application is like a bank, and an SBOM is like a blueprint. While a blueprint might make it easier for a team of thieves to pull off a daring heist, it will also make it much easier for the bank’s security team to keep the vault safe: they know which parts of the building are most vulnerable, and they can allocate their security resources accordingly.

“An SBOM will give away our trade secrets!”

Just like a prize-winning baker wouldn’t want to give away her secret chocolate chip cookie recipe, some software vendors wince at the idea of publishing their own list of ingredients. However, if your software truly is an original work, this shouldn’t be an issue.

Sharing your list of ingredients shouldn’t be the same as sharing your recipe. An SBOM doesn’t display your proprietary code, and it doesn’t detail how your third-party code is implemented within your application. Unless your application is just a reskin of several other companies’ products with no added value, you should have nothing to worry about on this front.

“An SBOM will take too much time and effort to maintain!”

Making an SBOM once is easy. Keeping your SBOMs up to date and organized can get complicated, however. This will take extra time.

However, generating and maintaining SBOMs is preventive work. Flossing your teeth takes a little extra time out of each day. Changing your car’s oil takes a few hours out of each year. But compared to the costs and pains associated with a root canal or an engine failure, the benefits outweigh the costs. Similarly, the time it takes to keep your SBOMs current shouldn’t come anywhere close to the costs of time, damages, and loss of trust associated with an otherwise avoidable breach.

We recommend simply making software bill of materials generation and maintenance part of your routine: product development teams should include an SBOM as an artifact with every new build. It might take a little while to get used to this practice, but in the end, it will be worth it.

(This becomes very easy using Finite State. You can generate a current software bill of materials document with the click of a button. Plus, our command line tool allows you to automate SBOM production—which means Finite State can automatically generate a new SBOM for you with every update!)

Create and verify SBOMs with Finite State

As governments and industries increase software supply chain security, software bills of material will become more and more common. It’s smart to get ahead of the game and begin learning to create and consume SBOMs now. A great place to get started is the NTIA’s SBOM resource library: this includes how-to guides, explainer whitepapers, and even a few use cases for reference. For a comprehensive understanding of what the future holds for SBOM and software supply chain security, you can explore our detailed predictions here.

If you’re already a Finite State customer, you can use our tools for free to generate your own SBOMs automatically—or import and export your suppliers’ SBOMs, even if you don’t have access to their code. 

Not a Finite State customer yet? Discover how our comprehensive Software Composition Analysis (SCA) suite can protect your software from third-party vulnerabilities. We monitor your code libraries, detect and patch vulnerabilities automatically, and streamline SBOM generation and consumption.

Ready to secure your software supply chain? Book a demo today and see how Finite State can strengthen your defenses in real time!