Cyber Resilience Act · 2026/2027

SBOM under the CRA: the file is the start of the process, not the finish

Author: Piotr AdamskiOperational and security review: Brillnet C-Team

Informational content. It does not replace individual legal advice or conformity assessment.

The Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies.

Generating the file does not finish the work. An SBOM becomes operationally useful when the team can move from a component to a real product release, vulnerability, impact decision, remediation and verification evidence.

What the CRA says about SBOMs

Part II of Annex I requires manufacturers to identify and document vulnerabilities and product components, including by drawing up an SBOM.

Annex VII links the SBOM to the technical documentation for vulnerability-handling processes. A market-surveillance authority may also request the relevant SBOM where it is necessary to verify compliance with the essential cybersecurity requirements.

One important distinction: the Regulation does not say that every manufacturer must publish the full SBOM to every user. Annex II asks for information on where an SBOM can be accessed if the manufacturer decides to make it available to the user.

File format is only the first decision

CycloneDX and SPDX are widely used SBOM formats. Selecting a format does not solve lifecycle management.

For each SBOM artefact, record at least:

  • product;
  • release/version;
  • generation time;
  • tool and generating process;
  • scan scope;
  • format version;
  • storage location;
  • artefact identifier or hash;
  • validation status.

Without a release link, it may be impossible later to establish whether a component was actually shipped to a customer.

The workflow that creates value

component → component version → product release → vulnerability → impact assessment → decision → action → fix → test → evidence → communication

Example:

  1. tooling identifies library X in release 4.8.1;
  2. a vulnerability is disclosed for specified versions of X;
  3. the team confirms whether the affected code is present and relevant in the product;
  4. an impact assessment and prioritisation decision are recorded;
  5. remediation is linked to a specific change and product release;
  6. a test verifies the result;
  7. verification evidence is attached to the case;
  8. if Article 14 criteria are met, the separate CRA reporting workflow starts.

Neither a CVE entry nor the SBOM itself decides product impact for the team.

SBOMs and suppliers

A component may come from open source, a commercial supplier or another internal team. A mature process therefore connects the dependency to:

  • supplier or source;
  • maintenance status;
  • vulnerability-information source;
  • person responsible for updating it;
  • replacement path if the component becomes unsupported.

This also matters for support-period decisions. The CRA allows manufacturers to consider support periods of integrated third-party components providing core functions.

Do not turn GRC into another scanner

Pulsar should not compete with software composition analysis tools, dependency scanners and SBOM generators. Those tools identify and describe components.

GRC adds value when it uses the output to support controlled decisions:

  • associate an artefact with the product and release;
  • link risk and action;
  • assign an owner and due date;
  • retain the decision;
  • attach remediation and test evidence;
  • provide history during review.

The current Pulsar repository confirms risk, action, vendor, document, evidence and reporting areas. CycloneDX/SPDX import is not confirmed in this handoff as a live product capability; do not market it until there is implementation evidence.

Check your current process

  • Can you identify the SBOM for a specific release?
  • Is its generation reproducible?
  • Does each critical component have an owner or source?
  • Can a vulnerability be tied to an affected product release?
  • Does a risk-acceptance decision have an approver and review date?
  • Does remediation have verification evidence?
  • Is there a clear rule for moving from vulnerability handling to CRA reporting assessment?

See Pulsar GRC on one evidence workflow

Sources

Sources checked: 12 September 2026.