Risposta a supply-chain attack con malware firmato — il playbook per CISO

Usa questo playbook quando una qualsiasi delle seguenti diventa vera:

• Un pacchetto che consumi (npm, PyPI, RubyGems, Maven, Crates, Go module, container image, GitHub Action) viene segnalato compromesso in un GitHub Security Advisory e il range di versioni affette si sovrappone a una versione installata negli ultimi 30 giorni.
• Un vendor advisory o un named-incident report (es. l'incidente Tanstack di maggio 2026, GHSA-g7cv-rxg3-hmpx) nomina un pacchetto o un account maintainer da cui dipendi.
• Una firma su un pacchetto in cui ti fidi viene riemessa da un'identità o pipeline di build inaspettata, anche prima che lo sfruttamento sia segnalato — anomalie sul transparency-log Rekor di Sigstore contano.
• Un segreto CI/CD che possiedi compare in un dump pubblico, paste site o stealer log, e il path di esposizione punta a uno step di install di pacchetto.

NON usare questo playbook per: CVE classiche nel tuo codice first-party (usa il tuo workflow standard di vulnerability management), incidenti di credential stuffing o account takeover senza vettore supply-chain, o zero-day contro binari firmati che non sono passati per il tuo build system. Quelli hanno alberi di containment diversi.

Il countdown parte al primo report credibile di terze parti, non alla verifica interna. Un "report credibile di terze parti" è: un GitHub Security Advisory, una CVE assegnata da un CNA, un security bulletin del vendor, o un post di incident tracking da un ricercatore riconosciuto con IoC riproducibili.

I gate:

• Ora 0 → Ora 1: triage, freeze, scoping. Devi sapere quali progetti hanno tirato il pacchetto e quali run CI hanno eseguito un install nella finestra di compromise.
• Ora 1 → Ora 4: containment delle credenziali. Ogni segreto che ha toccato un runner compromesso è presunto esfiltrato. Ruota, non "monitorare".
• Ora 4 → Ora 24: eradication e rebuild. Pinna a last-known-good, sostituisci credenziali in produzione, ricostruisci i container da base pulita.
• Ora 24 → Ora 72: notifica regolatore (se dati esfiltrati), notifica clienti (se artefatto downstream spedito), coordinamento upstream (advisory, PR di fix).

Le deadline non sono negoziabili. Aspettare "allineamento" col vendor affetto prima di iniziare la tua rotazione è il singolo failure mode più comune in questo scenario.

Obiettivo: fermare l'emorragia e conoscere il blast radius.

Azioni di triage (parallelizzabili, assegna owner):

• Conferma il report contro la fonte canonica (CISA KEV catalog, GitHub Security Advisories, l'advisory ID del vendor). Non agire su un singolo tweet senza un advisory di corroborazione.
• Identifica pacchetto + range di versioni + ecosistema affetti.
• Determina la finestra di compromise (quando la versione malevola è andata live, quando è stata ritirata).

Azioni di freeze:

• Blocca il range di versioni affetto nel tuo mirror privato (Artifactory, Nexus, GitHub Packages) — version-pin a last-known-good in una allowlist lato registry.
• Sospendi l'autoinstall in CI: disabilita qualsiasi pipeline che esegue npm install, pip install, bundle install o equivalente contro il registry pubblico finché il blocco sul mirror non è in posto.
• Ferma i deploy in produzione per i servizi che hanno consumato il pacchetto affetto negli ultimi 30 giorni.

Azioni di scoping:

• Grep dei tuoi lockfile (package-lock.json, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum) su ogni repository per il nome del pacchetto affetto e la versione compromessa.
• Estrai i log delle run CI per la finestra di compromise e identifica quali runner hanno eseguito install contro la versione compromessa.
• Per le container image: identifica quali immagini sono state costruite da una base che ha tirato il pacchetto, e quali ambienti le stanno eseguendo. Gli SBOM rendono questo una singola query; senza SBOM è una riconciliazione manuale di ore.

Ogni segreto presente nello spazio di memoria di un runner CI durante un install compromesso è presunto esfiltrato. Tratta la presunzione come fatto.

Ordine di rotazione (priorità alta → bassa):

1. OIDC token emessi ai runner compromessi durante l'install. Sono short-lived ma quasi certamente scambiati per cloud credential più long-lived dentro il codice malevolo. Revoca le session token cloud emesse nella finestra di compromise su ogni cloud provider usato (le attestazioni di provenance npm documentano la relazione con l'OIDC issuer).
2. GitHub Personal Access Token esposti nelle env var del workspace durante l'install — sia org-scoped che user-scoped. Audit dell'uso recente dei token via GitHub audit log per la finestra.
3. Cloud key long-lived (AWS access key, GCP service account key, Azure SP secret) presenti nei CI secret quando il runner ha eseguito l'install. Anche se usi OIDC primariamente, qualsiasi key long-lived di fallback è presunto leakato.
4. Deploy key e SSH agent forwarding che hanno toccato qualsiasi workspace che ha eseguito l'install.
5. Token dei package registry (token publish npm, API token PyPI, GitHub Packages token, credenziali push container registry). Il malware worm-style li riusa per ripubblicarsi — ruotare qui ti evita di diventare il prossimo vettore downstream.
6. API key SaaS terze parti in CI (Datadog, Sentry, Slack, Snyk). Non direttamente weaponizzabili nel build ma compaiono sui mercati stealer.

Documenta la rotazione in un singolo timeline log con timestamp e approver per ogni voce. Questo log è evidenza sia per gli advisory upstream sia per le notifiche downstream ai clienti.

Obiettivo: tornare a uno stato pulito, poi cercare cosa ha fatto il malware prima del containment.

Eradication:

• Pinna ogni progetto alla last-known-good del pacchetto affetto. Se non esiste versione sicura nella stessa major, fork-and-fix o rimuovi la dipendenza.
• Forza npm ci / pip install --no-cache / docker build --no-cache su ogni pipeline affetta — gli artefatti cacheati compromessi sono il vettore di reinfezione più comune in questa fase.
• Ricostruisci le container image da basi pulite. Non patchare in place; il malware può aver modificato node_modules o site-packages nell'immagine a strati.
• Revoca e riemetti qualsiasi artefatto firmato o attestato usando una credenziale compromessa.

Hunting (qui la maggior parte dei team si ferma troppo presto):

• Per ogni credenziale ruotata, interroga i log del provider upstream per l'uso di quella credenziale tra il timestamp dell'install e il timestamp della rotazione. Tutto ciò che è fuori dal tuo pattern normale è presunto attività adversary.
• Hunting dell'egress dai runner CI nella finestra di compromise: domini mai visti prima, egress su IP raw, DNS-over-HTTPS verso resolver sconosciuti, burst HTTPS verso paste service consumer. Questa è la signature dei payload tipici di esfiltrazione.
• Hunting in produzione per indicatori di payload eseguiti: cron job, systemd timer, scheduled task, registry run, egress inusuale dagli host produttivi che hanno eseguito la versione affetta.
• Confronta il diff degli SBOM contro la build provenance SLSA v1.2 per le release affette — i mismatch di provenance rivelano quali artefatti di release sono stati ricostruiti sotto la pipeline compromessa.

Obiettivo: chiudere il loop con upstream, downstream e regolatori.

Coordinamento upstream:

• Se il tuo team ha identificato l'issue indipendentemente, sottoponi un GitHub Security Advisory coordinato via il tab "Security" del repository affetto. Embargo finché upstream non conferma.
• Se un fix è disponibile, contribuiscilo via PR al progetto affetto. Se i maintainer sono unresponsive, richiedi disclosure dell'advisory via GitHub o MITRE.

Notifica downstream:

• Se hai spedito un artefatto downstream (build customer-facing, libreria che pubblichi, container image che altri tirano) che conteneva la dipendenza compromessa, notifica i clienti. Includi: la finestra di compromise, le versioni affette del tuo artefatto, la remediation consigliata (downgrade o upgrade), e qualsiasi IoC da cui i clienti possono fare hunting nel proprio ambiente.

Notifica regolatore (operatori UE):

• Entità essenziali/importanti NIS2: è un incidente significativo sotto NIS2 Title 13 se affetta la continuità di un servizio essenziale o importante, o se dati clienti sono stati esfiltrati. Early warning a ora 24, notifica completa a ora 72.
• Entità finanziarie significative DORA: notifica parallela sotto art. 19 DORA, con early warning a 4h, report intermedio a 72h.
• GDPR: se dati personali sono stati esfiltrati dai log CI, artefatti di build o produzione downstream, notifica art. 33 al Garante entro 72h dalla awareness.
• Regolatori settoriali (energia, sanità, finanza, PA): verifica la tabella di notifica settoriale specifica — alcuni hanno deadline più corte di NIS2.

Usa la stessa base evidenze per tutte le notifiche. Costruiscila una volta in fase di hunting, esporta per regime.

Lungo la response, pianifica di avere pronto (ogni voce firmata al momento della scrittura, con timestamp e chain-of-custody — l'assemblaggio manuale a posteriori sotto deadline regolatore è dove i team falliscono):

• Triage timeline log: timestamp del primo report, prima conferma interna, freeze, completamento rotazione, completamento eradication.
• Snapshot dei lockfile: pre-incidente e post-remediation, per ogni repository affetto. Il diff dimostra quali versioni sono state pinnate.
• Log delle run CI per la finestra di compromise su tutte le pipeline affette, con timestamp originali preservati.
• Diff degli SBOM: pre-incidente vs post-remediation, per ogni artefatto spedito.
• Log di rotazione credenziali: ogni credenziale ruotata, tempo di creazione originale, tempo di rotazione, approver, scope di accesso.
• Telemetria egress dai runner CI e dagli host produttivi che hanno eseguito la versione affetta, coprendo la finestra di compromise più 7 giorni prima e 7 dopo.
• Attestazioni di provenance: attestazioni di build SLSA per le release affette, dimostrando quali sono state ricostruite sotto la pipeline compromessa (riferimento specifica SLSA v1.2).
• Record di coordinamento upstream: submission GHSA, link PR, catena email col vendor.
• Log di notifica clienti: chi è stato notificato, quando, su quale canale, con quale contenuto.

La lezione operativa dalle organizzazioni peer: pre-costruisci questa chain di evidenze con una piattaforma continuous-evidence che firma ogni artefatto al momento della scrittura. La telemetria comportamentale di egress contro i runner CI — catturata da un'appliance on-prem che esegue AI Traffic Analysis con quattro inference head paralleli sul filo — produce la timeline di esfiltrazione come sottoprodotto dell'operazione normale, non come ricostruzione forense sotto deadline. Il check di firma ti ha detto che il pacchetto era autentico; il traffico ti ha detto cosa ha fatto.

1. Ritardo "fateci verificare prima di agire". I team perdono di routine 6-12 ore in verifica interna prima di iniziare la rotazione credenziali. L'advisory è già stato verificato dall'issuer; la tua finestra di verifica è per lo scoping del blast radius, non per decidere se agire. Inizia la rotazione in parallelo con la verifica.

2. Cancellare i workspace CI troppo presto. I workspace dalle run compromesse sono evidenze forensi. Snapshottali prima di qualsiasi cleanup. La maggior parte delle organizzazioni distrugge questa evidenza nella prima ora perché l'automazione recupera aggressivamente lo storage dei runner.

3. Saltare la revoca degli OIDC token. Il CI moderno usa OIDC token short-lived che "scadono da soli". Lo fanno — ma le cloud credential emesse via STS assume-role usando quegli OIDC token sono valide per ore e possono essere riusate. Revoca le STS session emesse durante la finestra su ogni cloud, non solo l'OIDC issuer.

4. Fidarsi di una copertura SBOM che non hai. La maggior parte del tooling SBOM copre bene le dipendenze dirette, male le transitive, peggio i pacchetti container-base, e per niente i tool build-time-only. Audita la copertura del tuo SBOM prima dell'incidente — affidarsi a SBOM incompleti durante lo scoping lascia blind spot che il malware sfrutta specificamente.

5. Notificare i clienti senza IoC. Una notifica cliente che dice "abbiamo usato un pacchetto compromesso ma non siamo sicuri di cosa abbia fatto" genera più carico di supporto di quanto ne devii. Includi sempre IoC su cui il cliente possa fare hunting — domini, IP, hash di file, nomi di processo, registry key — così può rispondere alla domanda senza tornare indietro.

6. Trattarlo come one-off. Il malware supply-chain worm-style (famiglia Shai-Hulud) è progettato per ripubblicarsi tramite le credenziali che ruba. L'incidente Tanstack di maggio 2026 ha riusato token rubati da compromise precedenti. Assumi che le tue credenziali ruotate possano essere state usate per pubblicare su altri registry prima della rotazione — audita la tua publish history durante la finestra di compromise.

Un incidente supply-chain con malware firmato tipicamente fa scattare più regimi di notifica in parallelo. Combinazioni comuni:

• SaaS provider UE: NIS2 Title 13 (se essenziale/importante) + art. 33 GDPR (se dati personali) + art. 19 DORA (se entità finanziaria) + notifica contrattuale al cliente (sempre). Stessa base evidenze, quattro export.
• Contractor federale US: reporting CISA (CIRCIA quando in vigore) + settoriali (FedRAMP, DFARS 252.204-7012) + leggi state-level di data breach dove dati personali hanno attraversato giurisdizioni.
• Regolati UK: NIS Regulations 2018 (se essenziale/importante) + UK GDPR + settoriali (FCA, ICO).
• Multinazionale: assumi che il regime con la barra più alta nella tua customer base sia la barra. Lo stesso playbook soddisfa tutti.

Il riferimento operativo per la cadenza lato UE è il playbook timeline incidenti NIS2 Title 13. Per l'angolo metodologico sul threat-led testing che esercita scenari supply-chain proattivamente, vedi TLPT (Threat-Led Penetration Testing) — la compromise supply-chain è uno scenario TIBER-EU standard per le entità finanziarie. La posizione difensiva del team di engineering Zero Hunt — e la posizione che NIST SP 800-204D codifica per le supply chain federali — è che la verifica di firma è necessaria ma non sufficiente: il monitoring comportamentale del traffico e l'attestazione continua di provenance devono girare in parallelo.