L'era delle patch ora viaggia a velocità macchina e i cicli trimestrali sono finiti

Che cosa succede quando trovare un bug costa meno che correggerlo? Ne abbiamo appena avuto una dimostrazione dal vivo, e non è stata un bello spettacolo. Alcuni governi hanno messo offline i loro siti, e chi gestisce l'impianto idraulico di internet ha passato la settimana in modalità triage.

In breve: due falle critiche in PHP, che secondo l'AFP alimenta gran parte dei siti web del mondo, sono state individuate con modelli di IA. Come riferisce L'Express, siti governativi in Europa e altrove sono andati offline in via precauzionale mentre i gestori correvano ad applicare le patch. Due società di sicurezza, Calif e Wiz, dicono di aver trovato i bug in modo indipendente, e Wiz ha dichiarato di aver usato modelli di OpenAI e Google. I bug erano nel codice da anni.

Per noi le falle in sé contano meno di ciò che mostrano. La scoperta ormai viaggia a velocità macchina. La maggior parte delle organizzazioni continua ad applicare le patch a velocità umana.

Ciò che spaventa non è il bug, è l'orologio

Michael Daniel, presidente della Cyber Threat Alliance ed ex coordinatore della cybersicurezza della Casa Bianca, ha dato all'AFP il dato che ci è rimasto in testa. Una volta servivano uno o due mesi perché comparisse una proof of concept, e altri uno o due perché finisse nei kit di exploit. Oggi, dice, si parla di ore o giorni.

Basta vedere che effetto ha su un ciclo di patch trimestrale. Se l'intervallo tra la divulgazione di una falla e il suo uso da parte degli attaccanti si riduce a ore o giorni, un processo costruito su finestre di manutenzione mensili è, a nostro avviso, la scelta di restare esposti. L'inchiesta di Reuters riassunta da Distributique riporta dati di VulnCheck secondo cui il numero di vulnerabilità scoperte raddoppia in un anno. Raddoppiare il volume in arrivo mentre la finestra di risposta crolla è una morsa che probabilmente non si risolve con più personale.

Dobbiamo però essere onesti sulle cautele. Daniel osserva che storicamente solo il cinque o sei per cento delle vulnerabilità è stato sfruttato, e nulla suggerisce che questa quota stia salendo. Su questa falla in particolare, le notizie sono discordanti. I ricercatori citati da Distributique dicevano che, al momento dell'inchiesta di Reuters, non era stato confermato alcun exploit funzionante. L'Express, dal canto suo, riferisce che alcune aziende tecnologiche avevano avvertito che certi hacker stavano già sfruttando le falle. Da qui non possiamo sciogliere il nodo. La nostra lettura è che sia prima di tutto un problema di velocità, e dire che internet sta già bruciando sarebbe esagerare. Fare spallucce sarebbe peggio.

«Testare tutto per settimane» era un lusso, non una politica

L'idea più scomoda dell'intervista a Daniel riguarda la tolleranza al rischio. La maggior parte delle aziende applicava quella che lui chiama tolleranza zero verso qualsiasi rottura, quindi testava le patch in modo esaustivo. Sostiene che ormai non hanno più quel tempo. Se una patch ha l'uno per cento di probabilità di rompere qualcosa, ma un attacco potrebbe costare 50 milioni di dollari, il calcolo cambia.

Crediamo che abbia ragione, anche se a molti reparti IT non piacerà sentirlo. Applicare le patch con lentezza e cautela era razionale quando lo sfruttamento era lento. Ora il costo dell'attesa è il rischio maggiore. In pratica significa tre cose poco affascinanti. Primo, un inventario accurato di ciò che usi e di quali parti sono esposte a internet. Secondo, percorsi automatizzati di test e rilascio capaci di distribuire in fretta una correzione. Terzo, mitigazioni temporanee per quando una patch non può partire subito. È più o meno la checklist dell'articolo di Distributique, e nulla di tutto ciò richiede l'IA. Richiede disciplina, che è più difficile.

Le piccole organizzazioni sono le vere perdenti. Il consiglio di Daniel per loro è netto: riorganizzarsi per poter accettare gli aggiornamenti dei fornitori il più in fretta possibile. Per chi usa una piattaforma gestita, significa soprattutto scegliere i fornitori in base alla rapidità con cui applicano le patch.

Il debito tecnico è la vera storia, e l'IA è l'esattore

Daniel parla di «debito tecnico in scadenza». Il costo implicito di tenere in vita software vecchio non compare mai a bilancio finché non succede un episodio come questo. Rob Joyce, ex direttore della cybersicurezza della NSA, l'ha definito «il grande incendio boschivo purificatore del vecchio software». Entrambe le immagini ci convincono.

C'è anche una lettura speranzosa. Daniel si aspetta che gli strumenti di IA vengano applicati al software prima del rilascio, così che il codice nuovo parta con meno falle. Jason Clinton, dirigente della sicurezza di Anthropic, ha scritto su X che le cose peggioreranno molto prima di migliorare e che bisognerà resistere circa 18 mesi, secondo 01net. È una previsione, non un fatto, e viene da un'azienda che costruisce questi modelli. La logica resta plausibile: prima o poi anche i difensori avranno gli stessi strumenti.

Un'altra cautela riguarda il rumore. Daniel ammette con franchezza che molte segnalazioni fatte dall'IA sono falsi allarmi o riguardano software mai esposto a internet. Il collo di bottiglia sembra essere il triage, non la scoperta.

Il nostro verdetto

Smettila di trattarla come una storia su PHP. Consideralo uno stress test della tua pipeline di patch e chiediti onestamente quanto tempo ti avrebbe richiesto questa settimana una correzione critica. Se la risposta è «settimane», quello è il progetto del prossimo trimestre, non del prossimo ciclo di patch. Fai l'inventario di ciò che usi, automatizza il percorso di rilascio, accetta un piccolo rischio di rotture e dismetti il software che tieni in vita solo per inerzia. La piena che Daniel descrive arriverà comunque. L'unica scelta è se hai costruito uno scolmatore.