Attacchi alla Supply Chain: 8 passi per ridurre l’esposizione

Negli ultimi mesi abbiamo assistito a una crescita esponenziale degli attacchi alla Software Supply Chain (la catena di montaggio del software).

Invece di colpire direttamente un’azienda, i criminali informatici puntano agli “ingredienti” che finiscono in ogni applicazione: librerie, dipendenze, strumenti di build e pipeline CI/CD. Se a monte entra un componente compromesso, il problema si trascina lungo tutta la linea e può arrivare fino al prodotto finale.

In questo articolo ripercorriamo quanto scritto dal nostro collega Matteo Bisi nel suo blog tecnico, cercando di ricostruire i passaggi essenziali del suo ragionamento.

Non è una novità: il pattern degli ultimi mesi 

Il pattern è quasi sempre lo stesso: i criminali si infiltrano in canali affidabili per distribuire codici malevoli.

Ecco alcuni esempi eclatanti successi in questi primi mesi del 2026:

• Bitwarden CLI: Il 22 aprile 2026 è stato compromesso il pacchetto ufficiale di Bitwarden CLI, uno strumento molto usato dagli sviluppatori. Per circa un’ora e mezza, chi lo ha installato ha scaricato senza saperlo una versione manomessa. Da notare sono le modalità con cui l’attacco è avvenuto: non è stato “bucato” direttamente Bitwarden in modo tradizionale, ma è stato sfruttato un passaggio della catena di pubblicazione e distribuzione del software (cioè il percorso con cui un aggiornamento viene preparato e poi reso disponibile). In pratica, gli attaccanti sono riusciti a far pubblicare un aggiornamento malevolo usando un meccanismo considerato affidabile e pensato per ridurre i rischi legati alle password. Proprio per questo l’episodio è significativo: mostra che anche i canali “di fiducia” possono diventare un punto di ingresso. Bitwarden ha individuato rapidamente il problema, ha rimosso la versione compromessa e ha rilasciato una versione corretta.

• Axios: questa libreria, usata da milioni di programmatori, è stata colpita per rubare le chiavi di accesso ai servizi Cloud (AWS e Google). Si tratta di una libreria JavaScript HTTP con oltre 100 milioni di download settimanali, è stata colpita nella stessa ondata di marzo 2026. Un account manutentore su npm è stato compromesso e una release malevola è stata pubblicata con un credential stealer postinstall che prendeva di mira segreti AWS e GCP, credenziali Kubernetes e qualsiasi token di servizio cloud presente nell’ambiente. Dati i numeri di download di Axios, anche una breve finestra di esposizione ha una portata enorme. 

   

• LiteLLM e Telnyx sono caduti nella stessa ondata, con gli attaccanti che passavano da un progetto compromesso al successivo usando le credenziali rubate lungo il percorso.

• Trivy, lo scanner di vulnerabilità dei container di Aqua Security ampiamente utilizzato, è stato compromesso nel marzo 2026. La pipeline di GitHub Actions è stata dirottata tramite tag di release contraffatti e sono state distribuite immagini Docker infettate. Poiché Trivy viene utilizzato all’interno di pipeline di build in migliaia di organizzazioni, l’attacco aveva un raggio d’azione potenzialmente molto ampio: uno scanner compromesso all’interno del CI/CD non è solo una minaccia per la build; è una minaccia per tutto ciò che la build tocca. Aqua e la community lo hanno rilevato. La campagna è attribuita allo stesso gruppo TeamPCP.

• Notepad++ , preso di mira dal gruppo Lotus Blossom (noto anche come Lotus Panda), tra la metà del 2025 e l’inizio del 2026. Gli attaccanti non hanno sfruttato un bug nell’editor stesso: hanno compromesso l’infrastruttura di hosting condivisa e dirottato il canale di aggiornamento. Un piccolo numero di obiettivi, principalmente organizzazioni governative, di telecomunicazioni e di infrastrutture critiche nel Sud-Est asiatico e in America Centrale, ha ricevuto installer trojanizzati contenenti beacon Cobalt Strike e backdoor personalizzate. Il pubblico generale non è stato colpito, ma la tecnica è stata precisa e persistente: gli attaccanti hanno mantenuto l’accesso per sei mesi utilizzando credenziali interne rubate.

Il pattern è chiaro: canali di aggiornamento fidati, release dall’aspetto legittimo, payload interpretati (JavaScript o Python) e furto di credenziali che prende di mira gli ambienti di sviluppo e le pipeline CI/CD. 

L’obiettivo è raramente distruggere qualcosa immediatamente, ma ottenere un accesso persistente ai segreti che aprono la porta successiva.

L’EDR non è sufficiente (ma resta un mattone importante)  

La maggior parte delle aziende si è dotata di piattaforme di endpoint detection and response (EDR) come CrowdStrike, SentinelOne, Microsoft Defender e strumenti simili. 

Sono tutti tool genuinamente efficaci nel perimetro del loro scopo, ma hanno un "punto cieco".

Una risposta sul perché le piattaforme EDR non rilevano i malware di questo tipo la fornisce Paul McCarty - ricercatore in ambito Supply Chain Security che ha preso parte al gruppo di esperti che hanno scoperto la compromissione di Trivvy - in un’intervista su Laterstack .

L'intervista, che varrebbe la pena leggere per intero per completezza di informazioni, può essere riassunta come segue. 

Gli EDR sono progettati per operare su due binari: riconoscere file eseguibili dannosi (i classici .exe) e rilevare pattern di comportamento anomali come la cifratura massiva di file. Tuttavia, entrambe queste due metodologie risultano essere irrilevanti nel contesto di queste tipologie di attacco alla supply chain perché vengono messi in atto utilizzando semplici script di installazione (in JavaScript o Python). Inoltre, il comportamento di un “infostealer” non assomiglia a quello di un ransomware: legge alcuni file dalle directory delle credenziali o dei browser, li serializza e li invia via POST su HTTPS. Si tratta di un comportamento normale, questi script leggono file e inviano dati, proprio come farebbe un'app legittima. 

L'EDR interviene spesso troppo tardi, quando il danno è già fatto.

Se si esegue npm install o pip install in un ambiente di sviluppo o in una pipeline di CI/CD, l’ EDR non sta proteggendo in modo significativo quell’operazione. Il presupposto che sia protetta è ciò che porta le organizzazioni a finire sui giornali come il nuovo caso di furto di dati o di incidente informatico.

Ma, come abbiamo detto, le piattaforme EDR rappresentano ancora un mattone fondamentale e la compromissione di Axios mostra esattamente dove l’EDR gioca ancora un ruolo importante.
In questo caso, infatti, l’attacco non si è fermato a un pacchetto JavaScript ma ha portato a un RAT binario multipiattaforma, distribuito tramite un eseguibile PowerShell rinominato su Windows. Questo passaggio rientra esattamente nelle tipologie di comportamento che l’EDR riesce a rilevare e bloccare. Per questo, il motore Lunar di SentinelOne ha rilevato la tecnica e il loro team ha condotto un hunting proattivo, intervenendo tempestivamente.

In breve, l’EDR non fornisce una protezione significativa nella fase dei pacchetti interpretati, ma può intercettare la fase del payload binario che segue, se la catena di attacco ne include uno e se l’EDR è configurato per agire autonomamente alla velocità della macchina piuttosto che aspettare un analista umano.

Regole di base per ridurre l’esposizione

Non esiste una configurazione che renda immuni. L’attacco a Bitwarden ha abusato di un meccanismo di pubblicazione legittimo. L’attacco ad Axios ha usato un account manutentore compromesso. L’attacco a Trivy ha falsificato un tag di release. Ognuno di questi vettori sembra legittimo nel momento in cui si attiva.

Quello a cui si deve puntare e su cui mantenere alta la soglia di attenzione è ridurre il raggio d’azione, accelerare il rilevamento e far in modo che gli attaccanti siano disincentivati dalla complessità che incontrano. 

Di seguito vediamo 8 buoni consigli da mettere in pratica.

Una nuova visione della fiducia

Tornando all’intervista di McCarty, c’è ancora un passaggio di cui vale la pena ricostruire il filo. Git non è stato creato tenendo in mente la sicurezza come aspetto essenziale, ma l’affidabilità della sorgente; proprio questo ha favorito il successo dell’attacco a Bitwarden. Gli attaccanti hanno fatto leva su quell’affidabilità, sovvertendo il suo meccanismo di Trusted Publishing.

In passato ci si fidava ciecamente delle piattaforme come GitHub. Oggi stiamo capendo che anche queste "ancore" possono essere manipolate. Progetti emergenti come gittuf, attualmente in beta nell’ambito dell’OpenSSF Supply Chain Integrity Working Group, cercano di spostare la sicurezza direttamente all'interno del codice, rendendolo verificabile a prescindere da dove viene ospitato.

Il consiglio finale? L’obiettivo non deve essere il rischio zero, ma aumentare il "prezzo" dell'attacco. Se colpire te diventa troppo costoso e complicato, i criminali passeranno al prossimo obiettivo.

La supply chain del software è stata una superficie di attacco primaria per anni. Gli incidenti degli ultimi mesi rendono semplicemente impossibile continuare a ignorare il pattern e impongono di iniziare a costruire le proprie difese agendo di conseguenza.

Nello sviluppo di una strategia DevSecOps robusta, che acceleri le attività e garantisca al contempo la sicurezza delle organizzazioni, è importante affidarsi a realtà con un team DevSecOps altamente specializzato, certificato e di grande esperienza, in grado di accompagnare questo percorso.

Scopri di più sulla Software Supply Chain Security con il nostro ebook!