Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Off-by-1 Labs, il gruppo di ricerca sulla sicurezza di 1Password, ha pubblicato il 6 agosto una misura su quanto valgono le patch scritte dai modelli. Ha generato 6.080 patch su sei vulnerabilità divulgate di recente e ne ha classificato l’esito. Lo studio è firmato da Keith Hoodlet, con revisione di Casey Ellis, Jason Haddix e Mike Shema.
Come è stato misurato
Le sei vulnerabilità sono reali e nominate: CVE-2026-31431, privilege escalation nel kernel Linux; CVE-2026-34197, esecuzione di codice remoto in ActiveMQ; CVE-2026-8512, use-after-free in Chrome; CVE-2026-45185, RCE in EXIM; CVE-2026-22738, RCE via SpEL in SpringAI; e GHSA-wpqr-6v78-jr5g, RCE nella CLI di Gemini.
I modelli sono due, ChatGPT-5.5 e Opus 4.8, entrambi nelle versioni con accesso alle capacità cyber. Per ogni vulnerabilità e per ogni modello sono state generate 540 patch, in gruppi da 20 sotto condizioni variate. Delle 6.480 prodotte, 400 sono state scartate perché segnalate dal modello stesso, e l’analisi finale ne conta 6.080.
Gli esiti sono classificati in cinque scenari, testuali: “Complete fix; does not alter application behavior”, “Complete fix; alters application behavior”, “Does not fix the vulnerability”, “Complete fix of the old vulnerability while adding a new vulnerability”, “Does not fix the vulnerability while adding a new vulnerability”.
I numeri
| Esito | Quota |
|---|---|
| Risolve la falla senza alterare il comportamento | 26,0% |
| Risolve la falla alterando il comportamento | 20,1% |
| Non risolve o introduce una vulnerabilità nuova | 53,9% |
La frase dello studio sulla prima riga è “The average success rate for generating a patch that fully resolved the vulnerability… was just 26.0%”. Sull’ultima: le patch “did not resolve the vulnerability, added a new vulnerability, or both, an average 53.9% of the time”.
Le patch fragili dentro quelle riuscite
Lo studio esamina anche il contenuto delle patch classificate come riuscite. Oltre il 33% di quelle classificate S1 e S2, cioè fra quelle che risolvono, contiene “subtleties that we would qualify as ‘fragile’ from a security context”.
Fragile qui ha un significato preciso: la patch mette un controllo mirato al posto di correggere la causa. Sul caso SpringAI i modelli hanno spesso “simply escaped specific characters in user input”, bloccando il proof of concept e lasciando in piedi la vulnerabilità sottostante.
Una patch così passa i test che usano l’exploit noto. Fallisce sulla prima variante.
Trovare e riparare sono capacità diverse
Nei record CVE ufficiali otto delle nove vulnerabilità che JFrog ha corretto in Artifactory, dopo l’incidente ricostruito a Black Hat, sono accreditate a ricercatori di OpenAI, e i modelli in valutazione ne avevano trovate di sconosciute.
Lo studio di Off-by-1 misura l’altra metà del ciclo, e dà 26,0%.
Le due cose non sono in contraddizione. Trovare una vulnerabilità richiede di produrre un input che rompe qualcosa, e la verifica è immediata: o l’exploit funziona o no. Ripararla richiede di capire perché il codice si rompe, distinguere il sintomo dalla causa e non spostare il problema altrove, e la verifica non è più binaria, perché una patch può risolvere e rompere insieme. Il 20,1% che risolve alterando il comportamento è esattamente quella zona.
Cosa ne pensiamo
Il 26,0% dipende dai due modelli e dalle sei vulnerabilità scelte, e cambierà con la prossima generazione. Il 33% di patch fragili dentro quelle riuscite descrive invece un modo di sbagliare che resta uguale, perché non si vede dal risultato del test.
Una pipeline che accetta una patch quando l’exploit noto smette di funzionare classifica quelle patch come buone. Ripetere lo stesso proof of concept dà lo stesso esito su una patch fragile e su una solida. Il controllo che le distingue è dove agisce la correzione, sulla causa o sull’input, e quella lettura del diff oggi la fa una persona.
Una patch generata da un modello va trattata come una proposta di un collaboratore esterno, quindi passa dalla stessa revisione, non da una corsia veloce perché “l’ha scritta l’AI”. E il criterio di accettazione va spostato dal proof of concept alla classe di vulnerabilità: se la correzione filtra caratteri, la domanda è cosa succede con la codifica successiva.
La conclusione dichiarata dallo studio è: “human expertise still plays an essential role in the process of fully resolving vulnerabilities in software without introducing unwanted side effects”. È una posizione di 1Password, che vende sicurezza, e va pesata per quello che è. I 6.080 campioni, le sei CVE nominate e i cinque scenari dichiarati la rendono però una posizione controllabile: la stessa classificazione si può rieseguire su altre vulnerabilità e altri modelli.
Fonti
- 1Password, Off-by-1 Labs: why AI-generated patches still require human review
- Dark Reading: AI-generated patches fail half the time
- Help Net Security: three in four AI-generated vulnerability patches leave something broken
- eSecurity Planet: 1Password finds AI security patches fail more than half the time