SBOM evidence for the Cyber Resilience Act, at ingest.
If you place a product with digital elements on the EU market, the CRA makes a machine-readable software bill of materials your obligation — not a nice-to-have. With a detonation host attached, Attestree generates a CycloneDX SBOM and a signed attestation the moment each package enters, and you can download both per version. It won't make you CRA-compliant on its own. It removes the part you'd otherwise reconstruct by hand.
Manufacturers must report actively exploited vulnerabilities and severe incidents to their CSIRT and ENISA — a 24-hour early warning, 72-hour detail, 14-day final report.
The essential requirements take full effect — including the Annex I Part II(1) duty to ship a machine-readable software bill of materials.
EU CRA = Regulation (EU) 2024/2847, in force 10 Dec 2024.
The SBOM requirement, in the CRA's own words.
Manufacturers shall "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies of the product."
— Annex I, Part II(1)
Two words carry the weight: machine-readable rules out a PDF, and at least the top-level dependencies sets a floor, not a ceiling. The Commission points to CycloneDX and SPDX as the formats that qualify. Attestree generates CycloneDX with Syft at the moment of ingest — not a post-hoc scan reconstructed at audit time.
Capability to obligation, with the citation.
CycloneDX SBOM, generated at ingest
The CRA asks for "a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies." With a detonation host attached, Attestree runs Syft over each package’s installed files the moment it enters, producing a CycloneDX SBOM, and stores it with the version: download it, with a component summary, from the version’s page. It is a third-party SBOM of what the installer put on disk, not a top-level view: a scan of installed files cannot tell top-level from transitive dependencies.
An attestation per package
When you integrate a third-party component, Article 13 expects due diligence on it. Attestree's attestation is that diligence, recorded: the installer's SHA-256 and code signer, what it did in the sandbox, and the digest of its SBOM. Since platform 0.240.0 it is signed per version, so you can download it and verify it on its own, offline.
Real sandbox detonation + behavioral record
The same clause asks you to "identify and document vulnerabilities and components." Detonating a package in a controlled VM and recording what it actually does surfaces behavior a manifest scan never would — evidence gathered before the component ships, not after.
Continuous reconciliation across the fleet
Under the CRA the SBOM is a living document, not a one-time PDF. Attestree's continuous inventory keeps the component picture current as versions change, so the evidence you hand an auditor matches what is actually deployed.
A signed, exportable audit bundle ships today. The builder re-verifies every span before sealing a SHA-256 manifest, and the manifest discloses how the signing key was held — a local file, or a Key Vault key — so a reviewer weighs the custody rather than guessing at it. It carries the signed audit spans, not the SBOM documents. The catalog’s Export evidence action writes a second signed bundle that does: for each version, its own signed statement, SBOM and component summary, checked offline by the same verifier. Where no signer is configured at all, the audit export refuses rather than handing you a bundle that would fail an auditor's check.
The CRA is bigger than an SBOM. We do the SBOM.
The honest scope, because the alternative loses an audit. Attestree automates the component-inventory and provenance evidence. The rest of the CRA programme stays with you or your GRC tooling:
- The full vulnerability-handling process and coordinated disclosure policy
- Article 14 incident & vulnerability reporting to your CSIRT and ENISA (the 24h / 72h / 14-day clock)
- Conformity assessment, the EU declaration of conformity, and CE marking
- The complete Annex VII technical documentation package
- Your product-level risk assessment and the Annex I Part I essential requirements
The same SBOM, for US federal SBOM requests.
The CycloneDX SBOM that maps to the CRA also supports SBOM requests made under Executive Order 14028 — the same downloadable artifact, not a second tool. It does not satisfy the NIST Secure Software Development Framework (SP 800-218) or the CISA Secure Software Development Attestation Form: those are a producer's statements about how it builds its own software. For the engineering-org view of this, see Attestree for SaaS engineering.
Straight answers.
Does Attestree make my product CRA-compliant?
No — and any tool that claims to is overselling. The CRA is a broad regulation: risk assessment, vulnerability handling, incident reporting, conformity assessment and CE marking all remain your responsibility. Attestree automates one specific piece — generating the SBOM and recording provenance evidence for the components you integrate (Annex I Part II(1) and the third-party due-diligence duty in Article 13).
What SBOM format does Attestree produce?
CycloneDX, generated with Syft over each package’s installed files at the moment it is ingested, once a detonation host is attached — a commonly used, machine-readable format the CRA accepts (alongside SPDX). The platform stores each run’s document; download it, with a component summary, from the version’s page, or export many versions in a signed catalog evidence bundle. The summary is not a top-level-only view: a scan of installed files cannot tell top-level from transitive dependencies, so the top-level SBOM of your own product stays yours to produce.
When do I need this by?
The CRA entered into force on 10 December 2024. The Article 14 reporting obligations — for actively exploited vulnerabilities and severe incidents — apply from 11 September 2026. The main obligations, including the Annex I Part II(1) SBOM requirement, apply from 11 December 2027. The reporting clock starts first.
Does this help with US federal SBOM requirements too?
Partly. The same CycloneDX SBOM supports SBOM requests made under US Executive Order 14028. The NIST Secure Software Development Framework (SP 800-218) and the CISA Secure Software Development Attestation Form are about how a producer builds its own software; evidence about the third-party components on your fleet does not answer them.
Start the SBOM before the deadline.
Generate a CycloneDX SBOM and a signed attestation for each winget installer your endpoints need — in the free Community Edition, on your own hardware, once you attach a detonation host.
Informational, not legal advice. Confirm your CRA obligations with qualified counsel.