Build provenance, signed artefacts, reference values
Attested software supply chain
The strongest TEE will faithfully verify the wrong build.
Runtime attestation compares what is running with what should be running. 'Should' comes from your build: provenance, signatures and reference values. If that chain is weak, the strongest TEE verifies the wrong thing.
Who this is for
- Release and build engineering teams, who produce what gets verified
- Product security teams, who own what the verifier accepts
- Open-source maintainers and foundations, whose builds others rely on
When trust has to be proved again
Every releaseProduce reference values and provenance together, so verifiers can trust the new build at once.
A dependency or base image changesMeasurements change even when your code does not.
A signing key is rotated or compromisedEverything signed with it needs a decision: keep, re-sign or revoke.
What we deliver
- A link from build provenance (SLSA, in-toto, Sigstore) to runtime reference values (CoRIM and similar).
- Release and revocation procedures that keep verifiers current.
- A review of what your attestation actually measures.
Questions worth answering
- Where do your verifiers get reference values from?
- How long after a release do verifiers accept it?
- Can you revoke one build without breaking the fleet?
Across the life cycle
DesignBuildMake or deployOperateUpdateRetire
The stage that decides here: build. This area is the build stage. Its output is what every later stage is compared against. See attestation in the product life cycle.
Rules and standards your buyers cite
Cyber Resilience ActNIS2
Industries that use this
Blockchains and decentralised networks
Go deeper
Who builds in this area
From our public landscape: SLSA, in-toto, Sigstore, GUAC, Witness, Chainguard, TestifySec, Kusari, GitHub Artifact Attestations.
Not quite your case? The runtime side? Attested cloud workloads. Model lineage? AI passport.
Working on Attested software supply chain? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.
Concepts: Re-attestation · Continuous attestation · Remote attestation · IETF RATS architecture