AIBOM vs SBOM: What's the Difference and Why You Need Both
An SBOM lists your software packages. An AIBOM lists your models, datasets, and AI API calls. Here is where the line sits and why you need both.
- An SBOM inventories software packages, versions, and licenses. An AIBOM inventories models, datasets, fine-tuned weights, and the AI APIs your code calls.
- An SBOM will not flag a call to an external model API or a weight file sitting in your repo. That blind spot is exactly what an AIBOM covers.
- The EU AI Act drives the need for an AIBOM; the EU CRA and US EO 14028 drive the need for an SBOM.
- CycloneDX supports both, so you can produce them in one format and one pipeline instead of two.
- Most teams keep both: the SBOM for the code supply chain, the AIBOM for the AI supply chain.
You already ship an SBOM. Then someone in your org wires an LLM into a product feature, and a regulator or a customer asks a new question: what AI are you actually running, and where did it come from? You open your SBOM to answer, and it has nothing useful to say.
That gap is the whole reason the AIBOM exists. An SBOM is a list of the software packages a system depends on. An AIBOM is a list of the AI parts a system depends on. They are built on the same idea, write down what is in the system, but they describe different layers, and one cannot stand in for the other.
What an SBOM actually covers
An SBOM (Software Bill of Materials) is the dependency inventory most security teams already know. For every component your software pulls in, it records the name, the version, the supplier, and the license. It is what lets you answer "are we affected by the latest OpenSSL CVE" in minutes instead of days.
It is good at what it does. The catch is its scope: it sees packages. A model is not a package, and an API call is not a package, so neither shows up.
What an AIBOM covers that an SBOM does not
An AIBOM (AI Bill of Materials) records the AI-specific components an SBOM walks straight past:
- Models you load locally, including the provider, the model card, and the license.
- Models you call over an API, like an OpenAI or Anthropic endpoint, which leave no package trace at all.
- Training and fine-tuning datasets, with their provenance.
- Fine-tuned weights you produced, linked back to the base model they came from.
- The ML libraries (transformers, torch, tensorflow) that an SBOM does catch, kept alongside the rest so the AI picture is in one place.
Rule of thumb: if it arrives through your package manager, the SBOM has it. If it arrives as a weight file, a dataset, or an HTTP call to a model, you need an AIBOM to see it.
AIBOM vs SBOM at a glance
| SBOM | AIBOM | |
|---|---|---|
| Inventories | Software packages and libraries | Models, datasets, weights, AI APIs |
| Records per item | Name, version, supplier, license | Provider, model card, training data, risk tier |
| Sees external API calls? | No | Yes |
| Sees a weight file in the repo? | No | Yes |
| Main driver | EU CRA, US EO 14028 | EU AI Act |
| Common format | CycloneDX, SPDX | CycloneDX ML-BOM |
Two examples of what an SBOM misses
First, the API call. A service imports the openai library and calls a chat endpoint. Your SBOM correctly lists the openai package. What it cannot tell you is which model the code asks for, that the call leaves your network, or that prompts and responses cross a third party. That context lives in the code, not the dependency list, and it is the part a risk reviewer cares about.
Second, the weight file. A teammate commits a 4 GB fine-tuned checkpoint into the repo. It is not in package.json or requirements.txt, so the SBOM never mentions it. But it is a model, it has a base model and a license behind it, and it ships in your product. The AIBOM is what records that it exists and where it came from.
“You cannot govern what your inventory cannot see. An SBOM that is blind to model API calls is not wrong, it is just answering a different question.”
When each one is required
The drivers are different, which is another reason you end up keeping both.
For SBOMs, the pressure comes from software supply chain rules: the EU Cyber Resilience Act and US Executive Order 14028 both expect software producers to know and disclose their components.
For AIBOMs, the pressure comes from the EU AI Act. It entered into force on 1 August 2024, with most obligations applying from 2 August 2026 and the high-risk system rules following later. It does not use the word "AIBOM," but it requires providers of high-risk systems to keep detailed technical documentation covering the models, the training data, and the risk measures. An AIBOM is the structured artifact that holds that information and keeps it current.
Do you really need both?
If you ship software, yes to the SBOM. If that software loads or calls AI, yes to the AIBOM too. They do not overlap enough to skip one. The SBOM answers "what code are we running," the AIBOM answers "what AI are we running," and an auditor or an incident will eventually ask both.
The good news is you do not need two separate programs. CycloneDX supports both a standard SBOM and an ML-BOM (its name for an AIBOM) that represents models, datasets, and configurations with provenance. One format, one toolchain.
If you are starting from scratch, generate the SBOM first since the tooling is mature, then layer the AIBOM on the same scan rather than running a separate AI audit by hand.
How O3 produces both from one scan
O3 reads your codebase the way a reviewer would. The same pass that builds the SBOM also picks up AI library imports, model config and environment variables, weight files, and the outbound API calls your code makes. Each AI component lands in the AIBOM with its provider, version, and where it is used, alongside a risk tier for the system.
It runs in CI (GitHub Actions, GitLab, Jenkins, or the CLI), so both inventories regenerate on every build instead of going stale the moment someone adds a model or a package. You get the code supply chain and the AI supply chain from one place.