AI Bill of Materials (AIBOM) Guide for Enterprise AppSec

What an AIBOM Actually Is

An AIBOM is a structured, machine-readable inventory of the components that compose an AI system. Components in this context are broader than the libraries a classical SBOM lists: an AIBOM captures the model artefact itself (architecture, parameter count, checkpoint hash), the training datasets and their licences, the fine-tuning datasets and any RLHF or DPO post-training, the embedding store and its index strategy when the system uses retrieval-augmented generation, the inference framework and runtime version, the model server and its quantisation parameters, the surrounding agent or orchestrator stack, the tool catalogue available to an agentic system, the guardrail or policy layer applied at inference, and the dependency relationships that link these pieces back to the deployed AI feature.

The reason an AIBOM exists as a defined artefact, rather than a generic JSON dump from an ML platform, is that the AI supply chain is recursive in ways the classical software supply chain is not. A first-party fine-tune sits on top of a third-party base model, which was pre-trained on web-scale data with unclear licensing, which itself uses a transformer architecture and a tokeniser shipped by a separate maintainer, and the inference framework that loads the checkpoint sits inside a container that pulls CUDA and cuDNN dependencies from yet another supplier. An AIBOM written to a defined standard is how a buyer, an integrator, an internal AppSec team, or a regulator walks the AI dependency graph quickly and decides whether a newly disclosed model vulnerability, training-data takedown, or licence dispute applies to the system they are operating.

An AIBOM is not a model evaluation report and it is not a red-team finding list. It does not say which prompts jailbreak the model, whether the model leaks PII at temperature zero, or whether the agent invokes the wrong tool when adversarially nudged. An AIBOM tells you what is in the system. The risk picture comes from running the AIBOM against a model-vulnerability data source (Hugging Face advisories, vendor model security pages, OSV-style ML advisory streams as they mature) and from layering the model card, the dataset card, the OWASP LLM Top 10 testing record, and the AI red-team output on top. The AIBOM is the inventory. The signals sit beside it.

AIBOM vs SBOM: Where the Two Documents Diverge

An AIBOM is sometimes described as an SBOM for AI, and that framing is partly correct. Both documents are inventory artefacts. Both are machine-readable. Both are produced as a side-effect of a build or release process. Both are consumed downstream by vulnerability management, audit, and procurement. The same NTIA-style minimum-elements intent that shaped SBOM uptake under EO 14028 is shaping the AIBOM conversation under the EU AI Act and the OMB memos that follow CISA Secure by Design. The continuities are real.

The discontinuities are also real, and they matter for the operator. An AIBOM captures data-side components that have no SBOM analogue. A training dataset is not a library: it has provenance, licensing, sensitive-data categorisation, and a lifecycle that can survive multiple model versions. A fine-tuning corpus may be derived from customer data with regulatory implications a library never carries. A model checkpoint is not a package: it has weights that can be analysed for memorisation, watermarked for provenance, and copied without leaving package-manager traces. An embedding store is not a dependency: it is a runtime corpus that affects the model behaviour without appearing in any classical lockfile. The AIBOM has to capture all of these.

An AIBOM is the strict superset of an SBOM when the system in question is an AI feature. The dependency libraries the classical SBOM captures still need to be there because the inference server, the tokeniser, the orchestrator framework, and the surrounding agent stack are all classical software. The model, the data, the embeddings, and the runtime policy layer extend that inventory with the components that make the system AI. Our SBOM guide covers the software-side inventory in detail and is the right starting point for any team approaching AIBOM through the SBOM door.

CycloneDX ML-BOM and SPDX 3.0 AI Profile

The two dominant machine-readable AIBOM formats are CycloneDX ML-BOM (the ML-BOM extension to CycloneDX, introduced in CycloneDX 1.5 and matured in subsequent releases) and the SPDX 3.0 AI Profile (introduced as part of the SPDX 3.0 release that split the specification into modular profiles). Both formats meet the broad AIBOM intent of capturing model, data, and runtime components in a single inventory. Both are widely referenced in the AI assurance and AI Act technical-documentation discussion. Choosing between them is not a moral question; it is a question of which fits your existing SBOM tool chain, your buyer expectation, and your regulator alignment.

A reasonable default for an AppSec-led programme that already runs CycloneDX SBOMs and VEX through an SCA pipeline is CycloneDX ML-BOM. The ML-BOM extension produces a single document that covers both the classical libraries and the AI components, which means the existing ingestion pipeline does not need a parallel path. A reasonable default for a regulated-procurement-led programme that cites ISO/IEC 5962 or that aligns its model documentation to model card and dataset card patterns is SPDX 3.0 AI Profile. The AI Profile inherits SPDX 3.0's explicit fields for intended use and training data, which map cleanly onto EU AI Act Annex IV technical-documentation expectations.

Many enterprise programmes generate both for the same artefact and let the consumer pick, in the same way mature SBOM programmes generate both SPDX and CycloneDX. The format choice is downstream of the underlying data capture: as long as the generator is recording the model identity, the dataset references, the dependency graph, and the runtime configuration accurately, converting between CycloneDX ML-BOM and SPDX AI Profile is a transformation, not a regeneration.

Model Cards and Dataset Cards: The Companions to the AIBOM

An AIBOM is a structured inventory. A model card is a structured narrative. The two documents complement each other and an AI assurance pack typically requires both. The AIBOM tells a consumer what is inside the system at a precise technical level. The model card tells a consumer what the system is meant to do, what it was evaluated for, and where it is known to perform poorly. Together they let a downstream operator answer both the inventory question (what are we running) and the behaviour question (what is it supposed to do, and how does it behave).

The original model card pattern, published in 2018 by Mitchell et al. and adopted in slightly different forms by Hugging Face, Google's Model Card Toolkit, and various vendor model registries, captures intended use, factors and metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats. The dataset card pattern, sometimes called a datasheet, captures the dataset motivation, composition, collection process, preprocessing, intended uses, and distribution. Both are pointer artefacts: they sit at a stable URL or registry path that the AIBOM references.

The audit-read benefits when the AIBOM references the model card and dataset card by stable URI rather than embedding the narrative. The model card and dataset card can evolve at their own cadence; the AIBOM pins the version of those documents that applied to a specific build. The combination produces a four-document pack: AIBOM, model card, dataset card, evaluation record. That pack maps cleanly onto the technical-documentation expectations of Annex IV of the EU AI Act and the documentation guidance in NIST AI RMF and ISO/IEC 42001.

The Signals an AIBOM Captures

An AIBOM is only useful if it captures the signals a downstream operator needs to make decisions. The defensible signal set has six layers. Programmes that try to skip a layer usually find the gap when a regulator, a buyer, or an incident asks them to prove something the missing layer would have answered.

Without model identity, you cannot prove which checkpoint was evaluated. Without training and fine-tuning data, you cannot answer a takedown notice or a data-subject request that asks whether personal data appears in the corpus. Without framework and runtime, you cannot trace a runtime vulnerability to the affected build. Without the retrieval and embedding stack, you cannot reason about the OWASP LLM08 vector and embedding weakness surface. Without the agent and tool catalogue, you cannot reason about the OWASP LLM06 excessive agency surface. Without guardrails and evaluation, you cannot connect the AIBOM to any defensible claim about model behaviour. The six layers are the floor.

How the AIBOM Reads Against the Framework Map

The AIBOM is increasingly cited across the regulatory and assurance map. The exact phrasing varies (the EU AI Act talks about technical documentation, NIST AI RMF talks about AI inventory and lifecycle documentation, ISO/IEC 42001 talks about AI system documentation, OWASP LLM Top 10 talks about model and supply chain transparency), but the underlying expectation is the same: a buyer, an auditor, or a regulator expects to see a structured record of what is in the AI system, where it came from, and how it behaves. An AIBOM written to CycloneDX ML-BOM or SPDX 3.0 AI Profile meets that expectation across the map.

The AI security posture management discussion sits one layer up from the AIBOM. Where the AIBOM is a static, build-time inventory artefact, AI posture management is the runtime read of how the inventory behaves: which models are active, which datasets are still in scope, which retrieval indexes have drifted. Our AI-SPM guide covers the operating layer that consumes AIBOM data and produces the posture read.

Generating an AIBOM: Build-Time, Registry-Time, and Runtime

There are three broad ways to produce an AIBOM. Build-time generation is the strongest and the rarest. Registry-time generation, where the AIBOM is produced at the model registry boundary, is the most common and the most pragmatic. Runtime generation, where the AIBOM is reconstructed from the running system, is necessary for shadow-AI discovery and for legacy AI features that never had a documented build.

The realistic default for an enterprise programme is a combination. Production models generate registry-time AIBOMs. Foundation models accessed through APIs use the vendor-supplied AIBOM (or the most equivalent vendor disclosure where a formal AIBOM is not yet published). Shadow-AI features discovered after the fact use runtime reconstruction. First-party fine-tunes that flow through a controlled training pipeline generate build-time AIBOMs that capture the strongest provenance. The four sources converge on the same engagement record at ingestion time.

Ingesting AIBOMs Into the AppSec and VM Programme

Generating an AIBOM is the easier half. Ingesting one (your customer AIBOMs, your vendor AIBOMs, your internal ML platform AIBOMs, your shadow-AI discovery output) and acting on the data is where most programmes stall. The ingestion problem has the same three layers as the SBOM ingestion problem (parsing, scoping, lifecycle) with three extra concerns that are unique to AI.

AIBOM and the Vulnerability Management Programme

The AIBOM connects to vulnerability management the same way the SBOM does, with two differences. The first difference is the source of the advisory data. Classical vulnerability sources (NVD, GHSA, OSV, vendor advisories) cover the libraries inside the AI runtime stack, but the model-side advisory landscape is younger and more fragmented. Hugging Face publishes model security advisories. Vendor model security pages cover their hosted foundation models. The OSV-style coverage for ML packages is improving but not yet uniform. Programmes treat the model-side advisory stream as a separate ingestion path that lands in the same finding queue.

The second difference is the nature of the finding. A classical CVE is binary: the dependency is on the affected version or it is not. A model-side finding is often behavioural: the model exhibits a known jailbreak pattern, the model leaks PII at a measurable rate, the model invokes the wrong tool under adversarial nudge. These findings are produced by red-team testing and behavioural evaluation, and they attach to the AIBOM-asset binding the same way a manual pentest finding attaches to an engagement.

A defensible AIBOM-aware vulnerability management read combines four streams: the classical SCA stream against the AI runtime libraries, the model-side advisory stream against the model identity, the red-team and behavioural evaluation stream against the model behaviour, and the dataset takedown and licence stream against the training data references. All four streams land as findings on the same asset record, ranked through the same prioritisation framework (CVSS for severity, EPSS where the finding maps to a CVE, KEV where the underlying library is in the known-exploited catalog), and worked through the same SLA discipline.

The AIBOM is what makes the four streams converge. Without it, the SCA findings live in one tool, the model advisories live in a model registry chat thread, the red-team findings live in a report PDF, and the dataset takedowns live in legal's inbox. With it, all four reference the same asset binding and the audit query reads from one record.

Common Failure Modes When Standing Up an AIBOM Programme

Six failure patterns recur across programmes that try to stand up AIBOM coverage in the first six months. Recognising them in advance saves the time spent rebuilding the pipeline after they surface in an audit conversation.

A Four-Week AIBOM Rollout for an Internal Programme

AIBOM coverage is achievable in four weeks for a programme that already has SBOM generation in place. The four-week shape below is not a productised plan; it is a recurring sequence that programmes converge on when they roll AIBOM into the existing AppSec, ML platform, and vulnerability management work.

Programmes that adopt this shape often arrive at week five with a single AIBOM inventory record that AppSec, the ML platform team, vulnerability management, GRC, and CISO leadership all read from the same source. The audit conversation collapses from a four-team scramble into a single record query.

Where SecPortal Fits

SecPortal does not generate AIBOMs and does not parse ML model files. The AIBOM generation work happens in the training pipeline, the model registry, the inference runtime, or the vendor supply chain. What SecPortal provides is the same engagement record where the AIBOM-derived findings, the surrounding SAST and SCA findings from connected repositories against the AI runtime libraries, the findings management workflow for triage and lifecycle, the document management store for the AIBOM file itself, the model card, and the dataset card, finding comments and collaboration for the cross-team conversation, the activity log for the timestamped state changes across findings, engagements, and documents, the compliance tracking mapping to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST, and AI-powered report generation when leadership wants the executive summary.

None of these features produce the AIBOM. What the platform provides is one record where the AIBOM document, the AIBOM-derived findings, the model card and dataset card references, the lifecycle, the framework mapping, and the leadership read all live so the audit conversation collapses into a query rather than a multi-team evidence scramble.

Wider Reading

The AIBOM topic intersects with several other parts of the AI security, vulnerability management, and AppSec programme. The following pages cover the adjacent disciplines from different angles and feed back into the AIBOM workflow.

• SBOM guide for the classical software-side inventory that the AIBOM extends. AIBOM is the strict superset of an SBOM when the system is an AI feature; the SBOM patterns and tools are the right starting point.
• VEX guide for the assertion document that pairs with the AIBOM to mark advertised vulnerabilities that are not exploitable in the deployed model and runtime.
• OWASP Top 10 for LLM Applications for the risk catalogue that sits beside the AIBOM and that the model card evaluation record references.
• AI security posture management (AI-SPM) for the runtime read of the AIBOM inventory: what is active, what has drifted, what has been replaced.
• MLSecOps implementation guide for the operating model the AIBOM lives inside, covering the six capability layers, the lifecycle gates, the responsibility split across data engineering, ML platform, AppSec, GRC and security leadership, and the framework crosswalk against the EU AI Act, NIST AI RMF, and ISO/IEC 42001.
• Software supply chain security guide for the umbrella operating model the AIBOM, SBOM, VEX, and SLSA workstreams sit inside, covering threat model, build integrity, regulatory frame, and audit-grade evidence.
• Secure code review for AI-generated code for the developer-side review discipline that surrounds AI-feature code in the same repositories the AIBOM describes.
• CISA Secure Software Development Attestation for the federal procurement-side push that is extending into AI components and that the AIBOM-plus-attestation pair is the natural answer to.
• System prompt leakage, indirect prompt injection via RAG, excessive agency, improper output handling, unbounded consumption, and prompt injection for the per-entry LLM vulnerability pages that produce findings against the AIBOM-bound assets.
• SBOM management and VEX publishing for the operating record that ties inventory generation, ingestion, asset binding, vulnerability matching, and customer delivery to one engagement. The same record shape carries AIBOM workflows.
• Vulnerability prioritisation and vulnerability SLA management for the workflow that ranks AIBOM-derived findings against scanner-led findings and turns the ranked queue into deadlines.
• NIST AI RMF, EU Cyber Resilience Act, CISA Secure by Design, NIST SSDF, and ISO 27001 for the framework-side mapping that AIBOM-derived evidence flows into. The AI Act Annex IV technical documentation reads directly against the AIBOM plus model card plus dataset card pack this guide describes.
• AppSec teams, product security teams, GRC and compliance teams, and CISOs for the buyer pages that read the AIBOM evidence from each perspective.

Run AIBOM-Aligned AI Security on a Single Record

AIBOM is mostly a recordkeeping problem in disguise. The formats are public, the generation patterns are converging, and the framework integration is documented. What stops most programmes is that the AIBOM file lives in the ML registry, the model card lives in a separate wiki, the SCA findings against the AI runtime live in the SAST tool, the red-team output sits in a report PDF, the dataset takedown notice arrives by email, and the framework mapping is in a spreadsheet. Producing the audit pack means reconciling five sources at audit time, and producing the leadership read means reconciling them again.

SecPortal is built around a single engagement record where AIBOM-derived findings, attached AIBOM documents, model card and dataset card references, finding lifecycle, framework mapping, leadership read, and activity audit trail all sit on the same workspace. The platform does not parse the AIBOM file for you. What it does is keep the rest of the programme on one record so the AIBOM you ingest somewhere else turns into AI security evidence on the engagement record without the multi-tool reconciliation that usually breaks the audit conversation.