SBOM Practical Check: How Your Company Implements the Software Bill of Materials by September 2026

12 min Reading Time

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.

TL;DR

• 🔒 The EU Cyber Resilience Act (CRA) will make Software Bills of Materials (SBOMs) mandatory from December 2027. First reporting obligations apply from September 2026 (EU Regulation 2024/2847).
• 📊 75 percent of all companies fell victim to a supply chain attack in 2024. Gartner’s forecast of 45 percent was too conservative (BlackBerry, 2024).
• 🛡️ The BSI (Federal Office for Information Security) specifically requires CycloneDX from version 1.6 or SPDX from version 3.0.1 as SBOM formats (BSI, 2024).
• 🏭 Deutsche Bahn manages 500,000 bills of materials using open-source tools and custom logic (FOSDEM 2026).
• ⚙️ Three implementation paths: fully automated in the CI/CD pipeline, hybrid with review, or manual for legacy software.

September 2026: The Countdown Is On

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’t know which components are in your software, you can’t assess whether a new vulnerability affects your product.

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?

What an SBOM Is – and What It Isn’t

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 “formal record containing details and supply chain relationships of the components contained in the software elements.”

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.

Regulatory Deadlines at a Glance

The EU Cyber Resilience Act phases in obligations in two stages:

From 11 September 2026: 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.

From 11 December 2027: 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.

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’s minimum requirements, demanding cryptographic checksums, license identifiers, and signature mechanisms, among other things.

“The CRA is a game-changer for the security of digital products!”

– Claudia Plattner, President of the Federal Office for Information Security (BSI)

Three Paths to SBOM: The Practical Check

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.

Option 1: Fully Automated in the CI/CD Pipeline

For whom: Companies with modern development processes, container-based deployments, and an established DevSecOps culture.

How it works: 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.

Pros: 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.

Cons: Initial integration work (2-4 weeks per pipeline), requires DevOps expertise, legacy systems without CI/CD are left out.

Option 2: Hybrid with Manual Review

For whom: Mid-sized companies with a mixed software landscape. Some products run in modern pipelines, while others are legacy systems without automation.

How it works: 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.

Pros: Covers the entire product landscape, realistically implementable with existing teams, fully complies with BSI TR-03183-2.

Cons: Higher ongoing personnel costs, manual steps are error-prone, review cycles slow down releases.

Option 3: Manual with Template Approach

For whom: Small software manufacturers with few products and no in-house DevOps team.

How it works: 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.

Pros: No tool investment required, quick start possible, meets the CRA’s minimum requirements.

Cons: Doesn’t 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.

How Deutsche Bahn Does It

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.

Three insights from the DB project are relevant for smaller companies as well:

SBOMs are not an end in themselves. 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.

Open source suffices – with custom logic. DB relies on FOSS tools like Syft and Trivy, supplemented by custom logic for integration with SAP and internal systems. Expensive commercial platforms weren’t necessary, but the integration work was substantial.

People make the difference. Technical tools alone aren’t enough. DB emphasizes that dedicated personnel are needed to integrate SBOMs into pipelines and continuously monitor the quality of generated bills of materials.

The Flip Side: Why SBOMs Aren’t a Silver Bullet

Despite all the enthusiasm about regulatory progress: SBOMs don’t solve all software supply chain security problems. IT managers should be aware of three limitations.

Fragmentation of standards. CycloneDX and SPDX are the two dominant formats, but they aren’t 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.

Quality issues. 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’t available. An SBOM that captures only 60 percent of dependencies creates a false sense of security.

Attackers adapt. 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.

CycloneDX or SPDX? The Format Decision

The BSI accepts both formats but recommends CycloneDX from version 1.6 or SPDX from version 3.0.1. For practical purposes:

CycloneDX 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).

SPDX 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.

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.

Checklist: SBOM Readiness in 90 Days

For IT managers who want to start now, here’s a concrete roadmap:

Weeks 1-2: Inventory

• Catalog all products with digital elements (including firmware, embedded software, IoT devices)
• Document existing CI/CD pipelines and build processes
• Assign responsibility (SBOM owner per product line)

Weeks 3-4: Pilot Project

• Select one product (ideally with a modern CI/CD pipeline)
• Integrate an SBOM generator (Syft for containers, cdxgen for applications)
• Generate the first SBOM and validate it against BSI TR-03183-2

Weeks 5-8: Rollout

• Extend the successful pilot to additional products
• Set up vulnerability monitoring (OSV, NVD, or commercial feed)
• Define and test the process for the 24-hour reporting obligation

Weeks 9-12: Hardening

• Define SBOM quality metrics (coverage, currency)
• Request supplier SBOMs and integrate them into your own bill of materials
• Build an audit trail and documentation for market surveillance

The Next Step

The SBOM obligation is coming. The question isn’t if but how well 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’t aware of.

Frequently Asked Questions

Do companies that only use software (not manufacture it) also need to create SBOMs?

No. The CRA targets manufacturers – companies that place products with digital elements on the EU market. Pure users don’t 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.

Which SBOM format should I choose – CycloneDX or SPDX?

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.

What does SBOM implementation cost for a mid-sized company?

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.

Does the SBOM obligation also apply to open-source projects?

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.

Does the SBOM need to be publicly accessible?

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.

Further Reading

• Supply Chain Security 2026: How Companies Protect Their Software Supply Chain (SecurityToday)
• NIS2 in Germany: What Companies Need to Know and Implement Now (SecurityToday)
• DORA and NIS2 Simultaneously: Compliance Double Pressure for Financial Service Providers (SecurityToday)

From the MBF Media Network

• DORA, AI Act, MiCA Simultaneously: Why RegTech Becomes a Mandatory Investment in 2026 (MyBusinessFuture)
• Cloud Trends 2026: What IT Decision-Makers Need on Their Radar Now (cloudmagazin)
• Digital Due Diligence: Why M&A Deals Fail Due to IT (Digital Chiefs)

Header Image Source: Pexels / cottonbro studio

About the author: Benedikt Langer

More articles by Benedikt Langer