10 AI Supply Chain and Model Security

Modern AI applications depend on a large number of external and internal components.

An enterprise AI system may rely on:

Foundation models
Open-source models
Embedding models
Tokenizers
Model repositories
Python packages
AI frameworks
Containers
Fine-tuning datasets
External APIs
CI/CD pipelines
MLOps platforms

Every dependency creates another trust boundary.

A system may appear secure at runtime while still being compromised through an upstream component.

Conceptually:

Model
+
Framework
+
Dependency
+
Dataset
+
Container
+
Pipeline
        ↓
Enterprise AI Application

This is the AI supply chain.

For an AI Security Engineer, the central question is:

Can we trust the models, code, data and artifacts that make up our AI system?

Learning Objectives

By the end of this lesson, you should be able to:

Explain what the AI supply chain includes.
Understand model provenance.
Recognize risks associated with external and open-source models.
Understand model repository security.
Recognize malicious or tampered model artifacts.
Understand dependency and package risk.
Understand AI framework security.
Recognize container and runtime risks.
Understand dataset provenance.
Protect fine-tuning pipelines.
Understand model integrity and version control.
Apply vulnerability management to AI components.
Understand AI Bill of Materials concepts.
Secure model promotion and deployment.
Assess AI supply-chain risk systematically.

What Is the AI Supply Chain?

The AI supply chain includes the technologies, data and artifacts required to build and operate an AI system.

A simplified lifecycle might be:

Model Source
    ↓
Dependencies
    ↓
Dataset
    ↓
Development
    ↓
Fine-Tuning
    ↓
Model Registry
    ↓
Container
    ↓
Deployment Pipeline
    ↓
Production

Any stage may become a target.

Traditional Software Supply Chain vs AI Supply Chain

Traditional software supply chains already include:

Source code
Packages
Build systems
Containers
CI/CD
Artifact repositories

AI adds additional components:

Models

Training Data

Fine-Tuning Data

Embedding Models

Model Registries

Model Weights

AI Frameworks

Therefore:

Software Supply Chain
        +
Model Supply Chain
        +
Data Supply Chain
        =
AI Supply Chain

Why AI Supply-Chain Security Matters

Imagine an enterprise carefully secures:

Authentication
RAG
AI agents
Cloud infrastructure

but downloads an untrusted model artifact.

Attack path:

Untrusted Model
      ↓
Enterprise Development
      ↓
Production Deployment

The organization may introduce the risk itself.

Supply-chain security begins before production.

Trust Must Be Established Upstream

A useful principle is:

Do not assume an AI component is trustworthy simply because it works.

Ask:

Where did it come from?

Who published it?

Which version is it?

Has it been reviewed?

Can integrity be verified?

What dependencies does it contain?

Who approved it?

1 — Foundation Model Security

Foundation models may come from:

Commercial AI providers
Cloud platforms
Open-source ecosystems
Internal model teams

Each source creates different security considerations.

Hosted Foundation Models

Architecture:

Enterprise Application
        ↓
External Model Provider

Security questions include:

Who operates the service?
What data is sent?
What is retained?
What model version is used?
Can the provider change the model?
How is availability handled?

Self-Hosted Models

Architecture:

Enterprise Infrastructure
        ↓
Model Runtime
        ↓
Model Files

Security responsibilities increase.

The organization now needs to protect:

Model files
Runtime
GPUs
Storage
Access control
Patching
Availability

Model Provenance

Model provenance means knowing where a model came from and how it reached production.

A model record may include:

Model:
example-model

Source:
Approved Repository

Version:
v3.2

Publisher:
Approved Vendor

Checksum:
Verified

Security Review:
Completed

Production Approval:
Approved

This creates traceability.

Provenance Questions

Ask:

Who created the model?

Where was it downloaded from?

Was it modified?

Was it fine-tuned?

Which dataset was used?

Who approved deployment?

Without provenance, trust becomes difficult to establish.

2 — Open-Source Model Risk

Open-source models provide significant flexibility.

But organizations should not assume:

Popular
=
Secure

Potential concerns include:

Unknown provenance
Tampered artifacts
Unreviewed dependencies
Unsafe serialization
Licensing concerns
Unknown training history

Open-Source Model Review

Before use, consider:

Source Repository

Publisher

Community Reputation

Release History

Artifact Integrity

File Format

Dependencies

Security Advisories

License

This is similar to evaluating open-source software.

3 — Model Repository Security

Models may be stored in:

Public model hubs
Cloud storage
Internal registries
Artifact repositories

The repository becomes a critical trust boundary.

Model Repository
      ↓
Development
      ↓
Production

Repository Risks

Potential risks include:

Unauthorized model upload
Model replacement
Account compromise
Malicious artifacts
Deleted or altered versions

Secure Model Registry

A stronger architecture:

External Model
      ↓
Security Review
      ↓
Approved Internal Registry
      ↓
Controlled Deployment

Production should preferably deploy from approved trusted locations rather than arbitrary internet sources.

4 — Model Tampering

An attacker may attempt to replace or modify a model artifact.

Attack path:

Attacker
   ↓
Model Registry Access
   ↓
Model Replaced
   ↓
Production Deployment

This is an integrity failure.

Model Integrity Verification

Organizations may track integrity using:

Checksums
Signatures
Immutable artifacts
Versioned registries
Controlled publishing

Conceptually:

Downloaded Model
      ↓
Integrity Verification
      ↓
Expected?
 ├── No → Reject
 └── Yes → Continue

5 — Model File Security

Model files may represent valuable intellectual property.

Protect them from:

Unauthorized download
Modification
Deletion
Copying

Use appropriate:

IAM
Storage security
Encryption
Audit logging
Network controls

6 — Model Serialization Risks

AI model ecosystems may use different file formats and serialization mechanisms.

Some formats may carry more risk than others depending on how they are loaded.

The practical security principle is:

Do not load arbitrary model artifacts from untrusted sources into privileged environments.

Treat model loading as a potentially security-sensitive operation.

Isolated Evaluation

Before introducing an external model into enterprise environments:

External Model
      ↓
Isolated Evaluation Environment
      ↓
Security Review
      ↓
Approved Registry

This limits potential impact during assessment.

7 — Python Package Security

AI applications heavily depend on Python ecosystems.

Dependencies may include:

ML libraries
LLM frameworks
Vector clients
Data processing libraries
Agent frameworks

Traditional dependency risks still apply.

Potential threats include:

Vulnerable packages
Malicious packages
Dependency confusion
Typosquatting
Compromised maintainers

Dependency Control

Use:

Approved Package Sources
      ↓
Version Pinning
      ↓
Dependency Scanning
      ↓
Build

Avoid unnecessarily downloading arbitrary packages during runtime.

8 — AI Framework Security

AI applications may use frameworks for:

Model inference
RAG
Agents
Tool orchestration

A vulnerability in the framework may affect many applications.

Security teams should track:

Framework versions
Security advisories
Dependency trees
Patch requirements

Framework security belongs to the broader secure development lifecycle.

9 — Package Version Pinning

Avoid uncontrolled dependency changes.

Weak:

package >= latest

may produce unexpected changes over time.

Controlled environments often prefer:

Known Tested Version

with deliberate upgrades.

The exact package-management approach depends on engineering practices.

10 — Container Image Security

AI applications frequently run in containers.

The container supply chain may include:

Base Image
    ↓
OS Packages
    ↓
Python Dependencies
    ↓
AI Application
    ↓
Model Runtime

Potential concerns include:

Vulnerable images
Malicious packages
Embedded credentials
Excessive privileges
Outdated components

Container Security Controls

Consider:

Approved base images
Image scanning
Minimal images
Non-root execution
Secret scanning
Image signing
Controlled registries

Detailed container security may be covered in specialist infrastructure tracks, but AI Security Engineers should understand the supply-chain dependency.

11 — Container Registry Security

A trusted container image is only useful if the registry is secure.

Attack path:

Attacker
   ↓
Container Registry
   ↓
AI Image Replaced
   ↓
Deployment

Controls include:

Strong authentication
Restricted publishing rights
Immutable tags where appropriate
Artifact signing
Audit logging

12 — Dataset Supply Chain

AI systems depend heavily on data.

Datasets may originate from:

Internal databases
Public datasets
Third-party providers
User submissions
Data marketplaces
Generated synthetic data

Every source has trust implications.

Dataset Provenance

Track:

Dataset Name

Source

Owner

Version

Classification

Usage Rights

Approval Status

Integrity

This helps understand what influenced the model.

13 — Data Poisoning

Attackers may manipulate training or fine-tuning data.

Conceptually:

Trusted Dataset
      +
Malicious Samples
      ↓
Training
      ↓
Modified Model Behavior

The attack targets model integrity.

Data Integrity Controls

Potential controls include:

Approved data sources
Access control
Versioning
Integrity checks
Change review
Anomaly detection

The exact controls depend on the training environment.

14 — Fine-Tuning Supply Chain

Organizations may fine-tune models using enterprise data.

Architecture:

Base Model
   +
Fine-Tuning Dataset
   ↓
Training
   ↓
Fine-Tuned Model

Every component should be traceable.

Fine-Tuning Security Questions

Ask:

Which base model?

Which version?

Which dataset?

Who approved the dataset?

Who initiated training?

Where was training performed?

Where is the resulting model stored?

Fine-Tuning Approval

A mature process may look like:

Approved Base Model
      ↓
Approved Dataset
      ↓
Controlled Training
      ↓
Evaluation
      ↓
Security Review
      ↓
Approved Model Registry

15 — Training Infrastructure

Training environments may contain:

GPUs
Sensitive datasets
Model files
Credentials
Development notebooks

Potential threats include:

Unauthorized access
Data theft
Model theft
Credential compromise

Training environments deserve enterprise security controls.

16 — Notebook Security

AI engineers often use notebooks for experimentation.

Potential risks include:

Hard-coded credentials
Sensitive output
Excessive cloud permissions
Untrusted code execution

Development convenience should not bypass security controls.

17 — External APIs

AI applications may rely on external:

Model APIs
Embedding APIs
Search APIs
Data APIs

Each becomes a supply-chain dependency.

Questions include:

What if the API is compromised?

What if the response is manipulated?

What if the service changes behavior?

What if availability fails?

Third-party service risk should be understood.

18 — AI Plugins and Extensions

AI platforms may support plugins or integrations.

Potential risks include:

Excessive permissions
Malicious plugin behavior
Compromised updates
Third-party data access

Only approved integrations should normally be enabled in enterprise environments.

19 — CI/CD Security

AI applications and models may be promoted through CI/CD.

Example:

Code
 ↓
Build
 ↓
Security Tests
 ↓
Artifact
 ↓
Deployment

Attackers may target:

Source repositories
Pipeline credentials
Build agents
Artifact registries
Deployment identities

Pipeline Credentials

CI/CD systems often hold powerful credentials.

Avoid:

Pipeline
 ↓
Permanent Administrator Key

Prefer restricted deployment identities where possible.

20 — MLOps Security

MLOps extends CI/CD into model lifecycle management.

A simplified MLOps pipeline:

Dataset
   ↓
Training
   ↓
Evaluation
   ↓
Model Registry
   ↓
Deployment
   ↓
Monitoring

Each stage should have defined:

Identity
Authorization
Integrity
Logging

Model Promotion

Avoid:

Developer Model
      ↓
Direct Production

Prefer:

Development Model
      ↓
Evaluation
      ↓
Security Validation
      ↓
Approval
      ↓
Production Registry
      ↓
Deployment

21 — Model Version Management

Model versioning is critical.

Track:

Model Name

Version

Source

Configuration

Fine-Tuning Dataset

Evaluation Results

Approval Status

This supports investigation and rollback.

Why Versioning Matters

Imagine production behavior changes.

Investigators ask:

Which model was active?

Was the model changed?

Was it fine-tuned?

Which dataset was used?

Without versioning, investigation becomes much harder.

22 — Rollback

Organizations should be able to move from:

Model v3

back to:

Model v2

if a serious issue appears.

Rollback capability should be tested.

23 — Model Configuration Security

Security-sensitive behavior may depend on configuration.

Track changes to:

System configuration
Safety settings
Tool configuration
Model routing
Prompt templates

The production artifact is not only the model file.

24 — Supply-Chain Secrets

Credentials may appear inside:

Repositories
Model configuration
Notebooks
Containers
CI/CD
Logs

Secret scanning should include AI development environments.

Bad Example

MODEL_API_KEY="..."

committed to source control.

Better

Application
      ↓
Managed Secret / Workload Identity
      ↓
Approved Service

25 — Vulnerability Management

AI applications still need vulnerability management.

Inventory:

Operating System

Containers

Libraries

AI Frameworks

Vector Database

Model Serving Runtime

Then:

Identify Vulnerability
      ↓
Assess Exposure
      ↓
Prioritize
      ↓
Remediate
      ↓
Validate

AI Components Change Quickly

AI ecosystems may update frequently.

This makes component inventory particularly important.

Without inventory, teams may not know:

Are we using the vulnerable version?

26 — AI Bill of Materials

Traditional software environments increasingly use an SBOM:

Software Bill of Materials

AI environments may require broader inventories including models and data.

A conceptual AI Bill of Materials might include:

Application

Foundation Model

Model Version

Embedding Model

AI Framework

Libraries

Container Images

Datasets

External Services

The exact terminology and implementation may vary.

The important goal is visibility.

Example AI Component Inventory

Component	Version	Source	Owner	Approved
AI Application	4.2	Internal	App Team	Yes
Foundation Model	v3	Approved Provider	AI Team	Yes
Embedding Model	v2	Internal Registry	AI Team	Yes
RAG Framework	1.x	Approved Package Repo	Platform	Yes
Container Image	2026.08	Internal Registry	DevOps	Yes

This makes supply-chain risk manageable.

27 — Third-Party Risk

External AI providers should be assessed like other critical vendors.

Consider:

Security controls
Data handling
Availability
Subprocessors
Incident notification
Access
Compliance

AI architecture should document vendor dependencies.

28 — Vendor Model Updates

Hosted model providers may update models.

This may change:

Model behavior
Safety characteristics
Output format
Performance

Organizations should understand how model changes are managed.

Where necessary, regression testing may be required.

29 — Unapproved Model Use

Developers may experiment with new models.

Example:

Developer
   ↓
Downloads Model
   ↓
Connects Enterprise Data

Potential concerns include:

Unknown trust
Data exposure
Licensing
Unreviewed behavior

Organizations may need approved model catalogs.

Approved Model Catalog

Example:

Approved Models

Model A
→ General Enterprise Use

Model B
→ Internal Code Use

Model C
→ Restricted Data Allowed

This helps engineering teams choose supported models.

30 — Model Theft

Attackers may target proprietary models.

Attack path:

Compromised Storage
      ↓
Model File
      ↓
Exfiltration

Controls may include:

Strong access control
Private storage
Monitoring
Encryption
Restricted downloads

31 — Model Extraction

When models are exposed only through APIs, attackers may attempt to approximate behavior through repeated querying.

Potential controls may include:

Authentication
Rate limiting
Monitoring
Quotas

The exact threat depends on the business value of the model.

32 — Supply-Chain Availability

Security also includes availability.

What happens if:

External Model Provider
      ↓
Unavailable

or:

Model Repository
      ↓
Unavailable

Organizations may require:

Redundancy
Cached approved artifacts
Alternative providers
Recovery procedures

Supply-Chain Threat Model

A useful model is:

Source
 ↓
Acquire
 ↓
Validate
 ↓
Store
 ↓
Build
 ↓
Test
 ↓
Approve
 ↓
Deploy
 ↓
Monitor

Ask security questions at every stage.

Stage 1 — Source

Where did it come from?

Stage 2 — Acquire

Was it downloaded through an approved channel?

Stage 3 — Validate

Can we verify integrity and provenance?

Stage 4 — Store

Is it stored in a controlled registry?

Stage 5 — Build

Are dependencies controlled?

Stage 6 — Test

Was security evaluation performed?

Stage 7 — Approve

Who approved production usage?

Stage 8 — Deploy

Is deployment controlled?

Stage 9 — Monitor

Can changes or vulnerabilities be detected?

Enterprise Secure Model Flow

A stronger model lifecycle might look like:

External / Internal Model Source
           ↓
Provenance Check
           ↓
Integrity Verification
           ↓
Isolated Evaluation
           ↓
Security Review
           ↓
Approved Internal Model Registry
           ↓
Controlled Deployment Pipeline
           ↓
Production
           ↓
Monitoring

Secure Fine-Tuned Model Flow

Approved Base Model
        +
Approved Dataset
        ↓
Controlled Fine-Tuning
        ↓
Evaluation
        ↓
Security Testing
        ↓
Versioned Model Registry
        ↓
Approval
        ↓
Production

AI Supply-Chain Assessment Methodology

When reviewing an enterprise AI application:

Step 1 — Inventory Components

Document:

Foundation Model

Embedding Model

Framework

Packages

Containers

Datasets

External APIs

Model Registry

CI/CD

Step 2 — Identify Sources

For each component:

Internal?

Vendor?

Open Source?

Public Repository?

Unknown?

Step 3 — Determine Ownership

Ask:

Who owns this component internally?

Who approves updates?

Who monitors vulnerabilities?

Step 4 — Review Provenance

Verify:

Source

Version

Publisher

Integrity

Approval

Step 5 — Review Access

Determine who can:

Upload Models

Modify Models

Delete Models

Publish Packages

Change Pipelines

Deploy Production

Step 6 — Review Model Registry

Check:

Authentication
Authorization
Versioning
Logging
Integrity controls

Step 7 — Review Dependencies

Identify:

Vulnerable libraries
Unpinned packages
Unapproved package sources

Step 8 — Review Dataset Sources

Determine:

Where does training data come from?

Who can modify it?

How is it versioned?

Is sensitive data included?

Step 9 — Review Fine-Tuning

Verify approved:

Base Model

Dataset

Training Environment

Resulting Model

Step 10 — Review Deployment

Ask:

Can developers deploy directly?

Is approval required?

Are artifacts immutable?

Which identity performs deployment?

Step 11 — Review Monitoring

Verify teams can detect:

Model changes
Registry changes
Pipeline changes
Package vulnerabilities
Unauthorized deployment

Step 12 — Review Recovery

Determine whether the organization can:

Rollback Model

Replace Dependency

Rebuild Container

Revoke Credential

Disable Model

Example — Untrusted Model Finding

Finding:
Production Application Uses Unapproved External Model

Affected Component:
Enterprise AI Assistant

Observed Behavior:
The production application loads a model directly
from an external public repository.

Security Concern:
Model provenance and artifact integrity are not
validated before production use.

Potential Impact:
A tampered or malicious model artifact could enter
the enterprise AI environment.

Recommendation:
Establish an approved model intake process, perform
provenance and integrity validation, evaluate models
in an isolated environment and promote approved
artifacts into an internal model registry.

Example — Model Registry Finding

Finding:
Developers Can Replace Production Model Artifacts

Affected Component:
Enterprise Model Registry

Observed Permission:
Development users have write access to the production
model repository.

Potential Impact:
Compromised developer credentials could modify or replace
the model used by production AI applications.

Recommendation:
Separate development and production model registries,
restrict publishing privileges, require controlled
promotion and monitor production model changes.

Example — Dependency Finding

Finding:
AI Application Uses Uncontrolled Runtime Dependencies

Affected Component:
AI Application Build Pipeline

Observed Behavior:
The production build downloads package versions dynamically
without a controlled dependency lock or approved package source.

Potential Impact:
Unexpected or malicious dependency changes may enter the
production build.

Recommendation:
Use controlled package sources, version pinning or lock files,
dependency scanning and reproducible build processes.

Example — Dataset Provenance Finding

Finding:
Fine-Tuning Dataset Has No Provenance or Change History

Affected Component:
Enterprise Fine-Tuning Pipeline

Observed Behavior:
The training dataset can be modified without documented
ownership, versioning or approval.

Potential Impact:
Unauthorized or poisoned data may influence production
model behavior without reliable traceability.

Recommendation:
Establish dataset ownership, trusted data sources,
version control, approval workflows and integrity
monitoring for fine-tuning datasets.

Example — Direct Production Deployment Finding

Finding:
AI Models Can Be Promoted Directly From Development to Production

Affected Component:
MLOps Deployment Pipeline

Observed Behavior:
Developers can deploy new model versions without
independent validation or production approval.

Potential Impact:
Untested, compromised or incorrectly configured models
may reach production.

Recommendation:
Introduce evaluation, security validation, controlled
model promotion, approval gates and rollback capability.

AI Supply-Chain Security Checklist

Models

Model sources documented.
Model provenance known.
Model versions tracked.
Integrity validated.
Approved model catalog maintained.

Repositories

Model registries authenticated.
Publishing rights restricted.
Production artifacts protected.
Changes logged.

Open Source

Public models reviewed.
External artifacts evaluated safely.
License requirements reviewed.
Untrusted artifacts isolated.

Dependencies

Package sources controlled.
Versions managed.
Vulnerability scanning implemented.
Unnecessary dependencies removed.

Frameworks

AI framework versions inventoried.
Security advisories monitored.
Updates tested before production.

Containers

Approved base images used.
Images scanned.
Registries protected.
Secrets excluded from images.

Datasets

Dataset sources documented.
Provenance maintained.
Dataset access restricted.
Changes versioned.
Poisoning risk considered.

Fine-Tuning

Base model approved.
Dataset approved.
Training environment controlled.
Output model versioned.
Evaluation completed.

CI/CD & MLOps

Pipelines authenticated.
Pipeline credentials restricted.
Deployment identities least privileged.
Production approval exists.
Rollback supported.

Secrets

Credentials excluded from source.
Credentials excluded from model context.
Secrets managed centrally.
Secret scanning enabled where appropriate.

Inventory

Models inventoried.
Libraries inventoried.
Containers inventoried.
External services inventoried.
Dataset dependencies understood.

Monitoring

Model changes monitored.
Registry changes logged.
Unauthorized publishing detectable.
Vulnerability exposure tracked.

Recovery

Models can be rolled back.
Compromised artifacts can be removed.
Dependencies can be rebuilt.
Credentials can be revoked.
Production models can be disabled.

Common Beginner Mistakes

Mistake 1 — Trusting Popular Models Automatically

Popularity does not establish provenance or integrity.

Mistake 2 — Downloading Models Directly Into Production

External models should pass through a controlled intake process.

Mistake 3 — Protecting Code but Ignoring Models

Models are also production artifacts.

Mistake 4 — Ignoring Dataset Provenance

Training data can influence production model behavior.

Mistake 5 — Letting Developers Replace Production Models

Production publishing should be controlled.

Mistake 6 — Ignoring Python Dependencies

Traditional software supply-chain risks still apply.

Mistake 7 — Assuming Model Files Are Harmless Data

Model-loading processes may themselves have security implications.

Mistake 8 — Using Production Data for Uncontrolled Experiments

Development environments should use appropriate datasets and access controls.

Mistake 9 — No Model Rollback

Organizations should be able to restore a previously approved version.

Mistake 10 — No Component Inventory

You cannot effectively secure what you do not know you are using.

AI Security Engineer Perspective

When reviewing the AI supply chain, ask:

Where did the model come from?

Can we verify the artifact?

Who approved it?

Where is it stored?

Who can replace it?

Which dependencies does the application use?

Which container runs it?

Where did the training data come from?

Who can modify the dataset?

How was the model fine-tuned?

Who can deploy to production?

Can we identify every production version?

Can we detect unauthorized changes?

Can we roll back quickly?

This is the mindset of supply-chain security for AI.

Interview Perspective

You may be asked:

What is the AI supply chain?

A strong answer is:

The AI supply chain includes the models, datasets, libraries, frameworks, containers, repositories, APIs and development or MLOps pipelines required to build and operate an AI application. Each component creates a trust dependency that must be inventoried, validated and controlled.

Another question may be:

What is model provenance?

A strong answer is:

Model provenance is the ability to understand where a model came from, who published or modified it, which version is being used, whether it was fine-tuned, which data influenced it and how it reached production. Provenance helps establish trust and supports incident investigation.

Another question may be:

How would you securely adopt an open-source model?

A strong answer is:

I would obtain it from a trusted source, verify provenance and artifact integrity, review its format and dependencies, evaluate it in an isolated environment, assess relevant security and licensing concerns and promote the approved artifact into a controlled internal model registry before production deployment.

Another question may be:

How would you protect a model registry?

A strong answer is:

I would require strong authentication, restrict publishing and deletion rights, separate development and production repositories, maintain immutable or versioned artifacts where appropriate, log changes and use controlled model promotion rather than allowing arbitrary production replacement.

Another question may be:

Why is dataset provenance important?

A strong answer is:

Because training and fine-tuning data influence model behavior. If the source, ownership, version and modification history of a dataset are unknown, it becomes difficult to detect poisoning, reproduce model behavior or determine what influenced a compromised model.

Key Takeaways

The AI supply chain includes:

Models
+
Datasets
+
Embedding Models
+
Libraries
+
Frameworks
+
Containers
+
Repositories
+
External APIs
+
CI/CD
+
MLOps

A secure lifecycle should look like:

Trusted Source
      ↓
Provenance
      ↓
Integrity Verification
      ↓
Evaluation
      ↓
Security Review
      ↓
Approved Registry
      ↓
Controlled Deployment
      ↓
Monitoring

Important principles include:

Know where models come from.
Verify model integrity.
Use controlled model registries.
Restrict who can publish production models.
Track model versions.
Protect training and fine-tuning data.
Control software dependencies.
Secure container images and registries.
Protect CI/CD and MLOps pipelines.
Maintain component inventories.
Monitor vulnerabilities and changes.
Support rollback and recovery.

Most importantly:

A secure AI application cannot be built from components whose origin, integrity and ownership are unknown.

What’s Next?

➡️ 11 — Model and Data Poisoning

You now understand the AI supply chain and the importance of trusted models, datasets and dependencies.

The next lesson focuses more deeply on what happens when an attacker deliberately manipulates the information or artifacts used by AI systems.

You will learn:

Training data poisoning
Fine-tuning poisoning
RAG poisoning
Model poisoning
Backdoored models
Trigger-based behavior
Dataset integrity
Model integrity
Poisoning attack paths
Detection challenges
Data provenance
Model provenance
Security testing
Incident response
Enterprise poisoning defenses

You will move from:

Can We Trust Our AI Supply Chain?

to:

What Happens If an Attacker
Deliberately Manipulates
Models or Data?

➡️ Next: 11 — Model and Data Poisoning