The strongest CRA SBOM process combines automation with release governance. Dependency discovery should feed a versioned SBOM, which should then be checked for completeness, stored with release evidence and connected to vulnerability intelligence and remediation workflows.
Start With a Defined Product and Release Boundary
Before generating an SBOM, define the product version, build, firmware image or software release to which it applies. A generic organisation-wide dependency list is not enough because CRA vulnerability handling depends on knowing which components are present in which released product versions.
Use a Commonly Used Machine-Readable Format
Annex I Part II requires the SBOM to use a commonly used and machine-readable format. The Regulation does not name one mandatory format in the Annex, so the practical objective is a structured output that can be generated, stored, compared and processed reliably while remaining adaptable to future implementing rules.
Capture at Least Top-Level Dependencies
The CRA expressly sets top-level dependencies as the minimum SBOM depth. Teams should still capture deeper dependency relationships where they are needed to determine exposure to transitive vulnerabilities, because operational vulnerability management can require more detail than the legal minimum wording.
Automate Generation From the Build Where Possible
SBOM generation is more reliable when connected to package manifests, lockfiles, build systems, container images and firmware build inputs. Manual spreadsheets can be useful for exceptional components, but a release process should reduce the risk that components are omitted simply because one team forgot to update a separate compliance file.
Include Identity Data That Supports Vulnerability Matching
A useful SBOM needs enough component identity information to connect a dependency to vulnerability intelligence. Depending on the ecosystem, that can include component name, version, supplier or maintainer, package identifier, source repository and relationship to the product. The exact fields should support traceability rather than exist only for formatting completeness.
Version the SBOM With Each Release
Dependencies can change between releases even where the product name does not. Store the SBOM with the release identifier and preserve historical versions so that a newly disclosed vulnerability can be mapped to the exact product releases that contain the affected component.
Validate the SBOM Before Release
Add release checks for missing direct dependencies, unresolved component identity, duplicate packages, stale versions and build inputs not represented in the SBOM. A syntactically valid file can still be incomplete, so validation should include product-specific completeness checks.
Connect SBOM Data to Vulnerability Handling
The SBOM is required within the CRA vulnerability-handling framework. Feed its component data into vulnerability monitoring, impact analysis, remediation and update workflows so that newly disclosed component vulnerabilities can be linked quickly to affected product versions.
Preserve the SBOM With Technical Documentation
Annex VII connects the SBOM to the technical documentation describing vulnerability-handling processes. The organisation should therefore retain the SBOM, generation method, relevant validation records and release context as part of the product evidence set.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.