Keeping CRA evidence per product: SBOM, known vulnerabilities and the technical file

• Classification against Annexes III and IV, the resulting conformity route and your rationale.
• Version, placing on the market and support period of the product as it is sold.
• The SBOM of that version, and the known vulnerabilities in its components with how each was handled.
• Documents: technical documentation (Annex VII), cybersecurity risk assessment, user information (Annex II), EU declaration of conformity (Annex V) and a coordinated vulnerability disclosure policy.
• A way to receive reports from outside, and a security contact.

Generate the SBOM where the software is built, and send it on to the product record automatically. Attesly takes CycloneDX and SPDX files by upload, by paste or from your CI pipeline through the API.

• The original is kept: the submitted file is retained with a numbered import receipt and a checksum, and older files survive later imports.
• Known vulnerabilities are matched: components that carry a package URL are checked against OSV.dev on import and on manual rescans.
• It is not a code scanner: Attesly reads the SBOMs your tools produce; it does not analyse your source code or binaries.

The SBOM is one item of the Cyber Resilience Act checklist; the other items need their evidence too.

Each release raises the same questions: is the SBOM still the one on the market, which findings does the release fix, and does the change affect compliance — a substantial modification within Article 3(30) is an assessment you have to be able to show. Keep the answers with the product instead of in a release email.

• SBOM imports are numbered, so the inventory of each release stays traceable after the next import.
• Findings carry the release that fixes them, next to your assessment.
• Documents are versioned and carry their language; earlier versions stay in the history.
• The support period keeps its reasoning: the information taken into account is recorded with the period.

Fictional example with the invented demo manufacturer Northwind Robotics and its NW-200 Edge Controller.

1. The build of NW-200 firmware 2.3 ends by posting its CycloneDX file to the product. The file is kept with its receipt; the component list is updated.
2. The OSV.dev match flags a known vulnerability in one component. The team records its assessment and the release that will carry the fix.
3. Firmware 2.4 ships with the fix. The team updates the product’s version, marks the finding as fixed in 2.4 and notes why the update is an ordinary security fix rather than a substantial modification.
4. The technical documentation gets a new version; the previous one stays in the history.
5. Importers and distributors see the product’s public trust page instead of asking for files by email.

Attesly’s readiness score summarises how complete a record is from your own inputs. It is an aid for finding gaps, not a conformity assessment.

Attesly is a documentation and workflow tool; it does not certify products, is not a notified body and does not give legal advice. See plans and pricing, book a call, or read how to prepare an Article 14 report.