Your ML Pipeline Has a Supply Chain Problem. The NSA Just Confirmed It.

You Pip Install Models From Strangers

On March 4, 2026, the NSA and CISA published joint guidance called "AI/ML Supply Chain Risks and Mitigations". The document names six components of your AI supply chain that can be compromised: training data, models, software, infrastructure, hardware, and third-party services.

If you're running ML in production, you already know at least three of those are basically a trust exercise. You pip install a model from Hugging Face. You pull a base image from Docker Hub. You fine-tune on a dataset someone scraped from the internet. Nobody audits any of it.

Protect AI has been scanning Hugging Face since 2024. As of April 2025, they had scanned 4.47 million model versions and found 352,000 unsafe or suspicious issues across 51,700 models. That's not a rounding error. That's roughly 3.7% of all scanned repositories flagging security concerns.

And it gets worse. In January 2026, researchers at The Register reported that Python libraries in AI/ML models can be poisoned via metadata, exploiting how frameworks like Nvidia NeMo use hydra.utils.instantiate() to load configs. An attacker can achieve remote code execution using built-in Python functions like eval() and os.system(). Over 700 models on Hugging Face use the affected NeMo format.

The Attack Surface You're Not Monitoring

Here's what a typical ML pipeline looks like from a supply chain perspective:

# Your ML pipeline's hidden trust assumptions
pipeline:
  data:
    source: "s3://shared-datasets/training-v3"   # Who put this here?
    preprocessing: "pandas==2.1.0"                 # Audited? No.
 
  model:
    base: "huggingface/bert-base-uncased"          # Integrity check? Maybe.
    fine_tune: "custom-lora-adapter"                # From your Jupyter? Cool.
 
  serving:
    framework: "torch==2.2.0"                      # CVEs checked? Probably not.
    container: "python:3.11-slim"                   # 47 known vulnerabilities.
 
  dependencies:
    - transformers==4.38.0
    - accelerate==0.27.0
    - datasets==2.18.0                             # Any of these typosquatted?

Every line is an implicit trust decision. The NSA guidance is saying: stop trusting implicitly.

The PyTorch dependency confusion attack from 2022 is the textbook example. An attacker published a malicious package called torchtriton on PyPI with the same name as an internal PyTorch dependency. Because pip resolves public packages first, nightly PyTorch builds included the malicious package for five days before anyone noticed. Five days of pip install torch-nightly pulling malware.

More recently, researchers found over 100 malicious packages targeting popular ML libraries on PyPI using typosquatting. Names like "Matplotltib" and "PyToich" designed to catch a single typo in your requirements.txt.

What the NSA Wants You to Do (And What Actually Works)

The NSA guidance recommends AI Bills of Materials (AI-BOMs), vendor security assessments, incident response plans, and provenance tracking for all AI components. That's the enterprise version.

Here's the practical version for teams running ML in production:

1. Pin and verify everything

# Don't do this
pip install transformers
 
# Do this instead
pip install transformers==4.38.0 \
  --require-hashes \
  --hash=sha256:abc123...
 
# Or use pip-compile with hashes
pip-compile --generate-hashes requirements.in

Hash pinning isn't new, but almost nobody in ML does it. Your web app team probably pins. Your ML team probably doesn't. Fix that.

2. Scan models before loading them

# Before you torch.load() anything from the internet
# Use Protect AI's model scanner or similar
from modelscan import ModelScan
 
scanner = ModelScan()
results = scanner.scan("./downloaded_model.pt")
 
if results.issues:
    print(f"Found {len(results.issues)} security issues")
    for issue in results.issues:
        print(f"  - {issue.severity}: {issue.description}")
    sys.exit(1)

Protect AI's Guardian scanner is integrated directly into Hugging Face now. Use it. If you're pulling models from anywhere else, scan them locally first. torch.load() uses pickle under the hood, and pickle deserializes arbitrary Python objects. It is, by design, a code execution vulnerability.

3. Build an AI-BOM

The NSA recommends AI Bills of Materials. CycloneDX has an ML-BOM spec that covers model provenance, training data, and dependencies. According to Cycode's 2026 State of Product Security report, only 19% of organizations have full visibility into where and how AI is used across development.

Start simple:

# ai-bom.yaml - minimum viable AI-BOM
model:
  name: "fraud-detection-v3"
  base_model: "bert-base-uncased"
  base_model_hash: "sha256:a8b3c..."
  source: "huggingface.co"
  fine_tuned_on: "internal-transactions-2024"
  framework: "pytorch==2.2.0"
 
training_data:
  sources:
    - name: "internal-transactions"
      records: 2400000
      pii_scan: "passed"
      last_audit: "2026-01-15"
 
dependencies:
  pinned: true
  hash_verified: true
  last_vulnerability_scan: "2026-03-15"
  known_cves: 0

4. Isolate model inference from your network

If a poisoned model runs arbitrary code during loading, it can exfiltrate data, establish a reverse shell, or modify other models. Run inference in isolated containers with no egress network access. This is basic container security, but most ML serving setups have full network access because "the model needs to call an API."

No, it doesn't. The model does math. If your serving container needs outbound internet access, something is wrong.

How This Connects to the EU AI Act

If you're an EU company, this isn't just about security hygiene. The EU AI Act Article 15 requires "appropriate levels of cybersecurity" for high-risk AI systems. Article 9 mandates risk management that covers "risks to health, safety or fundamental rights." A poisoned model in a healthcare or financial system is exactly that kind of risk.

The NSA guidance explicitly recommends documentation practices that map directly to EU AI Act conformity assessment requirements. Your AI-BOM is half your technical documentation done.

The Uncomfortable Truth

Most MLOps teams treat security as someone else's problem. The security team handles the infrastructure. The ML team handles the models. Nobody handles the space in between, where a typosquatted pip package meets an unpinned requirement meets an unscanned model checkpoint.

The NSA publishing this guidance isn't a surprise. It's a confirmation that nation-state actors are already targeting ML supply chains. The $12 billion in estimated losses from compromised ML models in 2025 should have been the wake-up call. This guidance is the snooze alarm.

If you're running ML in production and haven't audited your supply chain, the checklist is short: pin your dependencies, scan your models, document your AI-BOM, and isolate your inference. You can do all four in a week. The alternative is finding out from an incident report.

We've been building these supply chain audits into our ML platform work at DeviDevs. If this is the kind of thing keeping you up at night, we've been there.

About DeviDevs: We build ML platforms, secure AI systems, and help companies comply with the EU AI Act. devidevs.com