An SBOM is an ingredients list, not a safety check
What goes into a software bill of materials, what having one actually buys you, and the question it still cannot answer.
The fix for Log4Shell, a flaw in the Java logging library Log4j, was out in days. CISA, the US Cybersecurity and Infrastructure Security Agency, published an advisory alongside it. That advisory, AA21-356A, is built around the other problem: finding the library. It tells responders that knowing where Log4j exists in their environment is what protects their networks, and to assume all versions of Java and Log4j are vulnerable and include them in the inventory.
CVE-2021-44228 affected Log4j 2.0-beta9 through 2.14.1, a CVE being an entry in the public Common Vulnerabilities and Exposures catalogue, which gives each known flaw a permanent id.
The version range was narrow and the patch came in days. The searching took months.
A software bill of materials turns that search into a query.
CISA describes an SBOM as "a nested inventory, a list of ingredients that make up software components": one machine-readable file per thing you ship, listing every dependency inside an application, image or binary, with its version, licence and producer.
Not every question is a search
XZ Utils, a data compression library, is the other shape of problem.
CVE-2024-3094, disclosed on 29 March 2024, was a deliberate backdoor planted in the upstream project's own releases, versions 5.6.0 and 5.6.1; CISA's advice was to downgrade to something uncompromised, such as 5.4.6 Stable.
The question was binary: did any build of ours ever pull 5.6.0 or 5.6.1? A dated SBOM per release answers that a year on.
A scan of today's systems does not, because the bad version can be gone from there and still sitting inside an image a customer runs.
Your dependency manifests do not already contain this
A package.json records what you asked for, at what version range. What you got is in the
lockfile, package-lock.json, the generated file pinning the exact resolved version of every
package, including the ones you never asked for. Those are transitive dependencies: a dependency
of a dependency, which arrived because something you did want needed it.
In a container image a third layer sits under both, described by no lockfile: the distribution packages the base image brought.
Black Duck's 2026 Open Source Security and Risk Analysis report examined 947 commercial codebases across 17 industries and found open source in 98% of them; 87% contained a known vulnerability and 92% a component four or more years out of date.
The second job is licences
The same study found licence conflicts in 68% of codebases, up from 56% the year before, its largest single-year jump. None of that is a security problem.
Copyleft is a licence condition requiring anyone who distributes the software to pass the same freedoms on, which in practice means shipping source. Distribution is the trigger.
The GNU General Public License version 3, the GPLv3, leaves a gap there: running a service is not distributing a binary, so an operator who never ships one owes nothing.
The Affero variant, the AGPL, closes the gap by making it a trigger when users interact with the software over a network. That network case is what the Free Software Foundation's account of the AGPLv3 is written around.
The obligation is conditional both ways: an AGPL library in an internal tool nobody outside can reach triggers nothing, and "we never shipped a binary" is no defence for a public web service.
What has to be in one changed in July
The field list most articles quote is out of date.
On 29 July 2026, CISA, the NSA, the FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the minimum elements the National Telecommunications and Information Administration published in 2021. It adds ten required elements, renames others, and covers all software, including open source, AI software and SaaS.
The renames are what you now have to search for. Supplier Name is now Component Producer, which separates the original producer from whoever handed you the component.
Unique Identifiers is now Component Identifiers, and it demands at least one machine-processable
identifier. That means a PURL or a CPE. A PURL, or Package URL, writes a package's identity as
one string such as pkg:npm/lodash@4.17.21.
A CPE is the older Common Platform Enumeration scheme, the one the US National Vulnerability Database, the NVD, uses to match flaws to products.
The additions are about checking. Component Hash Value and Component Hash Algorithm let a reader confirm a component is the one named. SBOM Author Signature lets them confirm the file is the one your build produced.
SBOM Tool Name and SBOM Generation Context name the tool that wrote the file and how it was run, which is what tells a reader how much that tool probably missed.
An ingredients list nobody can check no longer counts as one.
Two formats, and the version your tool actually writes
SPDX and CycloneDX are the ones to choose between.
SPDX, Software Package Data Exchange, began at the Linux Foundation as a licence-compliance format and is an ISO standard, with ISO/IEC 5962:2021 standardising SPDX 2.2.1 and the spec line now at 3.0.
CycloneDX began at OWASP, the Open Worldwide Application Security Project, as a security format, is standardised as ECMA-424, and is at 1.7. SPDX's licence-first field set and CycloneDX's security-first field set each get a post of their own.
Standardise on one rather than a scanner's proprietary export, and keep the spec version separate from the tool version.
Anchore's output-format guide lists what its own generator can emit: Syft v1.51.1, the current release, writes CycloneDX JSON at 1.2 through 1.6 and SPDX JSON at 2.2 or 2.3, defaulting to 1.6 and 2.3. Those are the latest versions Syft supports, not the latest the standards have reached.
Pin the spec version explicitly, as generating an SBOM from a container image does.
Signing is what makes someone else's SBOM worth reading
An SBOM that arrives as a JSON file is a claim by whoever sent it, and nothing in it resists editing. Signing attaches cryptographic proof that a file came from you and has not been altered since.
An attestation is one step richer: a signed statement about a named artifact, carrying a typed claim rather than a bare seal.
Sigstore is the public signing infrastructure for that, and Cosign is its command-line tool. Both support keyless signing.
Instead of guarding a private key for years, the CI/CD pipeline that builds and ships your code on every push gets a short-lived certificate issued against its own identity.
The larger goal these pieces serve is provenance: the verifiable record of where an artifact came from and how it was built.
A signed SBOM attestation is one part of it, and the claim it carries is what is inside the artifact, not how the artifact was built.
Generate one per build and store it beside the image, in an OCI registry: the standard image store defined by the Open Container Initiative, which Docker Hub, GitHub's GHCR and Amazon's ECR all implement.
In the exchange below, watch the order: verification happens before the scan, and the vulnerability data the scan needs comes from outside the picture.
Who actually requires one
Do not take US Executive Order 14028 into a procurement conversation in 2026. The federal position moved the other way. In January 2026 the White House Office of Management and Budget issued Memorandum M-26-05. It rescinded M-22-18 and M-23-16, the memos that had required standardised vendor self-attestation, and left agencies free to choose whether to require SBOMs from their vendors at all.
Executive Order 14306, in June 2025, had already removed EO 14144's requirement that vendors supply them. EO 14028 has not been rescinded; its implementing guidance is gone.
The obligation that binds is European.
The EU Cyber Resilience Act, at Annex I Part II point 1, requires manufacturers to document their products' components in an SBOM, in a commonly used machine-readable format, covering at least the top-level dependencies. It need not be published, but it has to sit in the technical documentation, and the manufacturer has to produce it for market surveillance authorities.
Vulnerability and incident reporting obligations start on 11 September 2026. The SBOM and technical-documentation obligations apply from 11 December 2027. Top-level dependencies is the floor there, not the target.
Where the ingredients list stops
An inventory tells you what you have, not whether it is safe. Two things sit in between.
The severity number is often missing
The severity number you sort by is frequently missing.
Sonatype's 2026 State of the Software Supply Chain reports that nearly 65% of open source CVEs have no NVD-assigned CVSS score, CVSS being the 0 to 10 Common Vulnerability Scoring System rating attached to a vulnerability.
When it is absent your scanner is guessing. The same report puts 5 to 15% of components in enterprise dependency graphs at end-of-life, which no CVE describes.
Only as complete as where you pointed it
The other thing sits upstream of every tool: a generated SBOM is only as complete as the metadata the scanned artifact carries.
What a generator finds depends on where you point it: manifests and lockfiles in a source tree, installed packages in an image. A component that arrived by none of those routes does not appear. That is why the SBOM of your source tree and the SBOM of your shipped image legitimately differ, and why the honest answer to "is this complete" is no.
Reconciling either against a scanner's own view belongs with scanning an image or a filesystem for vulnerabilities.
Rescanning is cheap; the feed is not free
You can re-scan a stored SBOM without rebuilding or re-pulling the image, which is what earns its keep the day a zero-day lands, a flaw already exploited before a fix exists. The vulnerability data still has to reach you. Grype, Anchore's scanner for the SBOMs Syft writes, works from a database rebuilt nightly out of NVD, GitHub Security Advisories and distribution feeds, and by default refuses to run when the local copy is more than five days old. On an air-gapped network, one with no route to the internet, host it inside the environment and keep it refreshed.
An SBOM does less than the pitch implies and more than it costs. It will not tell you your software is safe; nothing that cheap does. It tells you what you shipped, when, at which versions, with enough hashes and signatures for someone else to check.
The inventory is the durable artifact. The verdict is not.