Enterprise AI BOM Field Requirements Matrix — Required and Optional Fields Defined by Standards and Regulatory Grounds

• 1: Supplier AI BOM Submission Requirements
• 2: AI BOM Authoring Guidelines for In-House Development Teams
• 3: Ingestion Vetting Checklist for External Models and Datasets
• 4: AI BOM Toolset Design Strategy

1 - Supplier AI BOM Submission Requirements

This document defines the requirements for the AI Bill of Materials (AI BOM) that a supplier providing AI models or AI systems to your organization must submit. It extends the existing Software Bill of Materials (SBOM) submission requirements to models and datasets, and the required items were derived from the supplier column of the AI BOM Field Requirements Matrix.

1. Standard Data Format

The AI BOM must be submitted in a machine-readable standard format. The following two formats are accepted.

Both formats are accepted on equal terms, but SPDX 3.0, which enforces the required properties of models and datasets at the format level, is recommended. CycloneDX below 1.6 and SPDX 2.x have no AI-specific profile and are not accepted as submission formats.

2. Information That Must Be Included

The following items must be included in every submitted AI BOM. Items whose values cannot be confirmed must not be left blank; they must be marked explicitly as “unknown.”

2.1 Document Metadata

2.2 System-Level Information

2.3 Model Information

2.4 Dataset Information

2.5 Security Information

Vulnerability referencing is optional under the consensus criteria, but it is treated as required for supplier submissions because the Cyber Resilience Act and U.S. Food and Drug Administration (FDA) guidance require it directly.

3. Identifier Rules

Models and datasets must be identified with machine-readable standard identifiers.

• Model identifiers use a Package URL (PURL) or Common Platform Enumeration (CPE). Native identifiers such as a model repository path or commit hash may be provided alongside these.
• Dataset identifiers use an accessible URL or URI.
• If multiple identifiers exist, all of them must be included.

4. Strengthened Requirements for Licensing, Provenance, and Sensitivity

Unlike existing software SBOM requirements, the AI BOM enforces the following three items with particular strictness.

Licensing must be stated separately for the model weights and the dataset. The submission must distinguish whether the model is open weight, open architecture, or open data, and must provide a link to the license document. Dataset provenance must go beyond a simple source statement to include the collection method (web crawling versus a commercial agreement), preprocessing and labeling steps, and whether synthetic data was used. Dataset sensitivity must indicate whether personally identifiable information, copyrighted data, or sensitive data such as financial or medical data is included.

5. Sample Document

The following is a minimal AI BOM skeleton in CycloneDX 1.6 format. An actual submission must fill in all the required items from Section 2 above.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-06-29T09:00:00Z",
    "authors": [{ "name": "Supplier legal name" }],
    "component": { "type": "application", "name": "Supplied AI system", "version": "1.0.0" }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "name": "Supplied model name",
      "version": "1.0",
      "bom-ref": "pkg:huggingface/org/model@1.0",
      "supplier": { "name": "Model producer" },
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "modelCard": {
        "modelParameters": {
          "datasets": [
            { "type": "dataset", "name": "Training dataset name", "classification": "public",
              "governance": { "owners": [{ "organization": { "name": "Data source" } }] } }
          ]
        }
      }
    }
  ],
  "vulnerabilities": []
}

6. Pre-Submission Verification Checklist

Suppliers must confirm the following before submission.

• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Are all required items from Section 2 filled in, or explicitly marked “unknown”?
• Are the model and dataset identified with standard identifiers?
• Is a license stated for both the model weights and the dataset?
• Are dataset provenance and sensitivity indicated?
• Is a vulnerability reference link provided?
• Was it generated at a point in time after the build or model release was complete?

For detailed inspection criteria, see the Ingestion Vetting Checklist.

2 - AI BOM Authoring Guidelines for In-House Development Teams

This document sets out the guidelines for the AI Bill of Materials (AI BOM) that in-house development teams must produce when building an AI model or AI system. Information accessibility is at its best at the point of production, so this document sets the required level at its highest. The required fields are drawn from the production column of the AI BOM Field Requirements Matrix.

Much of the information that the production team fails to record can never again be obtained by the adopting team or by parties further down the supply chain. For that reason, model and dataset details that the consensus baseline treats as optional are recommended for production-time authoring.

1. Authoring Principles

The AI BOM is generated after model training or system build completes. The lifecycle stage at the time of generation (pre-build, build, or post-build) is recorded in the metadata. Use SPDX 3.0 or later, or CycloneDX 1.6 or later, as the format, and where possible generate it automatically with a generation tool, then fill in the missing items by hand.

Fields whose value cannot be determined must be marked “unable to confirm” rather than left blank. Whenever a model or dataset is updated, the AI BOM version and timestamp are updated together.

2. Required Fields

The following must always be filled in. These are the items for which two or more standards in the matrix require presence.

3. Recommended Fields

The following are optional under the consensus baseline, but since they can only be recorded accurately at the point of production, authoring them is recommended. If model cards and data cards are maintained, their contents should in particular be linked to the AI BOM.

4. Model Hashes and Integrity

The model hash value and algorithm are optional under the consensus baseline, but the recommendation is strong. Recording the hash of the weight file or model artifact lets downstream parties verify model integrity. For the hash algorithm, use hash function names from the Internet Assigned Numbers Authority (IANA), and use algorithms approved by the National Institute of Standards and Technology (NIST).

5. Dataset Provenance and Sensitivity

The production team knows the provenance of the training dataset best. Record the source, the collection method, the preprocessing and labeling steps, and whether synthetic data was used, and indicate whether personally identifiable information, copyrighted data, or sensitive data is included. This information serves as the basis for meeting the training data documentation obligations of the AI Act and the training data overview requirements of Korea’s Framework Act on Artificial Intelligence.

6. Post-Authoring Checklist

• Are all the required fields in Section 2 filled in?
• Among the recommended fields in Section 3, have those obtainable from model cards or data cards been linked?
• Are licenses stated separately for the model weights and for the dataset?
• Is the lifecycle stage at the time of generation recorded?
• When the model or dataset is updated, are the version and timestamp updated as well?

3 - Ingestion Vetting Checklist for External Models and Datasets

This checklist sets the criteria for vetting transparency and risk, on the basis of the AI Bill of Materials (AI BOM), when an in-house development team brings in and uses an external AI model or dataset. The items to check are drawn from the ingestion column of the AI BOM Field Requirements Matrix.

Because the purpose of an ingestion check is to bring a model in rather than to build one, fields that feed directly into risk assessment are prioritized. Licensing is the basis for judging compliance risk, provenance and sensitivity for judging data lawfulness and privacy risk, and vulnerability references for judging security risk.

1. AI BOM Presence and Format

• Is an AI BOM provided for the object being ingested?
• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Does the AI BOM’s timestamp match the version of the object being ingested?

If no AI BOM is provided, or the format lacks an AI-specific profile, request one from the supplier before ingestion, or secure the minimum information independently.

2. Identification and Version (Required Check)

3. License Check (Required Check)

An empty license field, or one that conflicts with the intended use, is grounds to hold off on ingestion. Because the model license and the dataset license are separate matters, check each independently.

4. Data Lawfulness and Risk (Required Check)

If the dataset’s provenance is unclear, or whether it contains sensitive data is not stated, data lawfulness and privacy risk must be assessed separately.

5. Security Risk (Required Check)

Vulnerability references are directly required by the Cyber Resilience Act and by US Food and Drug Administration guidance, so this is checked as required during ingestion vetting.

6. Recommended Checks

The following are checked additionally when the risk level is high or the use case is subject to regulation.

• Model timestamp and producer
• Model properties, input/output properties, training properties
• Model hash value and algorithm (integrity verification)
• Dataset contents and hash
• System data flow and data usage
• Whether the intended application domain matches our intended use

7. Ingestion Determination

Figure 5. Ingestion determination flow (synthesized from research)

If all the required check items in Sections 1 through 5 above are satisfied, the determination is ingestion approved. If any one of a license conflict, unclear provenance, undisclosed sensitive data, or an unacceptable vulnerability applies, the determination is held, and the supplier is asked to remedy the gap or an alternative model is considered.

The determination result is recorded together with the ingested object’s AI BOM identifier, version, and determination date, for use in subsequent reassessment and supply chain tracing.

4 - AI BOM Toolset Design Strategy

Based on a survey of seven tool categories through their official repositories and documentation, this document lays out what to reuse from existing tools, what to extend or build new, in what order to build it, and what policy schema should define the matrix. The acquisition strategy was not fixed in advance but determined from the survey results, and the premise is that the organization already operates an existing SBOM platform (Dependency-Track).

1. Three Core Judgments

The standard path for generation, verification, storage, and model scanning already works with open source software. The aibom command in cdxgen actually produces CycloneDX 1.6 AI BOMs, sbomqs and OPA check field conformance, Dependency-Track ingests the software layer, and ModelScan and sigstore model-signing reinforce model integrity. There is no need to build everything from scratch in-house.

Standardizing the format on CycloneDX 1.6 is the more realistic choice. The SPDX 3.0 AI Profile has richer expressive power, but no mature tool actually generates it, and Dependency-Track cannot ingest SPDX. SPDX 3.0 is kept as a standard to track, while CycloneDX is set as the primary operational format.

Where new construction is unavoidable is narrow and clear: the policy layer that checks AI-specific fields, an inventory that treats models and datasets as first-class objects, and the determination of license usage restrictions. Everything else is covered by reuse or extension.

2. Reuse Determinations by Area

In summary, of the thirteen areas, seven are reuse, three are extension, and three are new. The three new areas — AI- and role-specific conformance rules, the model/data inventory, and license usage-restriction determination — are where this project’s unique value is concentrated.

3. Build Priority

P0 — A Minimal Working Pipeline (Reuse-Focused)

The first step is to wire together off-the-shelf tools into an end-to-end pipeline. Generation produces CycloneDX 1.6 with cdxgen aibom, model files are scanned with ModelScan and signed with sigstore, and the results are uploaded to Dependency-Track to obtain software-layer vulnerabilities and impact analysis. Validation checks the presence of required fields with an sbomqs custom policy. Almost all of this stage is reuse, so it delivers value quickly.

P1 — Extending the AI-Specific Layer

The next step adds new value. Codify the matrix into a policy schema to implement role-specific conformance checking (Section 4), and carry models and datasets through CycloneDX properties or external references to secure inventory traceability. Augment the license pipeline with an AI license dictionary (RAIL, OpenRAIL, Llama, Gemma, OpenMDW, CDLA), and receive model risk as huntr CVEs relayed through NVD.

P2 — New and Research Areas

Last are the parts where standards and research still need to mature. Automatic extraction of deep fields such as dataset statistics or bias, automatic determination of license usage restrictions, and data poisoning are handled through provenance and integrity traceability instead of detection. Bring SPDX 3.0 generation on board once the tool ecosystem matures, but for now keep it only as a standard to track. When Dependency-Track’s support for model/data classifiers (issue #4361) lands, promote P1’s workaround to a first-class inventory.

4. Policy Schema Design

Defining the matrix’s “element x required/optional x role” as a machine-readable policy is the core of this toolset. Since the survey found no tool that treats role-specific required sets as a first-class concept, this must be designed directly. It is split into two layers.

4.1 Field Registry

A table mapping each of the G7’s 50 elements to a CycloneDX path (and, eventually, an SPDX path) is kept in one place. The AI BOM Field Requirements Matrix already contains an element-by-element source mapping, so moving it into a machine-readable form looks like this.

# field-registry.yaml — maps G7 elements to BOM paths
model_license:
  g7: Model license
  cyclonedx: "components[?type=='machine-learning-model'].licenses"
  spdx: "Relationship(hasDeclaredLicense) from AIPackage"
dataset_provenance:
  g7: Dataset provenance
  cyclonedx: "components[?type=='data'].data[].governance"
  spdx: "DatasetPackage.originatedBy / dataCollectionProcess"
vulnerability_referencing:
  g7: Vulnerability referencing
  cyclonedx: "vulnerabilities[] or externalReferences[?type=='vcs']"
  spdx: "VulnAssessmentRelationship"

4.2 Role-Specific Policy Files

The required set for each of production, ingestion, and supplier is kept as a separate policy file. This simply carries over the role column of the matrix.

# policy/supplier.yaml — required elements for supplier submission (Section 4.6, 20 supplier-required elements)
required:
  - sbom_author
  - sbom_data_format_name
  - sbom_data_format_version
  - sbom_timestamp
  - sbom_dependency_relationship
  - system_name
  - system_components
  - system_producer
  - system_version
  - model_name
  - model_identifier
  - model_version
  - model_producer
  - model_license
  - dataset_name
  - dataset_identifier
  - dataset_provenance
  - dataset_sensitivity
  - dataset_license
  - vulnerability_referencing
recommended:
  - model_timestamp
  - dataset_content
  - model_hash_value

4.3 Determination Engine

Two engines are recommended together. For a quick start, an sbomqs custom policy (YAML) puts the role-specific files into operation today with no engine to learn, converting the fulfillment rate into a score. Where expressiveness is needed, OPA/Rego (conftest) branches on the input BOM’s role value to determine the required set. Because Rego follows the field registry’s paths to evaluate presence, it can express conditional requirements and cross-field consistency as well.

# policy/aibom.rego — skeleton for role-specific required-field checking
package aibom

deny[msg] {
    role := input.metadata.properties[_].value  # e.g. "supplier"
    req := data.policy[role].required[_]
    not field_present(req)
    msg := sprintf("Required element missing: %s (role: %s)", [req, role])
}

OSCAL is a tool built for expressing security controls, which makes it more than SBOM fields need, and it does not execute validation on its own, so it is not adopted. It is worth considering only if there arises a need to produce upper-level artifacts for regulatory or audit purposes (a requirements catalog, an assessment result report) in a federal-friendly format.

5. Reference Architecture and Dependency-Track Integration

The BOM for an AI system splits into a software dependency layer and a model/dataset layer. Dependency-Track handles the former layer right now, and does not yet accept the latter as a first-class citizen (issue #4361 is open as of this research and may change later). Integration is therefore split by layer.

Figure 4. The common pipeline and the two layers it splits into after validation (compiled from the survey)

The software layer needs almost no extra work. cdxgen turns an ML project’s PyPI or npm dependencies into CycloneDX, which is uploaded to Dependency-Track, correlating vulnerabilities against OSV and NVD and even providing impact analysis for “which projects use this component?” CVEs that huntr issued for ML libraries are also caught, passing through NVD.

The model/dataset layer is routed around until classifier support arrives. In the short term, models and datasets are uploaded as generic components, while core model card fields are carried through CycloneDX properties or external references to preserve them. Discoverability is limited, but traceability is preserved. Threats unique to model files (unsafe pickle, backdoored weights) don’t fit the CVE matching model, so they are checked separately with ModelScan and the results are linked to policy or tickets.

6. Limitations and Items Requiring Verification

The tool facts in this strategy were confirmed against each project’s official repository and documentation. The following require reconfirmation before adoption.

The licensing area carries the risk of a mismatch between what is declared and what is actually true. The so-called permissive-washing risk, in which the license declared on a platform diverges from the actual component license of the model or dataset, is well known, and it compounds an existing limitation: existing software license tools cannot parse model cards or dataset cards, or trace training data provenance. This toolset does not promise automatic detection for this and leaves verifying the match between declared license and actual output as a new-build target.

The timing of Dependency-Track’s support for model/data classifiers (#4361) is an external schedule outside our control. Because P1’s model/data inventory depends on this schedule, it should be designed with the workaround (preserving properties) as the default, promoting to first-class inventory once classifier support lands.

GUAC’s AI-specific handling, OSV’s model-specific record scheme, and any connector letting Dependency-Track directly consume huntr Insights and ModelScan results are all confirmed absent or unverifiable. No standard yet links model risk feeds and SBOM inventories, so this connection has to be filled with custom glue code.

There is no production tool for data poisoning detection. This toolset does not promise automatic poisoning detection and limits itself to traceability and preventive controls that record data provenance, hashes, and whether verification passed.

7. References

The tool determinations in this article were confirmed against each project’s official repository and documentation as primary sources. All access dates are 2026-06.

A1. CycloneDX / cdxgen Project. cdxgen — AI/ML BOM generation and the aibom CLI, --spec-version. https://github.com/CycloneDX/cdxgen (accessed 2026-06). — Used for: basis that cdxgen’s aibom automatically generates CycloneDX 1.6 AI BOMs.

A2. CycloneDX. Machine Learning Bill of Materials (ML-BOM) Capability Overview. https://cyclonedx.org/capabilities/mlbom/ (accessed 2026-06). — Used for: standard basis that CycloneDX 1.6 defines machine-learning-model and modelCard.

A3. SPDX. SPDX 3.0.1 — AI Profile Specification. https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed 2026-06). — Used for: basis that the SPDX 3.0 AI Profile exists at the specification level (expressiveness comparison).

A4. SPDX. tools-python (spdx-tools) — 3.0 experimental write-only, not recommended for production. https://github.com/spdx/tools-python (accessed 2026-06). — Used for: basis that no mature tool exists to generate the SPDX 3.0 AI Profile.

A5. interlynk-io. sbomqs — Policy Guide (custom policy, required type, feature scoring). https://github.com/interlynk-io/sbomqs/blob/main/docs/guides/policy.md (accessed 2026-06). — Used for: basis that sbomqs enforces field presence via custom policy and converts it into a conformance score.

A6. Open Policy Agent. Conftest — OPA/Rego policy evaluation for configuration files. https://github.com/open-policy-agent/conftest (accessed 2026-06). — Used for: basis that CycloneDX/SPDX JSON can be evaluated with Rego to branch role-specific required sets.

A7. OWASP Dependency-Track. Policy Compliance Documentation (condition types, regex values). https://docs.dependencytrack.org/usage/policy-compliance/ (accessed 2026-06). — Used for: basis that the Dependency-Track policy engine centers on license, vulnerability, and component coordinates, with policies configurable per project/tag.

A8. DependencyTrack. Issue #4361 — Request to support CycloneDX 1.5/1.6 classifiers (machine-learning-model, data). https://github.com/DependencyTrack/dependency-track/issues/4361 (accessed 2026-06). — Used for: basis that Dependency-Track does not yet ingest the model/data classifiers or modelCard (open as of this research).

A9. Protect AI. ModelScan — Static Scanner for Model Serialization Attacks (JSON reports, exit codes). https://github.com/protectai/modelscan (accessed 2026-06). — Used for: basis that model file serialization scanning is mature enough to insert into CI.

A10. Sigstore / OpenSSF. model-transparency (model-signing) — DSSE + in-toto Model Signing. https://github.com/sigstore/model-transparency (accessed 2026-06). — Used for: basis that model signing and provenance attestation map onto BOM integrity and provenance fields.

A11. Z. Tian et al. (2025). Data Poisoning in Deep Learning: A Survey. https://arxiv.org/html/2503.22759v1 (accessed 2026-06). — Used for: basis that data poisoning detection remains at the research stage with no general-purpose production tool.

A12. AboutCode. ScanCode Toolkit — License and Copyright Text Matching Engine. https://github.com/aboutcode-org/scancode-toolkit/ (accessed 2026-06). — Used for: basis for reusing the license identification engine while noting that AI license text needs to be added.

A13. Responsible AI Licenses (RAIL). FAQ / BigScience OpenRAIL-M — Use-Based Restrictions That Propagate to Derivatives. https://www.licenses.ai/faq-2 (accessed 2026-06). — Used for: basis that no standard exists for machine-reading and automatically determining RAIL-family conduct restrictions.

A14. LF AI & Data. Simplifying AI Model Licensing with OpenMDW. https://lfaidata.foundation/blog/2025/07/22/simplifying-ai-model-licensing-with-openmdw/ (accessed 2026-06). — Used for: basis that OpenMDW, a permissive license bundling models, data, and weights, is listed with SPDX (a candidate for the AI license dictionary).

A15. Protect AI. huntr — Bug Bounty and CNA for AI and ML. https://huntr.com/ (accessed 2026-06). — Used for: basis that CVEs issued by huntr flow into Dependency-Track matching via NVD.

A16. Google and OpenSSF. OSV.dev — Open Source Vulnerability Database. https://osv.dev/ (accessed 2026-06). — Used for: basis that OSV includes ML library vulnerabilities but does not record model-weight-specific risks themselves.

A17. Trail of Bits. Fickling — Static Analysis Tool for Pickle. https://github.com/trailofbits/fickling (accessed 2026-06). — Used for: basis for a high-risk pickle deep-inspection tool.

A18. OSS Review Toolkit. ORT — License Compliance Orchestration. https://github.com/oss-review-toolkit/ort (accessed 2026-06). — Used for: basis for reusing the policy rule engine and SBOM reporter.

A19. OpenSSF. GUAC — SBOM Graph and Impact Analysis. https://guac.sh/ (accessed 2026-06). — Used for: basis that it is an option for reinforcing impact analysis, while AI-specific handling remains unverified.