Home / Knowledge hub / SBOM requirement
Knowledge hub
SBOM requirement
A customer or regulator asking you to supply an SBOM with your software.
What it means
An SBOM requirement is a demand, from a customer, a procurement team or a regulator, that you provide a software bill of materials along with your product. It is written into questionnaires, contracts and tender documents.
The US NTIA set out minimum elements for an SBOM: supplier name, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp. Many requirements point to that list.
Why it matters
Sales can stall on it. A large or regulated buyer may refuse to proceed without one, and a team that has never produced an SBOM can lose weeks. It also shows up in security questionnaires and in vendor reviews.
A wrong or stale SBOM is worse than a late one, because it makes later claims hard to trust. Buyers also compare lists against known flaws and will come back with questions about what they find.
How it shows up
Prepare before you are asked. Generate an SBOM at build time in a standard format, SPDX or CycloneDX, include transitive dependencies, and store one per release. Decide who can share it, under what terms and how you will deliver updates.
Be ready for the follow-up. Customers may ask which listed flaws matter. A VEX statement answers that. Mistakes include handing over a spreadsheet by hand, listing only the top-level packages, and having no process for updates after release.
Questions people ask
SBOM requirement, answered
What must an SBOM contain?
The NTIA minimum elements are supplier, component name, version, other unique identifiers, dependency relationships, author of the SBOM and a timestamp.
Which format should we use?
Use SPDX or CycloneDX, as most requirements accept either. Ask your customer if they have a preference.
How often do we update it?
With each release, and when you learn something that changes it. An SBOM from last year describes last year's software.
Do we have to share it publicly?
Usually not. Many suppliers share under contract. Agree how it is handled with the customer.
Does an SBOM prove we are secure?
No. It lists what is inside. It does not say whether the software can be broken.
Sources
Where this comes from
Related
Terms that sit next to this one
SBOM
A list of every component your application includes, with versions.
CycloneDX
A standard format for writing an SBOM so tools can exchange it.
SPDX
A standard format for listing software components and their licences.
VEX
A statement that says whether a known flaw in a component can actually affect your product.
Security questionnaire
The list of questions a buyer's security team sends before they sign.
Ready for the customer who asks?
A buyer wants more than a list. We can evidence what an outsider could actually exploit in your application. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.