Skip to content

Chapter 4.9 — Supply chain security for AI

🎯 Objective

Treat the AI pipeline as an auditable supply chain — including code, dependencies, containers, models, datasets, prompts, schemas, MCP servers and A2A peers.

🧠 Base concepts

  • SBOM (Software Bill of Materials) — an inventory of an artifact's dependencies.
  • SPDX — an SBOM format maintained by the Linux Foundation, ISO/IEC 5962:2021 standard.
  • CycloneDX — an SBOM format maintained by OWASP, focused on components, vulnerabilities, services and ML/AI components.
  • SLSA (Supply-chain Levels for Software Artifacts) — a framework with levels (1 to 4) describing how much an artifact has verifiable provenance and a hardened build. Current version: SLSA v1.x.
  • OpenSSF Scorecard — an OpenSSF project that automatically evaluates the security practices of open-source repositories.
  • Sigstore / cosign — artifact signing and verification.
  • in-toto — verifiable attestations along the pipeline.
  • Provenance — a verifiable attestation of origin (who built it, from which source, in which environment).

🛡️ Applied to AI

Axis What to control Typical form
Code Build, dependencies, lint, vulns SBOM (SPDX/CycloneDX), Scorecard, dependabot/renovate, SLSA provenance
Containers Base image, layers, vulns Scanners (Trivy, Grype), signing (cosign), digest pinning
Models Origin, hash, version, license Model card + artifact hash; SBOM-ML (CycloneDX includes ML-BOM); model registry record
Datasets Origin, license, version, bias Dataset card; data contracts; lineage in the orchestrator
Prompts Version, owner, eval regression Prompts in a repo, semver, eval gate in CI
Schemas / Tools Version, owner, contract test Semver + contract tests + registry
MCP servers Origin, version, capabilities Version pinning; periodic capability review; signing
A2A peers Agent Card version, capabilities Version the Agent Card; review breaking changes
Embeddings / Indexes Model + dimension + version Index tag; dual-read during migration
Policy bundles Version + hash + signature OPA bundle service with auth and signing

🚨 Failure modes

  • A model loaded from a public hub without a pinned hash.
  • A dataset with an incompatible license used in fine-tuning.
  • A third-party MCP server updated silently, expanding capabilities.
  • A base container with a known vulnerability in a production model.
  • A prompt changed without a registry record; regression never detected.
  • No sbom.json for the final artifact -> impossible to answer "what is running?".

🛡️ Controls and mitigations

  • Generate an SBOM (SPDX or CycloneDX) in every build; store it with the artifact.
  • Adopt CycloneDX ML-BOM to describe models, datasets, hyperparameters and sources.
  • Attest provenance via SLSA + Sigstore.
  • Evaluate critical open-source projects via OpenSSF Scorecard.
  • Pin versions and digests (containers, MCP servers).
  • Block the build if the SBOM shows an unjustified critical vuln.
  • Maintain a model registry and dataset registry with lineage.
  • Review MCP server capabilities at each upgrade.

📈 Metrics

  • % of artifacts with an up-to-date SBOM.
  • % of models with hash + model card + documented license.
  • Time between a CVE disclosure and a patch in production.
  • OpenSSF Scorecard score for key dependencies.
  • Attempts to load an artifact without provenance.

📌 Checklist

  • [ ] Do builds generate an SBOM (SPDX or CycloneDX) automatically?
  • [ ] Do models have a hash, model card and license in the registry?
  • [ ] Do datasets have a dataset card and a documented license?
  • [ ] Do containers have a signature (cosign) and a pinned digest?
  • [ ] Do MCP servers/A2A peers have a pinned version and periodic review?
  • [ ] Is there a process to answer "what is in production?" in minutes?

📚 References