AI Supply Chain Dependencies

A machine learning infrastructure vendor's core AI pipeline was built on a combination of well-established open-source libraries and a smaller, specialised data preprocessing library called dataprep , a utility for cleaning and standardising training data inputs. The first three dependencies (scikit-learn, NumPy, pandas) were among the most scrutinised open-source projects in the ML ecosystem, with active security programmes, rapid vulnerability response, and continuous community audit. dataprep was a different story: maintained by a single developer, last committed eight months prior, with no security disclosure process and no dependency audit history. When a security researcher published a proof-of-concept demonstrating that a maliciously crafted model artifact processed by dataprep could execute arbitrary code during the data loading phase, the vendor had no monitoring in place to catch the disclosure. The vulnerability sat in their production AI pipeline for six months. The vendor learned about it when a customer's security team flagged the public advisory. The vendor's AI security programme had evaluated the model's training process, the inference API's security, and the training data provenance. It had not evaluated the security posture of the libraries that mediated between the training data and the model training process.

What are AI Supply Chain Dependencies, Really?

AI supply chain dependencies are the open-source libraries, pre-trained model components, data processing utilities, and ML framework packages that constitute the software stack on which an AI system is built , and through which supply chain attacks can compromise the AI system without attacking the model itself. Just as software supply chain security recognises that an application's security depends on every library and dependency it includes, AI supply chain security recognises that an AI system's integrity depends on every component in the stack that processes its training data, executes its inference, or manages its deployment.

The AI-specific dependency risk dimension extends beyond standard software supply chain risk in several ways. First, AI pipelines are often assembled from a heterogeneous mix of well-established frameworks (TensorFlow, PyTorch, scikit-learn) and specialised utilities (data preprocessing tools, feature engineering libraries, model serialisation utilities) where the specialised utilities may have significantly weaker security postures than the flagship frameworks. An organisation that focuses its dependency security programme on the major frameworks may miss the risk concentrated in the smaller specialised utilities that are less scrutinised and less actively maintained.

The model serialisation vulnerability is a specific and well-documented AI dependency risk. Python's pickle format , used by default in many ML frameworks for model saving and loading , allows arbitrary code execution when a malicious model artifact is loaded. Libraries that handle model loading without safe deserialization controls create a pathway where a supply chain attacker who can substitute a malicious model artifact in the model registry can execute code in the inference environment when the model is loaded. This attack requires no exploitation of the model's algorithm , only the ability to replace the serialised model file with a malicious one.

The data processing library attack surface is the second specific risk. Libraries that handle training data preprocessing , reading, parsing, transforming, and cleaning input data , process untrusted data from potentially untrusted sources. A vulnerability in a data preprocessing library that is triggered by malicious input data creates a pathway where a supply chain attacker who can introduce malicious training data can execute code in the training environment when that data is processed. The attack vector is the training data, not the model or the training algorithm.

The dependency freshness and maintenance risk is the governance dimension. ML ecosystem dependencies vary enormously in their maintenance activity, security disclosure processes, and vulnerability response timelines. A dependency maintained by a single developer with no security disclosure process provides essentially no security assurance , vulnerabilities may be discovered and exploited long before the maintainer is aware of them. The transitive dependency problem amplifies this: a well-maintained primary framework may include transitive dependencies on poorly maintained utilities, creating supply chain risk through a chain of dependencies that extends beyond the primary framework's security posture.

Why this matters

AI supply chain dependencies matter for TPRM because the vendor's AI system's security is bounded by the security of every component in its dependency stack , not just the model architecture and the training process. A vendor whose AI security programme focuses on the model layer while leaving the dependency layer unmonitored has a security posture that is stronger at the layers they assess and unknown at the layers they don't.

Where most teams get this wrong

The most consistent failure is assessing AI security at the model layer , training process, inference API, data provenance , without extending the assessment to the dependency stack that the AI pipeline is built on. The dependency layer is where many AI supply chain attacks will occur.

• AI security assessed at model layer without dependency layer evaluation
• Specialised utility dependencies not assessed , focus on major frameworks only
• Model serialisation format not assessed for safe deserialization
• Dependency monitoring absent , no process for tracking vulnerability disclosures in AI dependencies
• Single-maintainer dependencies not identified as elevated risk

What good looks like

Mature AI supply chain security programmes maintain a complete AI dependency inventory , including specialised utilities and transitive dependencies , monitor for vulnerability disclosures across all dependencies, assess model serialisation formats for safe deserialization, and apply risk-tiered maintenance standards that flag single-maintainer or inactive dependencies as elevated risk.

• Complete AI dependency inventory , all libraries including specialised utilities and transitive dependencies
• Continuous vulnerability monitoring , all AI dependencies in vulnerability disclosure monitoring
• Safe deserialization enforcement , model loading using safe formats rather than pickle where possible
• Dependency health assessment , maintainer activity, security disclosure process, last release
• Automated SBOM for AI pipelines , software bill of materials including ML dependencies

Tooling

Dependency Security , Snyk, Dependabot, OWASP Dependency-Check for AI library scanning

Software composition analysis tools can be applied to AI pipeline dependencies as well as application dependencies. For TPRM practitioners, asking whether the vendor's AI pipeline dependencies are included in their SCA scanning programme , specifically whether specialised ML utilities are covered alongside the major frameworks , provides a specific AI dependency security question.

Safe Model Loading , MLflow model registry with integrity verification, ModelScan for pickle safety

ModelScan and similar tools scan serialised model artifacts for malicious payloads before loading. For TPRM practitioners, asking whether the vendor's model loading process uses safe deserialization or scans model artifacts before loading provides a specific serialisation security question.

Governance challenges

The governance challenge with AI supply chain dependencies is the ecosystem heterogeneity problem. The AI/ML open-source ecosystem contains thousands of specialised packages with highly variable maintenance quality. A comprehensive dependency security programme for AI pipelines requires assessment tooling that covers the full ecosystem, not just the flagship frameworks.

• Include AI pipeline dependencies in SCA scanning
• Assess model serialisation format , avoid pickle where safe alternatives exist
• Monitor dependency health , maintainer activity and security disclosure process
• Ask for AI pipeline SBOM , complete dependency inventory
• Flag single-maintainer dependencies as requiring additional review

If you are a small team

Ask your highest-risk AI vendor for their AI pipeline SBOM , the complete list of Python packages and versions in their ML dependency stack. Then check two things: first, are all packages monitored for vulnerability disclosures through a tool like Snyk or Dependabot? Second, for any package with fewer than three active contributors or no commits in six months, what is the vendor's process for assessing security risk? Those two questions reveal whether the dependency layer has received equivalent security attention to the model layer.

• Ask for AI pipeline SBOM , complete ML dependency list
• Ask whether all packages are monitored for vulnerability disclosures
• Flag packages with single maintainers or extended inactivity
• Ask about safe model serialisation format

What to require

Ask directly:

"Can you provide the software bill of materials for your AI pipeline , specifically all ML library dependencies including specialised utilities , and are all of those dependencies monitored for vulnerability disclosures through an automated SCA tool?"

Expect as evidence

• AI pipeline SBOM with all ML dependencies
• SCA tool coverage for all AI dependencies
• Model serialisation format and safe loading confirmation
• Dependency health assessment for high-risk packages

A vendor who confirms AI security coverage should be asked for the AI pipeline SBOM. Model layer security covers the model. Dependency layer security covers the stack the model runs on. Both are required.

How to evidence it

• AI pipeline SBOM records
• SCA scanning coverage for AI dependencies
• Model serialisation security assessment
• Dependency health monitoring records

Key Takeaway

Four libraries. Three well-audited. One: single maintainer, eight months inactive, arbitrary code execution via malicious training data. Six months in the production pipeline before discovery. The AI security programme covered the model layer comprehensively. The dependency layer , the stack the model training process runs on , was not in scope. AI supply chain attacks don't require compromising the model algorithm. They require finding the weakest link in the dependency stack that processes training data or loads model artifacts. The AI pipeline SBOM is the inventory. SCA scanning is the monitoring. Safe deserialization is the architectural control. Together they cover the dependency layer the model-layer assessment misses.

More on AI governance

• AI API Key Exposure
• AI Adversarial Attacks
• AI Attack Surface Expansion