OpenAI ha aggiornato GPT-5.5-Cyber, la variante specializzata del modello GPT-5.5 destinata ai workflow di cybersicurezza autorizzati. Il sistema è progettato per assistere i team di difesa nell’identificazione, nella validazione e nella correzione di vulnerabilità software, operando su attività che richiedono analisi del codice, uso di strumenti, ragionamento multi-step e continuità su task complessi.
GPT-5.5-Cyber non è pensato come un modello disponibile senza restrizioni per qualunque richiesta tecnica. OpenAI lo colloca nel programma Trusted Access for Cyber, un sistema di accesso basato su verifica dell’identità, controlli sugli account, monitoraggio dell’uso e delimitazione degli ambienti autorizzati. L’accesso più permissivo è riservato a professionisti e organizzazioni che devono svolgere attività difensive, penetration test autorizzati, red teaming controllato o validazioni tecniche su infrastrutture di cui possiedono autorizzazione.
L’aggiornamento si concentra sulla capacità di trasformare la scoperta di un difetto in un processo di remediation più completo. Il modello può essere impiegato per esaminare repository, individuare porzioni di codice potenzialmente vulnerabili, ricostruire le condizioni che rendono sfruttabile un problema, proporre una correzione e contribuire alla verifica del patch. In un flusso operativo integrato, il risultato non è soltanto un alert o una spiegazione testuale della vulnerabilità, ma un insieme di elementi utilizzabili dal team: descrizione del rischio, componenti interessati, proposta di modifica, test di regressione e documentazione della correzione.
OpenAI collega GPT-5.5-Cyber alla piattaforma Daybreak e agli strumenti Codex Security. L’architettura descritta dall’azienda punta a rendere più continuo il passaggio fra rilevamento, prioritizzazione e correzione. Un sistema di questo tipo può analizzare vulnerabilità note, segnali emersi da scanner o code review, dipendenze software, configurazioni e risultati dei test, quindi aiutare il team a distinguere i problemi teorici da quelli effettivamente riproducibili nel proprio ambiente.
Nel benchmark CyberGym, che misura la capacità di un agente di riprodurre vulnerabilità note in ambienti software controllati, GPT-5.5-Cyber ha ottenuto l’85,6% nelle valutazioni a modello singolo, rispetto all’81,8% di GPT-5.5. Sul benchmark ExploitGym, dedicato alla riproduzione di vulnerabilità conosciute che conducono a esecuzione di codice non autorizzata in ambienti di test, il modello ha raggiunto il 39,5%, contro il 25,95% di GPT-5.5. Su SEC-bench Pro, che valuta scoperta di vulnerabilità e generazione di proof of concept su target software complessi e di lunga durata, GPT-5.5-Cyber ha registrato il 69,8%, rispetto al 63,1% del modello generale.
Questi risultati non significano che il sistema possa sostituire la revisione umana o che ogni patch prodotto sia pronto per l’applicazione diretta in produzione. La correzione automatizzata di una vulnerabilità deve essere verificata rispetto al comportamento dell’applicazione, ai requisiti di compatibilità, ai controlli di sicurezza esistenti e agli effetti collaterali sul codice. OpenAI indica infatti la generazione e il test delle modifiche all’interno di repository con accessi limitati, monitoraggio e revisione, anziché un modello di modifica autonoma indiscriminata dei sistemi.
La distinzione fra GPT-5.5 con Trusted Access for Cyber e GPT-5.5-Cyber resta centrale. Per la maggior parte delle attività difensive, come secure code review, triage delle vulnerabilità, threat modeling, analisi malware, detection engineering e validazione dei patch, OpenAI indica GPT-5.5 con Trusted Access come punto di partenza. GPT-5.5-Cyber viene invece riservato ai casi più specializzati, nei quali servono comportamenti più permissivi per attività autorizzate e controllate.
Il valore operativo dell’aggiornamento dipende quindi dall’integrazione nel ciclo di sviluppo e sicurezza. Il modello può ridurre il tempo necessario per passare da una segnalazione alla comprensione tecnica del difetto, dalla proposta di fix alla preparazione dei test di validazione. La responsabilità finale sulla priorità della vulnerabilità, sull’approvazione del codice e sul rilascio in produzione resta però in capo ai team che gestiscono il software e l’infrastruttura.