Red team vs blue team
Gli attaccanti raramente prendono di mira la Sua azienda. Prendono di mira il pacchetto, la Action o lo strumento di build da cui dipendono aziende in tutto il mondo, poi provano l'exploit su tutte contemporaneamente. Loro non hanno bisogno del Suo elenco di dipendenze. Lei sì.
Un attacco alla software supply chain compromette qualcosa con cui viene costruito un prodotto, come un pacchetto open source, un componente CI/CD o il sistema di build, invece di attaccare direttamente il prodotto. Il software moderno è in gran parte codice altrui: la maggior parte proviene da pacchetti open source, e la maggior parte di questi sono dipendenze transitive che nessuno nel team ha scelto. Compromettendo un solo componente molto diffuso si raggiunge ogni organizzazione che lo usa per costruire il proprio software.
Questo cambia il modo in cui gli attaccanti scelgono i bersagli. Non studiano le dipendenze di una singola azienda. Scelgono un pacchetto o uno strumento molto diffuso, poi lo sfruttano ovunque e vedono che cosa risponde.
Viene divulgato un difetto in un popolare pacchetto open source, e gli attaccanti lo sfruttano in ogni prodotto che distribuisce la versione vulnerabile, di solito come dipendenza transitiva che nessuno ha scelto direttamente.
Un attaccante prende il controllo dell'account di un maintainer, oppure un worm ruba i token di pubblicazione, e rilascia una versione avvelenata di un pacchetto fidato. Viene eseguita nel momento in cui una build la installa, come con il worm npm Shai-Hulud.
Un collaboratore si guadagna la fiducia di un progetto open source nel tempo, poi inserisce codice malevolo in una release che le distribuzioni e i prodotti a valle recepiscono, come con la backdoor di xz utils.
Pacchetti con nomi simili a quelli più diffusi sfruttano gli errori di battitura. La dependency confusion va oltre: un pacchetto pubblico con lo stesso nome di uno interno a un'azienda viene installato al suo posto.
Una GitHub Action o un altro strumento di build viene dirottato, e ogni pipeline che lo usa esegue il codice dell'attaccante con i propri secret a portata di mano, come con tj-actions e Codecov.
Viene alterata la build stessa, oppure l'artefatto viene sostituito tra la build e il deployment, così un albero dei sorgenti pulito produce comunque una release compromessa, come con SolarWinds.
SolarWinds è l'attacco alla supply chain più noto: codice malevolo inserito nella build e distribuito ai clienti come un normale aggiornamento. Gli attacchi più recenti puntano invece ai registry dei pacchetti e alle pipeline CI, dove un solo pacchetto o una sola Action compromessi raggiungono ogni build che li usa. Dai più recenti:
Un worm autoreplicante che si attiva quando viene installato un pacchetto npm infetto, ruba token npm, GitHub e cloud e pubblica versioni infette degli altri pacchetti della vittima. La maggior parte delle infezioni è avvenuta in CI.
Come controllare le Sue build →CISA ha riferito che ogni versione di questa popolare GitHub Action è stata compromessa per tre giorni, con secret esposti nei log dei workflow. I workflow che la referenziavano tramite tag hanno eseguito il codice dell'attaccante.
Andres Freund ha trovato una backdoor nelle versioni 5.6.0 e 5.6.1 di xz dopo aver notato che gli accessi SSH consumavano troppa CPU. Era stata introdotta nel progetto upstream stesso.
Un difetto in Apache Log4j 2 consentiva a un attaccante che controllava un messaggio registrato nei log di eseguire codice arbitrario, con valutazione CVSS 10.0. Per la maggior parte dei team la parte difficile è stata scoprire quali applicazioni contenessero log4j-core, di solito come dipendenza di una dipendenza.
Gli attaccanti hanno alterato lo script Bash Uploader che i team eseguivano nelle loro pipeline CI, in modo che inviasse l'ambiente CI, comprese credenziali, token e chiavi, a un server esterno all'infrastruttura di Codecov. È rimasto inosservato dal 31 gennaio fino alla segnalazione di un cliente il 1° aprile.
Gli attaccanti avevano da tempo un accesso occulto al processo di build di SolarWinds Orion e hanno inserito codice malevolo nelle release di Orion dalla 2019.4 alla 2020.2.1 HF1, che i clienti hanno installato come normali aggiornamenti. In risposta, CISA ha emesso una direttiva di emergenza.
Red team vs blue team
Ogni fase con le parole dell'attaccante, e la difesa che risponde.
Fase 1 di 3
Non serve conoscere il bersaglio. Scelga il pacchetto, e i bersagli si scelgono da soli.
Red team
Non Le serve il loro lockfile. I pacchetti più diffusi stanno in profondità nell'albero transitivo di quasi tutto, e la maggior parte dei team non sa dire quali distribuisce. Gli indizi pubblici restringono il campo: versioni nei bundle JavaScript e negli header HTTP, repository pubblici e immagini container. E tutto ciò che la loro build scarica fuori dal lockfile, come il binario scaricato da uno script postinstall o i layer sotto la loro immagine base, il loro scanner non l'ha mai visto, quindi nessuno lo sta correggendo.
Blue team
CRACI vede il traffico in ingresso in ogni build e registra ogni pacchetto e file che introduce, comprese le dipendenze nascoste che gli strumenti basati sul lockfile non vedono, a ogni profondità dell'albero transitivo. La Sua SBOM proviene dalla build distribuita, quindi Lei ha l'elenco di cui un attaccante non ha mai avuto bisogno, prima che qualcuno si metta a cercarlo.
SBOM in fase di build →Red team
Un nuovo advisory Le dice esattamente quali versioni sono vulnerabili. Costruisca l'exploit, scansioni tutto ciò che risponde e lasci che sia la scansione a dirLe chi sono. Lei inizia il giorno stesso, mentre il loro team si sta ancora chiedendo "siamo colpiti?" in un thread Slack.
Blue team
CRACI rivaluta di continuo le SBOM monitorate rispetto ai nuovi dati sulle vulnerabilità. La cronologia delle build mostra quali build contenevano la dipendenza vulnerabile, diretta o transitiva, così Lei sa dove è stata distribuita e per quanto tempo.
Siamo colpiti? →Fase 2 di 3
Sfrutti il difetto prima che venga corretto, oppure lasci perdere il difetto e salga sulla loro pipeline.
Red team
L'IA trasforma un advisory e il diff di una patch in un attacco funzionante prima che il loro team di sicurezza abbia fatto il triage del ticket. La divulgazione è il Suo segnale di partenza. La loro pianificazione dello sprint è la settimana prossima.
Blue team
I policy gate possono bloccare qualsiasi build che contenga una specifica CVE, così la versione vulnerabile smette di essere distribuita nel momento in cui Lei lo decide, a qualunque profondità dell'albero si trovi.
Remediation delle CVE →Red team
I workflow si fidano di tag come @v4, e i tag si possono spostare. Comprometta una popolare GitHub Action e ogni workflow che la usa eseguirà il Suo codice, con i propri secret a portata di mano.
Blue team
CRACI registra le GitHub Actions eseguite da un workflow nella SBOM della build, fissate al commit effettivamente eseguito. Quando una Action viene compromessa, Lei può vedere quali build hanno eseguito il codice malevolo invece di dedurlo da un tag.
Checklist di sicurezza CI/CD →Fase 3 di 3
Prenda i secret e resti per averne altri.
Red team
Una release malevola di un pacchetto esegue il suo script di installazione dentro la loro build, dove risiedono i token e le credenziali cloud. I runner CI di solito possono raggiungere tutta Internet, quindi i secret partono verso il Suo server prima che qualcuno sappia che il pacchetto è malevolo.
Blue team
Una policy di egress deny predefinita consente a una build di raggiungere le sue sorgenti di pacchetti e le destinazioni di pubblicazione, e blocca tutto il resto. Il malware che invia i Suoi secret all'host di un attaccante viene bloccato, anche come paziente zero di un attacco mai visto prima, e Lei riceve un avviso sulla violazione della policy.
Policy di egress →Red team
I runner self-hosted di lunga durata sono un regalo: piazzi qualcosa nel workspace o nella tool cache e aspetti che il job successivo, e la serie successiva di secret, venga da Lei.
Blue team
Ogni job CRACI viene eseguito nella propria macchina virtuale isolata, quindi nulla di ciò che un job lascia dietro di sé attende quello successivo. E non c'è nemmeno una flotta di runner da aggiornare e rafforzare.
Runner gestiti e self-hosted →Dopo la divulgazione
L'attaccante non ha bisogno di sapere che Lei usa quella dipendenza. Prova l'exploit ovunque e vede che cosa risponde. Il Suo team deve sapere dove quella dipendenza è stata distribuita. La differenza sta nel dover andare a cercare o meno, e ogni anno ci sono più corse da affrontare: veda quante CVE vengono pubblicate ogni giorno.
Red team
Blue team, senza un registro della build
Blue team, con CRACI
Nessun singolo controllo ferma ogni attacco alla supply chain. Combini i controlli seguenti, e ogni fase descritta sopra diventa più difficile. Per il lato della pipeline nel dettaglio, veda la checklist di sicurezza della pipeline CI/CD.
Gli attaccanti sorvegliano ogni advisory e provano l'exploit su tutti il giorno stesso in cui una vulnerabilità viene divulgata. Non hanno mai avuto bisogno del Suo elenco di dipendenze. Lei sì. CRACI dà al Suo team quell'elenco, ricavato dalla build stessa, e chiude le porte su cui gli attaccanti contano: egress aperto e runner condivisi.
Un attacco al codice, agli strumenti o ai servizi con cui viene costruito un prodotto, come un pacchetto open source, un componente CI/CD o il sistema di build, invece che al prodotto stesso. Una sola compromissione raggiunge ogni organizzazione che usa il componente interessato.
Il worm Shai-Hulud (dal 2025) si è diffuso attraverso pacchetti npm infetti e ha rubato secret CI. La compromissione di tj-actions/changed-files (CVE-2025-30066) ha dirottato una popolare GitHub Action. La backdoor di xz utils (CVE-2024-3094) è stata inserita in una libreria di compressione upstream. Log4Shell (CVE-2021-44228) ha sfruttato un difetto in una libreria di logging Java molto diffusa. Il Bash Uploader di Codecov (2021) è stato alterato per inviare credenziali CI a un server esterno, e SolarWinds Orion (2020) ha distribuito codice malevolo inserito nella build.
SolarWinds. Nel 2020, attaccanti con un accesso occulto al processo di build di SolarWinds Orion hanno inserito codice malevolo nelle sue release, e i clienti lo hanno installato come un normale aggiornamento. Ha dimostrato che un albero dei sorgenti pulito non basta: la build stessa deve essere affidabile e verificabile.
Di solito no, e non ne hanno bisogno. La maggior parte degli attacchi prende di mira un pacchetto, non un'azienda: una volta uscito un advisory, gli attaccanti provano l'exploit contro tutto ciò che potrebbe eseguire una versione vulnerabile e vedono che cosa risponde. Gli indizi pubblici, come le versioni nei bundle JavaScript o nei repository open source, li aiutano a mirare. L'asimmetria è che a Lei l'elenco serve: per sapere se è colpito, deve sapere che cosa ha distribuito ogni build, compreso ciò che ha scaricato fuori dal lockfile.
Nessun singolo controllo li ferma tutti. Conservi una SBOM di ciò che ogni build distribuisce e la monitori rispetto ai nuovi advisory, fissi dipendenze e GitHub Actions, blocchi le versioni vulnerabili in fase di build, limiti le connessioni dei job CI, isoli i job e ne limiti i secret, e verifichi che gli artefatti distribuiti siano quelli che ha compilato.
Esegua il commit di un lockfile e installi da esso in CI, e disattivi gli script di installazione dove una build non ne ha bisogno (--ignore-scripts di npm). Conservi un registro delle versioni di pacchetti effettivamente installate da ogni build, così può verificare rapidamente quando viene annunciata una nuova ondata come Shai-Hulud. Limiti le connessioni dei job CI, così uno script di installazione malevolo non può inviare i Suoi token all'esterno, e ruoti ogni token che una versione infetta potrebbe aver raggiunto.
Nelle esercitazioni di sicurezza il red team interpreta l'attaccante e il blue team difende. Questa pagina usa la stessa divisione: ogni fase di un attacco alla supply chain raccontata con le parole dell'attaccante, seguita dalla risposta della difesa.
Quelli noti, sì. Una release malevola con una CVE pubblicata, come la backdoor di xz, viene segnalata come qualsiasi altra vulnerabilità, e un policy gate può bloccare le build che la contengono. CRACI non analizza il comportamento dei pacchetti né ne valuta la reputazione, quindi un pacchetto malevolo del tutto nuovo non viene segnalato finché non esiste un advisory. A questo serve la policy di egress: con il deny predefinito, la build può raggiungere solo gli host di cui ha bisogno, quindi il pacchetto non può inviare i Suoi secret all'esterno, nemmeno in un attacco mai visto prima.