Summary: The defensive centre of gravity for supply chain — tamper-proof records of where artifacts came from, adapted from SLSA, SBOM and in-toto. Google’s position: provenance is indispensable, and dataset tooling is the immature part.
Sources: raw/Supply-chain-attacks/Same same but also different_ Google guidance on AI supply chain security.md; sc-report-final.md (Plexal & Oxford GCSCC); Security-Focused Guide for AI Code Assistant Instructions.md (OpenSSF); Understanding and Addressing Supply Chain Risks in AI Systems.md
Last updated: 2026-07-29
The core claim
“AI supply chain security can also benefit greatly from adopting the traditional supply chain security concept of provenance: a tamper-proof record of an artifact’s origins and modifications. Provenance can help track dependencies, ensure integrity, and mitigate risks, such as data poisoning and model tampering.”
(source: Google Cloud)
And the honest gap: “The ecosystem for storing, changing, and retrieving datasets is less mature than that for code management, but it is required at Google for AI.”
Why provenance rather than inspection
Because inspection is unavailable. Google’s opacity argument: model behaviour “is heavily influenced by their weights, which are at best difficult to analyze because there are so many of them, and their binary format.”
You cannot read a model the way you read a dependency’s source. So the question shifts from what does this artifact do to where did this artifact come from, and can I prove it. That is the same conclusion CMU reaches for training data in poisoning defences — “probabilistic methods to retroactively check whether data was tampered with are becoming less effective,” therefore chain of custody.
Two sources, two domains, one answer: provenance beats detection when the artifact is not inspectable.
SLSA, adapted
“Adapting Supply-chain Levels for Software Artifacts (SLSA) to the AI supply chain requires addressing challenges, such as the long and resource-intensive nature of AI model training, but can help provide crucial insight.”
The training-cost problem is real: SLSA assumes builds are reproducible and cheap to re-run. Model training is neither.
Google’s four steps
- Capture enough metadata to understand lineage — “where an artifact came from; who authored it, changed, or trained it; what datasets were used in training it; and what source code was used to generate the artifact.”
- Organize the information to support queries and controls — “captured during the artifact’s creation in a non-modifiable, tamper-evident way.”
- Increase integrity through cryptographic signing.
- Share it — “in an SBOM, provenance document, model card, or some other vehicle that will assist other developers.”
Worked examples given: a dataset “known to contain biases or inaccuracies” can be traced to every model trained on it; a pretrained model “found to have security vulnerabilities” can be traced to every model incorporating it.
“Collective action is key to securing the AI software supply chain. No matter how self-reliant an organization is, there will always be dependencies, datasets, and other shared components involved.”
The concrete artifacts
From OpenSSF’s assistant-instruction guidance, which is the most implementable statement of this in the corpus:
- SBOM in “standard formats like SPDX or CycloneDX”
- in-toto attestations “or similar frameworks to create verifiable records of your build and deployment processes”
- Integrity verification — “when adding important external resources (scripts, containers, etc.), include steps to verify integrity (like checksum verification or signature validation)”
- Pin container images “using immutable digests (e.g., SHA256 hashes) instead of mutable tags like
latest”, and verify with cosign or notation, enforced by Kubernetes admission controllers
That last item is the operational answer to the model-artifact tampering path in supply-chain-attacks.
The AI SBOM connection: OWASP runs a dedicated AI SBOM Initiative with an AIBOM generator — the artifact that would make this tractable for models rather than just code.
Assurance frameworks
The Plexal/Oxford report’s mitigation structure, organised by what you are securing:
- Procured components (hardware, architectures, datasets) → “procurement controls, testing”
- A trained model, procured or in-house → “audit controls”
- AI services used → “security requirements in contracts”
- Training and fine-tuning → “training time and training dataset controls”
- An operational model → “controls and processes to protect against, detect, and recover from threats”
Underpinned by “widely accepted standards and best-practice guidelines, such as ISO, NIST and industry bodies.”
The gap it names: “difficulty in obtaining assurance due to lack of metrics and standards for assured service provision.” Contractual security requirements are only as good as the ability to verify them, and that verification layer does not exist yet.
Education as a control
Unusually, the report treats education as a first-class mitigation alongside technical controls:
- For the C-suite: “understanding how to balance risk vs. reward in adopting AI”
- For technical teams: “the ability to use tools and processes to support secure AI adoption such as model cards and provenance tracking”
- Organisationally: “how to communicate AI supply-chain security risks within the organisation”
Procurement and vendor management
The LinkedIn source’s practical list: supplier and vendor transparency, DevSecOps practices, thorough vetting, trusted sources, continuous monitoring, and integrating cybersecurity into procurement.
That last point connects to the report’s finding that 28% of participant organisations had changed vendors over trust or compliance issues — procurement is already functioning as a security control, whether or not it is designed as one.
Regulatory hooks
- AI Act Art 10 data governance and Art 11 technical documentation are the compliance expression of lineage capture.
- Art 53(1)(d) requires GPAI providers to publish “a sufficiently detailed summary about the content used for training” — a weak, public-facing form of dataset provenance.
- Palo Alto recommends “cryptographic signing of models and datasets,” which is absent from Code of Practice Appendix 4 — that control set protects outbound weights but never verifies inbound artifacts.