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 you would think of a recipe or an ingredient list on food packaging. When you buy a jar of pasta sauce, the label tells you what is actually in the jar — tomatoes, garlic, oil, salt, and so on. A software bill of materials (often shortened to SBOM) does the same thing for software. It names every piece of code, open-source library, commercial tool, and third-party component that a developer used to build an process or system.

Most modern software is not written from scratch. Developers use existing libraries and frameworks — pre-written code that solves common problems — to build faster and avoid reinventing the wheel. An SBOM documents all of those pieces so that anyone who receives the software knows exactly what is inside it.

Key Takeaways

  • An SBOM is a complete list of every component and library used to build a piece of software, similar to an ingredient list on food.
  • Companies create SBOMs so they can track security vulnerabilities in the components they use and fix them quickly.
  • An SBOM typically includes the name of each component, its version number, and who created it.
  • Some governments and large organizations now require vendors to provide an SBOM before they will buy or use their software.

Why companies create software bills of materials

The main reason is security. When a vulnerability — a weakness that hackers can exploit — is discovered in a popular library, the people who maintain that library release a fix. But if you do not know that your software uses that library, you cannot know that you need to update it. An SBOM lets a company quickly search through all the software it uses and find which products contain the vulnerable component.

Without an SBOM, a company might not realize for months that one of its applications contains a dangerous flaw. With one, the security team can check the list, see the problem, and push out a fix in days. This is especially important for large organizations that use dozens or hundreds of software products from different vendors.

A second reason is legal and regulatory. Some industries — healthcare, finance, government — have rules about what software they can use and what they need to know about it. An SBOM helps prove that a piece of software does not contain components from countries under trade restrictions, or that it does not use unlicensed code, or that it meets other compliance requirements.

What information an SBOM actually contains

An SBOM is typically a structured document — often in a format called JSON or XML that computers can read easily. It lists each component with several pieces of information: the name of the component, the version number, who created or maintains it, and often a unique identifier that makes it straightforward to look up in security databases.

For example, an SBOM for a web process might list that it uses version 3.2.1 of a library called "Log4j" created by the Apache Software Foundation. If a security researcher later discovers a vulnerability in Log4j version 3.2.1, the company can search its SBOM, see that it uses that exact version, and know it needs to update.

Some SBOMs also include license information — which open-source license each component uses — so the company knows whether it is legally allowed to use that component in its product, and whether it needs to share its own source code publicly as a result.

Who requires software bills of materials

For many years, SBOMs were optional and uncommon. In recent years, that has changed. The U.S. government now requires federal contractors to provide an SBOM for any software they sell to the government. Large organizations like banks and hospitals increasingly ask their software vendors for one before they buy.

Some open-source projects have started publishing SBOMs as standard practice, even when not required, because it builds trust with users. If you read an open-source tool and it comes with an SBOM, you can see exactly what is in it and whether any of those components have known security problems.

How an SBOM differs from a privacy policy

A privacy policy tells you what a company does with your personal data. An SBOM tells you what code is inside the software itself. They answer completely different questions. You might read a privacy policy to understand whether an app sells your location data. You would read an SBOM to find out whether the app uses a library with a known security flaw.

An SBOM is also different from a changelog, which is a list of features and fixes that changed in each new version of software. A changelog tells you what the developers added or improved. An SBOM tells you what components they used to build it.

How to find an SBOM if you need one

If you are buying software for a business and want to see its SBOM, ask the vendor directly. Many companies now publish SBOMs on their website or in their documentation. If a vendor cannot or will not provide one, that is a signal that they may not be tracking their own components carefully — which is a security risk.

For open-source software, check the project's repository on GitHub or similar platforms. Many projects now include an SBOM file in the root directory of the code. If it is not there, you can sometimes generate one yourself using free tools designed for that purpose, though the result will only be as accurate as the tool and your knowledge of what the software uses.

The difference between an SBOM and a vulnerability scan

An SBOM is a snapshot — a list of what is in the software at a particular moment. A vulnerability scan is an active check that looks at that list and compares it against known security problems. You need both. The SBOM tells you what components you have. The scan tells you which of those components have known flaws.

Think of it this way: an SBOM is like a list of ingredients in your pantry. A vulnerability scan is like checking whether any of those ingredients have been recalled. You cannot do the second without the first.

Frequently Asked Questions

Do I need an SBOM for software I use at home?

Not for personal use. SBOMs are most useful for organizations that manage many software products and need to track security risks across all of them. If you use a single app on your phone or computer, the app store or vendor handles security updates for you automatically.

Can I create an SBOM for software I already own?

Yes, using automated tools that scan the software and list its components. The result will not be as accurate as one created by the original developers, but it is better than nothing if the vendor will not provide one. Tools like SPDX and CycloneDX are designed for this purpose.

Does an SBOM tell me if software is safe to use?

An SBOM tells you what is inside the software. Whether it is safe depends on whether any of those components have known security problems, which you would need to check separately using a vulnerability database or security scan.

Why do some companies keep their SBOM secret?

Some vendors worry that publishing a list of components makes it easier for hackers to find vulnerabilities. In practice, this is not how security works — hackers find vulnerabilities through research and testing, not by reading ingredient lists. Transparency about components is generally considered a security strength, not a weakness.