- 01An AI model supply chain has five distinct risk nodes. Base model weights, fine tuning datasets, fine tuning compute environments, model registries, and inference runtime dependencies.
- 02Model weights should be treated as code artifacts. They require a hash verified download, a quarantine scan, and a provenance record before they are used in any environment.
- 03Fine tuning datasets introduce training time poisoning risk. Dataset provenance, content scanning, and access control to fine tuning pipelines are required controls.
- 04Model registries need the same access control policies as code artifact repositories. Who can push a new model version is as important as who can deploy it.
The software supply chain security discipline taught enterprises to treat third party packages with the same scrutiny as code changes. Model weights are the equivalent artifact in an AI program, but most organizations that have mature software supply chain controls have not extended them to cover models.
The difference between a compromised dependency and a compromised model weight is the blast radius. A malicious package can exfiltrate data or execute code. A compromised model weight can systematically produce outputs that bypass safety controls, leak training data, or manipulate downstream decisions at scale before detection.
The five risk nodes in an AI model supply chain
/AI_SUPPLY_CHAIN_NODES
| Node | Risk | Control |
|---|---|---|
| Base model weights | Compromised weights that produce unsafe outputs or contain backdoors | Hash verified download from source, quarantine scan, provenance record |
| Fine tuning datasets | Poisoned training data that alters model behavior for specific inputs | Dataset provenance registry, content scanning, access controlled pipeline |
| Fine tuning compute environment | Compromised training infrastructure that modifies weights during training | Immutable training environment, output weight hash attestation |
| Model registry | Unauthorized model version push or model swap attack | Signed model artifacts, role based push access, promotion gates |
| Inference runtime dependencies | Vulnerable serialization libraries or runtime packages used at inference time | Software composition analysis on inference container, regular patching |
Treating model weights as code artifacts
The practical implementation of supply chain controls for model weights starts with the same question as software dependency management. Can you prove that the artifact you are running is the artifact you intended to run, and that it has not been modified in transit or at rest?
For model weights, this means computing a cryptographic hash at download time, recording it in a provenance database alongside the source URL and download timestamp, and verifying the hash again at deployment time. Any mismatch between the recorded hash and the deployment time hash should block deployment and trigger an alert.
Model weight intake process.
This process applies to any new base model or fine tuned model entering your environment, regardless of source.
- ▸Download to a quarantine environment with no network egress and no production access.
- ▸Compute a SHA 256 hash of all weight files and record in the provenance registry.
- ▸Run static safety evaluation against a fixed benchmark set to establish a baseline.
- ▸Verify hash matches the value published by the source if available.
- ▸Promote to development environment only after provenance record is complete.
Metrics for model supply chain governance
- 01Provenance coverage. Percentage of model artifacts in production with a complete provenance record. Target is 100 percent.
- 02Hash verification pass rate. Percentage of model deployments where the deployment time hash matched the recorded intake hash. Any failure is a P1 finding.
- 03Fine tuning dataset audit coverage. Percentage of fine tuning datasets with a documented provenance and content scan record. Target is 100 percent.
- 04Registry access review frequency. Model registries should have access rights reviewed quarterly. Track percentage of registries on schedule.
Connecting model supply chain governance to your existing security program
Model supply chain governance does not require building a new security capability from scratch. It requires extending three existing capabilities. Software composition analysis to cover inference runtime dependencies, artifact management to include model weight registries, and change management to include model version promotions.
The most effective way to drive adoption is to make model promotion gates part of the existing deployment pipeline. When a new model version is promoted to production, the pipeline should verify the provenance record, check the hash, and require a named security reviewer approval. This adds approximately ten minutes to a model deployment and catches the supply chain risks that would otherwise only surface in post incident reviews.