12 min Reading Time<\/p>\n
Deutsche Bahn alone manages 500,000 software bills of materials. What sounds like bureaucracy will become mandatory for every manufacturer of digital products in the EU from September 2026. Those who fail to prepare risk fines of up to 15 million Euro – and exclusion from the European market.<\/strong><\/p>\n Your security team faces a concrete challenge: From 11 September 2026, all manufacturers of products with digital elements must report actively exploited vulnerabilities to ENISA within 24 hours. Without an up-to-date SBOM, this is simply impossible. After all, if you don\u2019t know which components are in your software, you can\u2019t assess whether a new vulnerability affects your product.<\/p>\n The average detection time for supply chain infiltrations currently stands at 287 days. Nearly ten months during which attackers operate undetected in compromised systems. An SBOM drastically reduces this timeframe because it enables an immediate query: Do we use the affected library? Which version? In which product?<\/p>\n Sources: BlackBerry Global Threat Intelligence Report 2024; IBM\/Ponemon Cost of a Data Breach 2025; Verizon DBIR 2025<\/p>\n<\/div>\n A Software Bill of Materials documents all components, libraries, and dependencies in a software product. Think of it like the ingredients list on food packaging – only for code. The CRA defines it as a \u201cformal record containing details and supply chain relationships of the components contained in the software elements.\u201d<\/p>\n Important: An SBOM is not a security audit. It makes transparent what has been built – not whether it is secure. But without this transparency, systematic vulnerability assessment is impossible. Only the combination of SBOM and VEX (Vulnerability Exploitability eXchange) provides a complete picture: The SBOM lists the components, while VEX assesses whether a known vulnerability is actually exploitable in the specific context of use.<\/p>\n The EU Cyber Resilience Act phases in obligations in two stages:<\/p>\n From 11 September 2026:<\/strong> Mandatory reporting of actively exploited vulnerabilities to ENISA within 24 hours. This applies to products already on the market. Without an SBOM and automated vulnerability tracking, this deadline is practically impossible to meet.<\/p>\n From 11 December 2027:<\/strong> Full SBOM obligation for all products with digital elements marketed in the EU. The bill of materials must be provided in a machine-readable format and cover at least the top-level dependencies. Non-compliance risks fines of up to 15 million Euro or 2.5 percent of global annual turnover.<\/p>\n In parallel, the BSI (Federal Office for Information Security), as the future market surveillance authority, has published Technical Guideline TR-03183-2. It goes beyond the EU\u2019s minimum requirements, demanding cryptographic checksums, license identifiers, and signature mechanisms, among other things.<\/p>\n \u201cThe CRA is a game-changer for the security of digital products!\u201d<\/p>\n – Claudia Plattner, President of the Federal Office for Information Security (BSI)<\/p>\n<\/blockquote>\n For IT managers and CISOs, a very concrete question arises: How do we implement this? The answer depends on your own software landscape, the maturity of your CI\/CD pipelines, and the available budget. Three options have proven effective in practice.<\/p>\n For whom:<\/strong> Companies with modern development processes, container-based deployments, and an established DevSecOps culture.<\/p>\n How it works:<\/strong> Tools like Syft, Trivy, or cdxgen are integrated directly into the build pipeline. With every build, an SBOM in CycloneDX or SPDX format is automatically generated, versioned, and stored centrally. The SBOM updates automatically with every release.<\/p>\n Pros:<\/strong> Lowest ongoing effort, highest currency, scales with the number of products. According to ENISA, this is the recommended approach for companies with more than ten software products.<\/p>\n Cons:<\/strong> Initial integration work (2-4 weeks per pipeline), requires DevOps expertise, legacy systems without CI\/CD are left out.<\/p>\n For whom:<\/strong> Mid-sized companies with a mixed software landscape. Some products run in modern pipelines, while others are legacy systems without automation.<\/p>\n How it works:<\/strong> Modern products are captured automatically (as in Option 1). For legacy software, SBOMs are generated using binary analysis tools like FOSSA or Mend, which scan finished binaries. A security analyst reviews and supplements the results manually.<\/p>\n Pros:<\/strong> Covers the entire product landscape, realistically implementable with existing teams, fully complies with BSI TR-03183-2.<\/p>\n Cons:<\/strong> Higher ongoing personnel costs, manual steps are error-prone, review cycles slow down releases.<\/p>\n For whom:<\/strong> Small software manufacturers with few products and no in-house DevOps team.<\/p>\n How it works:<\/strong> SBOMs are created manually based on ENISA templates and BSI requirements. Developers document used libraries and versions in a structured table, which is then converted into CycloneDX or SPDX.<\/p>\n Pros:<\/strong> No tool investment required, quick start possible, meets the CRA\u2019s minimum requirements.<\/p>\n Cons:<\/strong> Doesn\u2019t scale, high error rate with complex dependency trees, becomes unwieldy with more than three products. ENISA explicitly warns that manually created SBOMs often fail to meet minimum quality standards.<\/p>\n Deutsche Bahn demonstrates that SBOMs work even at scale. At FOSDEM 2026, the company presented its approach: 500,000 SBOMs managed with a combination of open-source tools and custom logic, embedded in the existing enterprise architecture.<\/p>\n Three insights from the DB project are relevant for smaller companies as well:<\/p>\n SBOMs are not an end in themselves.<\/strong> DB treats SBOMs as a supporting method for various use cases – from vulnerability management and license compliance to supplier control. Those who view SBOMs merely as a regulatory checkbox miss out on operational benefits.<\/p>\n Open source suffices – with custom logic.<\/strong> DB relies on FOSS tools like Syft and Trivy, supplemented by custom logic for integration with SAP and internal systems. Expensive commercial platforms weren\u2019t necessary, but the integration work was substantial.<\/p>\n People make the difference.<\/strong> Technical tools alone aren\u2019t enough. DB emphasizes that dedicated personnel are needed to integrate SBOMs into pipelines and continuously monitor the quality of generated bills of materials.<\/p>\n Despite all the enthusiasm about regulatory progress: SBOMs don\u2019t solve all software supply chain security problems. IT managers should be aware of three limitations.<\/p>\n Fragmentation of standards.<\/strong> CycloneDX and SPDX are the two dominant formats, but they aren\u2019t fully compatible. Many companies generate both formats in parallel – CycloneDX for the security team, SPDX for the legal department. This doubles the effort without any security gain.<\/p>\n Quality issues.<\/strong> Not every automatically generated SBOM meets minimum quality standards. ENISA warns in its SBOM Landscape Report (December 2025) that software providers often fail to include relevant data simply because it isn\u2019t available. An SBOM that captures only 60 percent of dependencies creates a false sense of security.<\/p>\n Attackers adapt.<\/strong> Supply chain attacks doubled in 2025, with an average of 26 incidents per month from April 2025 onward. Attackers are increasingly targeting build pipelines themselves – the very infrastructure that generates SBOMs. A compromised build process can produce an SBOM that looks correct but is manipulated.<\/p>\n The BSI accepts both formats but recommends CycloneDX from version 1.6 or SPDX from version 3.0.1. For practical purposes:<\/p>\n CycloneDX<\/strong> is the better choice for security teams. The format offers native support for VEX, hashing, and dependency trees. Version 1.7 (October 2025) introduces additional patent metadata and enhanced cryptographic transparency. CycloneDX supports not only software SBOMs but also hardware (HBOM), AI\/ML, and cryptographic bills of materials (CBOM).<\/p>\n SPDX<\/strong> is stronger in license compliance and IP due diligence. As an ISO\/IEC 5962:2021-certified standard, SPDX enjoys higher regulatory acceptance, particularly among companies with international business.<\/p>\n Pragmatic recommendation: Start with CycloneDX for operational security. If your legal department requires SPDX, use conversion tools like cyclonedx-cli or spdx-tools. Both formats can be converted into each other, though some detail loss is possible.<\/p>\n For IT managers who want to start now, here\u2019s a concrete roadmap:<\/p>\n Weeks 1-2: Inventory<\/strong><\/p>\n Weeks 3-4: Pilot Project<\/strong><\/p>\n Weeks 5-8: Rollout<\/strong><\/p>\n Weeks 9-12: Hardening<\/strong><\/p>\n The SBOM obligation is coming. The question isn\u2019t if<\/em> but how well<\/em> your company will be prepared when the first reporting obligation takes effect in September 2026. The most pragmatic first step: Install Syft or Trivy in a test project and generate your first SBOM. It takes 30 minutes and immediately shows you how many dependencies are in your software that you weren\u2019t aware of.<\/p>\n Every question is locked. A tap unlocks the answer.<\/p>\n No. The CRA targets manufacturers – companies that place products with digital elements on the EU market. Pure users don\u2019t need to create their own SBOMs but should request SBOMs from their suppliers. The NIS2 Directive also requires critical infrastructures to document their software supply chain as part of risk management.<\/p>\n<\/details>\n For most security teams, CycloneDX from version 1.6 is the more pragmatic starting point because it offers native vulnerability and VEX support. SPDX is stronger for license compliance. The BSI accepts both formats in TR-03183-2. Many companies generate both in parallel and convert as needed.<\/p>\n<\/details>\n Tool costs can be zero since open-source tools like Syft and Trivy are production-ready. The main effort lies in integration: Expect 2-4 weeks of integration work per CI\/CD pipeline and half an FTE for ongoing monitoring and quality assurance. Commercial platforms like FOSSA or Mend start at around 15,000 Euro per year.<\/p>\n<\/details>\n It depends. Open-source software developed as a hobby project without commercial intent is exempt from the CRA. However, once a company integrates open-source components into a commercial product, it bears SBOM responsibility for the entire product – including all open-source dependencies.<\/p>\n<\/details>\n No. The CRA explicitly states that manufacturers are not required to publish their SBOMs. It must be part of the technical documentation and made available to market surveillance authorities upon request. Some companies voluntarily publish their SBOMs as a trust signal to customers.<\/p>\n<\/details>\n From the MBF Media Network<\/p>\nTL;DR<\/h2>\n
\n
September 2026: The Countdown Is On<\/h2>\n
What an SBOM Is – and What It Isn\u2019t<\/h2>\n
Regulatory Deadlines at a Glance<\/h2>\n
\n
Three Paths to SBOM: The Practical Check<\/h2>\n
Option 1: Fully Automated in the CI\/CD Pipeline<\/h2>\n
Option 2: Hybrid with Manual Review<\/h2>\n
Option 3: Manual with Template Approach<\/h2>\n
How Deutsche Bahn Does It<\/h2>\n
The Flip Side: Why SBOMs Aren\u2019t a Silver Bullet<\/h2>\n
CycloneDX or SPDX? The Format Decision<\/h2>\n
Checklist: SBOM Readiness in 90 Days<\/h2>\n
\n
\n
\n
\n
The Next Step<\/h2>\n
Frequently Asked Questions<\/h2>\n
Do companies that only use software (not manufacture it) also need to create SBOMs?<\/strong><\/summary>\n
Which SBOM format should I choose – CycloneDX or SPDX?<\/strong><\/summary>\n
What does SBOM implementation cost for a mid-sized company?<\/strong><\/summary>\n
Does the SBOM obligation also apply to open-source projects?<\/strong><\/summary>\n
Does the SBOM need to be publicly accessible?<\/strong><\/summary>\n
Further Reading<\/h2>\n
\n