Guide · EU Cyber Resilience Act
How to build a CRA-compliant SBOM
How to generate machine-readable SBOMs, VDR and VEX records, and 10-year audit evidence for the EU Cyber Resilience Act using Siemens Polarion and Black Duck.
What the CRA actually asks for
Machine-readable SBOM
The CRA requires manufacturers to identify and document product components in a machine-readable format — in practice SPDX or CycloneDX — covering at minimum the top-level dependencies of the product.
Coordinated vulnerability disclosure
Products must ship with a documented disclosure policy and a way to receive reports, plus records showing how each report was triaged and resolved.
Reporting windows
Actively exploited vulnerabilities and severe incidents follow a 24-hour early warning, a 72-hour notification, and a 14-day final report cadence to ENISA and the relevant CSIRT.
Support-period record keeping
Technical documentation and conformity evidence must remain available for 10 years (or the support period, if longer) after the product is placed on the market.
Conformity obligations apply from 11 June 2026, with reporting obligations starting 11 September 2026. Confirm current dates and scope with your regulatory counsel — this guide is engineering guidance, not legal advice.
Automating it with Polarion and Black Duck
- 01
Detect the full composition, not just the manifest
Run Black Duck across source, binaries, containers, firmware, and AI-assisted code. Manifest-only scans miss transitive and vendored components — which is where most of a typical codebase's open source actually lives.
- 02
Generate the SBOM in SPDX or CycloneDX
Export a machine-readable SBOM per build and attach it to the release. Regenerate on every release candidate so the SBOM always describes the artifact that shipped, not the branch it came from.
- 03
Turn findings into governed work items
X-DLM™ routes each Black Duck finding into a Siemens Polarion work item linked to the requirement, test case, release, and approver. Triage decisions become records instead of spreadsheet rows.
- 04
Produce VDR and VEX from the same records
A Vulnerability Disclosure Report lists what was found; a VEX statement records exploitability status — affected, not affected, fixed, under investigation — with the justification. Both should be generated from the Polarion decision trail, not written by hand.
- 05
Hold the 24 / 72 / 14 clock
Pre-define the workflow that fires when an actively exploited vulnerability is confirmed: who is notified, who drafts the early warning, who signs off, and where the timestamp is stored. The evidence is the workflow history.
- 06
Keep evidence for the full support period
Polarion LiveDocs and baselines retain SBOMs, advisories, approvals, and test evidence against a specific release for the 10-year window, so an audit years later reconstructs exactly what was known and when.
SBOM, VDR, and VEX — what each one is for
| Artifact | Answers | Regenerated |
|---|---|---|
| SBOM | What is in the product? | Every release build |
| VDR | What vulnerabilities affect those components? | Continuously |
| VEX | Is the product actually exploitable, and why or why not? | On each triage decision |
See it running on your own release process
X-DLM™ connects Siemens Polarion and Black Duck so SBOM generation, vulnerability response, approvals, and audit evidence stay linked across the software lifecycle.