For software makers and anyone placing products with digital elements on the EU market
When a vulnerability is exploited, show what you shipped and when you knew, unchanged.
A customer is breached through your product. The questions are which build they ran, what was in it, and when you learned of the flaw. The Cyber Resilience Act turns those questions into obligations.
- When it is tested
- An incident in a customer’s environment; a market-surveillance authority’s request; a dispute over when a vulnerability was known.
- What you will be asked for
- Documented vulnerabilities and components, including a software bill of materials, and the reporting of actively exploited vulnerabilities and severe incidents (Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I and Article 14).
- What goes wrong today
- Build artifacts, SBOMs and advisories are kept in repositories and ticket systems the team controls, and can be regenerated or edited after the fact.
- What changes
- Each release, its SBOM and each advisory is registered as a signed statement through the IETF SCITT interface. The artifact never reaches us: only its hash, under your own signature, inside the log. Receipts are standard COSE receipts.
Sealing shows that a record existed unchanged from a given moment; whether your records are enough is yours to judge. SCITT in the specification
Try it in two minutes
- Choose a real file of your own: a release artifact or its SBOM, or use ours: the real SBOM of the Workers behind this API. It is read in your browser and never uploaded.
- Seal it on Seal a file. A free sandbox key is issued on the page; only a salted fingerprint reaches the log.
- Make a copy, change one character in it, and check both against the receipt at Check. The copy fails; the original passes.
From your own systems it is one API call per record. Integrate · Other industries