Does an SBOM reveal secrets or source code?

No. An SBOM lists components, their versions, their identifiers, their licenses and their dependency relationships. It contains no code, no configuration and no key. The 2026 minimum elements allow access controls that limit sharing to authorized parties, but state that those controls must not prevent a customer from integrating the SBOM into its security tools. A vendor that refuses any SBOM in the name of confidentiality is confusing an inventory with an architecture.

SPDX or CycloneDX: which one should we require?

Both are recognized by the 2026 minimum elements and both are published standards, SPDX as ISO/IEC 5962:2021 and CycloneDX as ECMA-424. The right choice is the one your vulnerability management tools can read. Name the format and its version in the clause, accept the other one if the vendor has already automated it, and refuse anything that is not machine-readable, PDF and spreadsheet included.

What do we do with an SBOM once we receive it?

Load it into a tool that correlates it with published vulnerabilities, then file it with the vendor record, next to the software version it describes. The day a vulnerability hits a common library, you search for the component in your SBOMs instead of writing to every vendor. If the component is not listed, the 2026 minimum elements let you conclude that you are not affected.

Analysis · Software supply chain

SBOM: what to ask a vendor

An SBOM is only useful if it is complete, machine-readable and delivered with every release. What the CISA and NTIA minimum elements let you require.

By Sentrix · Published 2026-09-20

For a few years now, the request for a software bill of materials (SBOM) has been showing up in tenders and security questionnaires. Many buyers require it without knowing what they will do with the file; many vendors produce it without knowing what it must contain. Both sides now have a common reference text.

What the sources say

In July 2021, the NTIA (National Telecommunications and Information Administration, United States) published the minimum elements of an SBOM, in response to Executive Order 14028. The document defines an SBOM as a formal record of the components used to build software and their relationships, and sets three families of elements: data fields (supplier, component name, version, other unique identifiers, dependency relationship, SBOM author, timestamp), automation support (the SPDX and CycloneDX formats and SWID tags) and practices (frequency, depth, known unknowns, distribution, access control, accommodation of mistakes).

On July 29, 2026, CISA, the NSA, the FBI and international partners, including the Canadian Centre for Cyber Security, published the 2026 minimum elements, which replace the 2021 text after a public consultation that received more than 90 comments. The fields are now split into two categories: SBOM metadata (author, signature, timestamp, generation tool, generation context, document version) and component data (producer, name, version, identifiers, dependency relationship, hash value and algorithm, license). Depth becomes coverage: the SBOM must include all components, transitive dependencies included, with no minimum depth. The recognized formats remain SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424). The text applies to all software, including open source, AI and SaaS, while acknowledging that the latter two may require additional elements.

One passage of the 2026 text is worth keeping: the recipient of an SBOM should be able to conclude that a newly reported vulnerability does not affect them if the component in question does not appear in the SBOM. That is exactly the use a buyer should make of it.

Why it matters

An SBOM is not a vulnerability report. It does not say whether the software is secure; it says what it is made of. The value shows up the day a vulnerability hits a widely used library: the organization that holds the SBOMs of its critical software answers with one query, the one that does not writes to its vendors and waits.

It is also the only document that makes a questionnaire answer verifiable. "We manage our third-party dependencies" reads well on a page; a complete SBOM, signed, delivered with every release, can be checked.

The buyer mistakes we see most: requiring an SBOM without specifying the format or the coverage, receiving a PDF nobody can load into a tool, accepting the SBOM of an outdated version, and never opening it.

The vendor mistakes are symmetrical: producing an SBOM by hand, delivering it once, not distinguishing "no dependencies" from "unknown dependencies", and refusing any SBOM for fear of revealing secrets, when it lists components, not configurations.

What we think at Sentrix

A reasonable SBOM clause fits in five requirements, all backed by the 2026 minimum elements:

A machine-readable format, SPDX or CycloneDX, with the format version specified. Refuse the PDF and the spreadsheet.
One SBOM per delivered version, generated by a tool whose name appears in the metadata, timestamped, and regenerated with every new version. That is the Frequency element.
Full coverage, transitive dependencies included, and an explicit statement of what is unknown or deliberately withheld. An SBOM that does not declare its unknowns is incomplete.
Identifiers and hashes for every component, so that your vulnerability management tool can correlate without human intervention.
An agreed delivery channel, version-specific URL, API or repository, with access control that does not prevent integration into your tools.

Do not demand the impossible: the SBOM of a SaaS service changes at the pace of the service, and the 2026 text recognizes that delivery frequency must adapt to it. Ask instead for the SBOM of the latest deployment and, when a vulnerability makes the headlines, a VEX (Vulnerability Exploitability eXchange) notice, the attestation that indicates whether a product is affected by a known vulnerability.

For ISO 27001:2022, these requirements feed controls 5.19 to 5.21 (supplier relationships and the ICT supply chain) and 8.8 (management of technical vulnerabilities). For NIS2, they document the supply chain security the directive requires of the entities in scope. The ISO 27001 and NIS2 framework pages place these controls; the third-party risk module of the Sentrix platform keeps the SBOM with the vendor record.

The next step

Take your five most critical software products and ask for their SBOM this week, with no contractual clause, just by email. The answer (the file, the format, the date, or the silence) will tell you where each vendor stands, and where to start.

Sources

Frequently asked questions

Does an SBOM reveal secrets or source code?: No. An SBOM lists components, their versions, their identifiers, their licenses and their dependency relationships. It contains no code, no configuration and no key. The 2026 minimum elements allow access controls that limit sharing to authorized parties, but state that those controls must not prevent a customer from integrating the SBOM into its security tools. A vendor that refuses any SBOM in the name of confidentiality is confusing an inventory with an architecture.
SPDX or CycloneDX: which one should we require?: Both are recognized by the 2026 minimum elements and both are published standards, SPDX as ISO/IEC 5962:2021 and CycloneDX as ECMA-424. The right choice is the one your vulnerability management tools can read. Name the format and its version in the clause, accept the other one if the vendor has already automated it, and refuse anything that is not machine-readable, PDF and spreadsheet included.
What do we do with an SBOM once we receive it?: Load it into a tool that correlates it with published vulnerabilities, then file it with the vendor record, next to the software version it describes. The day a vulnerability hits a common library, you search for the component in your SBOMs instead of writing to every vendor. If the component is not listed, the 2026 minimum elements let you conclude that you are not affected.

Let's talk about your compliance program.

Last updated: 2026-09-20