Skip to content

Your first CRA report

The EU Cyber Resilience Act (Regulation 2024/2847) requires manufacturers of products with digital elements to handle vulnerabilities, ship a software bill of materials (SBOM), deliver security updates and document their software. yocman cra report gathers the build-side evidence for those requirements from the image you built — it does not certify compliance.

From the build directory of a finished build:

yocman cra report

It reuses the analyses you already have (cve, secrets, sbom, licenses, services, users, perms, kernel-audit) and reorganises their findings by CRA requirement area, with a status for each: No gap, Review, Gap, No evidence (a data source is missing), or Manual for what cannot be proven from a build.

A report to attach to your file

yocman cra report --format md -o cra.md     # Markdown for your compliance file
yocman cra report --format json -o cra.json # machine-readable, for CI
yocman cra report --fail-on high            # exit 1 if any area has a high/critical gap

What it can and cannot prove

The report maps each requirement to the evidence from your build. Two areas are always marked Manual, because a build cannot prove them:

  • the security update mechanism (signing, rollback, delivery) — cra report detects an OTA framework (SWUpdate, RAUC, OSTree, Mender…) in the image when present, but you must document how it works;
  • the vulnerability disclosure policy, the point of contact and the user documentation.

Missing data

Some evidence needs data the build only writes when a class is enabled — cve-check (CVEs), create-spdx (SBOM), buildhistory. Run yocman doctor to see what is missing and how to enable it; the report lists the same gaps.