SBOM production and delivery

Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.

Legal frame (Regulation (EU) 2024/2847)

• Annex I Part II(1): the manufacturer identifies and documents vulnerabilities and components contained in the product, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies".
• Annex II point 6: the user information states, if the manufacturer makes it available, where the SBOM can be accessed.
• Annex VII: the technical documentation includes the SBOM where applicable, to be provided to a market surveillance authority on reasoned request (point number to be checked against the Official Journal text). Under Art. 13(25), authorities may also request SBOMs of certain product categories for dependency assessments.
• Art. 13(24): the Commission may specify the format and elements of the SBOM by implementing act.
• These obligations apply from 11 December 2027. Publishing an SBOM to users is not required by the CRA; it is a choice.

Sources: Annex I, Annex II (unofficial consolidation; check the Official Journal text).

What CI produces today

SBOM	Format	Tool	CI job (ci.yml)
Source tree (all workspace dependencies)	CycloneDX JSON	Syft via anchore/sbom-action, pinned	sbom
Images app, worker, postgres, valkey, caddy	CycloneDX JSON, one per image	Syft (version pinned in SYFT_VERSION)	image-scan
Sandbox images (node, python, go, scanners, runner)	CycloneDX JSON	Syft in deploy/images/sandbox/build.sh	sandbox-images

Each image is also scanned with grype (fixable high and critical fail the build). The SBOMs are uploaded as CI artefacts. CI has not yet run on a remote, so no SBOM has been published yet.

Delivery (proposal)

1. With each release: the CycloneDX SBOM of every released image is attached to the release (release assets) and attached to the image in the registry as an attestation, so it can be retrieved by digest. The release notes link to it (Annex II point 6).
2. On request: customers and market surveillance authorities can request the SBOM of any supported release through the security contact in SECURITY.md. The PSIRT lead sends it within 5 business days.
3. Retention: SBOMs are kept for as long as the release's security updates must stay available — at least 10 years after release (Art. 13(9)) — and at least 10 years after the product is placed on the market for the technical documentation (Art. 13(13)).
4. Content check: each release SBOM is checked to contain at least the direct dependencies of each image and their versions and licences (CycloneDX components with purl).

Gaps

• Release pipeline with signing (cosign), provenance and SBOM attestation does not exist yet (planned with release hardening).
• The CI job artefact retention is the platform default and is not a 10-year archive; the release process must copy SBOMs to durable storage.
• No container registry chosen yet.

Questions for counsel

1. Is publishing the SBOM to all users advisable, or only on request?
2. Is a VEX document (exploitability statements) expected alongside the SBOM for known, unexploitable vulnerabilities?