Ogni settimana arrivano centinaia di CVE. Se guardi la coda, non finisci mai: il backlog cresce più veloce di quanto riesci a smaltirlo, e alla fine la risposta razionale diventa "le ignoriamo". È la decisione sbagliata, ma è quella che finisce per essere presa di default. Il punto non è se ignorare le vulnerabilità: è quale criterio usare quando devi scegliere.
Reachability: la sola domanda che conta
Una CVE critica in una libreria che il tuo servizio non importa, in un percorso di codice che non esegue mai, per una feature disabilitata: rischio pratico zero. La stessa CVE in un parser di immagini chiamato su upload pubblici, con input non validati: rischio immediato. Il concetto ha un nome chiaro — reachability — e si misura con strumenti di analisi statica e tainting, o più semplicemente con un inventario onesto delle dipendenze e delle funzionalità attive.
L'errore classico è avere un SBOM ("software bill of materials") preciso e sbagliato: l'elenco è esatto, la mappa dell'uso è inesistente. Il SBOM risponde a "cosa c'è", non a "cosa gira". Servono entrambi.
Fattori concreti di triage
Esposizione di rete. Internet esposto, VPN, solo interna? Molte aziende trattano come critiche CVE con score 9.8 che non hanno ascoltatore pubblico, mentre rimandano vulnerabilità con score 6.5 su un servizio in chiaro.
Sfruttabilità, non score. Il CVSS misura la gravità teorica. Contano di più: esiste PoC pubblica? compare in un catalogo di exploit attivi? è exploitata in campagna osservata? Un 9.8 senza codice e una 7.4 con PoC funzionante si gestiscono in ordine opposto.
Il componente è vivo? Versione EOL, software abbandonato, pacchetto mantenuto dalla comunità: il tempo di patch dipende da qualcun altro, e questo va nel calcolo.
Impatto d'affari. Cosa succede davvero se questo si sfrutta: dati personali, disponibilità, integrità delle decisioni? Il blast radius è metà del triage.
La finestra dei primi 72 ore
Quando una CVE viene sfruttata attivamente, la finestra utile è stretta. Un ordine di intervento che regge bene nella pratica:
Nessun accesso dall'esterno, se puoi toglierlo. Spegnere il servizio o filtrarlo a livello di perimeter batte quasi sempre l'attesa della patch.
Compromissione assumuta, non sospettata. Se la CVE è sfruttata, verifica con hunting su log e processi. Il punto di ingresso è il meno interessante: quello che conta è cosa è successo dopo.
Ruota i segreti. Credenziali, token, chiavi: se l'exploit ha dato accesso a un materiale, quel materiale è bruciato. La rotazione è l'azione che ferma la persistenza.
Poi la patch. A questo punto la correzione chiude la porta, ma non ripulisce.
Il canary token come strumento di verifica
Un approccio che sta diventando standard: usare un honeytoken per verificare se l'esca funziona, prima di fidarsi del sistema di rilevamento. Se pianti un file esca in una directory che ritieni monitorata e non arriva nessun alert, il problema non è l'attaccante: è il monitoraggio. È un test di copertura del SOC, eseguibile in dieci minuti e ripetibile ogni trimestre.
Conclusioni pratiche
Tre abitudini che fanno la differenza:
- una coda CVE per componente esposto, non per score;
- un honeytoken per ogni zona che vuoi considerare monitorata davvero;
la revisione mensile degli articoli "patched" con la stessa severità di quella degli articoli nuovi: una vulnerabilità non smette di esistere quando viene chiusa nel ticket.
Il backlog non si riduce con l'impegno. Si riduce scegliendo, in ordine.