Buyers now ask for your SBOM. Here is what they check

In short

• Buyers now treat a software bill of materials (SBOM), the list of software inside your product, as a condition of sale.
• India's standards body (BIS) asks for one with every CCTV registration. India's cyber security agency (CERT-In) recommends that public buyers require one, and the EU puts one in every technical file.
• A buyer trusts an SBOM that matches the shipped firmware, uses names that scanners can read and comes with a VEX statement.

From the engineering wiki to the sales checklist

The SBOM has moved from the engineering wiki to the sales checklist. In India, BIS (the Bureau of Indian Standards) asks for a software bill of materials with every CCTV camera registration. CERT-In, India's cyber security agency, recommends that government, public sector and essential services buyers require one. The EU makes it part of the technical file every maker must keep.

A buyer who cannot get a usable SBOM from you has every reason to find a supplier who can. What decides the sale is not whether you have an SBOM, but whether the buyer can trust it. That comes down to accuracy, identifiers and the VEX that travels with it, a statement of which known flaws actually affect your product.

Who now asks for one

BIS, for CCTV cameras. The series guidelines that come with ER: 01 list what each product's SBOM must include: all firmware components, open source libraries, operating system components and third-party software. STQC's test procedure adds that the lab checks your list of third-party components by running automated tools on the firmware. It gives FACT, a firmware analysis tool, as an example.

CERT-In, for public buyers. Version 2.0 of its SBOM guidelines (9 July 2025) is voluntary, but its advice is direct. Government, public sector, essential services and software export organisations should include SBOM requirements in all purchases. Software supplied to them should come with a complete SBOM, in SPDX or CycloneDX, the two common SBOM formats.

The EU, for everything connected. The Cyber Resilience Act asks makers to draw up an SBOM "in a commonly used and machine-readable format", covering at least the top-level dependencies. They must keep it in the technical documentation, and market regulators may ask for it.

US buyers. The minimum elements published in July 2021 by the NTIA, a US government agency, are still the baseline that US guidance builds on. CISA, the US cyber security agency, published an updated draft for public comment in August 2025.

What a buyer checks

Buyers start with the minimum elements, then check whether the data is usable.

Then come the questions a format checker cannot answer:

• Does the SBOM describe the firmware you ship, or the build plan from months ago?
• Are the versions the ones in the image?
• Can a vulnerability scanner match each component, through a package URL (purl) or a CPE name, the two standard ways to name software?
• Does the document say what it could not identify?

What good looks like

• One per release. Generated from the shipped image, every time, with the release version and image hash.
• Versions that match the image. Not the version the build system meant to include, but the one that ended up in the file system.
• Identifiers a scanner can use. A purl for packages, a CPE where NVD needs one, hashes where you have the file.
• Honest about unknowns. Components found only by a version string or a code signature should say so, with a confidence level.
• A VEX beside it. Without one, the buyer's scanner turns your SBOM into a list of every flaw in every component.

Why VEX travels with it

An SBOM tells a buyer what is inside, and a VEX tells them what it means. When a buyer runs your SBOM through public flaw databases such as NVD or OSV, they will see flaws in components your product never uses in an exposed way.

CERT-In's guidelines ask suppliers to state each vulnerability's status as not affected, affected, fixed or under investigation. They also ask for a CSAF advisory, a standard security notice, to follow it.

A good VEX turns a hundred alarming rows into the handful that need action. It is the document that keeps a buying review short.

How close can a firmware SBOM get?

On Linux firmware that ships a package database, very close.

It gets harder where there is no package database. A microcontroller image is one binary, and components can only be found from version strings and code signatures.

We now say how each component was identified, and with what confidence. For that kind of image, we recommend that you hold your supplier's SBOM, not just a list taken from the binary.

Questions for your engineering team

• Is an SBOM generated for every release automatically, and stored with the release?
• Does it come from the shipped image or from the build manifest, and have the two ever been compared?
• Which components have no version or no identifier, and why?
• Who writes the VEX status when a new vulnerability lands, and how fast?
• Can we hand a buyer the SBOM and VEX for a release shipped two years ago?

Producing one for every release

FDIE by Magdox builds the SBOM from each analysed firmware release and from your code repositories, per release, product or repository. It exports CycloneDX 1.6 or SPDX 2.3. Each component shows its version, where it was found, its licence, how it was identified and with what confidence.

Your people set the VEX status for each vulnerability, and the app exports it in CycloneDX, OpenVEX or CSAF 2.0. We do not decide VEX statements for you, because they are your company's word to its customers.