Il tuo processo di patching è troppo lento per l’era delle AI offensive

L’11 febbraio 2025, i ricercatori dell’Università dell’Illinois hanno dimostrato che GPT-4, fornito di una descrizione CVE, poteva sfruttare autonomamente l’87% di un dataset di 15 vulnerabilità one-day. Senza quella descrizione, la percentuale scendeva al 7%. All’epoca sembrava un margine di sicurezza: l’AI sapeva sfruttare vulnerabilità note, ma non scoprirne di nuove.

Quel margine si è chiuso il 7 aprile, quando Anthropic ha presentato Claude Mythos Preview. Il modello ha scoperto autonomamente migliaia di vulnerabilità zero-day nei principali sistemi operativi e browser. In un test, Mythos ha raggiunto l’83,1% sul benchmark CyberGym per la riproduzione di vulnerabilità. In una campagna contro OpenBSD con 1.000 scaffold run, il costo totale di calcolo è stato inferiore a 20.000 dollari.

I tempi di exploit si stanno accorciando a vista d’occhio. La vulnerabilità CVE-2026-33017 di Langflow (CVSS 9.8) è stata sfruttata in 20 ore dalla divulgazione, senza proof-of-concept pubblico. La CVE-2026-39987 di Marimo (CVSS 9.3) è stata colpita in 9 ore e 41 minuti.

Il rapporto Rapid7 2026 sulla minaccia informatica indica che il tempo mediano tra la pubblicazione di un CVE e la sua inclusione nel catalogo CISA KEV (Known Exploited Vulnerabilities) è di cinque giorni. Google M-Trends 2026 ha rilevato che lo sfruttamento avviene prima ancora del rilascio di una patch. Quando è stato pubblicato l’avviso per Langflow, il primo exploit è arrivato in 20 ore. Per Marimo, in meno di 10 ore.

L’assunzione che la finestra di patching sia sicura perché l’exploit richiede tempo non è più valida. Serve un cambio di paradigma.

Il primo mattone: sostituisci il solo CVSS con un filtro a tre livelli

La maggior parte dei programmi di vulnerability management prioritizza ancora in base al solo punteggio CVSS. Questo sistema quantifica la gravità teorica di una vulnerabilità, senza considerare se è effettivamente sfruttata in natura o quanto velocemente possa essere weaponizzata. Una vulnerabilità con CVSS 8.8 e una storia di sfruttamento attivo (come CVE-2026-34040 di Docker) finisce con priorità inferiore rispetto a una CVSS 9.8 che potrebbe non essere mai sfruttata.

Uno studio recente, validato su 28.377 vulnerabilità reali, propone una sostituzione concreta: un albero decisionale a tre strati che combina CISA KEV, EPSS (Exploit Prediction Scoring System) e CVSS.

• Strato 1 — Sfruttamento attivo: CISA KEV catalog. Azione: patching immediato (SLA: ore).
• Strato 2 — Sfruttamento previsto: EPSS via FIRST.org. Soglia: punteggio ≥ 0,088. Azione: escalation a pipeline Tier 0 (SLA: 24 ore).
• Strato 3 — Baseline di gravità: CVSS via NVD. Soglia: punteggio ≥ 7,0. Azione: remediation tipica secondo policy.

Il risultato convalidato è un aumento di efficienza di 18x, una copertura dell’85,6% delle vulnerabilità sfruttate e una riduzione del ~95% del carico di remediation urgente. Tutti e tre i data source sono aperti e gratuiti. L’integrazione è interamente automatizzabile: un singolo script può interrogare le API di CISA KEV, FIRST.org e NVD per ogni CVE pubblicato, confrontandolo con il tuo inventario asset. L’umano rimane nel loop come approvatore, non come grilletto.

Il secondo mattone: chiudi il gap di autorizzazione degli agenti AI

Creare exploit velocemente cambia anche il modo in cui vanno configurati i controlli per tutti i sistemi basati su agenti che ora possiedono credenziali privilegiate. Le tue policy di autorizzazione non sono state valutate contro il comportamento degli agenti AI. CVE-2026-34040 ha mostrato che l’architettura dei plugin di autorizzazione di Docker ignora silenziosamente ogni plugin quando la richiesta supera 1 MB. Plugin comuni come OPA, Casbin e Prism Cloud non rilevano questo bypass, che avviene nel middleware di Docker prima che la richiesta raggiunga il plugin.

L’IETF sta lavorando a modelli di autorizzazione per agenti. Il documento draft-klrc-aiagent-auth-01 (marzo 2025, con partecipanti di AWS, Zscaler, Ping Identity e OpenAI) propone l’uso di SPIFFE e OAuth 2.0 con credenziali dinamiche a vita breve. Parallelamente, il draft-prakash-aip-00 dell’IETF segnala che su circa 2.000 server MCP (Model Context Protocol) esaminati, nessuno aveva autenticazione. Ma questi standard sono tra mesi e anni dall’implementazione.

Nel frattempo, i team di sicurezza devono creare test a livello di agente per ogni confine di autorizzazione: richieste oversize, burst frequency e escalation multi-step di richieste privilegiate.

Il terzo mattone: mappa il blast radius delle credenziali

Una survey di CSA/Zenity pubblicata il 16 aprile 2025 ha rilevato che il 53% delle organizzazioni ha già visto casi in cui gli agenti AI hanno superato le autorizzazioni previste, e il 47% ha subito un incidente di sicurezza che coinvolgeva un agente. Quando strumenti come Flowise (CVE-2025-59528, CVSS 10.0), Langflow o n8n vengono compromessi, il raggio di esplosione si estende ben oltre l’host: contengono chiavi API per modelli LLM, credenziali di database, token di vector store e token OAuth verso sistemi business.

Un host AI builder compromesso non è una singola violazione di sistema: è una raccolta di credenziali che sblocca l’accesso autenticato a ogni servizio connesso. Senza mappe di dipendenza delle credenziali per ogni host AI tool, l’incident response per un agente compromesso è un terno al lotto. Per ogni istanza, documenta ogni credenziale, l’estensione del suo accesso e il relativo processo di rotazione. Inizia a migrare le chiavi API statiche verso token a vita breve dove i servizi downstream lo consentono.

Cinque azioni per questo trimestre

1. Deploy del filtro KEV-EPSS-CVSS a tre livelli: sostituisci la prioritizzazione basata solo su CVSS. Automatizza la raccolta dati dalle tre API in uno script schedulato contro il tuo asset inventory. Risultato atteso: 18x più efficiente, 85,6% di copertura, 95% di riduzione del carico.
2. Patching event-driven per servizi Tier 0: identifica i servizi a esposizione critica (esposti a internet, host AI builder, control plane di orchestrazione container). Attiva il patching su pubblicazione CVE invece che sul prossimo maintenance window. Obiettivo: patch in canary entro 4 ore da un CVE dichiarato critico. Se impossibile per legacy, applica immediatamente compensazioni: rimuovi esposizione internet, ruota credenziali, disabilita funzionalità vulnerabili, identifica un exception owner.
3. Test dei confini di autorizzazione a scala di agente: crea casi di test per ogni API che gli agenti AI possono raggiungere tramite policy AuthZ. Includi richieste con body > 1 MB, 5 MB, 10 MB, burst > 100 richieste/secondo e combinazioni di parametri inusuali (privileged flags, host mounts, capability additions). Applica la patch a Docker Engine 29.3.1 per CVE-2026-34040.
4. Mappatura del blast radius delle credenziali per tutti gli host AI builder: documenta ogni credenziale per ogni istanza di Langflow, Flowise, n8n e pipeline AI custom.