Your March 9, 2026 morning starts with a Slack ping. OpenAI has acquired Promptfoo. The evaluation tooling that anchors three of your CI/CD pipelines and produces the red-team evidence your AI Officer files quarterly is now a wholly-owned subsidiary of a frontier-model provider you also buy inference from. Your AI Officer has the same question as every other AI Officer in the Fortune 500 that morning: which of our pipelines depend on Promptfoo, what versions, signed by whom, and what is the substantial-modification gate going to say when we cut over to whatever post-acquisition release the new owners ship? If your answer is a Confluence page, your answer is wrong. The answer is a CycloneDX 1.7 ML-BoM with CDXA attestations, regenerated nightly by CI/CD, line-item diffable across releases, cryptographically signed, and wired into your Article 25 substantial-modification gate. This lesson is how you build that artifact for a real RAG pipeline, why CycloneDX 1.7 (March 25, 2026 release) is the format that won, and how the four BoM types, ML-BoM, SBOM, SaaSBOM, VEX, and the CDXA attestation layer give the regulator-grade supply-chain answer your conformity assessment was always going to require.

Why Supply-Chain Documentation Became Existential in 2026

Three forces converged on supply-chain documentation in the first half of 2026. The first was vendor consolidation. The OpenAI / Promptfoo acquisition (announced March 9, 2026; closed Q2) telegraphed a year of M&A in the AI-tooling stack, Promptfoo to OpenAI; Garak's commercial steward acquired by a US Big-Cloud in April; PyRIT and Inspect facing similar pressure from larger consolidators. Each acquisition reset version cadence, license terms, and behavioral defaults of tooling embedded deep inside enterprise eval pipelines. The enterprises that could not say which version of Promptfoo, signed by whom, ran which evaluation on which model on which date spent April-May rebuilding evidence trails the consolidators' new release tracks had quietly invalidated.

The second force was upstream model behavior change. Anthropic's Claude 4.x point-release cycle, OpenAI's GPT-5 family iteration, and Google DeepMind's Gemini 2.x updates each shipped behavioral deltas, reasoning depth, refusal calibration, tool-use policy, that broke downstream evaluation baselines. A deployer that could not produce a machine-readable diff between the model version that passed last quarter's red team and the version running in production this quarter could not evidence Article 26(5) post-market monitoring, could not invoke the Article 25 substantial-modification analysis, and could not answer the audit committee's "are we still using what we tested?" question. The shape of the answer was always going to be a BoM.

The third force was regulator-side hardening. Article 53(1)(a) Annex XI obliges GPAI providers to draw up and maintain technical documentation including the training and testing process, evaluation results, distribution channels, and methods used to test the model. Article 16(d) obliges high-risk system providers to maintain technical documentation per Annex IV. Article 25 substantial-modification transfers obligations onto any deployer who materially changes a deployed system. ISO/IEC 42001:2023 control A.10 (third-party relationships) requires the organization to document and manage AI-component third-party risks. NIST AI RMF Map 4 ("Risks and benefits are mapped for all components, including third-party software and data") and Govern 6.1 (third-party policies) sit on the same evidence. All five frameworks resolve to the same operational question: what is in your AI system, by version, with provenance, with cryptographic integrity, and how do you prove it?

The answer the industry settled on by mid-2026 is a CycloneDX 1.7 ML-BoM, signed via CDXA, regenerated in CI/CD, and gated into the substantial-modification workflow. This lesson walks the format, the four BoM types, the attestation layer, a worked RAG-pipeline example, and the six mistakes the early adopters made.

CycloneDX 1.7 and the Four BoM Types - ML-BoM, SBOM, SaaSBOM, VEX

CycloneDX is an OWASP-stewarded supply-chain specification originally designed for software components. The 1.4 release (2022) introduced a vulnerability-disclosure extension; 1.5 (2023) added formula and workflow; 1.6 (2024) introduced cryptographic-asset modeling; 1.7 (March 25, 2026) formalized the AI / Machine-Learning Bill of Materials and the CycloneDX Attestations (CDXA) layer. The 1.7 release is what consolidated the format's leadership for AI supply chains: SPDX 3.0 covers software-with-AI overlays but stops short of the integrated four-type model that CycloneDX 1.7 ships natively.

CycloneDX 1.7 ships four interoperable BoM types in a single specification:

• AI/ML-BoM, the AI-component inventory. Models (base, fine-tuned, embedding, reranker), datasets (training, fine-tune, evaluation, RAG-source), vector stores, RAG-retrieval sources, agentic toolsets, prompt templates, and evaluation harnesses. Each component carries identifier, version, supplier, license, hash (SHA-256 typical), provenance, and a model-card or datasheet reference.
• SBOM, the traditional software-component inventory. Languages, libraries, runtimes, containers, dependency graphs. The classic npm audit / pip-audit input.
• SaaSBOM, the SaaS-dependency inventory. Cloud APIs, hosted vector stores (Pinecone, Weaviate Cloud, MongoDB Atlas), MCP-server endpoints, third-party agent platforms, payment gateways. Each entry carries endpoint, version, SLA reference, regional posture, and the contractual identifier.
• VEX, Vulnerability Exploitability eXchange. Statements about whether a vulnerability in a component is actually exploitable in your deployment context (affected / not_affected / fixed / under_investigation with justification). VEX is the layer that lets a security team say "yes, this CVE is in our dependency tree, but the configuration that triggers it is not present in our deployment."

The four-type model matters because no single type covers a 2026 AI pipeline. A RAG agent has model components (ML-BoM), software dependencies (SBOM), SaaS endpoints to the vector store and LLM API (SaaSBOM), and known-CVE assessments across all three layers (VEX). A BoM artifact that only covers software (a classic SBOM) misses the model versions, the datasets, the vector-store endpoint, and the agent tools. A BoM that only covers the model misses the orchestration code. CycloneDX 1.7 lets all four types live in one signed artifact, cross-referenced by bom-ref identifiers, with a single CDXA signature envelope.

CDXA - CycloneDX Attestations

CDXA is the attestation layer added in CycloneDX 1.7. An attestation is a cryptographically-signed claim about a supply-chain fact, for example, "this ML-BoM was generated by Acme.CI v3.1.4 from commit a7c92f at 2026-05-15T03:14:00Z and signed by the Acme platform key (key-id: acme-platform-2026-q2)" or "this base model (Anthropic Claude 4 Opus, API version 2026-05-12) was used in evaluation suite Acme.Eval v2.3 on 2026-05-12 producing pass-rate 94.2% on the customer-service red-team battery."

CDXA statements use the in-toto attestation framework's predicate model and Sigstore/Cosign keyless signing as the default chain of trust. Claims fall into typed categories: build provenance (who built the artifact, from what source, on what runner); component identity (cryptographic hash binding the component reference to the actual bits); evaluation (which eval suite ran against the artifact, with what result); policy compliance (which policy gates the artifact passed). The CDXA layer lets a downstream consumer verify the BoM contents have not been tampered with and that the supply-chain claims attached to the BoM are signed by parties whose keys you trust.

For the Article 25 substantial-modification gate, CDXA is the technical mechanism that converts a Confluence-page handoff into a verifiable claim. Your change-management workflow can require, programmatically, that any new ML-BoM presented to the gate carries (1) a build-provenance attestation from your CI runner, (2) component-identity attestations binding the model and dataset references to their hashes, (3) an evaluation attestation showing the artifact passed the relevant red-team and benchmark batteries above the policy threshold, and (4) a policy-compliance attestation from your governance tool. No signatures, no gate pass.

Worked Example - ML-BoM for Acme.ServiceAssist v1.0 (RAG Pipeline)

The worked example is a RAG-pipeline customer-service agent: Acme.ServiceAssist v1.0. The agent answers customer inquiries about Acme's product line by retrieving from an internal knowledge base, optionally calling ServiceNow to look up ticket history, optionally calling Active Directory to verify identity, and using Microsoft Graph to read the customer's recent email thread for context. The base model is Anthropic Claude 4 Opus; the embedding model is OpenAI text-embedding-3-large; the vector store is Pinecone serverless; the retrieval source is Acme's curated knowledge base. The agent is fine-tuned on a curated set of Acme customer-service transcripts.

The full ML-BoM for Acme.ServiceAssist v1.0 has the following AI/ML-BoM components (excerpting one representative entry per component class; production BoM lists all):

The SBOM component of the artifact lists the orchestration code's traditional software dependencies: Python 3.12.3, the FastAPI runtime v0.111, the LangGraph orchestration library v0.2.x, the Anthropic SDK v0.30, OpenAI SDK v1.45, Pinecone client v5.0, and the dependency tree underneath each: pinned by SHA, listed by license, scanned by pip-audit and Trivy. The SaaSBOM component lists the external endpoints, api.anthropic.com/v1/messages (region: us-east), api.openai.com/v1/embeddings (region: us-east), the Pinecone serverless endpoint (region: aws-us-east-1, contract id), the ServiceNow tenant URL, the AAD/Entra ID tenant URL, the Microsoft Graph endpoint: each with provider, region, contract reference, and SLA tier. The VEX component lists each known CVE in the SBOM dependency tree with an exploitability statement: not_affected with justification for CVEs that affect code paths the deployment does not exercise; fixed for CVEs the most recent dependency pin has patched; affected with workaround for any remaining open issue.

The complete artifact, ML-BoM + SBOM + SaaSBOM + VEX, cross-referenced, is roughly 4,000 to 12,000 lines of JSON depending on dependency depth. It is generated by CI/CD on every build; signed via CDXA with the Acme platform's organizational key; published to Acme's internal artifact registry with versioned URLs; diffed line-by-line against the previous version; and gated into the substantial-modification analysis whenever any line-item change touches a model, dataset, vector-store snapshot, agent tool, or eval tool.

CI/CD Integration - Where the ML-BoM Lives in the Pipeline

The ML-BoM is not a quarterly artifact. It is a build artifact. The CI/CD integration pattern that worked for early adopters in Q1-Q2 2026 has five stages:

1. Discovery stage. The CI runner introspects the model-deployment manifest, pulls the pinned SBOM from pip-audit / npm audit / cyclonedx-bom, resolves the vector-store snapshot identifier from the deployment config, resolves the SaaS endpoints from the runtime environment, and stages the discovered components into a CycloneDX 1.7 JSON skeleton.
2. Enrichment stage. The pipeline pulls supplier-side metadata, model cards via vendor API, datasheet references from the internal data catalog, license metadata from package registries, vector-store snapshot hashes from the Pinecone API, and enriches the skeleton with full component metadata. Component hashes are computed where they are not vendor-supplied.
3. Evaluation-attestation stage. The pipeline runs the regression eval suite (Promptfoo, Garak, PyRIT, Inspect, OpenAI Evals as applicable), records pass-rates, and emits a CDXA evaluation attestation per suite: claiming "this artifact, identified by this hash, passed these batteries above these thresholds on this date." The attestations are signed and bundled with the BoM.
4. Signing stage. The complete BoM (all four types, with all attestations) is signed using Sigstore/Cosign keyless signing tied to the CI runner's identity (an OIDC token from the CI provider) and the organization's platform key. The signature envelope, the certificate chain, and the inclusion proof in the transparency log (Rekor) are bundled with the BoM.
5. Publication and gating stage. The signed BoM is published to the internal artifact registry with a versioned URL. A diff against the previous-version BoM is computed and posted to the change-management ticket. If any line-item diff touches a substantial-modification trigger (model swap, dataset replacement, vector-store schema change, agent-tool addition, eval-tool version change), the deployment is blocked from production until the substantial-modification workflow is closed out by the governance owner.

The pattern that does not work, and that early-2026 adopters learned from, is treating the ML-BoM as a quarterly snapshot prepared by an analyst. The half-life of an AI-pipeline BoM in 2026 is measured in days, sometimes hours: vendor API versions move, vector-store snapshots are reindexed, dependency pins update, agent tools ship hotfixes. A quarterly snapshot is stale before the next governance meeting. CI/CD generation is non-negotiable.

Key Management and Rotation for CDXA Signing

The CDXA signing key is a high-value cryptographic asset and a governance artifact. The patterns that worked in early 2026: keyless signing via Sigstore/Cosign with OIDC binding to the CI runner identity (the default for most open-source projects); KMS-backed keys (AWS KMS, Google Cloud KMS, Azure Key Vault) with role-scoped signing permissions for the CI runner (the default for most enterprises); hybrid arrangements using KMS-backed root keys with shorter-lived per-pipeline subkeys. Key rotation cadence, quarterly is common; semi-annual is the upper bound, should be documented and the rotation event should itself be a CDXA attestation. Compromise procedures should explicitly cover BoM artifact re-signing for in-flight production deployments.

Cross-Walks - How the ML-BoM Fits the Regulatory and Governance Stack

The ML-BoM is not a standalone artifact. It is the supply-chain evidence layer that anchors documentation requirements across five frameworks and three internal governance artifacts.

• Article 53(1)(a) Annex XI provider documentation. Annex XI requires GPAI providers to document training data sources, evaluation results, distribution channels, intended use. For a downstream deployer who has produced or substantially modified a model under Article 25, the ML-BoM is the machine-readable answer to "what is in this model" that the Annex XI obligation expects.
• Article 16(d) provider technical documentation. Article 16(d) obliges high-risk system providers to maintain technical documentation per Annex IV. The ML-BoM is the supply-chain section of the Annex IV technical file, the component inventory that the conformity assessment relies on.
• Article 25 substantial-modification analysis. Article 25 transfers provider obligations onto a deployer who substantially modifies a high-risk system. The substantial-modification gate is the operational mechanism for catching transfers; the ML-BoM diff is the substantive input the gate analyzes. Without the BoM, the gate is blind.
• ISO/IEC 42001:2023 A.10 third-party relationships. A.10 expects the organization to manage AI-component third-party risk. The ML-BoM is the operational artifact that lists the third-party components and their provenance.
• NIST AI RMF Map 4 and Govern 6. Map 4 ("Risks and benefits are mapped for all components, including third-party software and data") and Govern 6 (third-party policies and controls) sit on the ML-BoM as evidence.
• GPAI exposure map (lesson 003 artifact). The GPAI exposure map enumerates which foundation models are in the stack with their Article 51 status. The ML-BoM is the per-system instance of the same data, every line of the GPAI exposure map should resolve to one or more ML-BoM component entries across the production portfolio.
• Model card (Section 1 - Model Details). The model card's Section 1 identifies the model; the ML-BoM is where that identification carries the cryptographic hash, the API version, and the provenance attestation. The model card is the human-readable artifact; the ML-BoM is the machine-readable verification layer.
• Datasheet for datasets (lesson 028 artifact). The datasheet describes the training and evaluation datasets. The ML-BoM is where the datasheet's identifier and version are pinned with a hash and a provenance attestation; the datasheet reference in the BoM is what gives downstream consumers the path back to the documentation.

The pattern is the same one this program has repeated across documentation lessons: write the artifact once, cite it against multiple frameworks. The ML-BoM is the supply-chain artifact in that pattern. Build it once, sign it once, gate it once, cite it against Annex XI, Annex IV, Article 25, ISO 42001 A.10, NIST Map 4, and the GPAI exposure map.

Six Common ML-BoM Mistakes - And the Audit-Defensible Counter-Stances

Mistake 1 - No ML-BoM at All

The most common state in mid-2026 is no ML-BoM, only a traditional SBOM scoped to software dependencies. The mistake is to assume the SBOM covers the AI components. It does not: the SBOM lists Python packages, not foundation models, datasets, vector stores, or agent tools. The fix is to add the AI/ML-BoM type alongside the SBOM and require both for any AI-pipeline release. CycloneDX 1.7 ships both in one artifact; there is no operational reason to ship one without the other.

Mistake 2 - ML-BoM Lists Only the Foundation Model

The next-most-common state is an ML-BoM that lists only the base foundation model and skips the embedding model, the vector store snapshot, the retrieval source, the agentic toolset, and the evaluation tooling. The mistake reduces the BoM's value: the substantial-modification gate is blind to embedding-model swaps and tool additions, and the supply-chain attestation work is incomplete. The fix is to make the ML-BoM component-type checklist explicit in the CI pipeline and to fail the build if any class is missing.

Mistake 3 - No CDXA Signing

An unsigned ML-BoM is text in a repository. It cannot be relied on by a downstream consumer because it cannot be cryptographically distinguished from a tampered copy. The fix is to require CDXA signing (Sigstore/Cosign keyless or KMS-backed) for every BoM that leaves the CI pipeline, and to require signature-verification at every consumption point (the substantial-modification gate, the artifact registry, the downstream deployer's procurement intake).

Mistake 4 - ML-BoM Not Integrated With CI/CD (Stale)

The hand-curated ML-BoM goes stale within days of generation. The fix is non-negotiable CI/CD integration: every model-deployment build generates a fresh signed BoM, every deployment artifact carries the BoM reference, every artifact registry entry has the BoM attached. The hand-curated approach is acceptable only for the very first ML-BoM of a brand-new system; from the second release onwards, automation is the only sustainable path.

Mistake 5 - No Substantial-Modification Gate Trigger on ML-BoM Changes

An ML-BoM that is generated and signed but not wired into the substantial-modification gate is unused evidence. The fix is to add the BoM-diff job to the change-management workflow: any line-item change to a model, dataset, vector store, retrieval source, agent tool, or eval tool triggers a substantial-modification review by the governance owner. The trigger is the operational mechanism that converts the BoM from documentation into control.

Mistake 6 - No SaaSBOM Coverage for Cloud-Vendor Dependencies

An ML-BoM and SBOM without a SaaSBOM is missing the cloud-vendor surface. Vendor region changes, API endpoint changes, SLA tier changes, and contract identifier changes are all relevant to the supply-chain risk picture; without a SaaSBOM, those changes are invisible to the BoM-diff gate. The fix is to include the SaaSBOM as a required type in the CycloneDX 1.7 artifact: every SaaS endpoint the pipeline calls (LLM API, embedding API, vector-store API, MCP-server endpoint, identity provider, data plane) is a SaaSBOM entry with provider, version, region, contract reference, and SLA tier.

Key Takeaways

• CycloneDX 1.7 (March 25, 2026) is the format that won. Four interoperable BoM types, AI/ML-BoM, SBOM, SaaSBOM, VEX, in a single signed artifact, with the CDXA attestation layer for cryptographic supply-chain claims. SPDX 3.0 covers software-with-AI overlays but does not ship the integrated four-type model natively.
• The four BoM types cover four distinct surfaces. ML-BoM = AI components (models, datasets, vector stores, tools, eval tooling). SBOM = traditional software dependencies. SaaSBOM = cloud / SaaS endpoints. VEX = vulnerability-exploitability statements. No single type covers a 2026 AI pipeline.
• CDXA is the cryptographic attestation layer. in-toto predicate model, Sigstore/Cosign keyless signing (or KMS-backed), typed claims (build provenance, component identity, evaluation, policy compliance). The mechanism that converts a BoM from documentation into verifiable evidence.
• A complete RAG-pipeline ML-BoM covers base model, fine-tune dataset, embedding model, vector-store snapshot, retrieval source, agent toolset, and evaluation tooling. Each entry carries identifier, version, supplier, hash, and a model-card or datasheet provenance reference. Acme.ServiceAssist v1.0 example: Claude 4 Opus + Acme transcripts dataset + text-embedding-3-large + Pinecone snapshot + Acme KB + ServiceNow / AD-MCP / M365-Graph tools + Promptfoo / Garak / PyRIT / Inspect / OpenAI-Evals eval tooling.
• CI/CD integration is non-negotiable. Five-stage pipeline: discovery, enrichment, evaluation-attestation, signing, publication-and-gating. Quarterly hand-curated BoMs are stale within days; automation is the only sustainable path.
• The substantial-modification gate is where the BoM becomes control. A BoM-diff trigger on any line-item change to a model, dataset, vector store, retrieval source, agent tool, or eval tool routes the change into the Article 25 substantial-modification workflow. Without the trigger, the BoM is unused evidence.
• The ML-BoM is multi-framework evidence. Article 53(1)(a) Annex XI provider documentation; Article 16(d) Annex IV technical documentation; Article 25 substantial modification; ISO 42001 A.10 third-party relationships; NIST AI RMF Map 4 and Govern 6; GPAI exposure map; model card Section 1; datasheet for datasets. Write once, cite eight times.
• Vendor consolidation makes the BoM existential in 2026. The OpenAI / Promptfoo acquisition (March 9, 2026) is one of several M&A events that reset versions and behavior of tooling embedded in eval pipelines. Without a versioned signed BoM, the organization cannot answer "which version, signed by whom, ran when", the question every audit committee will ask.
• Six mistakes to avoid. No BoM at all; ML-BoM lists only the foundation model; no CDXA signing; not integrated with CI/CD; no substantial-modification trigger; no SaaSBOM coverage. The audit-defensible posture closes each one as a CI-pipeline policy and a governance-workflow gate.
• Key management is itself a governance artifact. CDXA signing keys are high-value cryptographic assets. Keyless (Sigstore) or KMS-backed (AWS / Google / Azure); quarterly rotation cadence; rotation events as CDXA attestations; documented compromise procedures including in-flight BoM re-signing.