AIBOM generation: discovering models, datasets and AI services

Generating an AIBOM is mostly a discovery problem. Models, datasets and AI services are spread across code, registries, notebooks and API calls. This guide covers where to look and what to capture.

What generation means for AI

For software, generating an SBOM usually means scanning a repository or container image. An AIBOM needs more. CERT-In's minimum elements include model developer, licensing, performance metrics, data source and data-set information ^[1], and none of these can be read from a dependency manifest. Generation therefore combines automated discovery with metadata pulled from the systems where models and data are managed.

Where to discover AI components

Model registries

If teams use a registry, it is the most reliable source. The MLflow Model Registry, for example, tracks versions, supports aliases such as "champion", and links each registered version to the run, logged model or notebook that produced it ^[2]. That link is where lineage to training data and parameters begins.

Model hub metadata

Hugging Face model cards include YAML metadata such as license, datasets, base_model (for fine-tunes, adapters, quantised versions and merges) and model-index evaluation results ^[3]. The OWASP AIBOM Generator uses this metadata to produce CycloneDX 1.6 AIBOMs and scores how complete they are ^[4]. Treat hub metadata as a supplier claim to be checked, not as verified fact.

External AI services

Hosted model APIs are the component most often left out of AIBOMs, and they can change without notice. Look for AI provider SDKs in code, API keys in secrets managers, and outbound traffic to AI endpoints. For each service, record the provider, the model identifier and version requested, the data categories sent, and the owning application.

What to capture per component

• Models: name, version or revision, type, developer, licence, artefact hash, base model and adapters, performance metrics, intended use and limitations. CycloneDX represents these as a machine-learning-model component with a modelCard ^[5].
• Datasets: source, version, licence, collection process, known bias and whether personal data is present. SPDX 3.0's DatasetPackage has properties for each of these ^[6].
• Software: frameworks, inference servers and their dependencies, generated as a normal SBOM.
• Infrastructure: accelerators, runtime environment and hosting, which the G7 minimum elements treat as a separate cluster ^[7].

Keeping generated AIBOMs accurate

1. Generate at the point of change. Run generation when a model is registered, promoted or retrained, and when a service changes its AI provider configuration.
2. Pin and hash. Replace references to "latest" with explicit revisions and record hashes of model files.
3. Reconcile sources. Compare registry contents with what is actually deployed. Models in production but not in the registry are the ones to investigate first.
4. Validate before publishing. Check each AIBOM against schema and policy (AIBOM validation).

Start small

Begin with the systems that make or support decisions about people, money or safety, and with every external model API. A complete AIBOM for ten important systems is more useful than a thin one for a hundred.

How IntelliXBOM helps

IntelliXBOM generates and ingests AIBOMs in CycloneDX and SPDX and correlates the models, datasets, frameworks and AI services they list with vulnerabilities, licences and business services. Required-field policies flag gaps such as missing hashes or dataset provenance, and version history shows what changed between generations.