SBOMs as Living Risk Infrastructure

In November, we hosted our annual SCANOSS workshop in Athens, bringing together practitioners, policymakers and technical leaders working at the forefront of software transparency. Among our guest speakers was Allan Friedman, internationally recognised for helping shape the global Software Bill of Materials (SBOM) movement and widely regarded as a leading authority on supply chain security.

During the discussion, Friedman noted that “we’ve won”. SBOM is no longer controversial. It is endorsed by governments, embedded in sectoral standards and referenced in regulatory frameworks across multiple jurisdictions. Yet he also cautioned that success carries its own risk: SBOM could “end up just becoming a very, very small part, you know, a box that we have to tick without really making a difference”.

That observation aligns closely with what we see across the market.

SBOM has crossed the policy threshold. The question now is whether SBOM will remain a compliance artefact, or mature into a live operational signal embedded across security, engineering and procurement workflows.

The NTIA SBOM Minimum Elements established a shared baseline. CISA’s updated guidance strengthened expectations around hashes, licence data, tool disclosure and generation context. PCI DSS 4.0 effectively embeds SBOM requirements within payment ecosystems. The EU Cyber Resilience Act is moving in a similar direction.

However, regulatory adoption does not equal operational maturity. Producing an SBOM does not automatically make it actionable.

The first maturity gap is definitional. Firmware, runtime components, cloud services, third-party calls and operating system layers all complicate scope. Policymakers may say “everything”, but engineering teams must define boundaries that are defensible and repeatable. Without clarity around generation context and coverage, two SBOMs for the same product can diverge materially.

The second gap is data quality and harmonisation. The Carnegie Mellon SBOM plugfest showed that different tools generate significantly different outputs for the same software. Friedman noted that meaningful comparison can require statistical analysis to distinguish signal from noise. Variation is expected in software analysis, but unmanaged variation undermines trust and downstream use.

SPDX and CycloneDX interoperability discussions have matured.

Translation tools exist. Serious vendors support both. The real differentiator is identifier precision, dependency depth accuracy, reproducible hashing and transparent generation logic. As Friedman remarked, “a block file is not transparent”. In other words, simply exporting a static file without context, consistency or integration does not provide visibility. Transparency requires structured, reliable and consumable data that systems can act upon. Maturity will be measured by consistency and reliability, not by the mere existence of a file.

The third gap is integration. In practice, many organisations generate SBOMs during release cycles and store them in repositories to satisfy potential audit requests. Once saved, they are rarely revisited. That approach may satisfy documentation requirements, but it does not support active oversight. As Friedman argued, transparency functions as an early warning mechanism, not a filing exercise. An SBOM only creates value when it connects to decision-making systems.

This is where Vulnerability Exploitability eXchange (VEX) becomes critical. Composition data and issue intelligence evolve at different speeds. Embedding vulnerability data directly inside SBOM artefacts risks stale information. VEX provides contextual exploitability signals. Friedman described it as a way of “addressing and prioritizing vulnerabilities that don’t matter”. SBOM defines structure; VEX refines relevance.

AI-generated code intensifies the need for this shift. Friedman warned about “slop forking”, where AI systems replicate vulnerable patterns without preserving traceability. This increases uncertainty around provenance and lifecycle responsibility.

Static PDF attachments are no longer credible. Enterprises expect machine-consumable artefacts that integrate directly into vulnerability management and asset inventory platforms. Friedman suggested that within two to three years, organisations should not be searching for standalone SBOM consumption tools. SBOM ingestion should be native to existing security systems. Vendors that fail to integrate downstream risk seeing their SBOM outputs archived for compliance rather than used for decision-making.

Geopolitical factors add another dimension. Country-of-origin considerations remain sensitive, yet export controls and supply chain scrutiny are intensifying. Provenance data, handled responsibly, may become part of composition intelligence strategies. SBOM data models must be flexible enough to accommodate such signals without becoming politicised instruments.

Positioning SBOM as living risk infrastructure requires three commitments. First, dual-standard support combined with rigorous identifier resolution and harmonisation logic. Second, measurable data quality and reproducibility rather than superficial coverage metrics. Third, deep integration with downstream ecosystems so that SBOM data informs governance, procurement and operational oversight.

SBOM adoption was phase one. Regulatory embedding is phase two. Dynamic operational integration is phase three. There is a baseline expectation that vendors selling into critical infrastructure should be able to explain what is inside their software.

If your SBOM strategy ends at document generation, you are operating below the emerging maturity curve. The expectation now is continuous composition awareness and defensible decision-making.

If you want to assess whether your SBOM capabilities function as a living risk signal rather than a compliance artefact, speak with our team. Organisations that operationalise transparency will define the next standard of software supply chain resilience.

SBOM is the structural foundation. From there, organisations can extend depth into Cryptography Bills of Materials (CBOMs) or AI Bills of Materials (AIBOMs), layering specialised intelligence on top of composition visibility. The evolution toward broader xBOM strategies begins with getting SBOM right.