The Moment That Changed Everything
It was a Tuesday morning in April 2024. An email from risk management lands in my inbox: “Stefan, are we affected by the XZ Utils backdoor? We need an answer by noon today.”
I know colleagues at other companies who were sweating in front of their laptops at that exact moment, manually digging through their repo landscape. At our place: a single report in TrustSource, filtered down to the affected package, cross-checked against our SBOM snapshots - under three minutes, and I had a complete answer for all 120 active products.
That is the difference between an SBOM as a living operational asset and the classic “we have an inventory list somewhere in a spreadsheet.” When XZ hit, the CRA and NIS2 were still abstract Brussels concepts for many teams. Today they are reality. And any organization without structured SBOM management does not just have a compliance problem starting in 2026, it has an operational one.
The mindset shift we went through in our OSPO: an SBOM is not a PDF for the auditor. It is the nervous system of your supply chain hygiene.
What the Regulation Actually Requires, and What It Doesn’t Say
The Cyber Resilience Act makes machine-readable SBOMs mandatory for every “product with digital elements,” starting at market entry, not whenever the auditor happens to knock. That is a fundamental difference from what many teams still expect. This isn’t a one-time documentation exercise, it’s continuous proof.
NIS2 raises the pressure on critical supply chains even further: affected organizations must be able to show which components they use and what their current vulnerability status looks like. Without an SBOM, that simply doesn’t scale.
A solid starting point is BSI TR-03183, which spells out concretely what belongs in an SBOM, from SPDX ID and license information to the relationship types between components. Genuinely useful, but in our setup this has long since been automated. TrustSource generates SBOMs that meet these requirements out of the box. No manual rebuild required.
SBOM Content per BSI TR-03183 - What Actually Belongs In It
The mandatory fields under TR-03183 Tier 1 and 2 sound manageable at first glance: package name, version, supplier, unique identifier (PURL or CPE), declared license, copyright. Trivial? In practice, legacy components are regularly missing 30 to 40 percent of these fields, something we see in every SBOM audit we run on new projects.
That’s why we introduced a hard quality gate: no merge without a green checkmark in TrustSource. The pipeline automatically checks whether every TR-03183-relevant field is populated. What used to be a manual compliance review that took weeks is now an automated check that takes seconds.
The SBOM as a Living Operational Asset, Not a Snapshot
The biggest misconception I still hear: “We do that once per release.” That’s about as useful as a fire extinguisher parked at the entrance of a huge building.
In our setup, every CI/CD build produces a new SBOM snapshot that is automatically stored in TrustSource. That has two immediate benefits.
First, we catch component drift immediately. TrustSource even raises an alarm on unexpected version jumps, exactly the pattern that shows up in dependency confusion attacks. That attack vector is subtle and nearly impossible to spot without automated SBOM monitoring.
Second, vulnerability correlation happens in real time. New CVEs are automatically checked against our SBOM data. During Log4Shell, we had a complete impact list within 5 minutes, for all 120 products at once. We knew exactly which versions were affected, and which weren’t. No manual searching, no guessing.
One more effect I underestimated at first: we now deliver machine-readable CycloneDX files on demand to our OEM customers. What started as compliance overhead has since become a genuine sales argument. Customers from the automotive and industrial space actively ask for it.
Making Supply Chain Risk Tangible - Numbers From Our Setup
After three years of running TrustSource in production, we have solid data. A few numbers I regularly use in management reporting:
- 68% of our components are transitive. Anyone who only tracks direct dependencies is blind to the biggest attack vector. Without a complete dependency graph, supply chain security is an illusion.
- License compliance findings dropped by more than 80% since we started running policy-as-code in the SBOM workflow. Developers get feedback directly in the pipeline, not six weeks later in legal review.
- Time-to-detect for critical findings (CVSS >= 9.0 with a known exploit) dropped from an average of 12 days to under 4 hours. That’s the difference between a controlled incident response process and a crisis night.
Common Pitfalls When Building an SBOM Program - and How We Solved Them
“We have too many repos.” That’s the argument I hear most often for why getting started feels too complex. My answer: don’t start with the entire portfolio. SBOM coverage of 20% of the right assets, meaning production-critical services and anything exposed externally, gets you further than 100% coverage on internal test projects.
Tool fragmentation is a real problem. Different scanners produce inconsistent PURLs, and once you try to consolidate SBOMs from three different tools, you get chaos fast. Normalization is mandatory before you start aggregating. TrustSource handles this automatically; anyone solving it without a platform can use ts-scan on GitHub as an open source foundation.
Organizational resistance is an often underestimated obstacle. The classic mistake: push the SBOM topic onto the compliance team and hope it scales from there. For us, it only worked once we folded the topic into our security champion program. Once developers see that an SBOM lets them run vulnerability triage in minutes instead of days, no more convincing is needed.
Conclusion & Next Steps: Your SBOM Roadmap for 2026
Three actions I recommend to every team - all three achievable within a single sprint:
- Adopt BSI TR-03183 as your quality benchmark. Not as a bureaucratic checkbox exercise, but as a concrete quality criterion for every SBOM you generate.
- Integrate SBOM generation into every CI/CD pipeline. Every build, every snapshot, stored automatically. No exceptions.
- Automate vulnerability matching. Manual CVE tracking is no longer an option in 2026.
2026 will be the year customers and regulators stop merely appreciating SBOMs and start actively demanding them: as a contract clause, a delivery condition, a regulatory proof point. Whoever invests in their SBOM infrastructure now will be able to deliver on demand. Whoever waits will have to retrofit under time pressure.
The best time to start an SBOM strategy was two years ago. The second best time is now.
If you want to gauge your own SBOM maturity without a months-long evaluation: a TrustSource demo takes 30 minutes and shows you concretely where you stand and what the next realistic step looks like. That is exactly what I wish someone had shown me before I got started myself.
User experience report. TrustSource end customer. Not compensated.