From Chaos to Clarity: Modern SBOM Practices That Actually Work

Interview:

What is your session about, and why is it important for senior software developers?

This session is about how to make SBOMs (Software Bills of Materials) actually work in real engineering environments - not as a checkbox exercise, but as part of a sustainable software security workflow.

I’ll walk through what a solid SBOM strategy looks like in practice: how to generate them properly, how to keep them accurate over time, and how to integrate them into modern build and release pipelines.

For senior software developers and architects, this is becoming a core responsibility. SBOMs aren’t something you can delegate to a separate compliance or security team - they need to be embedded into how we build, ship, and maintain software.

The reality is that SBOMs are quickly becoming a baseline requirement across compliance frameworks: the Cyber Resilience Act (CRA), PCI DSS 4.0, and many more are expected to follow. The question is no longer if you’ll need SBOMs, but when.

This talk is focused on the practical side: how to do SBOMs right, avoid the common pitfalls, and treat them as an engineering capability rather than a last-minute obligation.

Why is it critical for software leaders to focus on this topic right now, as we head into 2026?

It’s critical because SBOMs are quickly becoming a baseline expectation as we head into 2026.

Regulations like the Cyber Resilience Act and frameworks like PCI DSS 4.0 are raising the bar for software transparency, while customers are demanding clearer answers about supply chain risk.

SBOMs are no longer optional - they’re becoming the litmus test of a simple question: do you actually know what goes into your software?

And they can’t be treated as a one-time document. Software leaders need systems and release processes that keep SBOMs accurate and future-proof over time.

What are the common challenges developers and architects face in this area?

A few challenges come up again and again.

First, generating high-quality SBOMs is harder than teams expect. Modern software stacks span multiple languages, build systems, and packaging ecosystems, each requiring different tools and approaches. SBOMs only become useful when they’re accurate - the value you get from them is tightly tied to the quality of what you produce upfront.

Second, the real challenge is lifecycle management. In practice, a product isn’t a single SBOM - it’s dozens of components, each with its own release cycle. SBOMs can change on every CI/CD run, which means you need an architecture and process that can handle continuous updates over time.

Tooling is still fragmented, ownership is often unclear, and most teams don’t have a system designed to treat SBOMs as living security artifacts.

You can’t just generate them once, drop them into Jira or GitHub, and call it done - this takes careful planning and the right supporting infrastructure.

What's one thing you hope attendees will implement immediately after your talk?

Be proactive and start treating SBOMs as a real engineering capability, not a future compliance problem.

The first step is to take an honest look at whether your organization has an SBOM strategy at all - or whether each team is solving it independently. Generate an SBOM with tooling that fits your stack, and review it critically. Would you feel confident handing it to a customer, a security team, or a regulator?

But don’t stop at generating an SBOM - you need to make sure you’re producing high-quality SBOMs that are accurate, complete, and trustworthy. The value you get from them depends entirely on that foundation.

Then take the next step: integrate SBOM generation and signing directly into your CI/CD pipeline, so it becomes a standard part of every build and release - not a manual afterthought.

That exercise will quickly reveal what’s missing, but more importantly, it should prompt a bigger question: do you have a coherent, company-wide plan for SBOMs and security artifacts?

The Cyber Resilience Act is coming into force sooner than most teams expect. The worst time to figure this out is at the last minute.

What makes QCon stand out as a conference for senior software professionals?

It’s one of the few conferences where the talks are truly grounded in real experience. People come to share what’s actually working, not to pitch. And the hallway conversations are just as valuable. You’ll meet other folks solving similar problems and usually walk away with a few ideas you can try right away.