A software bill of materials is a list of every component, library, and dependency that goes into a piece of software

Think of it the way a food label lists ingredients. When you buy a jar of pasta sauce, the label tells you what's actually in it — tomatoes, garlic, salt, preservatives, and so on. A software bill of materials (often called a SBOM) does the same thing for software. It documents every open-source library, commercial component, and code dependency that a developer used to build an application or system.

A SBOM includes the name of each component, its version number, and often the license it comes under. For example, a web application might list that it uses version 18.2.0 of the React library, version 4.1.1 of a security package, and version 2.3 of a database connector. The list can be short for a simple program or contain hundreds of entries for complex software.

Companies create SBOMs because they need to know what's actually running on their systems. When a security flaw is discovered in a popular library, organizations can quickly check their SBOM to see if they're affected. Without one, a company might not realize for months that a vulnerability exists in code they're using.

Key Takeaways

  • A software bill of materials is a complete list of every component and library used to build a piece of software, similar to an ingredient list on food packaging.
  • Each entry in a SBOM includes the component name, version number, and usually the license type so organizations know what they're legally allowed to do with the software.
  • Companies use SBOMs to track security vulnerabilities, since they can quickly check whether a newly discovered flaw affects any of their systems.
  • The U.S. government now requires federal contractors to provide SBOMs for software they deliver, which has pushed the practice into wider use across the industry.

Why organizations need to know what's inside their software

Most modern software is not written from scratch. Developers build on top of existing libraries and frameworks that other people have already created. A single application might depend on dozens or hundreds of these components. Without a SBOM, nobody at the company actually knows what code is running.

This matters most when a security problem surfaces. In 2021, a critical flaw was discovered in the Log4j library, a piece of code used in millions of applications worldwide. Organizations that had a SBOM could immediately search it and find out whether they were affected. Companies without one had to manually hunt through their systems, and many took weeks to figure out what they were using.

A SBOM also helps with legal compliance. Open-source software comes with different licenses — some allow commercial use, some require you to share your own code if you use them, and some have other restrictions. A SBOM shows which licenses apply to each component, so a company's legal team can verify they're using software the way they're allowed to.

What information appears in a software bill of materials

A basic SBOM contains the name and version of each component. Version numbers matter because a security fix might be available in version 2.5 but not in version 2.3. If your SBOM says you're using version 2.3, you know you need to update.

Most SBOMs also include the license for each component. This tells you whether you can use it commercially, whether you have to publish your own source code if you use it, and what restrictions apply. Some also note where the component came from — whether it's from a public repository like GitHub, a commercial vendor, or an internal team.

Advanced SBOMs may include additional details like the component's release date, known vulnerabilities, or the hash of the actual code (a unique fingerprint that proves you're using the exact version you claim to be). The format and depth depend on what the organization needs and what tools they use to create the SBOM.

How companies create and maintain a software bill of materials

Most organizations use automated tools to generate SBOMs rather than creating them by hand. A developer runs a scanning tool on their codebase, and the tool reads through the code to find all the dependencies and libraries. The tool then outputs a list in a standard format.

Common formats include SPDX (Software Package Data Exchange) and CycloneDX. These are standardized ways of writing down the information so that different tools and organizations can read and understand each other's SBOMs. Using a standard format means you can take a SBOM from one vendor and feed it into your own security scanning tools.

Keeping a SBOM current is an ongoing task. Every time a developer adds a new library or updates an existing one, the SBOM needs to be regenerated. Many organizations run automated scans regularly — sometimes daily or weekly — to catch changes and make sure the SBOM stays accurate.

The difference between a SBOM and a vulnerability scan

A SBOM is a snapshot of what's in your software. A vulnerability scan is a check to see if any of those components have known security problems. You need both. The SBOM tells you what you have; the vulnerability scan tells you what's wrong with it.

Think of it this way: a SBOM is like a list of all the ingredients in your kitchen. A vulnerability scan is like checking each ingredient to see if any of them have been recalled. You can't do the second without the first — you need to know what you have before you can check whether it's safe.

Some tools combine both functions. They generate a SBOM and then automatically cross-reference it against databases of known vulnerabilities. This gives you a report that says "you're using component X version 2.3, and there's a critical flaw in versions 2.0 through 2.4, so you need to update."

Why the U.S. government started requiring SBOMs

In 2021, the U.S. government issued an executive order requiring federal contractors to provide a SBOM for any software they deliver to government agencies. The reasoning was straightforward: if the government is going to use software to run critical systems, it needs to know what's actually in that software and whether it contains components with known vulnerabilities.

This requirement has pushed SBOMs into wider use across the private sector. Many large companies now require their vendors to provide SBOMs, and some industries like healthcare and finance have started making them standard practice. Even companies that don't work with the government often create SBOMs because their customers expect them.

The requirement applies to software delivered to federal agencies, not to all software everywhere. However, the practice has become common enough that many organizations create SBOMs for all their software, not just what they sell to the government.

What to do if you need a SBOM from a vendor

If you're buying software from a vendor and you need a SBOM, ask for it directly. Many vendors now have processes in place to generate and deliver SBOMs. Some provide them automatically; others require you to request one.

When you receive a SBOM, check that it's in a format your tools can read — SPDX and CycloneDX are the most common. Verify that it includes version numbers for each component, since a list without versions is not very useful. If the SBOM is missing important information, ask the vendor for clarification.

Once you have the SBOM, feed it into your vulnerability scanning tools so you can see whether any of the components have known security problems. This is the whole point of getting the SBOM in the first place — to know what you have so you can check whether it's safe.

Frequently Asked Questions

Do I need a SBOM if I only use commercial software?

Not necessarily, unless you're a federal contractor or your industry requires it. However, commercial software also contains open-source components, so a SBOM can still be useful for tracking vulnerabilities. If you're concerned about what's in your software, asking your vendor for a SBOM is reasonable.

What happens if a SBOM is incomplete or inaccurate?

An incomplete SBOM is less useful but still better than nothing. You might miss a vulnerability that affects a component the SBOM doesn't list. If you discover your SBOM is inaccurate, regenerate it using your scanning tools and update your records. Going forward, run scans regularly to catch changes.

Can I create a SBOM for software I didn't write myself?

You can scan software you own and use to generate a SBOM of what it contains. However, you won't have the same level of detail as the original developer would have. For accurate SBOMs, it's best to get them from whoever built the software.

Is a SBOM the same as open-source disclosure?

Not quite. A SBOM lists all components, both open-source and commercial. Open-source disclosure typically refers to telling users which open-source licenses apply to software you're distributing. A SBOM is broader and includes proprietary components too.

How often should I update my SBOMs?

Update your SBOM whenever your software changes — when you add a library, update a dependency, or release a new version. Many organizations run automated scans weekly or daily to catch changes. At minimum, regenerate your SBOM before each release to production.