SBOM life cycle
The ground rule
One SBOM per build. Immutable once produced, versioned, tied to the artefact by its cryptographic hash.
Corollaries:
- an issued SBOM is never modified; a new one is issued instead;
- an SBOM “of the product”, with no build or version reference, has no value;
- two builds of the same code at two different dates may produce different SBOMs, if dependencies resolved differently — which is itself useful information.
The stages
| Stage | Where | What is produced |
|---|---|---|
| Generation | Build pipeline | Build SBOM |
| Validation | Pipeline | Quality score, failure below threshold |
| Signing | Pipeline | Signed SBOM, provenance attestation |
| Publication | Steering platform | Ingestion, initial correlation |
| Attachment | Artefact registry | SBOM indexed by hash, alongside the image |
| Monitoring | Platform | Daily re-evaluation against sources |
| Enrichment | PSIRT | VEX statements added as analysis proceeds |
| Archiving | Evidence vault | Long-term, immutable retention |
| Retrieval | On request | Extraction of a historical version |
| Deletion | End of retention period | Logged purge |
Retention period
Aligned with the technical documentation: at least ten years after the product is placed on the market, or for the support period if longer.
That means an SBOM produced today for a product still sold in five years must be retrievable in fifteen. The practical consequences are underestimated:
- the format must stay readable — hence standardised rather than proprietary formats;
- the public keys for verifying signatures must be retained;
- the storage medium will need migrating at least once;
- the index must survive a change of platform.
Indexing
An SBOM that cannot be found is an SBOM that does not exist. The minimum index:
| Key | Why |
|---|---|
| Product and commercial version | Entry point for an authority or customer request |
| Build reference | Link back to the CI chain |
| Artefact hash | Proof of correspondence |
| Build date and date placed on the market | Start of the ten years |
| Format and format version | Choice of reader |
| Signature and key | Verification |
| Associated VEX statements | Context of the handling decision |
Version-to-version comparison
An SBOM diff between two versions answers recurring questions:
- which components were added, and through which dependency path?
- which components were updated, and does that fix known vulnerabilities?
- which licences appeared?
- is the surface growing version after version?
That comparison is a useful input to change review, and it catches unintended introductions — a strong candidate for the engineering dashboard.
The test that counts
Once a year, a retrieval exercise: pick at random a version shipped more than two years ago, and produce within one working day its signed SBOM, its verified signature, its VEX statements and its technical documentation.
Until that exercise has been passed, the archiving arrangement is a hypothesis.