On this page
- Annex I connects component identification and SBOM information to vulnerability handling.
- Generate SBOMs from release builds and retain them by version.
- Validate transitive coverage and supplier identifiers.
- Link vulnerability matches to exploitability decisions and corrective evidence.
What the legal text points toward
Annex I, Part II, point (1) requires a commonly used machine-readable SBOM covering at least top-level dependencies as part of identifying and documenting product components and vulnerabilities. Capturing transitive dependencies is useful engineering practice; do not describe full transitive coverage as the exact statutory minimum.
The SBOM supports a wider duty: identify, remediate, test, document, and disclose vulnerabilities during the support period.
Minimum practical fields
Use SPDX or CycloneDX and record stable product/version identity, component name and version, supplier where known, package identifiers, dependency relationships, and generation metadata.
Operationalise the SBOM
Feed the release SBOM into a monitored vulnerability process. When a match appears, record product applicability, reachability or exploitability, affected versions, mitigation, fix, test evidence, publication, and any reporting decision.
Review quality and changes in ConformOps
The assessed release SBOM has an explainable document-quality score: 50 points for correlatable component identities, 25 for recorded dependency relationships, and 25 for product and document metadata. Presence, structural usability and freshness are shown separately. Even 100/100 does not establish completeness or CRA compliance. Observed repository coverage measures how many derived component identities also appear in the supplied SBOM; missing, empty or failed discovery leaves that comparison unknown.
Continuous change analysis compares completed runs in History, preserving each release, snapshot and supplied-document identity. Additions and removals stay explicit. Unambiguous stable SemVer replacements in supported ecosystems can be labelled upgrades or downgrades; other version changes keep their direction unknown. A switch between supplied and derived inventory is flagged because the apparent change may come from evidence coverage.
The vulnerability panel records VEX-style affectedness decisions for a specific release, component and advisory, with justification, author, supporting source references and superseded history. The full product history is downloadable as CSV. These are investigation records, not standards-format VEX interchange, compliance approvals or Article 14 reporting outcomes.
Does the CRA require a public SBOM?
The CRA does not impose a general duty to publish the complete SBOM publicly. Article 13(22) and Annex VII, point (8) allows a market-surveillance authority to request it where necessary to assess conformity. A customer contract may require separate delivery. Decide the recipient, release, confidentiality terms and channel before sharing.
An SBOM can parse successfully and still omit shipped components. Compare it with the packaged product, including bundled runtimes, native libraries, vendored code and container layers where relevant. Record presence, structural usability and completeness separately. A failed vulnerability lookup is an unknown result, not evidence of no vulnerabilities.
Frequently asked questions
Is an automatically generated SBOM sufficient?
It is a strong starting point, but manufacturers should validate completeness, product/version correspondence, transitive coverage, identifiers, and the process that acts on new vulnerability information.
Which format should we use?
SPDX and CycloneDX are commonly used machine-readable formats. Choose the format your release and vulnerability workflow can produce, validate, retain, and consume reliably.