I vostri prodotti sono sicuri? Come rispondere ai clienti dopo un attacco alla supply chain

Invii una prima dichiarazione entro poche ore, una risposta confermata non appena è in grado di dimostrarla, e un aggiornamento ogni volta che qualcosa cambia. Dica che cosa sa, che cosa sta ancora verificando e quando aggiornerà. Basi ogni "non coinvolti" su ciò che le Sue build hanno effettivamente installato durante la finestra dell'attacco, non sul lockfile di oggi.

Questo articolo tratta che cosa dire, quando e sulla base di che cosa. Per l'indagine vera e propria, cioè come scoprire se un componente vulnerabile è nei Suoi prodotti e da quando, veda siamo coinvolti da una CVE?.

Perché i clienti chiedono a Lei, non al registro dei pacchetti

Nella settimana successiva a un attacco di cui si è parlato molto, ci ha raccontato un piccolo fornitore di software, i clienti gli mandavano SMS: la vostra roba è sicura? La mia roba è sicura? I suoi clienti trattano dati sensibili, il suo team non ha uno specialista di sicurezza, e la domanda richiedeva una risposta in giornata.

I clienti non chiedono se un pacchetto sia stato compromesso. Il registro e i ricercatori lo hanno già detto. Chiedono se ciò che Lei ha fornito loro lo contiene, perché il Suo prodotto è la loro esposizione. Hanno a loro volta clienti, auditor o autorità di regolamentazione che pongono loro la stessa domanda. Nelle supply chain regolamentate, come semiconduttori, macchinari industriali e sanità, la domanda è contrattuale, non curiosità.

Chiederanno di nuovo anche se la Sua risposta non è verificabile. "Non siamo coinvolti" senza nulla dietro è una promessa; "abbiamo verificato ogni build di release dal 24 al 31 marzo e nessuna ha installato le versioni interessate" è una dichiarazione su cui possono contare.

Quattro attacchi recenti e la domanda sollevata da ciascuno

La risposta giusta dipende da come ha funzionato l'attacco, quindi un modello da solo non basta. Per ciascuno di questi, un solo fatto decide che cosa significhi "coinvolto" per un fornitore.

Backdoor in xz Utils (CVE-2024-3094), resa nota il 29 marzo 2024. Andres Freund ha trovato una backdoor nelle versioni 5.6.0 e 5.6.1 di xz. I tarball di release contenevano codice che non era nel repository Git, e questo iniettava la backdoor durante la build. La NVD e Red Hat le assegnano entrambe 10.0 in CVSS 3.1. Ha raggiunto soprattutto distribuzioni rolling e di test: Debian testing, unstable ed experimental, Fedora Rawhide e 41, openSUSE Tumbleweed e Kali, mentre le release stabili non erano interessate. La domanda sollevata: un'immagine o un dispositivo che abbiamo distribuito include xz 5.6.0 o 5.6.1, e quale immagine base ha usato ogni build?

Worm npm Shai-Hulud, a ondate da settembre 2025. I pacchetti infetti eseguono al momento dell'installazione uno script che ruba credenziali npm, GitHub e cloud e le usa per pubblicare versioni infette di altri pacchetti. La domanda sollevata: un job CI ha installato una versione infetta, e i nostri token di pubblicazione sono stati esposti, il che ci renderebbe un vettore di diffusione? La nostra scheda su Shai-Hulud elenca ogni ondata e come verificare.

LiteLLM su PyPI, 24 marzo 2026. Le versioni 1.82.7 e 1.82.8 sono state caricate direttamente su PyPI con codice che ruba credenziali e che non è mai stato nel repository GitHub del progetto. Nella 1.82.8 un file .pth eseguiva il payload all'avvio di qualsiasi interprete Python, non solo quando veniva importato LiteLLM; raccoglieva variabili d'ambiente, chiavi SSH, credenziali cloud e secret di Kubernetes. HiddenLayer collega l'attacco a TeamPCP, che quel mese ha colpito anche strumenti di Trivy e Checkmarx. Lo stesso advisory di LiteLLM dà due spiegazioni dell'accesso iniziale: fa risalire la compromissione alla dipendenza da Trivy nel suo workflow CI di scansione di sicurezza e afferma che l'account PyPI di un maintainer potrebbe essere stato compromesso. Persino la finestra di esposizione varia all'interno dello stesso advisory: circa 40 minuti in un punto, dalle 10:39 alle 16:00 UTC in un altro. La domanda sollevata: una build o un container distribuito includeva quelle versioni, e quali secret erano presenti in quell'ambiente?

axios su npm, 31 marzo 2026. Un attaccante ha preso il controllo dell'account npm di un maintainer e ha pubblicato axios 1.14.1 e 0.30.4, che aggiungevano una dipendenza, [email protected], il cui script di installazione scaricava un trojan di accesso remoto per macOS, Windows e Linux. Datadog colloca la finestra dalle 00:21 alle 03:25 UTC; secondo Snyk le versioni sono state rimosse alle 03:29 UTC. La domanda sollevata: una build ha risolto quelle versioni in quella finestra? Un lockfile committato prima della finestra risponde "no" per le build che lo hanno usato, e non dice nulla sulle build che hanno eseguito npm install senza di esso.

Attacco	Ecosistema	Versioni interessate	Finestra	Che cosa significa "coinvolto" per un fornitore
xz Utils	Distribuzioni Linux	5.6.0, 5.6.1	Settimane, fino alla divulgazione del 29 marzo 2024	L'ha distribuito, in un'immagine o in un dispositivo basato su una distribuzione interessata
Shai-Hulud	npm	Centinaia di pacchetti, per ondata	Da ore a giorni per ondata	Ci ha compilato, e i Suoi token potrebbero averlo diffuso; potrebbe anche averlo distribuito
LiteLLM	PyPI	1.82.7, 1.82.8	24 marzo 2026, dalle 10:39 UTC (le fonti divergono sulla fine)	Ci ha compilato o l'ha distribuito, e i secret in quell'ambiente potrebbero essere stati rubati
axios	npm	1.14.1, 0.30.4	31 marzo 2026, circa dalle 00:21 alle 03:25 UTC	Ci ha compilato durante la finestra; il trojan è stato eseguito sulla macchina di build

Le stesse domande si pongono per una vulnerabilità critica che non è un attacco alla supply chain. Quando PHP2Shell è stata sfruttata nell'ottobre 2026, i clienti di ogni prodotto che include PHP hanno chiesto quali delle loro versioni contenessero un PHP interessato. I passaggi che seguono si applicano invariati.

La risposta ha tre fasi

Fase	Quando	Che cosa invia
Prima dichiarazione	Entro poche ore dalla notizia	Che cosa sa, che cosa sta verificando, quando aggiornerà
Risposta confermata	Non appena è in grado di dimostrarla, di solito il primo giorno	"Non coinvolti" per versioni specifiche, o "coinvolti" con che cosa fare
Aggiornamento	Quando esce la correzione, quando emerge qualcosa di nuovo, quando chiude il caso	La stessa comunicazione, rivista

La prima ora: la prima dichiarazione

Una prima dichiarazione (holding statement) è la prima comunicazione pubblica che fa prima di avere tutti i fatti. Dica qualcosa di vero, in fretta. Il silenzio viene riempito da supposizioni, e un cliente che non sente nulla da Lei presume che non se ne sia accorto.

• Chi e dove. Un solo mittente con nome e cognome, sul canale usato dal cliente, più la Sua pagina sulla sicurezza. Un testo condiviso è meglio di risposte improvvisate: resta coerente, e l'ufficio legale lo rivede una volta sola.
• Che cosa contiene. Che è al corrente dell'attacco, che sta verificando i Suoi prodotti e i sistemi di build, che cosa sa finora, quando arriverà il prossimo aggiornamento e chi contattare.
• Che cosa non deve contenere. "Non siamo coinvolti" prima di aver verificato, ipotesi sull'attaccante o attribuzioni di colpa.

Modello 1: prima dichiarazione

Oggetto: [nome dell'attacco]: la nostra prima dichiarazione

Siamo a conoscenza della compromissione segnalata di [pacchetto o progetto], versioni [versioni interessate], pubblicate il [data]. Il nostro team di sicurezza sta verificando ogni release di [prodotto] e i nostri sistemi di build alla ricerca delle versioni interessate. Finora [non abbiamo trovato versioni interessate nei prodotti verificati / non abbiamo ancora completato la verifica]. Le invieremo un aggiornamento entro [data e ora, fuso orario]. Per qualsiasi domanda nel frattempo, può contattare [nome, indirizzo del contatto per la sicurezza]. Non faremo ipotesi sull'impatto prima che la verifica sia completata.

Per un SMS o una chat bastano due frasi:

Siamo al corrente della compromissione [nome dell'attacco] e stiamo verificando ora ogni release di [prodotto] e le nostre build. Riceverà da noi una risposta confermata entro [ora].

Faccia approvare tutti e tre i modelli dal legale prima che Le servano.

Il primo giorno: confermare, con le prove

Gli esiti possibili sono due, e ciascuno richiede le proprie prove. Per una risposta "non coinvolti", raccolga:

• il pacchetto e le versioni interessati, dall'advisory o dall'analisi dei ricercatori
• i Suoi prodotti e le versioni che i clienti utilizzano effettivamente
• per ciascuna di quelle versioni, la build che l'ha prodotta e il registro di ciò che quella build ha installato, non il lockfile attuale
• ogni build eseguita durante la finestra dell'attacco, compresi i job CI che non hanno mai prodotto una release
• per i worm che rubano token, se nei job che potrebbero aver eseguito il codice malevolo erano presenti secret CI

Siamo coinvolti da una CVE? spiega come stabilire ciascuno di questi elementi.

Ogni dichiarazione che fa deve essere supportata da qualcosa che può mostrare:

Dichiarazione	Che cosa deve poter mostrare	Che cosa non basta
"La versione Y del prodotto X non contiene il pacchetto Z"	La SBOM registrata dalla build di release della versione Y	Una scansione del repository attuale
"Nessuna delle nostre build ha installato le versioni compromesse"	I registri di installazione di ogni build nella finestra	Un lockfile che alcuni job aggirano
"La nostra pipeline di release non è stata compromessa"	I registri di rete e di utilizzo dei secret per la finestra	L'assenza di allarmi
"I clienti sulla versione Y sono al sicuro dopo l'aggiornamento"	Il registro della build corretta e le credenziali che ha ruotato	Una voce nel changelog

Modello 2: non coinvolti

Oggetto: [nome dell'attacco]: [prodotto] non è coinvolto

Abbiamo completato la verifica relativa alla compromissione di [pacchetto], versioni [versioni interessate]. Le seguenti versioni di [prodotto] non sono coinvolte: [elenco dei prodotti e delle versioni verificati]. Abbiamo verificato ogni build di release e ogni build CI eseguita tra il [data di inizio] e il [data di fine]. La presente dichiarazione si basa sul registro dei componenti installati da ciascuna build di release, non su una scansione del nostro codice sorgente attuale. Nessuna di queste build ha installato le versioni interessate. Se desidera le prove, possiamo inviarLe la SBOM delle versioni che utilizza, oppure una dichiarazione VEX. Qualora emergesse qualcosa che modifica questa valutazione, Gliene daremo comunicazione. Contatto: [nome, indirizzo del contatto per la sicurezza].

Dica "non coinvolti" per versioni specifiche. Non scriva mai "sicuro al 100%". Se poi il cliente chiede la SBOM completa, veda rispondere alle richieste di SBOM dei clienti.

Modello 3: coinvolti, con mitigazione

Oggetto: [nome dell'attacco]: intervento necessario per [prodotto], versioni da [x] a [y]

La nostra verifica relativa alla compromissione di [pacchetto] ha rilevato che le versioni di [prodotto] da [x] a [y] sono coinvolte. La prima build interessata è stata prodotta il [data]; la versione [z], rilasciata il [data], non contiene più [versione del pacchetto].

Che cosa significa: [rischio in termini semplici, per esempio "un componente installato in queste versioni può inviare credenziali dal sistema su cui è in esecuzione a un server esterno"].

Che cosa fare ora: aggiornare [prodotto] alla versione [z]. Se non può aggiornare subito, [mitigazione, per esempio bloccare le connessioni in uscita verso gli host elencati]. Se ha utilizzato le versioni di [prodotto] da [x] a [y] in [ambiente], ruoti [credenziali o chiavi] che erano disponibili in quell'ambiente.

Che cosa abbiamo fatto: abbiamo rimosso le versioni interessate dalle nostre build, ricompilato [prodotto] da dipendenze pulite, ruotato le credenziali usate dai nostri sistemi di build e [altre azioni]. [Abbiamo informato le autorità competenti ove richiesto.]

Le invieremo il prossimo aggiornamento entro il [data], o prima se cambia qualcosa. Contatto: [nome, indirizzo del contatto per la sicurezza].

Una comunicazione "coinvolti" può anche essere un obbligo di legge; veda la sezione sulle segnalazioni più avanti.

Dove si collocano VEX e CSAF. Una dichiarazione "non coinvolti" o "corretto" può essere pubblicata come VEX, così gli scanner dei clienti smettono di segnalare il pacchetto. I clienti più grandi possono aspettarsi anche un advisory leggibile dalle macchine; CSAF è il formato che la maggior parte di loro richiede.

Aggiornamento: chiudere come si deve

Invii un aggiornamento quando esce la correzione, quando la Sua indagine scopre qualcosa di nuovo, e una nota finale quando il caso si chiude. Mantenga un solo advisory per incidente e lo riveda invece di inviarne uno nuovo ogni volta (aggiornare, non sostituire). Registri che cosa ha detto, a chi e quando: il prossimo audit o il prossimo questionario di sicurezza di un cliente lo chiederà.

Che cosa dire quando non lo sa ancora

"Non lo sappiamo ancora" crea più fiducia di un "non coinvolti" da ritrattare. Frasi oneste che non allarmano nessuno:

• "Non abbiamo trovato [pacchetto] in [prodotti verificati finora]. Stiamo ancora verificando [prodotti o sistemi di build restanti] e La aggiorneremo entro [ora]."
• "Le versioni che utilizza sono state compilate prima della finestra dell'attacco. Stiamo confermando che nessuna build successiva le abbia sostituite."
• "Stiamo verificando se uno dei nostri sistemi di build abbia eseguito le versioni interessate. Il prodotto che ha installato è una questione separata, e risponderemo a entrambe."

Frasi da evitare:

• "Nessun impatto di alcun tipo"
• "Completamente sicuro"
• "Non toccati da alcun attacco alla supply chain"
• "Il nostro scanner non ha trovato nulla"

Quando l'attacco diventa un obbligo di segnalazione

Se vende prodotti con elementi digitali nell'UE, il Cyber Resilience Act applica i suoi obblighi di segnalazione dall'11 settembre 2026, il giorno in cui l'ENISA ha avviato la piattaforma unica di segnalazione. Una vulnerabilità attivamente sfruttata nel Suo prodotto, o un incidente grave che incide sulla sua sicurezza, fa scattare un preallarme entro 24 ore da quando ne viene a conoscenza, una notifica entro 72 ore e una relazione finale, da presentare tramite la piattaforma al CSIRT designato come coordinatore e all'ENISA. La guida al CRA illustra i passaggi.

Se una dipendenza compromessa che ha distribuito, o una compromissione della Sua pipeline di build, rientri in quelle definizioni è una valutazione che spetta a Lei e ai Suoi consulenti legali, non a questo articolo. Il regolamento definisce i termini:

• Una «vulnerabilità attivamente sfruttata» è «una vulnerabilità per la quale vi sono prove affidabili che un attore malevolo l'ha sfruttata in un sistema senza l'autorizzazione del proprietario del sistema» (articolo 3, punto 42).
• Un incidente è grave se «incide o è in grado di incidere negativamente sulla capacità di un prodotto con elementi digitali di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o funzioni sensibili o importanti», oppure se «ha portato o è in grado di portare all'introduzione o all'esecuzione di codice malevolo» nel prodotto o nei sistemi di un utilizzatore (articolo 14(5)).

L'articolo 14(8) aggiunge un obbligo nei confronti degli utilizzatori: informare gli utilizzatori interessati e, se del caso, tutti gli utilizzatori della vulnerabilità o dell'incidente e delle eventuali misure di mitigazione che possono applicare, «se del caso, in un formato strutturato, leggibile da dispositivo automatico e facilmente trattabile in modo automatico». Il modello 3 può contribuire ad adempiere a questo obbligo.

Si applicano anche altri regimi. Ai sensi della NIS2, i soggetti essenziali e importanti notificano gli incidenti significativi al proprio CSIRT o all'autorità competente, e molti contratti con i clienti prevedono clausole di notifica proprie, con scadenze proprie.

Essere pronti prima del prossimo

• Un registro di ciò che ogni build di release ha installato, conservato per il periodo di supporto del prodotto (SBOM in fase di build).
• Un elenco di quali clienti utilizzano quali versioni.
• I tre modelli qui sopra, approvati dal legale.
• Un mittente designato e un canale per ogni tipo di cliente.
• Una pagina sulla sicurezza e un file security.txt dove pubblicare gli aggiornamenti (divulgazione coordinata delle vulnerabilità).
• Il controllo del traffico in uscita sulla CI, così un pacchetto compromesso non può inviare secret a un host di cui la build non ha bisogno (policy di egress per GitHub Actions).

Per gli incidenti che arrivano a centinaia anziché uno alla volta, veda come scalare un PSIRT.

Come si colloca CRACI

La tabella delle prove qui sopra chiede sempre la stessa cosa: un registro di ciò che ogni build di release ha installato. È ciò che CRACI conserva. CRACI esegue le Sue build GitHub Actions sui propri runner e registra ogni pacchetto che ciascun job ha effettivamente scaricato, compresi i pacchetti recuperati dagli script di installazione e quelli ripristinati dalle cache. La SBOM di ogni build passata viene conservata, quindi a "una build ha installato axios 1.14.1 durante la finestra?" si risponde con la cronologia delle build, insieme al periodo in cui Lei è stato coinvolto, fin dove arriva la Sua retention.

Le release malevole note che hanno una CVE pubblicata, come la backdoor di xz, vengono segnalate come qualsiasi altra vulnerabilità, e un policy gate può bloccare le build che le contengono. CRACI non rileva un nuovo pacchetto malevolo in base al suo comportamento o alla sua reputazione.

La policy di egress di CRACI blocca le connessioni verso host di cui una build non ha bisogno, il che limita ciò che uno script di installazione malevolo può inviare all'esterno, anche in un attacco mai visto prima. Quando un cliente chiede le prove, può esportare in CycloneDX o SPDX la SBOM delle versioni che utilizza e inviargliela. CRACI supporta VEX.

Risponda a "siamo stati coinvolti?" con la cronologia delle Sue build, oppure approfondisca come funzionano gli attacchi alla supply chain.

Quando CRACI non è la risposta

• Le serve aiuto per la comunicazione in sé. La consulenza di PR e quella legale sono un altro lavoro.
• Il software interessato non è stato compilato su CRACI. CRACI registra le build GitHub Actions eseguite sui suoi runner; gli altri sistemi CI sono nella roadmap.
• La domanda riguarda il prodotto di un vendor che non ha compilato Lei. Le SBOM dei vendor possono essere aggiunte a CRACI, ma la risposta è valida solo quanto la SBOM del vendor.
• Deve intercettare un pacchetto malevolo del tutto nuovo prima che esista un advisory. CRACI segnala le release malevole note una volta pubblicato un advisory con una CVE; non rileva il malware in base al comportamento o alla reputazione (rispondere alle vulnerabilità zero-day).

Domande frequenti

Che cosa dico ai clienti quando un attacco alla supply chain fa notizia?

Invii una prima dichiarazione entro poche ore: è al corrente dell'attacco, sta verificando i Suoi prodotti e le build, che cosa sa finora e quando aggiornerà. Faccia seguire una risposta confermata per versioni specifiche dei prodotti non appena può supportarla con i registri delle build, e un aggiornamento quando qualcosa cambia.

Che cosa dovrebbe dire una prima dichiarazione?

Che cosa è successo, in una frase, che sta verificando i Suoi prodotti e i sistemi di build, che cosa ha trovato finora, l'ora del prossimo aggiornamento e un contatto. Non deve dire "non coinvolti" prima di aver verificato, né fare ipotesi sull'attaccante o attribuire colpe.

Come dico "non siamo coinvolti" senza promettere troppo?

Indichi i prodotti e le versioni verificati, l'intervallo di date delle build verificate e le prove utilizzate, come il registro dei componenti installati da ciascuna build di release. Dica "non coinvolti" per quelle versioni, offra la SBOM o una dichiarazione VEX e si impegni ad aggiornare se qualcosa cambia. Eviti "sicuro al 100%" o "completamente sicuro".

Che cosa dovrebbe contenere una comunicazione ai clienti "siamo stati coinvolti"?

Quali prodotti e versioni sono coinvolti, da quando e fino a quale versione corretta, il rischio in termini semplici, che cosa deve fare ora il cliente (aggiornare, ruotare le credenziali, bloccare gli host), che cosa ha già fatto Lei, quando arriverà il prossimo aggiornamento e chi contattare.

Quali prove dovrebbero supportare una dichiarazione "non coinvolti"?

Per ogni versione utilizzata dai clienti, il registro di ciò che ha installato la build che l'ha prodotta, non il lockfile di oggi. Aggiunga i registri di ogni build eseguita durante la finestra dell'attacco e, per gli attacchi che rubano credenziali, se nei job che potrebbero aver eseguito il codice malevolo erano presenti secret.

Devo segnalare un attacco alla supply chain ai sensi del Cyber Resilience Act?

Forse. Dall'11 settembre 2026 i fabbricanti di prodotti con elementi digitali venduti nell'UE devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto: un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale. Se un determinato attacco rientri in questi casi è una valutazione che spetta a Lei e ai Suoi consulenti legali.

Quanto presto dovremmo rispondere ai clienti?

Entro poche ore con una prima dichiarazione, anche se dice soltanto che sta verificando e quando aggiornerà. La risposta confermata segue non appena è in grado di dimostrarla. Un "stiamo verificando" rapido e onesto fa di più per la fiducia di un "non coinvolti" tardivo.