Software bill of materials (SBOM)

What is an SBOM?

An SBOM is a structured record of a product's components, the relationships between them, and the metadata that identifies each one without ambiguity. It answers one operational question: if a flaw is announced in component X, do we ship X, in which version, and where?

That question sounds trivial until a deadline forces you to answer it. A modern application is mostly code that someone else wrote and that your team never reviewed. An industry estimate cited on our call-path analysis page puts typical usage at 10% to 20% of imported code, so most of what you pull in never runs. The SBOM you generate is therefore long, mostly inert, and impossible to keep in anyone's head.

An SBOM is therefore only worth producing if something else reads it. A list of open-source dependencies sitting in a repository changes nothing. The same list, cross-referenced against a vulnerability feed and refreshed on every build, turns a disclosure into a work order. That refresh is the dividing line between a living inventory and a compliance artifact.

What an SBOM is not

Four things get confused often enough to be worth separating.

The distinction that costs teams the most is the first two. The document is an output; SCA is the engine. Buying the output without the engine leaves you with a snapshot that is wrong by the next commit.

Why SBOMs matter now

Three incidents turned a procurement checkbox into an incident-response tool and made component inventory a software supply chain security problem. Each exposed a different gap, and each gap now maps to a field in the current standard.

Log4Shell: when nobody could answer "do we use it?"

When Log4Shell (CVE-2021-44228) was disclosed in December 2021, the patch was available almost immediately. The bottleneck was not remediation. It was discovery. Log4j sat four and five levels deep inside build tools, agents and application servers that teams had never thought of as Java logging consumers.

Organizations with a current SBOM queried it and had a target list in minutes. Everyone else spent weeks grepping repositories and emailing vendors. That is why the 2026 Coverage element says an SBOM should list every component in the target software, including transitive dependencies, with no minimum depth. An inventory that stopped at direct dependencies would have missed Log4j in most of the places it was running.

SolarWinds: why hashes became two separate fields

The 2020 SolarWinds compromise worked because the malicious code arrived through a signed, official update. Nothing in the dependency list looked wrong. What was wrong was that the shipped artifact no longer matched what the build had produced.

An SBOM generated at build time gives you that baseline. If a component's cryptographic hash does not match the value recorded for it, the pipeline has grounds to reject the build before distribution. CISA now lists the hash value and the hash algorithm as two separate fields, precisely so the comparison can be automated rather than eyeballed. That pair is what turns an SBOM from a disclosure document into a control.

The 2025 npm compromise: the SBOM as triage

In September 2025, a phishing email against a single maintainer account led to malware reaching 18 widely used JavaScript packages with about 2.6 billion combined weekly downloads, among them debug, chalk and ansi-styles. The exposure window was hours. The only teams that could act inside it were the ones able to filter an existing SBOM by package name and version. Our write-up of the incident describes that move inside our platform: open the Packages table, filter by component name.

SBOM at Fluid Attacks

We generate the SBOM as a by-product of scanning, not as a separate exercise. The Fluid Attacks documentation states the principle plainly: "SCA tools can automatically generate a comprehensive SBOM, providing a detailed, standardized record of all components and their origins."

What we inventory, and from what

Our Software Composition Analysis reads lockfiles and manifests across 19 supported package managers, covering JavaScript, Python, Java, Kotlin, Ruby, Swift, PHP, Go, C#, Scala and Dart. Coverage moves: a September 2026 release added deterministic lockfile parsers for Yarn, pnpm and Bun.

Each entry is then matched against our own vulnerability catalog rather than a mirrored CVE feed. Weakness 448 in our database, "Use of software with malware", covers the case where "one or more dependencies used in the project contains code or components suspected of being compromised by malware or malicious behavior." It links to the requirements an auditor will ask about, which a raw feed cannot give you.

What it looks like in practice

The inventory is attached to a target of evaluation, which our platform documentation defines as follows: "A package ToE represents a third-party component on which the application depends."

The export itself is two clicks: "In Packages, click on Export SBOM and follow the prompts." The result is "available in the CycloneDX and SPDX formats."

The Packages section exports the inventory in two standardized formats.

Deterministic reachability, not probabilistic

Most of the value sits after the export. An SBOM tells you a flawed version is present; it does not tell you whether the flawed code can run. We answer that by tracing call paths, not by scoring likelihood. Our published comparisons show the difference against two SCA vendors.

Source: Fluid Attacks' public comparisons against Snyk and Black Duck, built from each provider's official product information.

A probabilistic verdict tells a developer a finding is probably irrelevant. A deterministic one tells them the function is never called from their entry points. Only the second survives a conversation with an auditor. As of October 2026, that verdict is also the seventh criterion in our organization priority configuration.

The limit we run into: The inventory maps the smaller share

Here is the part most vendor pages leave out. In our benchmark, the universe of 1,201 vulnerabilities broke down with 80% in the codebase, 13% in the backend, and the rest in dependencies and the frontend. Everything an SBOM can see lives in that last 7%, and it shares it with the frontend.

The detection numbers point the same way. Across that dataset, the automated tool that identified the highest percentage of vulnerabilities was our own scanner, at 22.7% recall with 99% precision; the strongest third-party tool reached 21.6% recall at 72% precision. A pentester working the same dataset found 1,076 of the 1,201 vulnerabilities: 89.6% recall at 100% precision. No inventory closes that gap, because the flaws that matter most are usually in business logic nobody imported.

The best automated recall was 22.7%; the pentester reached 89.6%.

That is an argument for generating the document, not against it. It is an argument against mistaking it for a security program. Teams that pair component inventory with manual testing cover both halves; those that buy only the first cover the half that was easiest to automate.

The practice that decides the rest: regenerate and gate

A document generated once is wrong by the next merge. The practice that makes the difference is regenerating on every build and enforcing a policy against the result. Our State of Attacks 2026 report, covering 1,119,396 vulnerabilities reported between January 1 and December 31, 2025, found that systems running our CI Gate reached a 72.2% remediation rate against 58% for systems without it. The inventory is the input; the gate is what gives it consequences.

Our guidance for the financial sector makes the same point: keep a detailed record of every component in use and scan it continuously.

Go deeper: our page on reachability analysis explains how call-path tracing filters a component list down to what is exploitable.

What goes in an SBOM: the 2026 minimum elements

In July 2026, CISA published the final Minimum Elements for a Software Bill of Materials, developed with the NSA, the FBI and fifteen international cybersecurity agencies. It replaces the 2021 NTIA baseline and the August 2025 public comment draft. The required data roughly doubled and now splits into two groups.

SBOM metadata

Metadata describes the document itself: who produced it, with which tool, at what point in the lifecycle, and in what format. The new fields are an author signature, a document version, the data format name and version, the tool name and version, and a generation context. That last one matters: a record built from source at compile time and one built by scanning a finished binary describe different things, and consumers are entitled to know which they got.

Component data

Component data describes the ingredients: Component Producer, Component Name, Component Version, Component Identifiers, Component Hash Value, Component Hash Algorithm, Component License and the dependency relationships between them. Every component should carry at least one common software identifier, a field that can also hold unique identifiers, commit hashes and intrinsic identifiers.

What changed from the 2021 baseline

The revision also separates what is genuinely unknown from what the author knows and is withholding, which lets a consumer tell a gap in the data from a commercial decision. If you certified a document against the 2021 list, assume it no longer qualifies.

Same idea, different product: both declare what is inside.

SBOM formats after the 2026 revision

CISA names two SBOM data formats as being in broad use. A third, SWID, was dropped from that list.

SWID tags, standardized as ISO/IEC 19770-2, remain in use for IT asset management. CISA dropped them from the named SBOM formats in 2026 on the grounds that SWID is not widely used and has too few tools behind it. The guidance still tells organizations to accept any widely used, interoperable and machine-processable format, so SWID is not forbidden — just no longer one of the two CISA points to.

If you are producing the SBOM for a security pipeline, the OWASP format is built for it and carries exploitability statements natively. If your driver is license compliance, the Linux Foundation one carries an ISO number, which still counts with some buyers. Emitting both costs almost nothing, and our platform does exactly that.

Regulations that require an SBOM

The document stopped being a recommendation several years ago.

Executive Order 14028 is the one that changed market behavior. It made the SBOM a condition of federal procurement, and the requirement propagated down supply chains with no federal exposure at all. The EU Cyber Resilience Act, which we covered when it was adopted, went further by attaching fines and market withdrawal to non-compliance.

Note what none of them ask. They require you to name your components, not to show that those components are sound. The CRA does not even require disclosure: its Annex II says only that if a manufacturer shares the document with users, it must say where to find it. An SBOM you can produce but not vouch for satisfies a reviewer and leaves the exposure untouched, which is why compliance and software supply chain security are not the same objective.

How to generate an SBOM with SCA

Generation is the easy part. Choosing a scanner that produces something trustworthy is not.

SCA resolves the dependency graph from lockfiles and manifests, matches each component against vulnerability data, and emits the SBOM in a standard format. Because it runs on every commit, the document stays current without anyone maintaining it by hand. Our DevSecOps tooling post describes the mechanic: as the scan inventories the open-source dependencies in your software, producing the SBOM is a formality.

Four criteria separate useful implementations from box-checking ones:

• Ecosystem coverage: a scanner that cannot parse your lockfile format will silently under-report. Check the package manager list against your stack, not against a marketing page.

• Full graph resolution: confirm the tool walks every level. CISA's Coverage element asks for it, and a scanner that reads only top-level manifests cannot produce a compliant SBOM.

• Vulnerability intelligence: a list of components is not a list of risks. Ask what the matching runs against, and whether the exploitability verdict is deterministic or inferred.

• Pipeline enforcement: generation without a policy gate produces a document nobody reads. Our supply chain analysis documentation covers how it connects to build-breaking policy.

The output then feeds everything else: our Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) cover the code the SBOM cannot see, and risk-based vulnerability management on a single platform is where findings get prioritized. Both our Essential and Advanced plans generate the document; the Advanced plan adds pentesters to the half automation misses.

Weakness 448 links a compromised dependency to requirements 155, 262 and 330.

Conclusions

An SBOM is an inventory, and an inventory is only as useful as the questions you can ask it. The 2026 revision raised the bar on what counts as a valid SBOM: every nested dependency, a common software identifier per component, a hash split into value and algorithm, a signed author, and two formats in broad use instead of three.

Meeting that bar is table stakes for selling software into the U.S. federal government or the European market. It is not a security strategy. Our benchmark puts 93% of real vulnerabilities outside the dependency layer an SBOM describes, and the best automated recall at 22.7% against a pentester's 89.6%. Generate the SBOM, regenerate it on every build, gate the pipeline on it, and then go test the part it cannot reach. The first three steps are a tooling decision. The fourth decides your actual exposure.

Frequently asked questions

Is an SBOM the same as SCA?

No. Software composition analysis is the process; the SBOM is one of its outputs. The scan resolves your dependency graph and matches components against vulnerability data. It is the standardized document that scan produces. You can hold one without running the other, but a file generated once and never refreshed stops reflecting your software within days.

Does an SBOM have to list transitive dependencies?

Yes, under the 2026 CISA Coverage element. The guidance says an inventory should include all components in the target software, including transitive dependencies, and states plainly that there is no minimum depth. That replaces the 2021 baseline, which covered top-level dependencies only. The reasoning comes from incidents like Log4Shell, where the vulnerable library was almost never a direct dependency.

How often should an SBOM be updated?

On every build. Dependencies change with every merge, and a stale SBOM gives false assurance. Regeneration alone is not enough either: in our State of Attacks 2026 data, systems enforcing a CI gate reached a 72.2% remediation rate versus 58% for those without one.

Can an SBOM find zero-day vulnerabilities?

No, and it is not meant to. It tells you what you have, not what is wrong with it. Its value appears the moment a flaw is disclosed: you query it, find every affected build, and start remediating while others are still searching. Discovery time is the variable it changes.

What is VEX and how does it relate to SBOMs?

VEX states whether a known vulnerability is actually exploitable in a given product. An SBOM might show you ship a flawed library; the companion document can state the flawed function is never reachable from your entry points. Used together, they cut the remediation queue down to what genuinely needs work.

Does Fluid Attacks generate SBOMs, and in which formats?

Yes, in CycloneDX and SPDX, from the Packages section of our platform. Our SCA resolves dependencies across 19 package managers, matches each component against our own weakness catalog, and determines exploitability deterministically across 14 languages. Both the Essential and Advanced plans include generation and export.

Know what you ship, and what it can reach

Our scanners inventory your dependencies on every commit and our pentesters test the code that inventory never describes. Start free trial · Contact us