Un file da 195 terabyte analizzato da Hudson Rock e una serie di credenziali trovate da CloudSEK raccontano un attacco alla catena di fornitura che, per quaranta minuti a marzo, ha trasformato versioni compromesse di LiteLLM nel cavallo di Troia di oltre 2.500 organizzazioni. Microsoft, Amazon, Cisco, Samsung e Salesforce sono solo alcune delle realtà i cui segreti di accesso sono finiti in mani non autorizzate.

Secondo le società di sicurezza, i pacchetti malevoli erano scaricabili dalla posizione ufficiale del Python Package Index (PyPI). In quella finestra, gli aggressori hanno estratto chiavi cloud, token di repository, chiavi SSH, segreti Kubernetes, credenziali per la pubblicazione di pacchetti, variabili d'ambiente e chiavi di provider LLM: materiale che, combinato, può consentire accessi a infrastrutture di sviluppo e produzione.

La densità di privilegi della toolchain AI

Questa non è una semplice fuga di credenziali. È il segnale che la filiera degli strumenti per l'AI ha una densità di privilegi molto più alta rispetto a quella del software tradizionale. LiteLLM, come strumento open source che semplifica lo sviluppo basato su modelli AI, si trova nel punto in cui applicazioni, provider LLM e infrastrutture si scambiano credenziali. Compromettere quel punto per pochi minuti significa intercettare non una singola applicazione, ma l'intero strato di orchestrazione che le tiene insieme. Chi valutava deployment on-premise per tenere i dati sotto controllo scopre che il rischio non si ferma al data center: anche un ambiente self-hosted, se costruisce le proprie pipeline recuperando dipendenze da registri pubblici, può vedere esposti segreti Kubernetes locali e chiavi SSH interne.

C'è poi un effetto di secondo ordine sulle responsabilità. I manutentori open source di LiteLLM subiscono la pressione di un incidente nato non da un bug nel codice, ma da un attacco alla distribuzione. I registri come PyPI devono dimostrare di poter rilevare pacchetti compromessi in tempo reale. Le aziende che fino a ieri trattavano le dipendenze come componenti a fiducia implicita ora devono introdurre verifiche di integrità, pinning delle versioni e proxy interni. In pratica, la supply chain dell'AI sta ereditando i problemi di npm e pip, ma con posta in gioco più alta: le credenziali di accesso ai provider LLM e ai cluster GPU rappresentano chiavi di accesso a capacità di calcolo costose e a dati potenzialmente sensibili. Per chi valuta deployment on-premise, questa variabile va integrata accanto a TCO e hardware: AI-RADAR analizza i trade-off su /llm-onpremise.

Il fatto che né CloudSEK né Hudson Rock abbiano identificato la fonte dell'esfiltrazione lascia una domanda aperta su chi abbia potuto sfruttare questa finestra. Ma il punto strutturale è un altro: la distribuzione di pacchetti attraverso PyPI, per quanto ufficiale, non offre garanzie sufficienti quando un singolo pacchetto compromesso può aggregare decine di tipi diversi di segreti. Per chi opera in contesti regolamentati o con requisiti di sovranità del dato, il controllo della catena di fornitura software diventa estensione diretta del controllo dei dati. La prossima volta che una pipeline scarica una dipendenza, la domanda non è se il codice funziona, ma chi altro ha avuto accesso a quei 40 minuti.