SBOMs and the EU Cyber Resilience Act: Building Audit-Ready Evidence

Generating a Software Bill of Materials (SBOM) does not make a product compliant with the EU Cyber Resilience Act (CRA).

An SBOM answers an important question: what components are in this product? It does not establish whether a vulnerable component is exploitable, whether a manufacturer has investigated a report, or whether a security update reached customers. Those questions require a repeatable vulnerability-handling process and evidence of its operation.

For software vendors, the useful shift is from component inventory to evidence lineage: connecting each released artifact to its dependencies, vulnerability assessments, remediation decisions and security updates.

What the CRA requires—and what engineering teams should add

Regulation (EU) 2024/2847, Annex I, Part II, point (1), requires manufacturers to identify and document vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. Other provisions of Annex I, Part II address remediation, security testing, coordinated vulnerability disclosure and secure update distribution.

Article 31 and Annex VII govern technical documentation, including relevant descriptions of vulnerability-handling processes and the SBOM. Article 13(13) requires manufacturers to keep the technical documentation and EU declaration of conformity available to market-surveillance authorities for at least ten years after placing the product on the market, or for the support period if longer.

These obligations do not universally prescribe CycloneDX, SPDX, PURLs, signed SBOM attestations, VEX files or a particular CI/CD platform. Those are implementation choices that can make the required processes easier to operate and demonstrate.

The CRA’s main requirements generally apply from 11 December 2027. Manufacturer reporting obligations under Article 14 have applied since 11 September 2026, including for relevant products already made available on the EU market. Scope, manufacturer role and product classification still need to be assessed for each product.

Build a release-specific component inventory

Top-level dependencies are the legal minimum described in Annex I, Part II, point (1), not necessarily an adequate operational inventory. A vulnerable library may enter through a transitive dependency, a base container image or a bundled binary.

For a containerized application, start with the immutable image digest, not a mutable tag. The following commands illustrate a local investigation; install Syft and Grype using their documented distribution methods first.

# Replace with your published image and its real digest.
IMAGE='registry.example.com/team/api@sha256:REPLACE_WITH_DIGEST'

# Inventory packages in the exact image.
syft "$IMAGE" -o cyclonedx-json=sbom.cdx.json

# Scan the generated inventory.
grype sbom:sbom.cdx.json -o json > vulnerabilities.json

# Record the manifest checksum for later integrity checks.
sha256sum sbom.cdx.json > sbom.cdx.json.sha256

The digest placeholder is deliberately non-executable until replaced. A checksum detects subsequent changes to the SBOM file; it does not prove that the inventory is complete or that it corresponds to the image. For stronger provenance, record the build identity, source revision and image digest, and consider a signed attestation binding the SBOM to that digest.

Build-time inventory generation also has blind spots. Validate the resulting SBOM against the built artifact, check whether your scanner identifies OS packages and language dependencies, and investigate missing or ambiguous identifiers. No single scanner should be treated as an infallible source of truth.

Turn vulnerability alerts into defensible decisions

An SBOM becomes operationally useful when new vulnerability intelligence can be matched against every supported release, including versions no longer being built.

flowchart TD
    A[Released image digest] --> B[Versioned SBOM]
    B --> C[Recurring vulnerability correlation]
    C --> D{Potentially affected?}
    D -->|No match| E[Retain scan evidence]
    D -->|Match| F[Assess affected code, exposure and mitigations]
    F --> G{Assessment outcome}
    G -->|Not affected| H[Document rationale and review date]
    G -->|Affected| I[Fix, test and release update]
    G -->|Uncertain| J[Investigate and track owner]
    H --> K[Release evidence record]
    I --> K
    J --> K

A scanner match is a lead, not a complete exploitability assessment. For example, a vulnerable package might be present while the affected functionality is absent from the compiled application. Conversely, apparently unreachable code may become reachable through configuration changes or a new execution path.

Vulnerability Exploitability eXchange (VEX) can express assessments such as affected, not_affected and under_investigation in a machine-readable form. OpenVEX and CSAF offer different ways to communicate vulnerability status. They are useful evidence formats, but the statement must be supported by analysis and revisited when the product or threat context changes.

A practical triage record should identify the affected product version, vulnerability identifier, evidence examined, decision, justification, reviewer, timestamp and next review condition. For not_affected, explain why the vulnerability does not affect that specific artifact; do not assume that container isolation or an unverified call graph automatically eliminates risk.

Importantly, a VEX status does not suspend CRA notification duties. Whether reporting is required depends on the conditions in Article 14, not the label assigned by an internal vulnerability management tool.

Preserve an evidence trail, not just files

The objective is to reconstruct what the manufacturer knew and did for a particular release. A compact internal evidence index might look like this:

# Illustrative engineering record, not a CRA-prescribed format.
release: "api-2.4.1"
source_revision: "REPLACE_WITH_GIT_COMMIT"
artifact:
  image: "registry.example.com/team/api"
  digest: "sha256:REPLACE_WITH_DIGEST"
evidence:
  sbom: "evidence/api-2.4.1/sbom.cdx.json"
  vulnerability_scan: "evidence/api-2.4.1/vulnerabilities.json"
  triage_register: "evidence/api-2.4.1/triage.json"
  test_results: "evidence/api-2.4.1/security-tests.json"
  release_approval: "evidence/api-2.4.1/approval.json"

This manifest is an engineering recommendation, not a mandatory CRA template or proof of conformity. In production, validate referenced files, record their hashes, control access, maintain version history and implement retention according to the applicable documentation requirements.

A signed attestation can establish that a particular identity made a statement about an artifact. It cannot independently establish the truth of the statement. Likewise, an immutable archive can preserve an incorrect SBOM perfectly. Completeness checks, reviews and documented exception handling remain essential.

Design for Article 14 reporting timelines

Since 11 September 2026, manufacturers have been subject to CRA reporting requirements for actively exploited vulnerabilities contained in their products and severe incidents affecting product security, when the relevant statutory conditions are met.

The reporting process uses the CRA Single Reporting Platform, with notifications addressed through the designated CSIRT and ENISA arrangements. The principal deadlines are:

These are different reporting tracks. Do not treat every newly published CVE, every scanner match or every vulnerability in an upstream project as an automatic Article 14 notification trigger.

The practical engineering question is whether your team can identify affected products and supported releases promptly enough to support incident assessment. Test that capability with a tabletop exercise: select a hypothetical exploited dependency, query archived SBOMs, establish which artifacts contain it, assess actual impact, and prepare the information needed for the reporting decision.

A workable implementation sequence

Start with one product and one release pipeline. Generate an SBOM from the published artifact, preserve it under an immutable release identifier and verify that the inventory covers the components you expect. Then add recurring vulnerability correlation across supported releases, a triage register with accountable reviewers, and evidence links to patches and security advisories.

Only after those fundamentals work should you add automated VEX publication, signed attestations and broader portfolio reporting. Automating weak evidence merely makes weak evidence easier to produce at scale.

The result is not automatic CRA conformity. It is a more reliable software supply-chain process: one that lets engineering teams trace a vulnerability from a component to an affected release, a documented decision and, when needed, a delivered fix.

For software vendors building this capability, ape factory helps connect software supply-chain security with CI/CD, platform engineering and operational vulnerability management—without presenting engineering tooling as a substitute for legal conformity assessment.

Primary sources and further reading

• Regulation (EU) 2024/2847 — Cyber Resilience Act — especially Articles 13, 14 and 31, Annex I Part II and Annex VII.
• European Commission — CRA reporting obligations .
• European Commission — CRA legislative summary .
• European Commission — Implementation guidance announcement (July 2026) .

Regulatory interpretation should be reviewed against the current legal text, applicable implementing measures and the product’s specific circumstances before publication or use in a conformity assessment.