The Audit Will Ask for Receipts: Shipping a Signed SBOM With Every Firmware Build

The Binary Is No Longer the Whole Product

A firmware image used to answer a simple question: did the device receive the code we built? That answer is no longer sufficient for many US buyers. Procurement teams, sector regulators, and security reviewers increasingly ask for the ingredients of that image, not just its hash. The software bill of materials has moved from a compliance checkbox to an operational artifact in the OTA pipeline.

The policy backdrop matters. Executive Order 14028 in 2021 put SBOM practices on the federal agenda, and subsequent guidance from CISA and NTIA defined minimum elements and formats. By 2026, those expectations have reached commercial procurement, critical infrastructure contracts, and connected-product reviews. For medical devices, premarket cybersecurity expectations add another layer. A vendor that cannot produce a machine-readable SBOM for a firmware release is now a vendor with a sales problem, not merely a documentation gap.

The deeper problem is architectural. Most OTA pipelines still treat firmware as a single opaque binary built by a black box. An SBOM that is assembled by hand after the release is already stale. To survive an audit, the inventory has to be a first-class build output, signed and delivered with the same discipline as the firmware itself.

Minimum Contents for an OTA SBOM

An SBOM for a server application is useful. An SBOM for firmware has to answer additional questions: which hardware targets does this image support, which toolchain produced it, and which components are statically linked into the final binary? At a minimum, each release should identify component name, version, supplier, dependency relationship, and a unique identifier such as a package URL or CPE. Include cryptographic hashes for components where the build system can produce them.

Add firmware-specific metadata: the digest of the firmware artifact, the target board and silicon revision, the build timestamp, the compiler and linker versions, and any vendored libraries that do not come from a package manager. If the device ships with a bootloader, radio stack, or real-time operating system, those belong in scope too. The SBOM should describe the product that actually leaves the building, not the application layer alone.

Use a standard format. SPDX and CycloneDX both have broad tool support and can be validated automatically. The format matters less than the discipline: the file must be machine-readable, reproducible, and tied to the exact artifact that will be offered to devices.

Generate at Build Time, Not by Hand

The only SBOM that survives an audit is the one the build system creates. Make SBOM generation a required CI stage for every firmware release. If the build cannot enumerate a dependency, fail the build or record an explicit exception with an owner and an expiration date. Hand-maintained spreadsheets drift within weeks, especially when a vendor library is updated quietly to fix a defect.

A practical pipeline step looks like this: resolve dependencies, compile the firmware, generate the SBOM from the build graph, compute the firmware digest, bind the digest into the SBOM, sign the SBOM, and publish both artifacts to the OTA release store. The release is not eligible for deployment until those steps pass. This turns SBOM creation from a documentation chore into a gate.

Sign the Inventory and Bind It to the Binary

Signing the firmware alone is not enough. An attacker who can alter the SBOM can hide a vulnerable component from audit and incident response. Sign the SBOM with a key held in an HSM or a managed signing service, and bind the signature to the firmware digest. A DSSE envelope or an in-toto attestation gives you a verifiable statement that this SBOM describes this binary.

Publish the verification instructions alongside the release. Your customers should be able to check that the SBOM was produced by your build system and that it matches the firmware they received. Internally, the OTA backend should refuse to serve a firmware artifact whose SBOM signature or digest binding does not validate. That single control prevents a class of release-store mistakes that audits are designed to catch.

Delivery: Sidecar, Manifest, or Embedded?

Devices rarely need to parse a full SBOM. The backend and the customer do. For most fleets, deliver the SBOM as a signed sidecar artifact next to the firmware and reference it from the release manifest. The manifest can carry a compact summary, such as SBOM format, digest, and signature reference, while the full document remains retrievable by release ID. This keeps device storage and bandwidth low without sacrificing auditability.

For constrained devices or offline update paths, include a compact component list in the release manifest and keep the full SBOM in the release store. Do not embed a large SBOM in every firmware image unless the device genuinely needs it. The goal is traceability, not payload bloat.

The CVE Drill: Using the SBOM Under Pressure

An SBOM earns its keep when a dependency CVE lands. The response should be a query, not a scavenger hunt. Which releases contain the affected component? Which device models are in the field? Which of those devices are eligible for the next OTA wave? If the SBOM store is indexed by component and version, those answers arrive in minutes. If it is a folder of PDFs, the incident starts with a manual review.

Run the drill before you need it. Pick a component, simulate a critical vulnerability, and walk through identification, rollout pause, rebuild, signing, and emergency delivery. Preserve the SBOMs and release manifests used during the drill. Auditors do not only ask whether you have an SBOM. They ask whether you can use it when the pressure is real.

Audit Evidence That Survives Procurement Review

Procurement reviewers want evidence that the process is repeatable. Keep SBOMs immutable for the life of the product, with access logs and retention policies. Map each device to the release it runs and therefore to the SBOM for that release. Record exceptions, approvals, and remediation dates. If a customer asks for the SBOM for a build shipped eighteen months ago, the answer should be a link and a signature, not an apology.

Firmware is no longer a single opaque binary in the eyes of US buyers. Treat the SBOM as a signed release artifact, and the audit becomes a demonstration of engineering discipline rather than a last-minute scramble.