AI-BOM vs SBOM: why your SBOM misses your models
If you already generate an SBOM, you might assume your AI supply chain is covered. It isn't. A conventional SBOM answers "what packages did we install?" — an AI-BOM answers "what learns, infers, or decides in this system, and where did it come from?" Those are different questions with different failure modes.
What a standard SBOM sees — and what slips through
Run a typical SBOM generator against an ML service and you get the Python and OS packages: torch 2.4.0, transformers 4.44.2, openssl, and so on. Useful. But the highest-risk artefacts in an AI system are not packages:
| Artefact | In a standard SBOM? | Why it matters |
|---|---|---|
Model weight files (.safetensors, .pt, .gguf, .onnx) | No — not installed via a package manager | Unknown provenance, unknown licence, unscanned for tampering (OWASP ML05/ML06) |
| Weights baked into container layers | No — invisible without layer inspection | The image ships to prod carrying a model nobody inventoried |
Hosted model API usage (openai, anthropic SDK calls, hardcoded model IDs) | Only as an SDK package name | The actual dependency is a third-party model that changes under you |
| Model licences (OpenRAIL, Llama licence, research-only) | No | AI model licences carry use restrictions package licences don't |
| Datasets and training-data references (DVC files, HF dataset imports) | No | Data provenance is an EU AI Act Annex IV requirement |
| GPU infrastructure (Terraform/K8s GPU requests) | No | Cost and capacity are part of the system description regulators expect |
Each row is something the EU AI Act's Annex IV Section 2 or a serious security review will ask about, and each is invisible to a package-manager walk.
What an AI-BOM adds
An AI-BOM scanner starts from the same manifests an SBOM tool reads (requirements, lockfiles, package.json, go.mod) but adds AI-specific detection:
- Weight-file detection by extension and well-known sentinel names (
pytorch_model.bin,model.safetensors), including inside OCI image layers — no Docker daemon needed - Model ID extraction from source (hardcoded
gpt-4o,claude-sonnet-4-6, HF repo IDs) so hosted-model dependencies are first-class inventory entries - AI-aware risk enrichment: each component cross-referenced against OWASP ML Top 10, MITRE ATLAS, and live CVE/GHSA feeds —
langchainis not just "a package", it is a prompt-injection surface - Licence capture for models, where restrictions differ materially from OSS package licences
- Infrastructure telemetry: GPU instance types with cost estimates, because "computational resources" is literally an Annex IV line item
Not either/or: the two compose
This is not an argument to replace your SBOM. The right shape is an AI-BOM that *exports to* the SBOM standard your security tooling already ingests. CycloneDX 1.5 has model-card and ML extensions, so AI components can ride the same rails as everything else — Dependency-Track, GUAC, procurement portals. (We cover the export workflow in the CycloneDX guide.)
Who is asking for AI-BOMs
- EU AI Act auditors — Annex IV Section 2(a) requires documenting "pre-trained systems and components used". That is an AI-BOM by another name.
- Enterprise procurement — AI-usage questionnaires are now standard in vendor security review; an generated, current AI-BOM answers them in one attachment.
- Your own security team — the first question after any model-supply-chain CVE (and there is one every few months now) is "do we run this anywhere?" An inventory that regenerates per commit answers in seconds; a spreadsheet answers in panic.
The operational rule
Inventories rot at the speed of your merge rate, so the only AI-BOM worth having is the one generated by the pipeline. One CI job, running on every push, emitting the inventory plus the risk register — that is the whole setup. The AIcap CLI does exactly this (free, MIT-licensed, and your source never leaves the runner); the GitHub Actions tutorial in this series has the copy-paste workflow.
AIcap generates your AI-BOM, risk register, and Annex IV draft from a single CI run — free CLI, EU-hosted ledger.
Get started free →