Compliance & Standards
BSI IT-Grundschutz für KMU: Einstieg ohne BSI-Berater
Oskar Braun9 Min.
Supply Chain Security | SBOM
SBOM & Supply Chain
Security: Transparency in the
Software Supply Chain.
93% of all codebases contain open-source components. Supply chain attacks like SolarWinds and Log4Shell show: those who don't know their dependencies cannot protect them. The CRA makes the Software Bill of Materials a legal requirement.
Last updated: March 2026 - Reviewed by certified experts
CRA Obligation
Art. 13
SBOM creation and maintenance
Formats
2 Standards
SPDX 2.3+ and CycloneDX 1.4+
Affected
7,000+
Manufacturers of digital products in DE
Update Obligation
5 Years
Security updates after market placement
- of codebases contain open source components
- 93%
- affected 35% of all Java applications
- Log4Shell
- CRA transition period for reporting obligations
- 18 months
- max. patch SLA for CRITICAL vulnerabilities
- 6 months
Fundamentals
What is a Software Bill of Materials?
A Software Bill of Materials (SBOM) is a machine-readable, structured list of all software components contained in a product, application, or service - comparable to the ingredients list on a food product or the bill of materials in manufacturing.
Modern software is largely composed of open-source components and third-party libraries. According to the Synopsys Open Source Security and Risk Analysis (OSSRA), 93% of all commercial codebases contain open-source components. Without an SBOM, it is unclear which components are present in which versions - and therefore also which known vulnerabilities the product contains.
The Cyber Resilience Act (Art. 13 para. 3) makes the SBOM a legal requirement for all manufacturers of digital products. At the same time, NIS-2 requires supply chain security and DORA requires third-party ICT vetting - both presuppose SBOM transparency.
SBOM Ecosystem at a Glance
- CRA Obligation
- Art. 13 para. 3 Regulation (EU) 2024/2847
- NIS-2 Reference
- Art. 21 para. 2 lit. d - Supply chain security
- BSI Guideline
- BSI TR-03183 - Cyber Resilience Requirements
- Format SPDX
- ISO/IEC 5962:2021 - Linux Foundation
- Format CycloneDX
- OWASP standard - security-optimised, VEX support
- DORA Reference
- Third-Party ICT Vetting - Art. 28-30 DORA
SPDX vs. CycloneDX - Quick Comparison
SPDX ISO standard (5962:2021), broad tool support, strong for licence compliance
CycloneDX OWASP, native VEX support, better for security workflows, actively developed
CRA - NIS-2 - BSI TR-03183
The 8 Core Requirements for SBOM & Supply Chain Security
Effective supply chain security management covers far more than creating an SBOM. The following requirements cover the entire lifecycle from SBOM creation to continuous monitoring and regulatory evidence management.
01
SBOM Creation and Maintenance (CRA Art. 13)
The Cyber Resilience Act (Art. 13 para. 3) requires all manufacturers of digital products to create and maintain a complete Software Bill of Materials. The SBOM must cover all software components - direct and transitive dependencies - be versioned, and updated with each product release. It must be made available to market surveillance authorities (in the EU: national competent authorities such as BSI in Germany) upon request.
Cyber Resilience Act 02
Component Identification - Direct and Transitive
A legally compliant SBOM covers not only direct dependencies (packages referenced in the source code) but also all transitive dependencies (dependencies of dependencies). In modern software projects, transitive dependencies can account for 80-95% of all components. Identification is done via CPE (Common Platform Enumeration), PURL (Package URL), or internal identifiers. Standard formats: SPDX (ISO/IEC 5962:2021) and CycloneDX (OWASP).
03
CVE Monitoring and Vulnerability Feeds
A static SBOM is not enough - it must be continuously checked against current vulnerability databases: NVD (National Vulnerability Database), OSV (Open Source Vulnerabilities), GitHub Advisory Database, and authority-specific sources. Automated CVE feeds enable immediate notification when known vulnerabilities are published in SBOM components. Response time for CRITICAL vulnerabilities (CVSS 9.0+): maximum 6 months according to BSI TR-03183.
Vulnerability Management Consulting 04
VEX - Vulnerability Exploitability Exchange
VEX documents supplement the SBOM with contextual information on the exploitability of known vulnerabilities. A VEX statement can explain for each CVE: "not affected" (e.g. the vulnerable code path is not called), "affected and fixed", "under analysis", or "in progress". VEX significantly reduces false-positive alerts and is a central element of efficient vulnerability management programs. CISA and ENISA recommend VEX as a complement to the SBOM.
05
Supplier Risk Assessment
NIS-2 Art. 21 para. 2 lit. d requires affected entities to review and risk-assess their suppliers and service providers. In the software context, this means: evaluating the security maturity of all key component suppliers (open-source projects, commercial libraries, external service providers), contractual obligations for vulnerability disclosure and patch management, and regular reassessment when the supplier landscape changes.
NIS-2 Supply Chain Security 06
Patch Management Process
A structured patch management process defines binding SLAs for applying security updates: CRITICAL (CVSS 9.0-10.0) within 24-72 hours, HIGH (CVSS 7.0-8.9) within 30 days, MEDIUM and LOW risk-based. The process must be documented, traceable, and auditable. For CRA-affected manufacturers, there is an additional obligation to provide patches free of charge and without delay for the entire support period (min. 5 years).
07
CI/CD Integration of the SBOM Toolchain
SBOMs must be generated and versioned automatically with every build process. CI/CD integration means: SBOM generation in the build step (e.g. Syft, CycloneDX-CLI, SPDX-tools), automatic CVE matching in the security gate (e.g. Grype, Trivy, OSS-Review-Toolkit), artifact signing (Cosign, Sigstore) for integrity proofs, and automated VEX updates for new CVE publications. The result: every release contains a current, signed SBOM.
DevSecOps Consulting 08
Regulatory Provision on Request
Both CRA Art. 13 and BSI TR-03183 require that the SBOM be made available to market surveillance authorities on request. The SBOM must be in a machine-readable standard format (SPDX JSON, CycloneDX JSON/XML), complete and current, and map the entire component hierarchy. A missing or incomplete SBOM in response to an official request can be interpreted as a violation of CRA obligations and sanctioned with fines.
Note: The SBOM obligation under the CRA applies to all manufacturers, regardless of product category and class. For NIS-2-affected operators, the requirement for SBOM transparency follows indirectly from the supply chain obligation - even without a direct legal SBOM obligation, the demand on software suppliers is practically unavoidable.
Real Cases
Real Supply Chain Attacks: What Would an SBOM Have Prevented?
The most serious cyberattacks in recent years had one thing in common: they exploited missing transparency about software dependencies and build processes. An SBOM requirement would have dramatically shortened detection time in each case.
- SolarWinds Orion - December 2020
18,000 organisations affected, undetected for 8 months
Attackers injected malicious code (SUNBURST backdoor) into the SolarWinds Orion build process, which was delivered with a legitimate software update to 18,000 customers - including US federal agencies, defence contractors and Fortune 500 companies. The attack went undetected for 8 months. An SBOM with build integrity proofs and artifact signing would have made the compromised build identifiable early.
- Log4Shell (CVE-2021-44228) - December 2021
CVSS 10.0 · 35% of all Java applications affected
The most critical vulnerability of the decade in the Java logging library Log4j affected millions of products worldwide. The central problem: manufacturers often did not know that Log4j was present in their products as a transitive dependency. Companies with complete SBOMs were able to identify affected products in hours - others needed weeks or months. Log4Shell was the key driver for the CRA SBOM requirement.
- Codecov CI/CD Compromise - April 2021
15,000 affected customers, CI/CD access compromised
Attackers compromised the build script of the code coverage service Codecov and exfiltrated environment variables, CI/CD credentials, and source code repositories of 15,000 customers over several months. The attack shows the risk of software-in-software: an external service integrated into CI/CD pipelines becomes an attack vector. SBOM transparency over all development tools and CI/CD dependencies would have made the risk visible.
- Kaseya VSA Ransomware - July 2021
1,500 MSPs and 50,000 end customers - $70M ransom
REvil exploited zero-day vulnerabilities in Kaseya VSA for a supply chain ransomware attack that struck 1,500 managed service providers and their end customers through a single compromised software vendor. The VSA vulnerabilities could have been fixed through consistent vulnerability management and timely patches. Under the CRA, manufacturers like Kaseya would be required to report actively exploited vulnerabilities within 24 hours and to provide timely patch delivery.
- xz-utils Backdoor - March 2024
2 years of trust-building - insider attack on open source
A state-sponsored attacker built trust in the open-source project xz-utils over two years under a pseudonym, gained maintainer rights, and injected a backdoor into version 5.6.0/5.6.1 of the widely used compression library. The backdoor enabled remote code execution in SSH services. The attack demonstrates the risk of open-source dependencies without supplier risk assessment and underlines the need for SBOM provenance information.
What These Incidents Have in Common
In each of these cases, the software supply chain was the attack vector - not the direct systems of the affected parties. Those who don't know their dependencies can neither protect them nor respond quickly. A complete SBOM with continuous CVE monitoring would have reduced the Mean Time to Detect (MTTD) from months to hours in every scenario.
Technology
SBOM Toolchain: From Generation to Monitoring
A production-ready SBOM toolchain covers four stages: generation, analysis, management, and monitoring. The following tools are proven in practice and have established themselves as industry standards.
Stage 1 - Generation
- Syft (Anchore)
Container images, filesystems, polyglot - SPDX + CycloneDX output
- CycloneDX-CLI
OWASP reference tool, ideal for CI/CD integration, all ecosystems
- Trivy (Aqua)
All-in-one: SBOM generation + CVE scanning in one tool
Stage 2 - CVE Analysis
- Grype (Anchore)
Vulnerability scanner for SBOMs and containers, integrates NVD + OSV
- OSS-Review-Toolkit
Eclipse/Linux Foundation, comprehensive: SBOM, CVE, licence compliance
- OWASP Dep-Check
Established for JVM/Maven/Gradle projects, NVD integration
Stage 3 - Management
- OWASP Dependency-Track
Reference platform for continuous SBOM management, VEX support
- SW360 (Eclipse)
Component catalogue, licence management, SBOM export, enterprise-ready
- Renovate / Dependabot
Automated dependency update management in CI/CD
Stage 4 - Signing & Provenance
- Sigstore / Cosign
Linux Foundation - artifact signing, SBOM integrity, software provenance
- SLSA Framework
Supply-chain Levels for Software Artifacts - build provenance standard
- in-toto
Supply chain attestation - complete traceability of every build step
Consulting Services
How AWARE7 Helps with SBOM & Supply Chain Security
We guide manufacturers and operators in building a complete supply chain security strategy - from the first SBOM to a continuous vulnerability management programme.
SBOM Toolchain Implementation
Tool selection (Syft, CycloneDX, Trivy), CI/CD integration, format standardisation, artifact signing - from pilot installation to production operation.
Toolchain ConsultingVulnerability Management & CVE Monitoring
Building patch SLA processes, OWASP Dependency-Track implementation, VEX programme, and continuous monitoring against NVD, OSV, and authority sources.
Vulnerability ManagementSupply Chain Penetration Test
Targeted tests on supply chain attack vectors: CI/CD pipeline security, build process integrity, dependency confusion attacks, insider threat simulation.
Request PentestCRA-Compliant SBOM & Technical Documentation
Creation and review of CRA-compliant SBOMs under Art. 13 - in SPDX and CycloneDX formats, including VEX statements and preparation for authority requests.
CRA ComplianceSupply Chain Security under NIS-2 Art. 21
NIS-2-compliant supplier evaluation, supplier risk assessment processes, contractual clauses for IT suppliers, and monitoring programmes for key third-party providers.
NIS-2 Supply ChainSBOM Training & Awareness
Training for development teams and management: SBOM concepts, tool introduction, supply chain risk awareness, and regulatory requirements (CRA, NIS-2, DORA).
Request Training„Software Bill of Materials is not a technical niche topic - it is the foundation of modern product responsibility. If you don't know what's in your software, you can find yourself reacting in weeks instead of hours when a Log4Shell hits. The CRA makes this a legal obligation. We help you build the lead now.“
Chris Wojzechowski
Auditor with BSI Section 8a Audit Competence · AWARE7 GmbH
FAQ
Frequently Asked Questions on SBOM & Supply Chain Security
The most important questions about Software Bill of Materials, vulnerability management, and supply chain security - answered with technical depth.
What is a Software Bill of Materials (SBOM)?
A Software Bill of Materials (SBOM) is a machine-readable, structured list of all software components contained in a product or application - comparable to an ingredients list for software. For each component, it contains: name, version, licence, origin (manufacturer or open-source project), dependency relationships, and any known vulnerabilities (CVE references). The SBOM forms the basis for vulnerability management, licence compliance, and supply chain security.
Which SBOM formats are recognised under the CRA?
The Cyber Resilience Act does not prescribe a specific format, but in practice two standards have become established: SPDX (Software Package Data Exchange), an ISO/IEC standard (ISO/IEC 5962:2021) originally developed by the Linux Foundation, and CycloneDX, an OWASP project particularly optimised for security use cases with VEX integration. Both formats are available in JSON, XML, and other serialisations. ENISA and BSI recommend both formats as acceptable implementations. CycloneDX is often preferred because it natively supports vulnerability information and VEX statements.
Who must create an SBOM?
Under the Cyber Resilience Act (Art. 13), all manufacturers of products with digital elements are required to create SBOMs - this covers both hardware products with firmware/software and pure software products placed on the market independently. Importers step into the manufacturer role when the manufacturer is located outside the EU. For NIS-2-affected operators, the SBOM is an important foundation for supply chain security under Art. 21 para. 2 lit. d - even without a direct legal SBOM obligation, the requirement on software suppliers is practically unavoidable.
What is the difference between direct and transitive dependencies?
Direct dependencies are components explicitly referenced in source code or package manifests (e.g. package.json, pom.xml, requirements.txt). Transitive dependencies are dependencies of dependencies - packages required by direct dependencies, without being referenced in your own code. In modern applications, transitive dependencies account for 80-95% of all included packages. Log4Shell was a classic transitive dependency problem: many products contained Log4j not directly, but through several layers of dependencies.
What is VEX and what is it used for?
VEX (Vulnerability Exploitability Exchange) is a document format that supplements SBOMs with contextual information on the exploitability of known vulnerabilities. For each CVE known in an SBOM component, a VEX statement can indicate: "not_affected" (the vulnerable code location is not executed), "affected" (affected and action required), "fixed" (resolved in version X), or "under_investigation". VEX significantly reduces the problem of massive false positives: an application can contain a component with 50 known CVEs, of which only 3 are actually exploitable in the specific usage context. VEX makes these statements formal and machine-readable.
How is an SBOM integrated into CI/CD pipelines?
SBOM generation should be fully automated as part of the build process. Typical tools: Syft (Anchore) for container images and filesystem SBOMs, CycloneDX-CLI for polyglot projects, Trivy for combined SBOM generation and CVE scanning. In the CI/CD flow: (1) build step generates SBOM, (2) security gate compares SBOM against CVE databases and checks policy rules (e.g. no CRITICAL CVEs without VEX approval), (3) SBOM is signed as a build artifact (Cosign/Sigstore), (4) SBOM and VEX are versioned and archived with the release. Result: every release contains a demonstrable, integrity-secured SBOM.
What patch SLAs apply to SBOM-identified vulnerabilities?
BSI TR-03183 (Cyber Resilience Requirements for Manufacturers and Products) defines recommendations for patch response times: CRITICAL (CVSS 9.0-10.0): within 24-72 hours, or at least within 6 months for regular patches. HIGH (CVSS 7.0-8.9): within 30 days. MEDIUM and LOW: risk-based, typically 90-180 days. The CRA additionally requires manufacturers to provide security updates free of charge and promptly for at least 5 years. Actively exploited vulnerabilities must be reported to the national competent authority within 24 hours (from September 2026).
How do SBOM and NIS-2 supply chain security relate?
NIS-2 Art. 21 para. 2 lit. d requires affected entities to secure the supply chain. For software-intensive organisations, this means: evaluating the security maturity of all software suppliers, requesting SBOMs from key suppliers, checking for known vulnerabilities (CVE scanning), and monitoring SBOM suppliers for new vulnerabilities. Organisations that manufacture products themselves must additionally fulfil CRA SBOM obligations. NIS-2 and CRA together create a complete SBOM cycle in the supply chain.
What does SBOM implementation cost?
The effort for SBOM implementation depends on the number of products, the technology diversity, and the current maturity of CI/CD processes. For a single product with an established CI/CD pipeline, an initial SBOM toolchain integration is achievable in 2-4 weeks (EUR 15,000-40,000). Ongoing costs include: CVE monitoring tools (Grype, Trivy, commercial: Dependency-Track), VEX maintenance, and the process effort for vulnerability assessment and patch management. Companies that start early have a significant advantage over those that must act shortly before the CRA deadline.
What open-source tools exist for SBOM management?
Established open-source tools for the SBOM ecosystem: SBOM generation: Syft (Anchore), CycloneDX-CLI, SPDX-tools, Trivy. CVE scanning: Grype (Anchore), Trivy, OSS-Review-Toolkit (ORT), OWASP Dependency-Check. SBOM management and VEX: OWASP Dependency-Track (the reference implementation for continuous SBOM management), SW360 (Eclipse Foundation). Artifact signing: Sigstore/Cosign (Linux Foundation), Notary v2. The SBOM tooling ecosystem is growing quickly - AWARE7 advises on tool selection and integration based on your specific technology stack and compliance requirements.
Aus dem Blog
Weiterführende Artikel
Alle ArtikelDevelop Your SBOM Strategy Together
In a free 30-minute conversation, we analyse your current SBOM maturity, review your regulatory requirements (CRA, NIS-2, DORA), and develop a concrete roadmap for a production-ready supply chain security strategy.
Kostenlos · 30 Minuten · Unverbindlich
