Chapter 57 — Secure AI Supply Chain
57.1 Introduction
Modern AI applications rarely consist entirely of code written by one development team.
A production AI platform may depend on:
open-source libraries
package registries
container images
operating-system packages
AI model files
tokenizer files
datasets
third-party APIs
plugins
SDKs
cloud services
CI/CD actions
infrastructure modules
browser dependencies
model-serving frameworks
This creates a large software and AI supply chain.
A vulnerability introduced somewhere upstream can eventually affect the production application.
Therefore:
An AI system is only as trustworthy as the supply chain supporting it.
Supply-chain security attempts to establish where components came from, whether they were modified, whether they contain known vulnerabilities, and whether they are approved for use.
57.2 What Is an AI Supply Chain?
A simplified chain is:
Developer
↓
Source Code
↓
Dependencies
↓
Build System
↓
Container
↓
AI Runtime
↓
Model
↓
Deployment
↓
Production
A more complete system may look like:
Open Source
↓
Package Registry
↓
Dependency Resolver
↓
Source Repository
↓
CI/CD
↓
Build Artifact
↓
Container Registry
↓
Deployment
↓
AI Service
↓
Model Provider
↓
Production User
Every stage introduces potential risk.
57.3 Supply-Chain Threats
Important threats include:
malicious package
compromised dependency
typosquatting
dependency confusion
vulnerable library
compromised build server
tampered container
malicious model file
untrusted plugin
stolen signing key
compromised CI/CD action
provider compromise
The objective is not to assume every external component is malicious.
The objective is to reduce unnecessary trust.
57.4 Dependency Management
AI applications frequently contain many dependencies.
For example:
Application
├── Web framework
├── Database driver
├── Authentication library
├── AI SDK
├── Vector database client
├── File parser
├── Image library
└── Video library
Each dependency introduces:
code
permissions
update requirements
vulnerabilities
licensing considerations
maintenance dependencies
57.5 Direct vs Transitive Dependencies
A project may explicitly install:
library-A
But library-A may depend on:
library-B
library-C
library-D
These are transitive dependencies.
Therefore:
Reviewing only the packages listed directly in the project configuration is insufficient.
The complete dependency graph matters.
57.6 Dependency Lockfiles
A lockfile records resolved dependency versions.
Examples include:
package-lock.json
pnpm-lock.yaml
yarn.lock
Lockfiles help make builds reproducible.
Without a lockfile:
Build 1 → dependency version X
Build 2 → dependency version Y
may occur unexpectedly.
With a properly maintained lockfile:
Build 1 → version X
Build 2 → version X
unless the dependency is intentionally updated.
57.7 Dependency Updates
Dependencies should be updated systematically.
A useful lifecycle is:
Discover
↓
Assess
↓
Test
↓
Update
↓
Deploy
↓
Monitor
Blindly running updates in production is not a sufficient strategy.
Updates should be tested for:
compatibility
security
performance
behavior changes
57.8 Vulnerability Scanning
Dependency scanners can identify known vulnerabilities.
Conceptually:
Dependency Graph
↓
Vulnerability Database
↓
Matching
↓
Risk Assessment
↓
Remediation
A vulnerability finding should be evaluated based on:
severity
exploitability
exposure
affected functionality
availability of patch
compensating controls
A vulnerability number alone does not determine actual application risk.
57.9 Dependency Pinning
Critical production dependencies may be pinned to known versions.
For example:
framework = exact tested version
This reduces unexpected upgrades.
However, pinning forever creates another risk:
Old dependency
↓
Known vulnerability
↓
Never updated
Therefore:
Pin for reproducibility, update for security.
57.10 Dependency Allowlisting
Organizations can maintain approved dependency lists.
For example:
Approved:
library-A
library-B
library-C
New packages require review.
This reduces uncontrolled dependency growth.
57.11 Package Registry Security
Package registries are important trust boundaries.
Before installing a package, teams should consider:
maintainer reputation
package history
version history
source repository
release provenance
known vulnerabilities
dependency tree
permissions
maintenance activity
A popular package is not automatically risk-free.
57.12 Typosquatting
Attackers may publish packages with names resembling legitimate packages.
Conceptually:
trusted-package
trusted_packge
trusted-packag
trusted-package2
A developer may accidentally install the wrong package.
Defenses include:
approved package lists
lockfiles
code review
registry verification
automated dependency checks
57.13 Dependency Confusion
A project may expect an internal package:
company-internal-utils
If a package with the same name exists in a public registry and package-resolution rules are poorly configured, the wrong package may be selected.
Organizations should define explicit package sources and repository configuration.
57.14 Software Bill of Materials
An SBOM is an inventory of software components.
Conceptually:
Application
|
+-- dependency A
+-- dependency B
+-- dependency C
+-- dependency D
The SBOM may include:
component name
version
supplier
license
dependency relationships
package identifier
An SBOM improves visibility.
57.15 AI Bill of Materials
AI systems can extend the traditional software inventory.
An AI-oriented inventory may include:
application
libraries
container
runtime
model
model version
tokenizer
prompt templates
datasets
plugins
external providers
This creates a broader AI component inventory.
57.16 Model Supply Chain
AI models introduce a unique supply-chain problem.
A model may come from:
internal training
third-party provider
open-source repository
model hub
fine-tuning service
external vendor
The organization needs to know:
where the model came from
which version it is
who published it
what license applies
how it was evaluated
what format it uses
57.17 Model Files as Untrusted Artifacts
Model files should not automatically be treated as harmless data.
Depending on format and tooling, loading an untrusted artifact can create security risks.
Therefore:
Untrusted Model
↓
Quarantine
↓
Validation
↓
Scanning
↓
Safe Loader
↓
Evaluation
↓
Approval
↓
Production
The safest supported serialization format and loading mechanism should be preferred.
57.18 Model Provenance
A production model record should track provenance.
Example:
model_id
name
version
publisher
source
download_date
checksum
license
evaluation_id
approval_id
A cryptographic digest can help identify whether the artifact changed.
Conceptually:
Model File
↓
Hash
↓
Expected Hash
↓
Verification
57.19 Model Integrity
If the expected artifact has digest:
H_expected
and the downloaded artifact produces:
H_actual
the system should verify that:
H_actual == H_expected
before treating the artifact as the expected version.
Hash verification identifies modification relative to the trusted reference.
It does not by itself prove that the original artifact was trustworthy.
57.20 Model Evaluation Before Deployment
A model should pass appropriate evaluation before production.
Possible categories:
functional evaluation
quality evaluation
security evaluation
privacy evaluation
safety evaluation
performance evaluation
cost evaluation
robustness evaluation
The model should not be approved solely because it produces impressive outputs.
57.21 Container Supply Chain
AI applications frequently run inside containers.
The container itself is a supply-chain artifact.
A container may contain:
base operating system
runtime
system packages
application dependencies
AI libraries
model-serving software
configuration
Each layer should be considered.
57.22 Base Image Security
A container often begins with a base image.
For example:
Base Image
↓
Application Layer
↓
AI Runtime
↓
Final Image
A vulnerable base image can affect the entire application.
Use maintained, minimal base images where practical.
57.23 Minimal Containers
Reducing unnecessary software reduces attack surface.
Instead of:
large image
+
many unused tools
+
development packages
prefer:
minimal runtime
+
required application dependencies
This is especially useful for production deployments.
57.24 Container Scanning
Container images can be scanned before deployment.
Conceptually:
Container Build
↓
SBOM Generation
↓
Vulnerability Scan
↓
Policy Check
↓
Registry
↓
Deployment
A deployment gate can block images with unacceptable findings.
57.25 Container Signing
Organizations can use artifact signing to establish provenance.
Conceptually:
Build
↓
Artifact
↓
Sign
↓
Registry
↓
Verify
↓
Deploy
Deployment systems can require verification before accepting an artifact.
57.26 CI/CD Security
The build pipeline is one of the most important supply-chain trust boundaries.
A secure pipeline should protect:
source repository
build runner
secrets
dependencies
artifacts
deployment credentials
signing keys
A compromised pipeline can potentially produce compromised production software.
57.27 CI/CD Least Privilege
Build jobs should receive only the permissions they need.
For example:
Build Job
├── Read source
├── Install dependencies
├── Build artifact
└── Publish artifact
It should not automatically have unrestricted production administration privileges.
57.28 Build Isolation
Build environments should be isolated appropriately.
Avoid allowing untrusted build inputs to access:
production credentials
private networks
unrelated source repositories
administrative interfaces
Build systems are high-value targets.
57.29 Secrets in CI/CD
Secrets should not be embedded directly in:
source code
Dockerfiles
configuration files
logs
build artifacts
Instead use controlled secret-management systems.
The pipeline should receive temporary credentials where practical.
57.30 Git and Source Integrity
Source code should be protected through:
branch protection
code review
signed commits where appropriate
protected tags
restricted merge permissions
CI checks
Production deployment should ideally be connected to a trusted source state.
57.31 Pull Request Security
Security checks can run automatically when dependencies or infrastructure change.
For example:
Pull Request
↓
Unit Tests
↓
Dependency Scan
↓
Secret Scan
↓
Static Analysis
↓
Container Scan
↓
Security Review
This shifts security earlier in the lifecycle.
57.32 Open-Source AI Models
Open-source models can provide major benefits:
local deployment
customization
transparency
reduced vendor dependence
offline operation
But teams should still evaluate:
model provenance
license
security
quality
known limitations
model format
dependencies
maintenance
“Open source” does not mean “automatically secure.”
57.33 Model Hub Security
When retrieving models from public repositories, verify:
publisher
repository
version
release information
integrity
license
documentation
evaluation
Avoid allowing arbitrary production systems to automatically download unknown models at runtime.
A controlled promotion process is safer.
57.34 Runtime Model Downloads
A risky architecture is:
Production Server
↓
Internet
↓
Download arbitrary model
↓
Load immediately
A safer architecture is:
Approved Source
↓
Controlled Download
↓
Verification
↓
Security Scan
↓
Evaluation
↓
Approval
↓
Internal Artifact Store
↓
Production
This creates a clear trust boundary.
57.35 Plugin Supply Chain
Plugins can greatly expand application capabilities.
A plugin may receive:
network access
filesystem access
API access
AI context
user information
tool permissions
Therefore plugins should be treated as privileged extensions.
Each plugin should have:
plugin_id
version
publisher
permissions
dependencies
risk_level
approval_status
57.36 Plugin Permissions
A plugin should receive only required permissions.
Example:
Plugin A:
READ_PROJECT
Plugin B:
READ_PROJECT
WRITE_PROJECT
Plugin C:
EXTERNAL_NETWORK
Permissions should not automatically equal full application access.
57.37 Plugin Isolation
Where practical, plugins can run in separate processes or sandboxed environments.
Conceptually:
Main Application
|
Permission Layer
|
Plugin Sandbox
|
Plugin
The sandbox limits what the plugin can access.
57.38 Provider Supply Chain
AI providers themselves become dependencies.
A provider outage can affect:
model availability
latency
cost
application functionality
Provider changes can also alter model behavior.
Therefore provider governance should track:
provider
models
contract
data handling
regions
availability
security controls
fallback provider
57.39 Multi-Provider Architecture
A provider abstraction can reduce dependency risk.
AI Gateway
|
+------------+------------+
| | |
Provider A Provider B Local Model
Routing can consider:
availability
cost
privacy
latency
capability
risk
Fallbacks should be tested rather than assumed to work.
57.40 Supply-Chain Risk Scoring
A component can be evaluated using multiple signals:
component age
maintenance status
known vulnerabilities
privilege level
publisher trust
usage scope
internet exposure
criticality
The objective is prioritization.
Not every dependency requires the same review depth.
57.41 Critical Components
Particularly important components may include:
authentication library
authorization layer
cryptography library
AI model loader
file parser
container runtime
database driver
agent framework
payment integration
These should receive stronger review.
57.42 Vulnerability Response
When a vulnerability is discovered:
Detect
↓
Identify affected components
↓
Assess exposure
↓
Prioritize
↓
Patch / mitigate
↓
Test
↓
Deploy
↓
Verify
Do not assume every vulnerability requires immediate replacement without analysis.
57.43 Emergency Dependency Updates
Critical vulnerabilities may require emergency response.
The process may include:
Emergency Finding
↓
Affected Systems
↓
Temporary Mitigation
↓
Patch
↓
Focused Testing
↓
Production Deployment
↓
Verification
The change should still be documented.
57.44 Supply-Chain Monitoring
Monitoring should continue after deployment.
Useful signals include:
new vulnerability disclosures
dependency changes
unexpected package releases
provider incidents
model changes
container vulnerabilities
plugin updates
A component inventory makes this monitoring possible.
57.45 Dependency Graph
A useful internal representation is:
Application
|
+-- Framework
| |
| +-- Dependency A
| +-- Dependency B
|
+-- AI Runtime
| |
| +-- Library C
| +-- Library D
|
+-- File Processor
|
+-- Library E
When vulnerability information arrives for Library E, the organization can determine which applications are affected.
57.46 SBOM Example
Conceptually:
{
"application": "AI-Creative-Platform",
"version": "1.0.0",
"components": [
{
"name": "framework",
"version": "X.Y.Z"
},
{
"name": "ai-runtime",
"version": "A.B.C"
},
{
"name": "database-client",
"version": "M.N.P"
}
]
}
A real SBOM format should follow an established standard rather than relying on an arbitrary custom structure.
57.47 AI Supply-Chain Inventory
A broader inventory can be:
AI System
|
+-- Source Code
+-- Dependencies
+-- Container
+-- Runtime
+-- Model
+-- Tokenizer
+-- Dataset
+-- Prompt Package
+-- Plugin
+-- External Provider
+-- Infrastructure
This is much more useful for AI governance than tracking only the application package list.
57.48 Supply-Chain Security Testing
A comprehensive test program should include:
Dependency Testing
known vulnerability
outdated package
unexpected dependency
malicious package simulation
Container Testing
vulnerable base image
unnecessary packages
unsafe configuration
unapproved image
Model Testing
invalid artifact
unexpected model version
integrity mismatch
unsafe loader behavior
CI/CD Testing
unauthorized deployment
secret exposure
untrusted artifact
insufficient permissions
Plugin Testing
permission escalation
unauthorized data access
unexpected network access
57.49 Reference Secure Supply-Chain Architecture
SOURCE
|
+--------+--------+
| |
Code Models
| |
Dependency Verification
Review |
| Evaluation
+--------+--------+
|
CI/CD
|
Security Checks
|
+-----------+-----------+
| | |
SAST SCA SBOM
| | |
+-----------+-----------+
|
Build Artifact
|
Container Scan
|
Sign Artifact
|
Artifact Registry
|
Deployment Gate
|
Runtime
|
Monitoring
57.50 Secure Promotion Model
A component should progress through controlled environments:
UNTRUSTED
↓
QUARANTINED
↓
VALIDATED
↓
TESTED
↓
APPROVED
↓
INTERNAL REGISTRY
↓
PRODUCTION
This applies particularly well to:
models
containers
plugins
important dependencies
57.51 Supply-Chain Security Checklist
Dependencies
[ ] Dependency inventory exists.
[ ] Lockfiles are maintained.
[ ] Vulnerability scanning exists.
[ ] Critical dependencies are reviewed.
[ ] Unused dependencies are removed.
Source
[ ] Repository access is controlled.
[ ] Branch protection exists.
[ ] Code review is required.
[ ] Deployment source is traceable.
CI/CD
[ ] Build permissions follow least privilege.
[ ] Secrets are protected.
[ ] Build environments are isolated.
[ ] Artifacts are traceable.
Containers
[ ] Base images are maintained.
[ ] Images are scanned.
[ ] Images are minimized.
[ ] Production images are controlled.
Models
[ ] Model provenance is tracked.
[ ] Model artifacts are verified.
[ ] Models are evaluated before production.
[ ] Production models are versioned.
[ ] Runtime arbitrary downloads are restricted.
Plugins
[ ] Plugins are inventoried.
[ ] Plugin permissions are explicit.
[ ] Plugin versions are tracked.
[ ] Plugins are evaluated before approval.
Providers
[ ] AI providers are documented.
[ ] Provider dependencies are monitored.
[ ] Data handling is reviewed.
[ ] Fallback strategy exists where required.
SBOM
[ ] Software inventory is generated.
[ ] AI components are tracked.
[ ] Dependency relationships are visible.
[ ] Vulnerability response can identify affected systems.
57.52 Final Architecture Principle
AI supply-chain security is fundamentally about controlling trust.
Instead of:
Download
↓
Trust
↓
Deploy
use:
Acquire
↓
Identify
↓
Verify
↓
Scan
↓
Evaluate
↓
Approve
↓
Sign / Record
↓
Deploy
↓
Monitor
The most important principle is:
Every external component should have a known origin, controlled promotion path, appropriate security evaluation, and traceable production identity.
A mature AI supply chain connects:
Source Security
+
Dependency Security
+
Build Security
+
Artifact Security
+
Model Security
+
Plugin Security
+
Provider Governance
+
Runtime Monitoring
into one continuous chain of trust.
The goal is not to eliminate every external dependency.
The goal is to ensure that external dependencies do not become invisible or uncontrolled trust relationships.