SBOM for CRA — release-specific software inventory
An SBOM identifies software components. It is useful evidence for vulnerability handling, but it is not a certificate or a list that automatically establishes CRA conformity.
Identify the artefact
Associate the SBOM with the actual product, customer variant, release and source artefact. Record format, generation context and verification; a successfully parsed file does not establish authenticity or completeness.
From component to human decision
Use stable identifiers and versions to review CVE/OSV matches. A match is a finding, not proof of exploitability. Record affectedness, rationale, VEX where appropriate and the evidence behind remediation.
Keep it current
Regenerate or update the inventory when releases change and retain historical SBOMs. Link backports and update rollouts to affected deployments. Do not assume one SBOM describes all forks delivered to different customers.
Next steps
Official sources and review context
Regulation (EU) 2024/2847 · European Commission · ENISA SRP
CRA-I18N-2026-10-14-DRAFT-4
Operational tools and retained records. No legal opinion, conformity assessment, certification or confirmation of CRA compliance is generated.