Approfondimento editoriale · fonti ufficialimedium
Patchare tutto è finita: il metodo del rischio, spiegato
A giugno 2026 la CISA ha emanato la direttiva BOD 26-04, che cambia il modo in cui le agenzie federali americane decidono cosa correggere prima. La regola non è più "aggiorna tutto e in fretta", ma "aggiorna prima ciò che è davvero rischioso", secondo quattro criteri. Vincola le agenzie USA, non le aziende italiane; ma il metodo è replicabile ovunque ci sia una coda di patch più lunga del tempo disponibile — cioè quasi dappertutto. Un approfondimento su come funziona e cosa se ne può prendere.
Il problema di "patchare tutto"
Chiunque gestisca vulnerabilità conosce la sensazione: la lista degli aggiornamenti da fare è più lunga del tempo e delle mani disponibili. Per anni la risposta implicita è stata "patcha tutto, e presto". Sulla carta è ineccepibile; nella pratica produce una coda indistinta in cui una falla catastrofica e sfruttata attivamente ha la stessa urgenza apparente di una svista teorica su un sistema interno che nessuno può raggiungere. Quando tutto è prioritario, niente lo è.
La direttiva BOD 26-04, emanata dalla CISA il 10 giugno 2026, prova a rompere questo schema per le agenzie federali statunitensi. Sostituisce due direttive precedenti — la BOD 22-01, quella del catalogo delle vulnerabilità sfruttate, e la BOD 19-02 — e sposta il baricentro dalla severità astratta al rischio concreto. Non riguarda le aziende italiane sul piano dell'obbligo. Ma il ragionamento che propone è generale.
I quattro segnali che contano
Il cuore della direttiva è un insieme di criteri per decidere l'ordine. Semplificando quanto dichiarato dalla CISA, una vulnerabilità sale in cima quando è pubblicamente esposta, quando è nel catalogo delle vulnerabilità sfruttate attivamente, quando è facilmente automatizzabile su larga scala, e quando ha un impatto tecnico grave. Sono quattro domande, non un punteggio unico da subire passivamente.
- 01È raggiungibile da fuori?l'esposizione pubblica è il primo moltiplicatore
- 02È già sfruttata (KEV)?non un rischio teorico, ma un attacco in corso
- 03Si automatizza facilmente?ciò che scala colpisce molti, in fretta
- 04L'impatto è grave?presa di controllo, esecuzione di codice, furto massivo
Quando una vulnerabilità risponde "sì" a tutti e quattro, la direttiva impone alle agenzie di correggerla entro tre giorni. È la stessa finestra strettissima che si vede sulle voci più gravi del catalogo KEV, e non è un caso: quel catalogo è uno dei segnali di ingresso del modello.
Cosa se ne prende un'azienda
Il valore di BOD 26-04, per chi non è un'agenzia federale, non sta nell'obbligo ma nel metodo. Tre cose sono trasferibili. La prima: usare il catalogo CISA KEV come lista di priorità reale, perché elenca ciò che qualcuno sta effettivamente sfruttando, non ciò che in teoria potrebbe esserlo. La seconda: pesare l'esposizione insieme alla severità — una falla critica su un sistema irraggiungibile è meno urgente di una media su un servizio affacciato su internet. La terza, spesso trascurata, è la parte di governance: la direttiva chiede alle agenzie di saper spiegare perché hanno corretto certe cose prima di altre, e di verificare — con una triage forense — se i sistemi vulnerabili non siano già stati compromessi. Prioritizzare non è solo velocità: è saper rendere conto delle scelte.
Un'avvertenza onesta. "Patchare per rischio" non vuol dire "non patchare il resto": le vulnerabilità fuori dai quattro criteri restano da chiudere, solo con una scadenza più lunga. Il rischio del modello è che qualcuno lo usi come scusa per rimandare all'infinito ciò che non è in cima. Ma applicato bene fa una cosa preziosa in un contesto di risorse finite: mette il tempo dove serve di più. Le fonti da cui prendere il dettaglio sono la direttiva e la sua guida di implementazione, entrambe pubbliche sul sito della CISA.
