CRA SBOM and vulnerability handling template

Start each SBOM and vulnerability record by fixing the exact product version it applies to. CRA technical documentation must identify the product, software versions affecting compliance, support-period information, and the vulnerability handling process.

Do not use one generic SBOM label for every build. Exposure, remediation, and user advisory decisions depend on the released version, supported branch, and update channel.

The CRA requires an SBOM in a commonly used, machine-readable format and says it must cover at least top-level dependencies. The law does not name CycloneDX, SPDX, or another specific public format in the source material used for this page, so keep the template format-neutral unless a later implementing act or your conformity route requires more.

The useful operational record is broader than a dependency export. It should show why each integrated component does or does not affect the product's CRA risk assessment, vulnerability exposure, and update path.

Every vulnerability record should separate intake facts from legal-reporting conclusions. The CRA vulnerability handling duty applies broadly during the support period, while mandatory Article 14 reporting is triggered only for actively exploited vulnerabilities in the product and severe incidents affecting product security.

Record the awareness basis. The Commission FAQ explains that mandatory reporting is not triggered merely because a flaw exists or is found in good-faith testing without reliable evidence of malicious exploitation.

Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed, including through security updates, and to apply effective and regular security tests and reviews. The template should therefore track the chosen remedy and the evidence that it worked.

Avoid hard-coded severity-to-deadline tables unless they are grounded in your own policy and risk assessment. The CRA source material supports a risk-based remedy path, not one universal patch deadline for all vulnerabilities.

Annex I Part II requires a coordinated vulnerability disclosure policy, a reporting contact, and measures to facilitate sharing of information about vulnerabilities, including vulnerabilities in third-party components contained in the product. ENISA's vulnerability disclosure material also describes CVD as a multi-party process that coordinates reporting, fixing, mitigation, and public disclosure.

For integrated components, the finished-product manufacturer still has to handle the vulnerability in the finished product. If the component maintainer cannot fix it, the record should show the product-level alternative.

The SBOM and vulnerability template should not sit apart from the CRA technical file. Annex VII expressly includes the SBOM where applicable, the vulnerability handling process, coordinated disclosure policy, evidence of the reporting contact, and the technical solutions chosen for secure update distribution.

Keep confidential technical documentation separate from public advisories. The CRA does not generally require public release of the technical documentation or SBOM, although users must receive required user information and may be given SBOM access if the manufacturer chooses to make it available.