Why a Bill of Materials matters for software and AI

(A talk by Dr Nick Allott, CEO NquiringMinds at Kellogg College, University of Oxford)

A software bill of materials, or SBOM, is simply a list of ingredients for a software system. Think of it like food labelling: you want to know whether the thing you are buying contains nuts or other allergens. For software, an SBOM tells you which components and dependencies are inside the product you are running or shipping, and it is the practical foundation for managing supply chain risk.

Regulators in the EU and the US are already pushing SBOMs into policy and procurement. Whether you like the idea or not, it is becoming part of how organisations buy, secure and certify software. Beyond regulation, SBOMs are useful because they make otherwise intractable problems measurable and actionable.

If you don’t solve labelling and versioning properly, all of the other stuff people talk about in trustworthy AI becomes relatively meaningless.

Core use cases for SBOMs

• Vulnerability management – identify which software components map to known CVEs and prioritise fixes.
• Export and foreign ownership risk – determine whether components create regulatory or national security exposure.
• Licensing risk – spot viral or restrictive licences (for example GPL) that could contaminate a product.
• Long‑term liability and support – understand how much of your product is third party so you can budget maintenance and support obligations.

These are not theoretical. Organisations can use SBOMs to answer practical questions: which devices are affected by a newly disclosed vulnerability, which suppliers use components from a flagged jurisdiction, and how much of a product’s codebase is third party.

Turning SBOMs into measurable vulnerability analysis

A useful analytical flow turns binaries into an SBOM, maps components to CPEs (Common Platform Enumerators), maps CPEs to CVEs (vulnerabilities), and then to CWEs (vulnerability types). By filtering CWEs you care about, for example memory‑safety weaknesses, you can put a number on the potential risk in a product.

That numerical picture supports several concrete capabilities:

• Build a business case and prioritise engineering work by impact rather than intuition.
• Triaging for development teams so they focus on the highest real risk first.
• Procurement scoring: require suppliers to provide an SBOM and use it to compare risk across offers.
• Network onboarding: refuse to connect devices whose SBOMs exceed a risk threshold.
• Emergency response after critical disclosures (for example Log4j) – quickly find and patch affected assets.

Introducing the concept of vulnerability surface

The notion of an attack surface is often fuzzy. A more precise, countable concept is the vulnerability surface, the list of known vulnerabilities that apply to your system.

Three useful views of vulnerability surface:

1. Envelope – the maximum set of CVEs that could apply when you aggregate CVE lists against components.
2. Active – the subset of those vulnerabilities that are actually exploitable in your specific deployment (harder to determine).
3. Predicted – which components historically generate more high‑severity vulnerabilities and so are likely to produce future risk.

Knowing the envelope is straightforward. Determining the active set requires additional analysis such as VEX declarations (Vulnerability Exploitability eXchange) or contextual verification. Predicted risk comes from empirical patterns across components and can guide long‑term remediation and architecture choices.

From SBOM to TAIBOM – why AI needs its own Bill of Materials

AI systems are software, but they bring large and distinct data and model dependencies. A simple inference system contains layers of risk – hardware, OS and runtime, the inference code and configuration, and the learned weights. The weights themselves are massive data objects & the training data behind them is another large dependency.

Two observations make the problem worse. First, models are dynamic – they can be retrained and updated. Second, the value chain is distributed – data owners, trainers, infrastructure providers and integrators are often different organisations. Risk in a training environment can propagate into an inference deployment even if the two are air‑gapped.

Key AI‑specific challenges

• Stability and versioning – how do you assert that the labelled model is the same one running in production?
• Dimensionality – models and datasets run to terabytes or petabytes; labels must scale.
• Air‑gap and provenance – training and inference may be isolated and spread across suppliers.
• Distributed responsibility – who signs which claim about data quality, curation or fairness?

What TAIBOM should provide

TAIBOM is not an attempt to fully describe every possible characteristic of an AI system. It is a pragmatic, cryptographically anchored way to label and version components, describe dependencies, and attach attestations that can be propagated through a distributed supply chain.

Use cases mirror SBOMs but extend into data and model territory:

• Data poisoning and data pollution – identify whether training data has been compromised or contains inadvertent corruption.
• Performance and regression checks – confirm that deployed models still meet certified accuracy or behaviour metrics.
• Licensing and copyright risk – track whether training data had appropriate rights or triggered copyright disputes.
• Trust and fairness attestations – attach signed claims about curation practice, bias testing, or explainability checks at the artefact level.
• Supply chain transparency – enable downstream consumers to query provenance, version and attestations across the chain.

How TAIBOM works in practice

The approach is straightforward and deliberately technology agnostic. Each artefact – training data, model weights, code, configuration – is labelled, versioned and cryptographically signed. Verifiable credentials or digital certificates are used to sign assertions about those artefacts.

Dependencies between artefacts are themselves signed constructs. That means an inference package can carry signed pointers to the SBOM of the runtime, the model weights, and the training SBOM. Queries can then be executed over this graph of signed statements to answer operational questions such as:

• Has the model been retrained since certification?
• Was the training dataset signed and its licences acquired?
• Did the data curation follow a declared best practice?
• Are there any CVEs in the training environment that could have contaminated the weights?

The emphasis is on being distributed. There is no need for a single central database. Instead the system is composed of many signed, verifiable fragments that can be stitched together and queried by any party who needs to assess trust.

Practicalities and next steps

SBOMs are not perfect, but they are useful and increasingly required. Organisations should treat SBOMs as foundational security practice – they enable vulnerability analysis, supply chain transparency and more informed procurement.

For AI systems, the same principle extends to data and models. Label, sign, and version artifacts, describe dependencies and attach attestations that downstream consumers can verify. Doing so turns many subjective trust claims into machine‑executable queries and makes continuous assurance feasible in distributed ecosystems.

Final thought

Adopt SBOM practices now and extend them for AI. The technical building blocks exist – component enumeration, CVE/CWE mappings, verifiable credentials and signed provenance. The remaining work is collective: defining interoperable labels, scaling signing practices, and embedding these flows into procurement, development and operational processes.