Model Supply-Chain Security

Best time to learn: After the original roadmap's Docker, dependency hygiene, and deployment fundamentals (Weeks 7--8). Learn a short provenance primer before using any external model checkpoint in a project; complete this module during the advanced supplement.

Prerequisites - Python environments and package/dependency management. - Docker image and deployment basics. - Familiarity with Hugging Face model repositories and model loading. - Basic hashes, signatures, and software supply-chain concepts.

### Threat model

A model artifact is executable-adjacent, high-impact input to your system. The supply chain includes weights, tokenizer files, configuration, custom model code, adapters, datasets, evaluation assets, packages, and the infrastructure that downloads and stores them.

Study: - Unsafe model serialization and deserialization. - safetensors and the limits of choosing a safer weight format. - pickle-based loading risks and arbitrary code execution hazards. - trust_remote_code and custom repository code. - Model and dataset repository impersonation or compromise. - Weight, tokenizer, configuration, and adapter substitution. - Dependency confusion, typosquatting, compromised packages, and transitive dependencies. - Provenance, checksums, signatures, immutable version pinning, and artifact inventories. - Model cards and dataset cards as useful metadata, not cryptographic proof of safety. - Scanning and review before an artifact is admitted to a production environment.

### Labs

• Artifact inventory (2h): Select one small public model. Record repository, exact revision, file list, model format, tokenizer/config files, declared dependencies, license, and provenance claims.

• Safe-loading comparison (2h): In an isolated disposable environment, compare a safe tensor loading path with an unsafe serialization example. Do not execute untrusted artifacts on your host. Explain exactly what the format does and does not protect against.

• Integrity gate (2h): Download a pinned artifact, calculate file hashes, store an approved manifest, alter a copy, and verify the gate rejects the changed artifact.

• Repository review (2h): Inspect custom model code, dependencies, install hooks, and remote-code requirements. Document why each permission is needed or reject the artifact.

• Admission control (2h): Add a model-artifact approval checklist to one project. Record source, revision, hashes, license, reviewer, scan results, and deployment version.

### Project integration

• Project 1: Pin the Ollama model identifier/version where possible; record provider/runtime/model configuration. If using downloaded Hugging Face artifacts, use a pinned revision and a controlled cache.

• Project 2: Add approved model and embedding-model manifests. Prevent silent model changes from invalidating evaluation baselines.

• Deployment: Keep model files separate from application code, use read-only mounts where possible, and run model-loading processes with minimal filesystem and network permissions.

### Measurable completion criteria

• You can explain why safetensors reduces a particular class of deserialization risk but does not prove that weights are benign.

• Every model artifact used in the project has a recorded source and pinned revision or version.

• An integrity test detects a modified artifact.

• Unreviewed custom model code is not executed by default.

• You can produce an artifact inventory and explain its residual risks.

Do not overreach: Do not attempt to build a universal model malware scanner. Artifact provenance, safe loading, isolation, and admission controls are the target.

------------------------------------------------------------------------