La catena di fornitura del software resta il punto più fragile della sicurezza aziendale, e l'ultima campagna documentata da Amazon lo conferma in modo quasi didattico. Gli attaccanti non hanno forzato sistemi: hanno costruito relazioni. Contributi apparentemente utili ai progetti, disponibilità a farsi carico della manutenzione, mesi di presenza credibile nelle comunità di sviluppo, fino a ottenere i privilegi di pubblicazione sui pacchetti.
Le analisi ricondurrebbero le operazioni a gruppi collegati alla Corea del Nord, con una struttura di attacco che alterna pazienza e sfruttamento improvviso. In Italia una parte della campagna è stata intercettata prima che producesse effetti, il che indica che i presidi di monitoraggio funzionano quando esistono.
Il meccanismo colpisce perché non richiede vulnerabilità tecniche. Un pacchetto compromesso a monte entra legittimamente in migliaia di build, viene firmato, superata ogni verifica di integrità, e arriva in produzione con tutti i crismi. Il codice malevolo non deve bucare nulla: viene invitato dentro.
Le contromisure sono note ma applicate a macchia di leopardo. Software Bill of Materials aggiornata, pinning delle versioni, verifica delle dipendenze transitive, monitoraggio dei cambi di manutentore sui pacchetti critici, ambienti di build isolati. Nessuna di queste è nuova, tutte richiedono disciplina continuativa.
Con l'ingresso di componenti AI negli stack aziendali il problema si allarga. Modelli scaricati da repository pubblici, librerie di orchestrazione degli agenti, estensioni e connettori: ogni elemento è una dipendenza, e ognuna eredita la fiducia che riponiamo in chi la mantiene. Sapere esattamente cosa gira nella propria infrastruttura AI è oggi parte della sicurezza, non della documentazione.