Negli ultimi mesi il settore AI ha iniziato a confrontarsi con una nuova categoria di rischio operativo che non riguarda direttamente i modelli linguistici, ma l’intera infrastruttura software utilizzata per svilupparli, distribuirli e aggiornarli. Diversi incidenti che hanno coinvolto ecosistemi collegati a OpenAI, Anthropic e Meta hanno evidenziato come le superfici di attacco più critiche si stiano spostando verso supply chain software, CI/CD pipeline, dipendenze open source e sistemi automatizzati di packaging.
Uno dei casi più discussi è stato l’attacco alla supply chain di TanStack tramite pacchetti npm compromessi, dove un worm denominato “Mini Shai-Hulud” ha pubblicato decine di versioni malevole sfruttando una concatenazione di vulnerabilità che includevano misconfigurazioni GitHub Actions, cache poisoning e furto di token OIDC direttamente dalla memoria dei runner CI. L’aspetto più rilevante non è stato soltanto l’attacco in sé, ma il fatto che il malware abbia sfruttato pipeline ufficiali di rilascio considerate affidabili dagli sviluppatori e dai sistemi automatici di deployment.
Parallelamente, il caso Mercor-LiteLLM ha mostrato quanto il problema possa propagarsi rapidamente nell’ecosistema AI enterprise. Dopo una compromissione legata a componenti middleware utilizzati nelle pipeline AI, diverse aziende hanno avviato audit interni sui fornitori che gestiscono dati di training, annotazione e orchestrazione dei modelli. In particolare, Meta ha sospeso parte delle attività collegate a Mercor mentre OpenAI ha avviato verifiche interne sull’eventuale esposizione di dataset proprietari.
Dal punto di vista architetturale, il problema nasce dalla crescente stratificazione della filiera AI moderna. Un singolo prodotto enterprise può dipendere contemporaneamente da foundation model esterni, librerie open source, sistemi di orchestrazione agentica, provider cloud, pipeline di fine-tuning e piattaforme di monitoraggio distribuite su più vendor. Questo crea supply chain multilivello nelle quali una vulnerabilità introdotta in un componente secondario può propagarsi rapidamente verso ambienti produttivi considerati ad alta affidabilità.
La conseguenza è che i tradizionali processi di AI red teaming stanno mostrando limiti evidenti. Molte valutazioni di sicurezza si concentrano ancora su jailbreaking, prompt injection o allineamento dei modelli, mentre attacchi reali stanno colpendo build systems, release automation e dependency graph software. Secondo varie analisi di settore, queste pipeline rappresentano oggi una delle superfici meno monitorate negli ambienti AI enterprise.
In risposta a questo scenario stanno emergendo nuove pratiche di vendor due diligence specifiche per l’AI supply chain. Le aziende iniziano a richiedere SBOM aggiornati, tracciabilità dei modelli, audit sulle dipendenze transitive, verifica delle pipeline CI/CD e mappatura dei sub-processori AI utilizzati dai fornitori. Framework come AI Controls Matrix della Cloud Security Alliance e le recenti linee guida NSA sulle supply chain AI stanno contribuendo a formalizzare questi controlli all’interno dei processi enterprise di procurement e governance.
L’evoluzione più significativa è che la sicurezza AI sta rapidamente diventando un problema di infrastruttura distribuita più che di singolo modello. In molti ambienti enterprise il rischio operativo non deriva più soltanto dall’output generato dall’LLM, ma dalla fiducia implicita concessa a pipeline automatizzate che gestiscono codice, pesi dei modelli, dataset e release software lungo supply chain sempre più frammentate e dinamiche