needhelp
← Back to blog

GPT-6 Cyber: leggere i benchmark e verificare le correzioni

by xingwangzhe
openaicybersecuritygpt-6security-research

OpenAI ha presentato GPT-6 Cyber il 5 novembre 2026, inizialmente per alcuni clienti Daybreak Red tramite API e Codex. Per i team conta trasformare le scoperte in correzioni revisionate e distribuite.

Che cosa è stato pubblicato

La scheda del sistema descrive una variante di GPT-6 Astra specializzata nel lavoro di sicurezza autorizzato. L’accesso è limitato. L’annuncio non implica disponibilità per ogni account API; qui non vengono inventati identificativi o chiamate SDK.

Come leggere i numeri

ExploitGym sale dal 32.1% al 48.5%: 16.4 punti percentuali, circa il 51.1% di miglioramento relativo. Sfruttare una vulnerabilità indicata e trovare un difetto sconosciuto sono compiti diversi.

Il test web senza sorgenti riporta un richiamo del 40.3%, contro il 32.0% di Astra. Il dato non descrive il carico dei falsi positivi. Prima di stimare risparmi servono obiettivi, budget, tentativi, interventi umani e costo per scoperta accettata; questo sito non ha riprodotto i test del fornitore.

Linux e Firefox: seguire le prove

Il rapporto Linux distingue 2,308 candidati, 1,724 vulnerabilità riprodotte e 948 exploit funzionanti di elevazione locale dei privilegi. Un sospetto e una violazione osservata dei permessi hanno peso diverso. L’elevazione locale presuppone accesso locale e non equivale a esecuzione remota.

La campagna ha consumato 1,213,430 dollari di crediti API, circa 1,279 per exploit locale funzionante. Non è un listino né il costo completo del lavoro. L’avviso Firefox documenta componenti, gravità e riferimenti. Il 27 ottobre precede il lancio del modello: scoperta, segnalazione, correzione e annuncio vanno datati separatamente.

Dalla risposta alla correzione

Il diagramma propone un processo dell’autore, non un’architettura ufficiale. Si fissano prima revisione e ambiente. Il modello propone ipotesi e patch; un esecutore separato riproduce il difetto e verifica la soluzione.

Ambito autorizzatoRevisione fissaIpotesi del modelloRiproduzione isolataPatch propostaTest di regressioneRevisione umanaDistribuire e verificare

Conservare input, log, comandi e diff. Lo stesso caso deve fallire prima e riuscire dopo, con test di regressione sui comportamenti validi vicini. Disabilitare una funzione può eliminare il crash e danneggiare il prodotto.

Un controllo eseguibile

Salvare il codice in evidence-gate.ts ed eseguire bun run evidence-gate.ts. Non usa la rete né GPT-6 Cyber. Controlla un record locale con commit, ambiente e risultati prima e dopo la patch.

type Finding = {
id: string;
commit: string;
environment: string;
before: number;
after: number;
regression: number;
reviewer: string | null;
};
function readyForReview(f: Finding): boolean {
return (
/^[a-f0-9]{40}$/.test(f.commit) &&
f.environment.trim().length > 0 &&
f.before !== 0 &&
f.after === 0 &&
f.regression === 0
);
}
const finding: Finding = {
id: "LAB-001",
commit: "a".repeat(40),
environment: "isolated-vm / fixture-v1",
before: 1,
after: 0,
regression: 0,
reviewer: null,
};
if (!readyForReview(finding)) {
throw new Error("Evidence incomplete");
}
console.log(
JSON.stringify({
id: finding.id,
readyForReview: true,
approved: finding.reviewer !== null,
}),
);

L’esempio produce readyForReview: true e approved: false. I codici di uscita devono arrivare da un esecutore affidabile. Il controllo non dimostra sfruttabilità, correttezza o identità del revisore; servono approvazioni autenticate e artefatti immutabili. Sostituire il commit fittizio con quello verificato.

Confini imposti durante l’esecuzione

L’annuncio riporta 99.93% di rispetto del perimetro senza prompt di distribuzione e 100% con essi. Sono osservazioni di test, non garanzie universali. La scheda classifica la capacità cyber come Critical.

Autorizzazioni, uscita di rete e credenziali devono essere controllate fuori dal modello. L’esecutore richiede budget limitato e stato eliminabile. Istruzioni ostili nei file o nelle pagine sono dati e non ampliano i permessi.

Valutare un progetto pilota

Usare un repository proprio e confrontare revisioni e budget uguali. Misurare scoperte uniche accettate, riproducibilità, tempo di revisione, accettazione delle patch e tempo al rilascio. Anche i duplicati consumano risorse.

Inserire codice sospetto irraggiungibile, errori già risolti, patch che nascondono il crash e obiettivi non autorizzati. Senza prove il sistema deve mantenere l’incertezza e fermarsi. Il mio criterio è ridurre il tempo dalla scoperta riproducibile alla correzione distribuita.

Riferimenti

Un’IA ha assistito nella stesura e traduzione. Fatti citati, esempio e raccomandazioni dell’autore sono distinti.

Share this page