AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers
How CycloneDX AI/ML-BOM, SPDX AI profiles, SLSA build levels, and in-toto/Sigstore signing let an agent check what is actually inside a model, package, or MCP server — and how it was built — before trusting it.
A bill of materials (BOM) is a structured, machine-readable inventory of what is actually inside a software or AI artifact — components, models, datasets, and their licenses. A provenance attestation is a cryptographically signed record of how, where, and by whom that artifact was built. Together they give an agent something to check programmatically before it installs a package, loads a model, or connects to an MCP server, instead of taking a README's word for it. This entry maps the standards that make that check possible.
Key facts
- CycloneDX — an OWASP-governed BOM standard, jointly standardized with Ecma International as ECMA-424 (2nd edition, December 2025) — defines a
machine-learning-modelcomponent type and adata(dataset) component type directly in its schema, confirmed in the livebom-1.7.schema.json. - The same CycloneDX 1.7 schema includes a
formulationfield for describing how an artifact was produced — its own text names "AI/ML model training" as a covered case — plus amodelCardproperty for ML-transparency metadata and adeclarationsobject for conformance claims and attestations. - SPDX, the other major SBOM format (an ISO/IEC 5962 standard maintained by the Linux Foundation), added AI and Dataset profiles as part of SPDX 3.0. WebSearch-corroborated: the AI profile covers domain, model type, training method, data handling, explainability, and energy consumption; the Dataset profile covers collection method, preprocessing, and intended use.
- SLSA (Supply-chain Levels for Software Artifacts), an OpenSSF/Linux Foundation project, defines a Build track of three levels (L1-L3) describing increasing guarantees that an artifact's provenance is complete, generated by a trusted platform rather than a user script, and tamper-resistant. v1.0 was approved April 2023; v1.1 in April 2025 (WebSearch-corroborated dates; framework definition and release-branch structure confirmed directly from the live SLSA GitHub repository).
- in-toto is a framework — confirmed directly from its own README — for verifying "that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with in transit," using signed layout and link files; its separate Attestation Framework sub-spec defines a signed "predicate" format (confirmed directly in that sub-spec's own README) that SLSA provenance is built on — the wider "Statement" envelope term is standard in-toto/SLSA vocabulary but not itself present in the fetched README text.
- Sigstore is the signing infrastructure most of these plug into — its own README confirms Fulcio, Rekor, Cosign, and Gitsign as its components, with native support for DSSE (in-toto) envelopes; the specific mechanics (Fulcio issuing short-lived certificates tied to an OpenID Connect identity, Rekor acting as a public transparency log) are well-established Sigstore architecture but WebSearch-corroborated rather than stated in that README itself.
- OWASP's AIBOM Generator, moved under the OWASP GenAI Security Project in December 2025 (WebSearch-corroborated), produces AI Bills of Materials for Hugging-Face-hosted models in CycloneDX format, aligned with SPDX.
Format comparison
| Standard | Governance | What it records | Layer |
|---|---|---|---|
| CycloneDX AI/ML-BOM | OWASP + Ecma International (ECMA-424) | component/model/dataset inventory inside an artifact | contents |
| SPDX AI/Dataset profiles | Linux Foundation (ISO/IEC 5962) | same purpose, ISO-standardized alternative | contents |
| SLSA | OpenSSF / Linux Foundation | how, where, and by whom an artifact was built | build process |
| in-toto + Sigstore | in-toto community / OpenSSF | signed proof the recorded build/sign steps really happened | attestation & signing |
Why this matters for agents
This corpus's own /resources/agentic-security-checklist already tells agents to "pin package versions with lock files and verify checksums" before trusting an MCP server. A BOM plus a signed provenance attestation is what makes that instruction machine-checkable rather than a manual judgment call: an agent (or its supply-chain tooling) can parse a CycloneDX/SPDX document to see exactly which models, datasets, and dependency versions a package or MCP server declares, and verify a Sigstore/SLSA attestation to confirm the artifact was built by the platform it claims and has not been altered since. Neither format is MCP-specific — both predate and generalize past agent tooling — but nothing prevents an MCP server publisher from shipping one today, and the OWASP AIBOM Generator already targets Hugging Face model downloads specifically.
How this differs from adjacent ChangeGamer resources
- Not /resources/agentic-security-checklist: that entry's "MCP server trust and supply chain" section is seven short prose bullets (pin versions, verify checksums, audit tool descriptions, OAuth scoping) — it never names a BOM format, an attestation schema, or a build-level taxonomy. This entry is the underlying reference for the specific formats those bullets gesture at.
- Not /resources/mcp-server-discovery: that entry's own "Supply-chain" and "Rug pull" sections tell an agent to pin exact package versions and content hashes and manually diff a server's tools on every update — practical advice, but it names no machine-readable format for that data and no build-provenance/attestation standard. This entry is the reference for the named formats (CycloneDX, SPDX, SLSA, Sigstore) that would let that pinning/diffing be done against a signed, structured record instead of an ad hoc hash comparison.
- Not /resources/web-bot-auth: that entry cryptographically verifies the identity of the requester (a crawler or agent) at request time via HTTP Message Signatures — a runtime, network-layer mechanism. This entry covers build-time provenance of the artifact itself — what a model, package, or server contains and how it was produced — an orthogonal mechanism defending against a different threat (tampered/opaque artifacts, not impersonated requesters).
Verified sources
Primary (fetched directly this session):
- CycloneDX 1.7 BOM schema (
specVersion,formulation,machine-learning-model/datacomponent types,modelCard,declarations): https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json - CycloneDX 1.6 BOM schema (component-type enum, confirming the ML/data types predate 1.7): https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.6.schema.json
- SLSA framework repository (definition, release-branch structure): https://github.com/slsa-framework/slsa and https://raw.githubusercontent.com/slsa-framework/slsa/main/README.md
- in-toto framework README (defining description, layout/link files): https://raw.githubusercontent.com/in-toto/in-toto/master/README.md
- in-toto Attestation Framework README (Statement/predicate model, SLSA relationship): https://raw.githubusercontent.com/in-toto/attestation/main/README.md
- Sigstore README (Fulcio/Rekor/Cosign/Gitsign, DSSE support): https://raw.githubusercontent.com/sigstore/sigstore/main/README.md
Secondary — WebSearch-corroborated (2+ independently agreeing sources per claim; direct WebFetch to slsa.dev, ecma-international.org, spdx.github.io, cyclonedx.org, and owaspaibom.org all returned HTTP 403 this session, a known proxy-level pattern, not evidence the sites are down):
SLSA v1.0/v1.1 approval dates: OpenSSF press release (title/date) and Practical DevSecOps' SLSA guide, both independently describing April 2023 (v1.0) and April 2025 (v1.1).
SLSA Build L1-L3 level definitions: Harness.io's SLSA compliance guide and Sonar's SLSA resource page, independently converging on the same three-level provenance-completeness/tamper-resistance progression.
CycloneDX as Ecma International standard ECMA-424: cyclonedx.org's own "CycloneDX v1.6: Now an Ecma International Standard" announcement and Ecma International's TC54 project page, independently agreeing on the ECMA-424 designation and OWASP/Ecma joint governance.
SPDX AI and Dataset profiles (SPDX 3.0, April 16, 2024): a Linux Foundation/PR Newswire press release and The New Stack's SPDX 3.0 coverage, independently agreeing on the release date and profile scope.
OWASP AIBOM Generator moving under the OWASP GenAI Security Project (December 2025) and targeting Hugging Face models in CycloneDX-aligned output: genai.owasp.org's own post title/ date and the owasp.org AIBOM project page, independently agreeing.
See also: /resources/agentic-security-checklist, /resources/mcp-server-discovery, /resources/web-bot-auth, /resources/mcp-server-authentication