Signing and integrity
The problem
A JSON file sitting next to an artefact commits nobody. Nothing in it proves:
- who produced it;
- when it was produced;
- which artefact exactly it corresponds to;
- that it has not been modified since.
An unsigned SBOM is a statement, not evidence. For technical documentation meant to be put to an authority ten years later, the difference is decisive.
The mechanisms
Signing the document
Sign the SBOM itself and attach the signature to the artefact in the registry. Two common approaches: a classic detached signature with an organisational key, or signing through a supply chain signing infrastructure such as Sigstore / cosign, with an ephemeral identity and a transparency log.
The transparency log adds something specific: it makes the signature publicly verifiable and timestamped, which directly answers “did this SBOM exist on that date?”.
Artefact hash
The SBOM must contain the cryptographic hash of the artefact it describes, and the artefact must be retrievable by that hash. It is this link that lets you show, years later, that this SBOM describes that binary.
Provenance attestations
An attestation is a signed statement about how the artefact was produced: source repository, revision, build chain, parameters, dependencies. The in-toto model provides the structure; the SLSA framework defines progressive levels.
The SLSA framework defines four named levels for its build track:
| Level | What is required |
|---|---|
| Build L0 | No requirements — the absence of SLSA |
| Build L1 | The build process is consistent and provenance exists, describing the platform, the process and the top-level inputs. It is distributed to consumers |
| Build L2 | The build runs on dedicated infrastructure, not an individual’s workstation, and provenance is tied to it by a signature whose authenticity is verified downstream |
| Build L3 | The platform prevents runs from influencing one another, and makes the signing material inaccessible to user-defined build steps |
Reproducible builds are not a level of that track: they are a distinct property, described below, that strengthens third-party verifiability.
Reproducible builds
Two builds of the same code produce bit-for-bit identical artefacts. This is the most demanding objective and the most probative: it lets a third party verify that the shipped binary matches the published source.
For a product under a ten-year support period, reproducibility has a second, often decisive benefit: it forces the build environment to be pinned and documented, and therefore makes it possible to rebuild eight years from now.
The link to the Regulation’s requirements
| Requirement | What signing contributes |
|---|---|
| Annex I, Part I — integrity protection | Verification at install and at update |
| Annex I, Part II, point 7 — secure distribution of updates | Authenticated channel, signed fixes, rollback protection |
| Annex VII — technical documentation | Dated, tamper-evident proof of what was shipped |
What to put in place
- Sign every SBOM at build time, in the pipeline, with no human step.
- Generate a provenance attestation for every artefact.
- Store signatures and attestations with the artefact, indexed by hash.
- Verify the signature before any deployment and before any publication.
- Manage keys: rotation, revocation, retention of historical public keys — without the 2027 public key, a 2027 signature cannot be verified in 2035.
- Test retrieval: an annual exercise consisting of finding, verifying and presenting the signed SBOM of an old version.
That last point is the only one that proves the arrangement works. See Evidence retention.