What Is an SBOM? Software Bill of Materials Explained

An SBOM, or software bill of materials, is a machine-readable list of every component inside a piece of software, including each library, its version, who made it, and how the pieces depend on each other.

Its job is to answer one question quickly. Is the vulnerable thing in here? For a company with 20 to 1000 users, the useful follow-up is whether you'll ever produce an SBOM or only receive them, and that answer shapes how much of this lands on you, your vendors, or whoever runs your managed cybersecurity services. CISA's 2026 rules, final since July 29, 2026, now define what a usable one contains.

December 2021 is the easiest way to see why this exists. A flaw turned up in Log4j, a small open-source library that records what an application is doing, and Log4j was tucked inside thousands of commercial products. Apache shipped fixed versions within days. Finding out whether your ERP, your firewall console, or your badge system had Log4j somewhere inside took far longer, because very few vendors could say. Some still can't.

The Cyber Safety Review Board, a federal panel that investigates major cyber incidents, studied the response afterward. Its July 2022 report recorded one federal cabinet department spending 33,000 hours on Log4j, and it called the flaw endemic, meaning vulnerable copies would keep turning up in systems for a decade or more. A good share of those hours went to hunting for the component rather than fixing it.

With an SBOM, that hunt becomes a lookup.

What Is an SBOM, in Plain Terms?

Software's parts list. That's an SBOM at heart. Each component gets a line with its name, version, maker, and what it depends on, written in a format software tools can read and search.

If you run a manufacturing floor, you already know the idea. The bill of materials for a circuit board lists every resistor, capacitor, and chip down to the supplier, so when a supplier recalls a part you can tell within the hour which finished boards contain it. Software has always had the same structure. It just kept it out of sight.

CISA's SBOM guidance calls it a nested inventory, and nested is the word that matters. Your accounting package might include a reporting module, the reporting module includes a logging library, and that logging library turns out to be Log4j, which you'd never see on an invoice, an install screen, or anywhere in the vendor's documentation. Developers call these buried pieces transitive dependencies, components pulled in by other components rather than chosen directly. They're why nobody could answer the Log4j question from memory. Not even the vendors.

Here's one line from an SBOM for a vulnerable build of Log4j, translated out of the file format into plain columns.

That version number does the heavy lifting. Log4Shell, the name the December 2021 flaw picked up, affected releases up through 2.14.1, so any tool comparing this row against public vulnerability data flags it in seconds. One row. No phone calls.

What Goes Into an SBOM Under CISA's 2026 Rules?

CISA's 2026 Minimum Elements require two groups of data. One group describes the SBOM itself, such as who made it, when, and with which tool. The other describes each component, and now includes a hash and a license.

Published on July 29, 2026, the 2026 Minimum Elements for a Software Bill of Materials replaces the list the NTIA published in 2021. That older list had seven fields. Supplier, component name, version, a unique identifier, dependency relationship, the author of the SBOM, and a timestamp. A sensible floor for a year when hardly any tools could produce an SBOM at all.

Two of the additions carry most of the weight. The hash is a fingerprint of the actual file, so a tampered copy with the right name and the right version no longer slips through. Generation context records when in the software's life the list was made, which sounds like trivia until you compare an SBOM built from source code with one built from the finished installer and find they don't match. They rarely do.

Your lawyers will care most about the license field. Black Duck's 2026 OSSRA report found license conflicts in 68% of the codebases it audited, up from 56% a year earlier. Not a security problem, exactly. Still a problem.

CISA also notes that the elements apply to all software, while some types, artificial intelligence and software as a service among them, may need more than the minimum.

Why Did SBOMs Go From Nice-to-Have to Required?

Start with what's inside commercial software now. The same OSSRA report audited 947 codebases across 17 industries and found open source in 98% of them, and the average number of vulnerabilities per codebase more than doubled, up 107% in a year. Nearly every product you license is partly written by strangers. Generous, careful strangers, usually. Still strangers.

Executive Order 14028, signed in May 2021, pushed federal agencies to ask software sellers for SBOMs. Log4j arrived seven months later and made the argument better than any policy memo could. Then 2026 rearranged the picture again.

Table sources: OMB M-26-05, the European Commission's Cyber Resilience Act page, and FDA's cybersecurity guidance for medical devices.

Read those dates side by side and something odd shows up. Washington loosened its grip this year. Brussels tightened. And the EU's reporting clock started on September 11, 2026. The CRA also says, in Recital 77 of the regulation, that manufacturers shouldn't be obliged to make the SBOM public. So it exists for regulators and, if you ask, for customers.

None of these rules reaches a company that only buys software. Its vendors are covered. And the pressure rolls downhill.

Do You Produce SBOMs or Consume Them?

A company that buys software and builds none of it is an SBOM consumer. It asks vendors for SBOMs and uses them. A company that ships software, firmware (the software built into a device), or connected devices is a producer and has to create them.

That split decides almost everything else in this article, so it's worth being honest about which side you're on. You're a producer if any of these sound familiar.

• A connected medical device with software on board. That's a cyber device under Section 524B, and the SBOM goes into your FDA submission. The IT and security side of running that kind of company is covered on our page for medical device manufacturers.
• Firmware in anything you sell into Europe, whether it's a motor controller, a sensor, or a piece of test equipment.
• Federal software sales, but only if the contracting officer asks. After M-26-05, some will and some won't.
• Your biggest customer's supplier agreement. Read it. An SBOM clause can show up there long before any regulation reaches you.

Everyone else is a consumer. A distributor running NetSuite and 40 cloud apps. A law firm living in iManage. A 300-person manufacturer whose only homegrown code is an Excel macro somebody wrote in 2014 and nobody dares touch.

If that's you, and your stack is mostly cloud apps, you don't need an SBOM program. No new tooling, no repository, no job title. You need a software inventory you actually trust, plus the habit of asking your five or six most important vendors for their SBOMs at renewal, meaning the ERP, the accounting system, the firewall, and whatever else would stop the business if it went dark for a week. A spreadsheet and one paragraph in the procurement checklist. That's the whole thing.

Producers have real work ahead of them, and it usually starts as a question about the build pipeline, the automated process that compiles and packages the product, for the engineering team rather than IT, because the SBOM has to come out of that same process. Where does the list get generated, which of the six SBOM types does your regulator expect, and who signs it?

SPDX, CycloneDX, and VEX

SBOMs come in two standard formats. SPDX, maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both carry the same core data, and decent tools convert between them, so the format rarely decides anything.

SPDX started life as a way to track software licenses. CycloneDX came out of the security world. You'll hear engineers argue about which is better. Let them. As a buyer, accept either, as long as it's the machine-readable version and not a PDF.

VEX is the more interesting companion. Short for Vulnerability Exploitability eXchange, it's a statement from the vendor saying whether a vulnerability in one of their components can actually be used against their product. A scanner reading an SBOM flags every known issue in every listed component, and plenty of those issues live in code the product never calls, so without some help your team ends up chasing alerts that were never going to matter. CISA's minimum requirements for VEX give the vendor four ways to answer.

• Not affected. The component is present, the flaw can't be reached, and the vendor has to say why.
• Affected, which means act. Usually with a fix or a workaround attached.
• Fixed? Then the statement names the version where it's resolved.
• Under investigation. Fine for a week. Not for a quarter.

Without VEX, an SBOM is a smoke alarm that goes off for toast. Every morning. You stop listening by February.

What an SBOM Won't Tell You

It's a list, remember. Lists are only as good as the moment they were made and the tool that made them, and a handful of limits catch people out.

• It isn't a vulnerability scan. Software composition analysis, or SCA, is the scanning, and the SBOM is the list that scanning produces or reads. The list sits still while new vulnerabilities get published against old versions every week, so something has to keep matching the two. That matching is part of vulnerability management, and it's where an SBOM earns its keep.
• It's a snapshot, and there are six kinds. CISA's SBOM types document sorts them by when the list was made, from design through source, build, analyzed, deployed, and runtime. A build SBOM describes what went into the installer. A runtime SBOM describes what actually loaded when the program ran. Ask which one you're getting.
• Depth varies. The CRA's floor is top-level dependencies, the components a product pulls in directly, and Log4j regularly sat a level or two below that.
• Cloud apps are awkward. The code runs on the vendor's servers and changes constantly. Don't expect a SaaS SBOM unless you ask for one, and don't be surprised if the answer is a security page instead.
• It can't see a zero-day vulnerability. If nobody has published the flaw yet, no list can flag it.

None of that makes an SBOM less useful. It makes it one layer, sitting alongside monitoring and patching rather than replacing either.

How Do You Ask a Vendor for One?

Ask plainly, as an inventory request tied to a product and version you run. Specific questions get usable files. Vague requests get a marketing PDF.

Our guide to software supply chain security covers when to ask, at purchase and at every renewal. The request itself goes better with a little structure. Leave regulation out of the first email. Mention the CRA or a federal memo and the request tends to land with the vendor's legal team, where it can sit for weeks. Something like we'd like the SBOM for the version of your product we run, so we can check our exposure when new vulnerabilities are announced usually reaches an engineer instead.

Then ask the follow-ups.

• Which format is it in? SPDX or CycloneDX, in JSON or XML, is what you want.
• How deep does it go, top-level only or every nested component?
• When does it get refreshed? Every release is the right answer. Once a year isn't.
• Do you publish VEX statements, and if so, where would we find them the morning a big vulnerability hits and our scanner lights up?
• What's the end-of-support date for the version we're on? A component past end of support gets no more fixes, however tidy the list looks.

Keep the files with the rest of your supplier records. If you already run vendor risk management for manufacturers or any kind of supplier review, the SBOM belongs in the same folder as the SOC 2 report and the insurance certificate, ready for the day a CISA alert names a component. An SBOM nobody ever checks against an alert is just paperwork with a file extension.