SBOM: an inventory that is only useful if it is generated at build time

A software bill of materials is a machine-readable inventory of the components inside a piece of software: libraries, their versions, their suppliers and how they depend on one another. It is the software equivalent of a manufacturing parts list, and it exists for one practical reason — when a vulnerability is announced in a widely used library, every organisation running software has to answer whether it is affected.

That is the test to design against. An SBOM that takes a week to assemble after the question is asked has not solved the problem it was created for. The organisations that answered the large open-source vulnerability events quickly were the ones that already had component inventories per release, not the ones who started generating them when the news broke.

What an SBOM has to contain

• Supplier and component name, for every component including transitive dependencies.
• Version, precisely — a range is not an inventory.
• Unique identifiers, such as package URLs or common platform enumerations, so the entry can be matched against vulnerability data automatically.
• Dependency relationships, so it is clear what pulled in what.
• Author of the SBOM and the timestamp it was generated, because an inventory without a date describes an unknown build.
• Ideally, the build or release it belongs to, so it can be tied to what is actually deployed.

Generate it in the build, not afterwards

The reliable point of generation is the build pipeline, where the resolved dependency graph already exists. Scanning a finished container or binary afterwards produces a plausible list with known gaps: statically linked code, vendored source, components installed by a script rather than a package manager. Both approaches have a place — build-time for accuracy, artefact scanning as a cross-check — but a programme that relies on scanning alone will be missing components it cannot name.

One SBOM per release, stored with the release. An SBOM for "the product" is out of date the moment a build ships, and the question you will be asked is about the version a customer is running, not about the current state of the main branch.

The inventory is not the answer, only the input

Knowing a vulnerable library is present is the start. Whether the vulnerable code path is reachable in your product is a separate judgement, and communicating it is what exploitability exchange documents exist for — a structured statement that a component is present but not affected, with the reasoning. Without that, teams either patch everything on principle or field the same customer question repeatedly, and both are expensive in different ways.

Where the inventories live

Ettex Records holds an SBOM per release with its date and the release it describes, so a question about a specific customer version has one answer; Ettex Sheets carries the component-to-product view that answers "where else is this library" without regenerating anything; and the formats these files come in are covered in cyclonedx. What customers and regulators actually ask for is covered in sbom requirements.

Being direct: this is a records approach, not a software composition analysis tool. Generating accurate SBOMs and matching them against vulnerability data is what those tools do, and any organisation shipping software needs one; what this covers is keeping the resulting artefacts findable per release.