A software bill of materials can be generated in seconds and become unreliable just as quickly.

Run a scanner against a development checkout, save the result as sbom.json, and the team technically has a file. But which release does it describe? Was it generated before or after the lockfile changed? Does it include the bundled runtime, native modules, container base, installer, and vendored code? Can the same binary be tied back to the same component list six months later?

The Cyber Resilience Act makes the operational answer important. Annex I requires manufacturers to identify and document vulnerabilities and components — including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies.

That wording sets a minimum. A useful SBOM process goes further by creating a trustworthy relationship between the inventory, the product artifact, and the release decision.

Define the unit of inventory before choosing a tool

"Generate an SBOM" is underspecified. First define what counts as one product release.

For a WordPress plugin, the unit may include PHP dependencies, bundled JavaScript, vendored libraries, and the exact ZIP delivered to customers. For an Electron app, add the Electron and Chromium versions, native Node modules, auto-update components, and per-platform installers.

Write a release inventory contract: product and version identifier, platforms, each build artifact and checksum, package ecosystems and lockfiles, bundled runtimes and vendored components, build commit and workflow run, SBOM format and tool version, and known blind spots. A generator that misses a bundled runtime isn't "mostly complete" if that runtime carries the vulnerability that matters.

Generate from the closest trustworthy point to shipment

Source-only scanning is useful in development, but release evidence should describe what customers receive. Generate or reconcile the SBOM as late in the trusted build pipeline as practical:

  1. The release workflow resolves locked dependencies in a controlled environment.
  2. The application and installers are built.
  3. The SBOM is generated for the final artifact.
  4. Automated checks validate format, identifiers, duplicates, and gaps.
  5. Artifact, checksum, SBOM, test results, and approval are archived under one release identity.
  6. The release ships only after the evidence bundle is complete.

SPDX and CycloneDX are the common formats — pick the one your tools and customers can consume. Preserving identifiers, versions, and provenance accurately matters more than the format choice.

Validate the SBOM like any other build output

An SBOM can be syntactically valid and materially wrong. Check four things: is it complete against your inventory contract? Is it internally consistent — versions, identifiers, duplicates, hashes? Is it tied to the shipped bytes, with hashes and release IDs stored alongside and corrections kept as traceable revisions? And is it reproducible enough to investigate — can you explain material component differences on rebuild?

The inventory feeds triage

A component inventory becomes valuable when it feeds vulnerability triage: inventory → match → assess reachability and exposure → decide → remediate or accept → verify → communicate. A scanner match is not the final risk decision — record the affected releases, whether the vulnerable code is reachable, exploitability in your configuration, the decision owner and rationale, and verification.

Note the CRA doesn't require publishing your SBOM to the public — the recitals explicitly recognize confidentiality concerns. But you must be able to produce, retain, and retrieve it. Store immutable release copies, log disclosures, and test retrieval during an incident exercise.

Review deltas, not full inventories

A 2,000-line inventory is hard to review; a release delta is actionable: components added or removed, dependencies upgraded, new licenses, components leaving support, findings changed since the last release. Keep the full SBOM as the system record; make the delta the human review surface.

The practical test

Pick one production release from six months ago and give a teammate 30 minutes: which components shipped? Which issues were open at release time? What changed from the previous version? If the answers need personal memory or archaeology across systems, the problem isn't the SBOM format — it's missing release evidence.

Where does your SBOM workflow break today — incomplete inventories, noisy matches, or evidence scattered across tools? Send me a line or two; I'm collecting patterns across small vendors, no call needed. And if you'd rather automate the whole thing, the founding beta is open: https://getwaybill.io/founding-beta.

Sources