In a talk at QCon London 2026, Viktor Petersson argued that software teams are running out of time to adopt SBOMs (Software Bills of Materials) due to pending legislative changes in both the US and Europe.
Petersson, founder of sbomify and co-founder of digital signage platform Screenly, drew on three years of experience building SBOM tooling by walking through the current regulatory landscape, and spoke on the practical mechanics of generating high-quality SBOMs and on the emerging standards for distributing the resulting artefacts.
“SBOMs have become the litmus test of knowing what goes into your software.”
— Viktor Petersson, QCon London 2026
Petersson opened by talking about the upcoming EU Cyber Resilience Act, which applies to any “product with digital elements.” Petersson described this as a deliberately catch-all phrase covering anything that connects to the internet. The first enforcement window opens in September 2026, with full compliance, including SBOM mandates, required by December 2027. He warned that CRA is more powerful than earlier frameworks such as GDPR, because it can do more than just impose fines. As Petersson put it in his talk, “CRA is not about fines. They can actually block sales. Your products can be blocked from the European market.” Germany has already implemented, with other EU member states expected to follow.
He also mentioned US Executive Order 14028, which was signed in 2021. This made SBOMs a procurement condition for any organisation selling software to the federal government. The FDA requires them for medical devices sold in the US market, and PCI-DSS 4.0 mandates SBOM production for companies in the payment card industry. Petersson predicted that SOC 2 and ISO frameworks will follow in due course.
Petersson went on to discuss formats for SBOMs, explaining that there are two dominant standards that overlap somewhat: SPDX, developed by the Linux Foundation from 2010 onwards and widely used in operating systems and embedded environments, and CycloneDX, created at ServiceNow in 2017 and more prevalent at the application dependency layer. He mentioned a myth that one is for security and the other for licence compliance, but since both formats can handle both tasks, teams tend to choose one based on where in the stack they operate, rather than one or the other having a functional gap. Both tools output in JSON and XML.
Petersson talked at length about his work on defining and implementing processes and tools for generating and distributing high-quality SBOMs. He co-chaired a working group within CISA to produce a white paper on high-quality SBOM generation, with the constraint that all recommended tooling must be open source. The resulting blueprint splits the process into four stages: creation, augmentation, enrichment, and signing, and he explained some of the options available for each.
For SBOM creation, generic tools such as Syft and Trivy are convenient and widely adopted, but Petersson argued that domain-specific tools, such as CycloneDX’s Python or Rust generators, produce higher-quality output. He warned against using a common shortcut: pointing a generic scanner at a large Docker container and treating the result as complete. “The quality would be really bad,” he said. “A much better path is to break out these individually and have separate SBOMs for each.”
Signing is the step most teams skip, and Petersson was direct that this is a mistake. He asserted that the specific tool used matters less than the act of signing itself. Cosign has emerged as a common choice, but the core principle is that signing in CI when the code is generated allows a verifiable chain of custody back to the attestation.
“Any signing is better than no signing. Do sign your SBOMs in your pipeline, not on somebody’s machine.”
— Viktor Petersson, QCon London 2026
The lifecycle dimension of SBOM management is where Petersson believes most teams have the biggest gaps, with a real end-user product rarely correlating well to a single SBOM. A smart thermostat, for example, might involve a Yocto embedded OS image, a Python backend, a Node frontend, and a Docker container, each with its own artefact. Screenly itself produces around twenty SBOMs, any of which might change on a CI run. Regulators can demand an SBOM for a product version from several releases ago, which makes a versioned, managed release process for these documents as important as it is for source code. Petersson compared current practice to software development before version control: “Dealing with SBOMs today feels like managing source code in the 90s, with patches sent over email.” Petersson suggested that emailing SBOMs or uploading them to SharePoint remains a common practice.
He then talked about the Transparency Exchange API (TEA), an OWASP project co-chaired by CycloneDX creator Steve Springett, designed to address the challenge of reliably distributing SBOMs and beyond, broadly covering other security artefacts as well. TEA is currently progressing through ECMA to become a platform-agnostic ISO standard, providing a universal discovery mechanism for security artefacts based on a product identifier and a website address. He walked through how a consumer could, in theory, pick up a hardware product in a shop, look up its identifier, and programmatically retrieve its SBOMs, VEX files, and SOC 2 documents through a single API. Petersson observed that TEA has the potential to avoid every language inventing its own method for distributing SBOMs.
Petersson mentioned some common mistakes, such as generating SBOMs outside CI, skipping signing altogether, and also merging SBOMs from multiple ecosystems into one big one. He suggested that all of these are avoidable with careful process design from the start. He closed out his talk by reinforcing the message that CRA enforcement begins sooner than most teams expect, but that teams can catch up thanks to the work already done.
