AI Supply Chain Security

Software supply chain security became a mainstream engineering concern after the SolarWinds attack in 2020 and the Log4j vulnerability in 2021. The AI supply chain introduces the same categories of risk — third-party components, transitive dependencies, build pipeline integrity — but with additional attack surfaces specific to AI: model weights, training datasets, fine-tuning services, and AI-specific libraries that have already accumulated their own CVE histories.

Understanding the AI supply chain requires a wider frame than traditional software supply chain security. The components are different, the attack vectors are different, and the blast radius of a compromised component can be different — a poisoned model weight affects every inference request, not just the requests that trigger a specific code path.

Third-Party Model Risk

The most significant AI-specific supply chain risk for most teams is the use of pre-trained model weights from public registries or third-party providers without adequate vetting.

HuggingFace model registry risk. HuggingFace is the dominant public model registry with over 900,000 models hosted as of mid-2026. The platform has minimal automated security vetting of uploaded model weights. Models on HuggingFace have been documented with two distinct classes of malicious content: pickle-based arbitrary code execution payloads embedded in model weight files (exploiting Python's unsafe pickle deserialization when loaded with torch.load()), and intentionally misrepresented model capabilities or training provenance in model cards written by uploaders.

CVE-2024-34083 and related pickle vulnerabilities. Security researchers identified multiple models on HuggingFace in 2024 that, when loaded with standard PyTorch loading functions, executed network callbacks to external servers. The attack exploited Python pickle's ability to embed arbitrary callable objects in serialised data. When torch.load() deserialises the model file, the embedded callback executes with the same permissions as the loading process — which in a data science environment is often a privileged user with filesystem and network access. Models with descriptive, professional-looking names and model cards were among those identified as malicious.

Vetting process for third-party models. Before using a model from any public registry in a production system:

1. Prefer models from known, accountable publishers (the official pages of model labs such as Meta, Mistral AI, Google, and Stability AI) rather than re-uploads by anonymous accounts.
2. Download the safetensors format of the weights where available. Safetensors is a safe serialisation format that does not permit arbitrary code execution at load time.
3. If only pickle-format weights are available, load the model in an isolated sandbox environment with network access blocked and filesystem writes limited to a specific directory. Monitor for unexpected network calls or file system activity during loading.
4. Verify the SHA256 checksum of the downloaded weights against the checksum published by the model author on a channel independent of the registry (the author's GitHub release page or official website).
5. Review the model card for specificity and credibility. A model card that lacks training details, dataset descriptions, or evaluation results is a red flag.

Misrepresentation of model properties. Beyond code execution risks, a model that is misrepresented in its model card poses a different class of risk: deploying a model believing it has certain safety properties (was safety-trained, was trained on curated data) when it does not. Safety properties in particular may be claimed in model cards without adequate evidence. Test safety properties empirically with your own red team before deploying.

Open-Source AI Library Vulnerabilities

The AI application layer relies on a small number of high-level libraries for orchestration, retrieval, and integration. These libraries have accumulated their own vulnerability histories.

LangChain CVEs. LangChain, the most widely used AI orchestration library, has accumulated multiple security vulnerabilities since its 2022 release. Notable examples include:

• CVE-2023-29374 (arbitrary code execution via Python REPL tool): LangChain's Python REPL tool executed arbitrary Python code provided by the LLM. In an agentic system where user-supplied input could influence the code the LLM generated, this created a path from user input to arbitrary code execution on the server.
• CVE-2023-34541 (server-side request forgery via URL injection): LangChain's document loaders fetched URLs provided in user input without adequate validation, enabling SSRF attacks.
• CVE-2023-38860 (prompt injection via document loaders): Several document loaders injected retrieved document content directly into prompts without sanitisation, enabling indirect prompt injection.

LangChain's rapid development pace and broad attack surface (it integrates with dozens of external services) make it a high-priority target for vulnerability researchers and attackers. As of mid-2026, it is important to keep LangChain pinned to a specific reviewed version and apply security patches on a short cycle.

LlamaIndex vulnerabilities. LlamaIndex has a smaller CVE surface than LangChain but has had documented vulnerabilities in its query pipeline and data connectors. The general pattern is the same: data connectors that load external content and inject it into prompts without sanitisation create indirect injection paths.

Dependency audit for AI libraries. AI application libraries have large transitive dependency trees. A standard npm-style or pip audit will surface known CVEs in the dependency tree. Additionally, AI libraries often pull in model-specific dependencies that may have their own vulnerabilities — the ONNX Runtime, various model quantisation libraries, and specific hardware acceleration libraries have all had security advisories.

AI Dependency Management

Managing AI dependencies in a production application requires the same practices as managing any software dependencies, with additional considerations for the rapid release cadence of AI libraries and the possibility of breaking changes between minor versions.

Pin dependency versions. Specify exact versions for all AI libraries in your requirements or lock files. The combination of rapid development, breaking changes, and security patches in AI libraries makes loose version specifications (such as langchain>=0.1.0) risky: a version that was not present when you last tested may introduce new behaviour or vulnerabilities.

Separate evaluation and production environments. Use a staging environment that mirrors production for evaluating dependency updates before promoting them to production. AI library updates frequently change model behaviour in subtle ways that integration tests may not catch — evaluate on your eval set before promoting.

Automated vulnerability scanning. Integrate CVE scanning into your CI/CD pipeline using tools such as Dependabot (GitHub), Snyk, or pip-audit (Python). Set up alerts for new CVEs in your dependency tree and define a target time-to-remediation based on severity.

Minimal dependency surface. Audit your AI library usage and remove integrations you are not actively using. LangChain's broad surface area is only a risk if you have enabled the modules with known vulnerabilities. If you are not using the Python REPL tool, remove it from your configuration. If you are not using certain document loaders, do not import them.

SBOM for AI Systems

A Software Bill of Materials (SBOM) is a machine-readable inventory of all components in a software system. Traditional SBOMs cover application code and its dependencies. AI SBOMs must extend this to cover the AI-specific components that traditional dependency trees do not capture.

Standard SBOM components for AI systems:

• Application code and dependencies (standard SBOM content)
• AI orchestration library and version (LangChain, LlamaIndex, Haystack)
• Foundation model identifier (model name, version, revision hash where available)
• Model serving infrastructure (vLLM, TGI, Triton Inference Server, and version)
• Embedding model for RAG systems (model identifier and version)
• Vector database and version (Pinecone, Weaviate, Qdrant)
• Fine-tuning framework if applicable (Axolotl, Unsloth, Hugging Face TRL)
• Training dataset identifier and version where available

AI-specific SBOM challenges. Traditional software dependencies are identified by package name and version, which maps to a specific, reproducible artifact. AI model versions are less reproducible: model providers update model weights under the same version identifier (for example, "gpt-4o" may refer to different underlying weights at different points in time). The SBOM for an AI system that uses a hosted API cannot reliably identify the exact model weights being used unless the provider supports explicit model version pinning. This is a gap in the current SBOM tooling ecosystem.

Model registry in SBOM. For self-hosted or downloaded models, the SBOM should include the SHA256 hash of the model weights alongside the model name. This provides a reproducible identifier that will change if the weights change, enabling detection of silent weight substitution.

SBOM generation tools for AI. The SPDX and CycloneDX SBOM formats have been extended with AI-specific metadata fields as of their 2024 releases. Tools such as Syft and CycloneDX-Python can generate SBOMs with AI component fields for Python-based AI applications. Verify your SBOM tooling supports the AI metadata extensions before treating generated SBOMs as complete.

Model Registry Security

For organisations that host internal model registries (for storing fine-tuned models, tracking training runs, and managing model versions), the registry itself is a supply chain attack surface.

Model registry access controls. Restrict who can push new model versions to the registry. Treat model push permissions the same as production deployment permissions — requiring two-person review and CI/CD pipeline gates before a trained model can be promoted to the production registry. An attacker with push access to the model registry can replace a legitimate production model with a backdoored version.

Model signing. Apply cryptographic signing to model artifacts in the registry. A signing scheme where model weights are signed with the training pipeline's private key and the public key is independently distributed allows downstream systems to verify that the weights they are loading were produced by an authorised training run. Sigstore's cosign tool, extended to support model artifacts, is an emerging standard in this space.

Training run provenance. Link each model in the registry to the specific training run that produced it, including the training code version, training data version, hyperparameters, and environment details. This enables auditing of what training configuration produced a specific model version and supports incident response if a model behaves unexpectedly in production.

Container Image Security for Model Serving

Model serving is typically deployed in containers (Docker, Kubernetes), and the container image carries supply chain risk beyond the model weights themselves.

Base image vetting. AI/ML serving containers frequently use base images from GPU vendor registries (NVIDIA NGC, AMD ROCm repositories) that are large and have complex dependency trees. Audit these base images for known CVEs using container scanning tools such as Trivy or Grype before deploying them.

Model serving framework vulnerabilities. vLLM, Text Generation Inference (TGI), and similar high-throughput model serving frameworks have active development histories and have had security advisories. Pin the serving framework version, audit for CVEs, and evaluate updates before deploying.

Image signing and provenance. Apply the same model signing approach to container images: sign container images in your CI/CD pipeline and verify signatures before deploying to production. This prevents supply chain attacks where a compromised registry replaces a legitimate image with a malicious one.

Vendor AI API Risk Assessment

Third-party AI API vendors (foundation model providers, fine-tuning services, embedding services) are supply chain components from a security perspective.

Evaluating a fine-tuning service. When using a third-party fine-tuning service (submitting your training data to an external service that returns trained model weights), assess: what happens to your training data during and after the fine-tuning job (is it retained by the provider, for how long, under what data processing agreement?), what security guarantees apply to the returned model weights (are they verified to not contain additional modifications beyond the fine-tuning?), and what happens if the fine-tuning service is compromised — could it introduce backdoors into your trained model?

Minimum requirements for third-party AI vendors. Before sending training data, proprietary documents, or personal data to any AI vendor: confirm a data processing agreement (DPA) is in place if the data includes personal data under GDPR; review the vendor's security policies and incident response procedures; confirm the vendor's SOC 2 Type II or equivalent certification; understand the data retention and deletion policies for submitted data; and obtain written confirmation that submitted data will not be used for the vendor's own model training without your consent.