Ask Suppliers for an SBOM You Can Use

If a supplier says it can provide a software bill of materials, ask for an example covering the product version your organisation actually runs. That turns a broad assurance statement into something the IT team can inspect and use during the next vulnerability announcement.

An SBOM describes software composition. It does not, by itself, prove that the product is secure, fully inventoried or promptly maintained. Its practical value depends on scope, identification, freshness and the supplier's response when a listed component needs attention.

Tie the document to a release

Ask for the product name, version or build identifier, creation date, producing organisation and the artefact or service deployment it describes. If several editions or deployment options exist, establish which one is covered.

For installed software, compare the document with your deployed build. For a continuously changing hosted service, ask how the supplier describes the current scope and notifies customers of material changes. A static document from a procurement exercise may no longer represent the service being used.

Request a machine-readable format that your chosen tools can process. SPDX provides a standard model for exchanging component and relationship information. CycloneDX's SBOM capability likewise describes inventories of components, services and dependencies. Agree the supported format and version rather than accepting an unstructured spreadsheet labelled “SBOM”.

Retain the original document with its release context and any supplier signature or integrity evidence. Do not alter the supplied file to make a tool accept it without keeping a record of the transformation.

Ask what is included and excluded

Review whether the inventory covers application libraries, bundled runtimes, operating-system packages in supplied images, plugins and separately downloaded components. Ask whether it represents source dependencies, build inputs, the shipped product or an observed running deployment.

Those are useful but different views. A development dependency may not ship to customers; a runtime plugin may appear only after installation. Record the boundary so a missing component can be investigated intelligently.

Ask how components are identified and related. Names and versions should be specific enough to distinguish packages with similar names. Where the format supports package identifiers, hashes or dependency relationships, check whether the supplier supplies them consistently.

Take a small sample of components visible in the product or its documentation and look for them in the SBOM. An unexplained omission is a question for the supplier, not immediate proof of dishonesty. The response should clarify scope or correct the document.

Define the vulnerability response alongside the inventory

The next operational question is who will tell you whether a component vulnerability affects your product. Request a support route, expected update process and the information the supplier needs to assess your deployment.

CycloneDX supports Vulnerability Exploitability eXchange information, which communicates vulnerability impact in the context of a product. This can help explain why a listed vulnerable component is or is not exploitable in a particular use. Treat the statement as evidence to assess against its issuer, product version, conditions and date.

A “not affected” response should identify the relevant vulnerability and explain its basis sufficiently for your team to understand the conclusion. Ask what would invalidate it, such as enabling an optional feature or installing another plugin. Do not turn a statement about one release into a permanent exemption for all future versions.

If the supplier is still investigating, keep that status visible with a next-update time. Meanwhile, assess exposure and any documented temporary measure. The SBOM gives the investigation a starting point; the action still depends on the product and the environment.

Run one practical supplier exercise

Choose a known component and a relevant advisory during a planned review. Ask the supplier which supported product versions include it, whether those versions are affected and what customers should do. Use a genuine advisory without assuming that the mere package-name match establishes exposure.

Check whether the answer arrives through the promised support route and can be connected to your asset inventory. Record the response quality, missing information and any update commitment. This is more informative than collecting several assurance documents that nobody has tried to use.

For your own deployed software, assign an internal owner to receive new SBOMs and compare them with the running release. Add the inventory update to the release process so security and support staff do not keep working from the previous version.

Keep the procurement requirement proportionate

Prioritise suppliers whose software has important access, holds sensitive data or would be difficult to replace. Agree a realistic deliverable and review process with each one. Avoid a requirement so vague that any file passes, or so disconnected from your tooling that the result cannot be consumed.

The useful record is concise: covered product, scope, format, update route, vulnerability contact and the outcome of the practical exercise. Keep unresolved gaps visible during renewal and upgrade decisions, with a named person responsible for following them up.

References

• SPDX project, SPDX Overview. Accessed 17 October 2026.
• CycloneDX, Software Bill of Materials. Accessed 17 October 2026.
• CycloneDX, Vulnerability Exploitability eXchange. Accessed 17 October 2026.