Supply chain transparency required by the CRA, NIS2 and your customers
An SBOM (Software Bill of Materials) lists all components of your software in machine-readable form and makes the supply chain transparent.
An SBOM (Software Bill of Materials) is the machine-readable parts list of a piece of software: it enumerates every component a product is built from, in-house modules, open-source libraries, purchased components and their dependencies, each with version, licence and origin. What the bill of materials has been to manufacturing for decades, the SBOM now brings to the software supply chain: verifiable transparency about what is actually inside a product.
We accompany you in developing and implementing comprehensive SBOM strategies that meet CRA requirements while creating strategic advantages through improved supply chain visibility and proactive vulnerability management.
6 service modules
Bookable individually or as an end-to-end programme.
Baseline in one to two weeks: which products need SBOMs, which build processes exist, where you stand against CRA Annex I and BSI TR-03183-2.
Vendor-neutral choice: CycloneDX or SPDX, Syft, Trivy, Microsoft SBOM Tool or platform generators, matched to your build landscape.
SBOM generation as a fixed step in every pipeline: automatic, versioned, signed. Manually maintained SBOMs are outdated with the first release.
SBOMs create value in operation: continuous matching against CVE feeds, VEX statements, connection to your vulnerability management.
The SBOM as part of the technical documentation under CRA Annex VII: presentable to the BSI, robust in conformity assessment.
Demand, validate and merge SBOMs from your suppliers: contract clauses, quality criteria and handling incomplete deliveries.
5 phases
We start with the products facing the earliest CRA deadlines and bring generation, management and vulnerability integration into steady state one after the other.
product inventory, CRA applicability per product, build landscape, gap against BSI TR-03183-2.
prioritised roadmap.
tool selection in a PoC on a real product, format decision CycloneDX or SPDX, first automatically generated SBOM in the build.
pipeline integration across all affected products, central versioned storage, artefact signing.
Dependency-Track or comparable platform, continuous CVE matching, VEX process, connection to vulnerability and reporting processes.
demand and validate supplier SBOMs, CRA documentation per Annex VII, preparation for BSI and customer audits.
Your contact
Sarah Richter
Head of Information Security, Cyber Security
10+ years of experience, CISA, CISM, Lead Auditor, DORA, NIS2, BCM, Cyber and Information Security
SBOM implementation is the key to transparent and secure supply chains in the Cyber Resilience Act. Our clients benefit from strategic SBOM approaches that not only ensure compliance but also create operational excellence through improved transparency, proactive vulnerability management, and trustworthy partnerships along the entire value chain.
Successful SBOM implementation requires a comprehensive consideration of technology, processes, and partnerships. Automation and continuous improvement are crucial for sustainable supply chain security and CRA compliance.
8 QUESTIONS, BRIEFLY ANSWERED
An SBOM is a machine-readable inventory of all components in a piece of software: in-house modules, open-source libraries, purchased components and their dependencies, each with version, licence and origin. It makes the software supply chain transparent and answers within minutes which products contain a vulnerable component. Common formats are CycloneDX and SPDX.
Yes. The CRA (Regulation (EU) 2024/2847) requires manufacturers to document product components, at least the top-level dependencies, as an SBOM and to present it to market surveillance authorities on request. In Germany the BSI is responsible; Technical Guideline TR‑03183‑2 specifies the requirements. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, full CRA applicability from 11 December 2027.
CycloneDX originates from the OWASP community and is designed for security use cases: vulnerability matching, VEX integration, DevSecOps toolchains. SPDX comes from the Linux Foundation, is standardised as ISO/IEC 5962 and historically strong in licence compliance. Both are machine-readable and accepted by the BSI. In practice the ecosystem decides: Dependency-Track and security tooling favour CycloneDX; licence management favours SPDX. Many tools export both.
The NTIA Minimum Elements are the established baseline: component name, version, supplier, unique identifiers (such as purl or CPE), dependency relationships, SBOM author and timestamp. BSI TR‑03183‑2 adds licence information and hashes among others. Unique component identification is critical; without it, automated matching against vulnerability databases fails.
Established open-source tools are Syft (Anchore) and Trivy (Aqua Security); both produce CycloneDX and SPDX from source code, artefacts and container images. Microsoft provides the SBOM Tool, GitLab and GitHub generate SBOMs directly in the pipeline. For management and CVE matching, Dependency-Track (OWASP) is the de-facto standard. Tooling is rarely the bottleneck; automated generation on every release is.
VEX (Vulnerability Exploitability eXchange) is the SBOM's counterpart: a machine-readable manufacturer statement on whether a product is actually affected by a known vulnerability. Without VEX, SBOM matching against CVE databases produces many false alarms, because a contained component is not automatically exploitable. With VEX you document 'not affected' with reasoning and focus remediation on real risk.
Yes. Container images are the most common use case: tools like Syft and Trivy scan images including OS packages. Firmware and embedded systems are more demanding (binary analysis, Yocto and Buildroot integration), but that is exactly where the CRA applies, since products with digital elements are in scope. Manufacturers of connected devices should start early.
The SBOM is the inventory foundation of vulnerability management for software components: continuous matching against CVE feeds shows which products are affected by new vulnerabilities, VEX assesses actual exploitability, and remediation runs through your patch and release processes. The CRA requires exactly this chain, including reporting actively exploited vulnerabilities to ENISA within 24 hours from 11 September 2026.
Our clients trust our expertise in digital transformation, compliance, and risk management
Schedule a strategic consultation with our experts now
30 Minutes • Non-binding • Immediately available
Direct hotline for decision-makers
Strategic inquiries via email
For complex inquiries or if you want to provide specific information in advance