What Is a Software Bill of Materials? A Guide for Software Buyers

Imagine you're back in December 2021. A vulnerability has just been discovered in a piece of code called Log4j — a small logging tool so widely used that it was quietly running inside thousands of software products around the world, most of which had no idea it was there. The moment the vulnerability is made public, the question lands on your desk: which of the software products you use are affected?

You call your vendors. Most can't answer quickly. Some can't answer at all — not because they're hiding something, but because they just don't have a current inventory of what's actually inside the software. Log4j could be in any of your systems. Or none of them. You have no way to know because neither do your vendors.

That's the problem a software bill of materials — an SBOM — exists to solve.

What is a software bill of materials?

When you order a new furniture set from IKEA, the box comes with a parts list. Every screw, every bracket, and every dowel is documented so you can check that you received all the necessary bits and pieces.

An SBOM is basically a parts list for software. It's a structured document that catalogs every component: the open-source libraries, the third-party packages, the component names, version numbers, and license information, as well as where each piece originated. It also captures transitive dependencies — the packages that your vendor's components rely on in turn, which come along for the ride even if you never interact with them.

These nested layers are where risks tend to hide, and an SBOM makes them visible. If something in that list has a known flaw, you can take proactive measures before it breaks or causes issues.

Why buyers are being asked about SBOMs now

SBOMs have been a concept in software development circles for years, but they've recently crossed over into procurement, legal, and compliance conversations. Their value as early warning systems and diagnostic tools has led to regulatory pressure and changes in enterprise buying behavior.

That regulatory pressure is now written into law. DORA, NIS2, and the EU Cyber Resilience Act all include requirements around software transparency and supply chain risk management — pushing organizations to document what software they depend on, what's inside it, and what happens if something in it fails. An SBOM is the mechanism that makes that documentation possible.

The private sector followed. Large organizations are now asking vendors for SBOMs alongside SOC 2 reports, penetration test results, and security questionnaires — treating component transparency as a baseline contractual requirement rather than a nice-to-have.

Both shifts were accelerated by a wave of supply chain attacks that made the underlying risk impossible to dismiss. The SolarWinds breach, Log4Shell, and the XZ Utils backdoor — attacks that collectively compromised tens of thousands of organizations and, in some cases, went undetected for years — moved software component visibility from a developer concern to a board-level one. Each attack exploited the same blind spot: organizations running software they couldn't see inside of.

» Take a look at why supply chain attacks are causing more regulatory pushback. 

What you can do with an SBOM

Compliance and regulatory pressure might be what's pushing SBOMs into contracts, but the organizations getting real value from them are treating them as operational tools. It can completely change how you address risk:

• Respond to vulnerabilities faster. When a new CVE drops (a publicly cataloged security flaw, assigned a unique ID and severity score), you can run the SBOM through a vulnerability scanner to cross-reference your vendor's component list against databases of known flaws. That turns a potential week-long audit into an hour's work.

• Catch license issues before they become legal problems. Open-source components carry license obligations. Some restrict commercial use, some require you to publish modifications. An SBOM surfaces those obligations so you can know if you're potentially violating any before an external audit holds you liable.

• Ask better questions during vendor due diligence. An SBOM shows how heavily a vendor's product depends on third-party components with no direct support relationship. That's a risk signal you won't get without the list.

• Build a more realistic continuity plan. Knowing what went into the software gives you a clearer starting point for what recovery protocols you would need to have in place if a vendor suddenly failed or stopped support.

The shift in how you think about vendor risk is significant. An SBOM moves you from reactive — waiting for a vendor to tell you about a problem — to informed, with a clear picture of your exposure before anything goes wrong.

What an SBOM doesn't do

It's worth being upfront about the limits of what an SBOM gives you. While an SBOM might sound like the ideal solution to software risk, it falls short.

In the end, an SBOM is just a list of components. It can tell you what went into building the software: which libraries were used, which versions, and where they came from. That information is genuinely valuable for vulnerability management and due diligence, and it gives you a real head start on disaster preparation. But knowing the composition of a piece of software is different from having access to those specific components.

If your vendor goes insolvent, gets acquired, or discontinues the product, an SBOM does nothing to keep your operations running. You can see what used to be in the box — every screw, every bracket — but the contents are gone. You can't rebuild from a list. You can't hand a list to a development team and ask them to somehow source the materials themselves and maintain your software. 

So you can prepare with it, but when you're actively busy with a recovery, you need more. This is where software escrow comes in. It captures complete copies of all those components and keeps them safe and up to date until the moment you need them. If your vendor ever does disappear, you get your hands on the components to rebuild it all from scratch. 

What to ask your vendor when requesting an SBOM

Asking for an SBOM is straightforward. Getting one that's actually useful is where most buyers run into trouble. There's a significant difference between a well-maintained, current document in a recognized format and a spreadsheet that was generated once at launch and never touched again. Here's what to look out for:

1. Format: Ask for CycloneDX or SPDX by name. These are the two established industry standards, and either can be fed into a scanner or shared with an auditor. A custom export in an undocumented format isn't useful.

2. Update frequency: A one-time SBOM is already stale the moment your vendor ships an update. Ask them to produce a fresh one with every release.

3. Completeness: Ask whether it covers transitive dependencies — the full dependency tree, not just the top-level components. That's what carries most of the risk.

How a vendor responds to these questions can also raise some red flags. A vendor with mature internal processes will comply without hesitation. If a vendor becomes defensive, offers vague reassurances, or tries to convince you that you don't need it, you'll be better off going with an alternative.

When a vendor can't or won't share an SBOM

Some vendors won't produce an SBOM. Some don't have the internal processes to generate one. Whatever the reason might be, you're left with the same exposure: critical software running in your environment with no visibility into what's inside it and no documented plan for what happens if the vendor relationship ends.

This is when a software escrow should be a non-negotiable. It's the only way to protect yourself when transparency isn't available — and it addresses the gap that an SBOM, even a good one, can't close on its own.

When you set up escrow, the vendor deposits their source code, data, and documentation — including build instructions — into a secure, encrypted vault managed by a neutral third party. Where an SBOM is the IKEA parts list, software escrow is the box with all the components and assembly instructions. Plus, with added verification, you can put the deposits through build tests to make sure you'll have a working system when you need to recover. 

Take action against your vendor risk

An SBOM is where vendor risk management starts. Ask for one, check that it's in a recognized format, and make sure it covers the full dependency tree and is kept current with every release.

The next step is securing your access to those elements, so that you can rebuild and keep your systems running if something goes wrong.

» Not sure whether an SBOM is enough for your vendor risk strategy? Book a free consultation, and we'll help you work out where the gaps are.