Supply Chain Security | SBOM
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
Fundamentals
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.
SPDX vs. CycloneDX - Quick Comparison
CRA - NIS-2 - BSI TR-03183
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.
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 ActA 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).
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 ConsultingVEX 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.
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 SecurityA 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).
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 ConsultingBoth 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
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
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
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
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
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
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.
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
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
Stage 2 - CVE Analysis
Stage 3 - Management
Stage 4 - Signing & Provenance
Consulting Services
We guide manufacturers and operators in building a complete supply chain security strategy - from the first SBOM to a continuous vulnerability management programme.
Tool selection (Syft, CycloneDX, Trivy), CI/CD integration, format standardisation, artifact signing - from pilot installation to production operation.
Toolchain ConsultingBuilding patch SLA processes, OWASP Dependency-Track implementation, VEX programme, and continuous monitoring against NVD, OSV, and authority sources.
Vulnerability ManagementTargeted tests on supply chain attack vectors: CI/CD pipeline security, build process integrity, dependency confusion attacks, insider threat simulation.
Request PentestCreation and review of CRA-compliant SBOMs under Art. 13 - in SPDX and CycloneDX formats, including VEX statements and preparation for authority requests.
CRA ComplianceNIS-2-compliant supplier evaluation, supplier risk assessment processes, contractual clauses for IT suppliers, and monitoring programmes for key third-party providers.
NIS-2 Supply ChainTraining 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 additional audit procedure competence (Section 8a BSIG) · AWARE7 GmbH
FAQ
The most important questions about Software Bill of Materials, vulnerability management, and supply chain security - answered with technical depth.
Aus dem Blog
BSI IT-Grundschutz für KMU: pragmatischer Einstieg mit dem KMU-Profil, wichtigste Bausteine, kostenlose BSI-Werkzeuge und Unterschied zu ISO 27001.
Oskar Braun 
Supply-Chain-Sicherheit für KMU: Supply-Chain-Angriffe, SBOM, SLSA, Dependency-Confusion und praktische Schutzmaßnahmen erklärt.
Jan Hörnemann 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.
Free · 30 minutes · No obligation
Arturs Nikitins
Initial consultation & needs analysis
Looking for personal advice?
No obligation · Reply within 24h on business days
