How to validate an AIBOM: a step-by-step procedure

A practical procedure for checking an AIBOM you have generated or received from a supplier, using open-source tools and a written field policy. Allow about an hour for the first one; later ones can be automated.

Before you start

You need the AIBOM file, a written list of required fields, and access to the model artefacts or registry the AIBOM describes. The procedure below applies the four layers described in AIBOM validation: schema, policy, consistency and provenance.

Step 1: identify format and version

Open the file and check its header. A CycloneDX JSON document declares bomFormat and specVersion. An SPDX 3 document is JSON-LD and references the SPDX 3 context. Record both, because each tool validates against a specific version. CycloneDX ML-BOM fields exist from version 1.5 onwards ^[1].

Step 2: run schema validation

CycloneDX. Run the CycloneDX CLI validate command with the input file and, if needed, the specification version. It supports versions 1.0 to 1.7 ^[2].

SPDX 3. Run both structural and semantic checks. The SPDX project publishes a JSON Schema and a SHACL model and recommends using both ^[3]. spdx3-validate, installed with pip install spdx3-validate, performs both in one run ^[4].

Fix or reject any schema errors before continuing. Later steps assume a well-formed document.

Step 3: confirm AI components are present

Check that the document actually describes AI. In CycloneDX, look for components of type machine-learning-model with a modelCard, and components of type data ^[5]. In SPDX 3, look for AIPackage and DatasetPackage elements ^[6]. A file that contains only software packages is an SBOM, not an AIBOM.

Step 4: apply the field policy

For each model component, check every required field. A CERT-In-based policy requires the Table 10 elements, including Model Name, Model Version, Model Type, Model Developer, Model Licensing Information, Software Dependencies, ML Models and Algorithms, Model Performance Metrics, Data Source and Data Sets Information ^[7]. See CERT-In AIBOM requirements for a field mapping. Record results in a table like this:

The table is an illustration of the format, not real data.

Step 5: check consistency

• Every dataset and base model referenced by a model exists as a component or a resolvable external reference.
• Licence identifiers are valid, and model, dataset and dependency licences do not conflict with your intended use.
• Software dependencies list versions, so they can be matched to vulnerability data.
• Timestamps and authors are present on the document.

Step 6: verify provenance

Compare each model's listed hash with the artefact in your registry or deployment. If the model is signed, verify the signature; Sigstore's model_signing tool supports Sigstore, public-key and PKCS #11 signing ^[8]. For serialised model files, check whether a scan has been run; ModelScan covers Pickle, H5 and SavedModel formats ^[9].

Step 7: record the result

Store the AIBOM, the tool outputs, the policy results and the decision (accept, accept with conditions, reject) together, with the date and reviewer. When the next version arrives, diff it against this one; the CycloneDX CLI includes a diff command ^[2].

Automating it

Once the steps are stable, run steps 2 to 6 in CI when a model is registered, and at intake for supplier deliveries. Keep step 7's decision with a named human for production models.

How IntelliXBOM helps

IntelliXBOM runs schema and required-field checks on CycloneDX and SPDX AIBOMs, including CERT-In AIBOM policies, and reports gaps per component. It keeps each version with diffs and stores validation results as timestamped evidence.