Customer SBOM requests: how to answer one

Supplying components or embedded software to manufacturers? See the SBOM guide for suppliers, which covers contracts, VEX and an SBOM per delivered software version.

Why customers are asking now

• The Cyber Resilience Act. Manufacturers selling in the EU need an SBOM of their own product and have to take care with the components they bring in, so the question moves down the supply chain.
• NIS2. Essential and important entities have to address supply chain security. The directive does not name SBOMs, but an SBOM is one way for a buyer to see what a supplier ships. See SBOMs as NIS2, ISO 27001 and SOC 2 evidence.
• Sector rules. FDA section 524B requires an SBOM for cyber devices, and other sectors have rules of their own.
• Their own vulnerability work. A customer who knows what is in your product can tell whether a new CVE affects them without opening a support ticket.

What to agree before you send anything

Question	Why it matters
Which product and version?	An SBOM describes one release. Send the one they run, not the latest build.
Which format?	Most requests accept CycloneDX or SPDX. Ask whether they need a specific version.
How deep?	Top-level dependencies may not be enough. Expect to be asked for transitive ones.
Once, or with every release?	A contract may expect a new SBOM for each release, which rules out anything done by hand.
Under what terms?	An SBOM shows how your product is built. Agree the confidentiality terms and how the file is delivered.

What a good answer contains

• An SBOM in the agreed format, for the exact release the customer runs.
• Every component with its name, version, supplier, license and a package identifier.
• The dependency relationships, so that a transitive package can be traced to what pulled it in.
• The date, the tool that produced it and the build it came from.
• An honest note on anything the SBOM does not cover (see SBOM completeness).

For what the files look like, see SBOM examples. On the two formats, see CycloneDX vs SPDX. For what the customer is likely to check on arrival, see the SBOM quality checklist.

Mistakes that come back later

• Sending the latest build instead of the shipped one. Builds are not reproducible by default, so rebuilding the same commit gives no guarantee of the same SBOM. Only the SBOM from the build that produced the release shows what the customer received.
• Assembling it by hand for the occasion. It satisfies the request once, and you have to repeat it for the next customer and the next release. See SBOM automation.
• Promising more than you can repeat. "We'll send one with every release" is an easy line in a contract and a hard one to keep without automation.
• Treating the SBOM as the end of it. The follow-up question is "are you affected by this CVE?", and it arrives when the next big vulnerability does.

How to be ready for the next request

Requests get easy when the SBOM already exists. Produce one for every release in the pipeline that builds it, keep it with the release, and monitor it for new vulnerabilities. Then a request takes a download and a short note, and you can answer the follow-up from the same record.

How CRACI handles this

CRACI records an SBOM from every GitHub Actions build that runs on its runners, so each release already has one when someone asks for it.

• Export in CycloneDX or SPDX, including transitive dependencies and the vulnerabilities found in the components.
• Evidence from the build itself. Every component in the SBOM was in the build, and hidden dependencies that lockfile-based tools miss are recorded.
• A completeness state on every job, so that you know what you are sending before you send it.
• Build history. You can see past builds and their SBOMs, and which builds contained a vulnerable dependency, within your retention period.
• Answers to the follow-up. CRACI keeps re-evaluating monitored SBOMs, supports VEX and shows which products run which versions in the inventory view.

Customer SBOM requests: frequently asked questions

Are we required to give customers our SBOM?

It depends on your market and your contracts. The Cyber Resilience Act makes the SBOM part of the technical documentation, which goes to a market surveillance authority on request, and it does not require publishing it. A customer's right to it usually comes from the contract, so check what you have agreed.

Which SBOM format should we send?

CycloneDX or SPDX, whichever the customer asks for. If they have no preference, either works. Ask whether their tools need a specific version.

Do we need to include transitive dependencies?

The Cyber Resilience Act asks for at least the top-level dependencies, but many buyers expect the full tree, and vulnerabilities often sit in transitive packages. A full SBOM is the safer answer.

Should the SBOM go to the customer under an NDA?

That is your decision and your customer's. An SBOM shows what your product is made of, so many vendors share it under their existing contract or an NDA instead of publishing it.

How often should we send an updated SBOM?

As often as you agree. Dependencies change with each release, so a new SBOM per release is the honest default, and that is only practical if the SBOM comes out of the build.

What if the customer asks about an older release?

You need the SBOM from the build that produced that release. CRACI keeps build history within your retention period, 180 days by default with custom retention on Enterprise, so export anything you need to keep for longer.

We have never made an SBOM. Where do we start?

Start with the release your customer runs and a tool that works from your real build. If you are on GitHub Actions, moving the build to CRACI runners gives you a recorded SBOM from the first run.