The problem: Supplier SBOMs arrive in different formats, with different identifiers and inconsistent scope. Merging them into one file makes the inventory look complete while destroying the ability to trace a component back to its supplier.
What to ask a supplier for
- A machine-readable SBOM: CycloneDX JSON or SPDX 2.3 JSON, with the specification version declared.
- The component scope: which parts of the deliverable are covered, and which are explicitly excluded (vendor blobs, third-party libraries, build tooling).
- Exact versions and a package identifier (purl or CPE) for each component, not just a display name.
- The generation method and the point in the build where the SBOM is produced.
- The update cadence and the process for notifying you when a component changes.
- The supplier module identity, so the inventory can be linked to the product version you ship.
The minimum-elements guidance from NTIA and CISA is a useful baseline for the data fields, but it does not replace the contractual question of what the supplier will provide and when.
Validate on receipt, before merging anything
- Check the schema and the declared version. A supplier file that fails schema validation should go back, not into your product record.
- Count components and compare with what you expect for the module. A suspiciously small inventory is a coverage problem.
- Inspect identifiers and exact versions. Name-only components cannot be matched to advisories.
- Resolve dependency references and look for filtered-out components.
- Record the supplier, the module version and the date received with the file.
A validated supplier SBOM is still the supplier's claim about their deliverable. Validation does not audit the supplier and does not prove the component list is complete for the binary they shipped.
Keep the origin: do not flatten everything into one inventory
A single merged SBOM is convenient for a scanner and bad for an investigation. When an advisory names a supplier library, you need to know which supplier module contained it, which of your firmware builds included that module, and which product versions shipped those builds.
Keep the supplier module as an entity with its own version and SBOM, then link it to the firmware build and the product version. The free tools validate each file and compare two releases; the product-version link is the part the Early Access workflow is being built around.
Illustrative relationship
Supplier component → supplier module → firmware build → product version. The website shows this relationship; it does not query your live product data or claim that a specific device is affected.
When a supplier update arrives
- Ask for the new SBOM and validate it before comparing.
- Compare it with the previous supplier SBOM to see what actually changed.
- Map the change to the firmware builds that contain the module.
- Review applicability with the product context; a version change is not automatically an exploitable issue.
- Record the decision and the evidence with the affected product version.
Scope and limits
- This guide describes a process, not a contract template; procurement and legal terms need their own review.
- The free tools validate and compare files. They do not provide a supplier portal or live product-version traceability.
- A component match is a lead for review, not proof that a device is affected.