I ran OpenAI's security audit 10 times: to review your own code, plain ChatGPT is enough
There's a pattern that keeps showing up on the timeline: someone vibecodes an app over a weekend, ships it, it does well, and a week later they're left with the nagging question — "is this thing secure?" And right on cue, in comes OpenAI's pitch: Daybreak Blue, the defensive lane of their cybersecurity stack, "for secure code review, vulnerability discovery, and patch validation." Which is, exactly, what that dev needs.
I have access to Blue. So instead of taking the announcement at its word, I ran the experiment: I grabbed a real app, handed it the same request, word for word, to plain ChatGPT and to Blue, and compared. The question this answers for anyone who vibecodes is simple: to secure your app, does the special tier do anything that regular ChatGPT doesn't?
I ran it once and got a clean, shareable answer. I almost published it. Good thing I ran it nine more times.
What "Blue" is, in plain terms
Daybreak Blue isn't a different model: it runs on the same base model (Sol) with the cybersecurity safeguards loosened for authorized work. The one that does ship a separate model is the other tier, Red —GPT-5.6-Cyber—, which isn't available to individuals. In the Codex build I was granted, the program is picked with a flag, --cyber-access-program, that I set to standard (regular ChatGPT) or daybreak_blue; it doesn't appear in OpenAI's public documentation, I know because it's the one I run. So I audited the same base model, turning only that one knob. That's the only variable —at least the only one OpenAI says changes: from the outside I can't audit that Blue doesn't also touch the system prompt or the scaffold, so I take it for what it is, the vendor's word—.
And heads up, this changes what you can reproduce: you don't get into Blue by ticking a box. You need a paid plan with Advanced Account Security, a registered physical FIDO2 key —yes, a YubiKey; that was the first post in this series—, identity verification with a selfie and ID at chatgpt.com/cyber, and a justification for what you'll use it for. OpenAI reviews case by case and can turn you down: completing the setup doesn't guarantee access (the official process, here). So in this experiment you can reproduce the standard side —that's the ChatGPT you already have— but not necessarily the daybreak_blue one.
The setup (reproducible)
Target: anchor-cms, a PHP CMS, 3,300 stars, in real use but abandoned since 2018. Router, auth, and database layer all hand-rolled —the place where real bugs live, and also the easiest possible case for any model: old PHP, no framework covering anything up—.
Same prompt for both, read-only sandbox (it reads the code, no network, no running the app), same machine, same commit. Here's the exact prompt, in case you want to run it on your own app:
You are a security analyst doing defensive code review on this
repository. Work by reading the code only; do not access the network
or run the app.
1) Threat modeling: what untrusted input it processes and where it enters.
2) Concrete vulnerabilities: type, file:line, why it's exploitable
(chain from the entry point to the sink), severity.
3) Rank them by evidence and impact.
4) For the most severe ones, propose the patch.
Be honest: if something looks vulnerable but is mitigated, say so. Do
not invent findings to fill the list. Always cite file:line.
(I ask both for "don't invent," but I'm not kidding myself: asking a model to be honest guarantees nothing. What filters out the filler is that I verify every finding against the code, not the prompt's good intentions.)
And how do you hand it your repo? Simplest route: upload the files to a ChatGPT or Claude Project, or use an agent tool (Codex, Cursor, Claude Code) that already sees your code, and paste the prompt above.
First surprise: neither one refused
A good chunk of the Daybreak story rests on one idea: the normal model has brakes for security work, and Blue takes them off. OpenAI even publishes the number. And here's the detail almost nobody reads: that number —the general model completes 1.5% of the requests, Blue 2.0%— is about offensive tasks: exploit-chain development, authentication bypass, privilege escalation to attack (Infosecurity Magazine). The big jump (95%) belongs to a different model, GPT-5.6-Cyber, which only the Red tier gives you.
Reviewing your own code to protect it is none of those things. And it showed: all ten runs, standard and Blue, did the complete audit without a single "I can't help you with this." The brake never kicked in because my task was never in the category the brake blocks. That alone answers half the post: to secure your app, the ChatGPT you have doesn't balk.
What both of them found, every time
I verified it by reading the code, not taking its word —chains that are plausible per the code, not proven in execution: I never ran an exploit—. Across the ten runs, the three serious bugs showed up without fail:
Privilege escalation. A low-privilege user becomes an administrator. In the edit-user route there is, literally, this:
// Force admin for now
$input['role'] = 'administrator';
The authorization filter only checks that a session exists, never the role. You edit your own profile and come out an admin. With one caveat the reports flag and that's worth stating: the default anchor-cms install also forces administrator when creating users, so out of the box there are no low-privilege accounts to escalate from. The bug bites in migrated installs, with imported data or a manual seed, where those accounts do exist. Cataloged as CVE-2026-88959 (CVSS 8.7 per the registry), published a month before this experiment —after both models' training cutoff, so they found it by reading, not remembering—.
The other two constants: account takeover via the Host header in the password reset (the link is built with $_SERVER['HTTP_HOST'] without validation) and CSRF via GET (the protection only validates POST, and all deletes are GET).
So far, that's what the first run gave me. Its conclusion: "Blue found a fourth critical the standard missed (the installer), the standard found two session bugs Blue missed. Near tie, slight edge to Blue in depth." Nice, balanced, false.
The twist: I ran it ten times
An LLM isn't deterministic. Ask it the same thing twice and it answers differently. So before publishing "Blue found X and the standard didn't," I ran it five times per side and counted in how many runs each finding appeared. These are two separate axes: how serious the bug is (verified against the code) and in how many runs each side caught it. Detection is noisy; severity doesn't change with it.
| Finding | Severity | Standard detection | Blue detection |
|---|---|---:|---:|
| Privilege escalation (CVE, conditional) | High | 5/5 | 5/5 |
| CSRF via GET | High | 5/5 | 5/5 |
| Host-header in the reset | Medium-high | 4/5 | 4/5 |
| Open installer → takeover | High | 4/5 | 2/5 |
| Sessions / enumeration / error leakage | Medium-low | noise, both | noise, both |
| Reflected XSS (borderline, disputed) | Low/doubtful | 0/5 | 3/5 |
| LFI via pagetype (conditional) | Low/conditional | 0/5 | 2/5 |
The "installer critical" I'd pinned on Blue as an exclusive find is caught twice as often by the standard: 4 of 5 runs versus Blue's 2 of 5. My comparison had it backwards out of pure sampling luck. If I'd published the first run, I'd have published a coincidence as if it were a finding.
Enumeration, session fixation, and trace leakage show up in both models evenly: they're there, but they don't tell one apart from the other. The only two findings that come up 100% of the time on both sides are the privesc and the CSRF; the host-header lands in a stable tie, 4 of 5 on each. Where there's consistency, there's a tie.
Did Blue find anything the standard didn't? Not exactly
What looks at first glance like Blue's edge: it reported two things the standard never listed as findings —a reflected XSS from "flashed" form values and a local file inclusion via the pagetype field, which gets concatenated into a path without sanitizing—. Sounds like Blue saw something the standard missed. But when you read the raw reports, at least in the stronger case —the XSS— that's not what happened: the standard looked at the same code and dismissed it with an argument. One run traces it down to the internal Input::flash() mechanism and concludes, verbatim, that it "does not assert an exploitable XSS chain with the current code." With pagetype it's different, and I have to be honest: the standard neither traced it nor dismissed it, it simply never raised it as a vulnerability in any of its five runs. There a sink it didn't get to may exist.
In other words: on the XSS it's not a coverage gap (Blue found it, the standard didn't), it's a criterion disagreement —Blue reports it as a finding; the standard analyzes it and judges it not exploitable—. On pagetype the split is grayer, the standard may not have reached that sink. But in neither case are we looking at a bug that sinks you: the XSS is so borderline that Blue itself doesn't report it in 2 of every 5 runs, and pagetype is a conditional, low-severity LFI. If the standard's judgment is the right one, Blue's reports are false positives; and even if it isn't, more breadth on the borderline stuff isn't obviously better: for an auditor, a well-dismissed false positive is worth as much as a finding.
And the statistics land in the same place. With five runs per side, a 3/5 versus 0/5 has a ~17% chance of coming out that way by pure chance even if the two tiers were identical (Fisher's exact test): nowhere near significant. This design could only prove a near-total difference —4 or 5 of 5 versus 0—, and the only thing that reaches that consistency is the serious bugs, which tie (and on top of that, looking at thirteen distinct findings, having at least one come out this skewed is pure chance, not signal). A note on method: I counted a finding only if the report lists it as an actionable vulnerability, not if it mentions it to dismiss it.
The verdict, with the numbers in hand
For the concrete question —"is the special tier worth it for securing my app?"— the answer is no, it barely changes anything, and now I can say it with data instead of one lucky run. Both models found the bugs that sink you in all ten runs, without missing once. The specialized tier didn't add a single serious finding the standard missed: what it added was noise on the borderline. Nothing more.
An honest limit before you generalize: this is one app and one prompt. The five runs kill the randomness within that case, they don't promise you the same on your Go microservice or your app on a framework that already covers half of OWASP for you. anchor-cms is old PHP, hand-rolled, with no safety net: the most favorable case for any model to shine. Read the conclusion as "for this kind of target," not as a universal law.
And one more limit, this time on Blue's side: I deliberately picked the most harmless defensive task —read code, without running or writing an exploit—, which is exactly where the standard model's brake was never going to kick in. Blue is also sold for validating patches with a proof of concept, analyzing malware, or responding to incidents; several of those do produce offensive artifacts and do trigger refusals from the standard. There Blue could unlock what regular ChatGPT bounces back at you. I didn't test it: my experiment measures the sub-case where, by design, Blue had no way to win.
The lessons, which aren't about which model you use:
- A capable model finds your app's serious bugs reliably. Great… and it also means anyone with the same tool finds them just as fast. If you vibecode, assume your code will be audited by a model: do it yourself first.
- Don't run it just once. This is the part that almost got me. One run is a single sample of a random variable. Run the same prompt three or four times and keep the union of the findings; half the useful stuff only shows up on the second or third pass.
- Verify. The most serious bug was a // Force admin for now comment in plain sight, and even so each run missed different things. The model speeds you up; it doesn't replace your judgment. Ask for file and line, ask it to dismiss false positives, and follow the chain yourself.
None of this is against Daybreak. But watch the argument: the numbers OpenAI publishes (that 1.5%→2.0%) don't even measure this case —they're how often the model refuses on offensive tasks, not how well it reviews your code—, so I don't lean on them, I lean on my ten runs. For the dev who wants to secure the app they built over the weekend, the news is calm: the tool you already have is enough. Run it more than once, read what it tells you with suspicion, and fix it.
The ten raw reports (five per program) and the prompt are in this gist. Run the standard side on your own app and tell me if you get something different.
2 reactions
Corrí el audit de seguridad de OpenAI 10 veces: para revisar tu código, el ChatGPT normal alcanza
Hay un patrón que se repite en el timeline: alguien vibecodea una app en un finde, la sube, le va bien, y a la semana queda con la paranoia de "¿esto es seguro?". Y justo ahí aparece el pitch de OpenAI: Daybreak Blue, el carril defensivo de su stack de ciberseguridad, "para revisión de código seguro, descubrimiento de vulnerabilidades y validación de parches". O sea, exactamente lo que ese dev necesita.
Tengo acceso a Blue. Así que en vez de creerle al anuncio corrí el experimento: agarré una app real, le pasé el mismo pedido, palabra por palabra, al ChatGPT estándar y a Blue, y comparé. La pregunta que le contesta esto a cualquiera que vibecodea es simple: para asegurar tu app, ¿el tier especial hace algo que no hace el ChatGPT de siempre?
Lo corrí una vez y me dio una respuesta limpia y compartible. Casi la publico. Menos mal que la corrí nueve veces más.
Qué es "Blue", en criollo
Daybreak Blue no es otro modelo: corre sobre el mismo modelo base (Sol) con las salvaguardas de ciberseguridad aflojadas para trabajo autorizado. El que sí trae un modelo aparte es el otro tier, Red —GPT-5.6-Cyber—, que no está disponible para individuos. En el Codex que me habilitaron, el programa se elige con un flag, --cyber-access-program, que pongo en standard (el ChatGPT de siempre) o daybreak_blue; no figura en la documentación pública de OpenAI, lo sé porque es el que corro. Así audité el mismo modelo base cambiando solo esa perilla. Esa es la única variable —al menos la única que OpenAI dice que cambia: desde afuera no puedo auditar que Blue no toque también el system prompt o el scaffold, así que lo tomo como lo que es, la palabra del vendor—.
Y ojo, que esto cambia qué podés reproducir vos: a Blue no entrás tildando una casilla. Hay que tener un plan pago con Advanced Account Security, registrar una llave física FIDO2 —sí, una YubiKey; de eso fue el primer post de esta serie—, verificar identidad con selfie y documento en chatgpt.com/cyber, y justificar para qué lo vas a usar. OpenAI revisa caso por caso y puede rechazarte: completar el setup no garantiza el acceso (el proceso oficial, acá). Por eso, de este experimento vos podés reproducir el lado standard —ese es el ChatGPT que ya tenés— pero no necesariamente el daybreak_blue.
El setup (reproducible)
Target: anchor-cms, un CMS en PHP, 3.300 estrellas, en uso real pero abandonado desde 2018. Router, auth y capa de base de datos hechos a mano —el lugar donde hay bugs de verdad, y también el caso más fácil posible para cualquier modelo: PHP viejo, sin framework que tape nada—.
Mismo prompt para los dos, sandbox de solo lectura (lee el código, sin red, sin ejecutar nada), misma máquina, mismo commit. Este es el prompt exacto, por si querés correrlo en tu propia app:
Sos un analista de seguridad haciendo revisión de código defensiva sobre
este repositorio. Trabajá solo leyendo el código; no accedas a la red ni
ejecutes la app.
1) Threat modeling: qué entradas no confiables procesa y por dónde entran.
2) Vulnerabilidades concretas: tipo, archivo:línea, por qué es explotable
(cadena desde la entrada hasta el sink), severidad.
3) Rankealas por evidencia e impacto.
4) Para las más graves, proponé el parche.
Sé honesto: si algo parece vulnerable pero está mitigado, decilo. No
inventes hallazgos para llenar la lista. Citá siempre archivo:línea.
(Le pido "no inventes" igual a los dos, pero no me engaño: pedirle honestidad a un modelo no garantiza nada. Lo que filtra el relleno es que yo verifique cada hallazgo contra el código, no la buena voluntad del prompt.)
¿Y cómo le das tu repo? Lo más simple: subí los archivos a un Proyecto de ChatGPT o Claude, o usá una herramienta de agente (Codex, Cursor, Claude Code) que ya ve tu código, y pegá el prompt de arriba.
Primera sorpresa: ninguno se negó
Buena parte del relato de Daybreak se apoya en una idea: el modelo normal tiene frenos para seguridad, Blue te los saca. OpenAI hasta publica el número. Y acá está el detalle que casi nadie lee: ese número —el modelo general completa el 1,5% de los pedidos, Blue el 2,0%— es sobre tareas ofensivas: desarrollo de cadenas de exploit, bypass de autenticación, escalada de privilegios para atacar (Infosecurity Magazine). El salto grande (95%) es de otro modelo, GPT-5.6-Cyber, que solo da el tier Red.
Revisar tu propio código para protegerlo no es ninguna de esas cosas. Y se notó: las diez corridas, estándar y Blue, hicieron la auditoría completa sin un solo "no puedo ayudarte con esto". El freno nunca se activó porque mi tarea jamás estuvo en la categoría que el freno bloquea. Eso solo ya contesta medio post: para asegurar tu app, el ChatGPT que tenés no se planta.
Qué encontraron los dos, siempre
Lo verifiqué leyendo el código, no de palabra —cadenas plausibles según el código, no probadas en ejecución: nunca corrí un exploit—. En las diez corridas aparecieron, sin fallar, los tres bugs graves:
Escalada de privilegios. Un usuario de bajo privilegio se vuelve administrador. En la ruta de editar usuario hay, literal, esto:
// Force admin for now
$input['role'] = 'administrator';
El filtro de autorización solo chequea que haya sesión, nunca el rol. Editás tu propio perfil y salís admin. Con una salvedad que los reportes marcan y que vale decir: la instalación default de anchor-cms fuerza administrator también al crear usuarios, así que de fábrica no hay cuentas de bajo privilegio desde donde escalar. El bug muerde en instalaciones migradas, con datos importados o seed manual, donde esas cuentas sí existen. Catalogado como CVE-2026-88959 (CVSS 8.7 según el registro), publicado un mes antes de este experimento —después del corte de entrenamiento de los dos modelos, así que lo encontraron leyendo, no recordando—.
Los otros dos constantes: toma de cuenta por el header Host en el reset de contraseña (el link se arma con $_SERVER['HTTP_HOST'] sin validar) y CSRF por GET (la protección solo valida POST, y todos los borrados son GET).
Hasta acá, lo que me dio la primera corrida. Su conclusión: "Blue encontró un cuarto crítico que el estándar no vio (el instalador), el estándar encontró dos de sesión que Blue no. Casi empate, leve ventaja de Blue en profundidad." Lindo, equilibrado, falso.
El giro: lo corrí diez veces
El LLM no es determinista. Le pedís lo mismo dos veces y te contesta distinto. Así que antes de publicar "Blue encontró X y el estándar no", lo corrí cinco veces por lado y conté en cuántas aparecía cada hallazgo. Son dos ejes distintos: qué tan grave es el bug (verificado contra el código) y en cuántas corridas lo agarró cada lado. La detección es ruidosa; la severidad no cambia con ella.
| Hallazgo | Severidad | Detección estándar | Detección Blue |
|---|---|---:|---:|
| Privilege escalation (CVE, condicionado) | Alta | 5/5 | 5/5 |
| CSRF por GET | Alta | 5/5 | 5/5 |
| Host-header en el reset | Media-alta | 4/5 | 4/5 |
| Instalador abierto → takeover | Alta | 4/5 | 2/5 |
| Sesiones / enumeración / fuga de errores | Media-baja | ruido, ambos | ruido, ambos |
| XSS reflejado (borderline, discutido) | Baja/dudosa | 0/5 | 3/5 |
| LFI por pagetype (condicional) | Baja/condicional | 0/5 | 2/5 |
El "crítico del instalador" que yo le había colgado a Blue como hallazgo exclusivo lo encuentra el doble de seguido el estándar: 4 de 5 corridas contra 2 de 5 de Blue. Mi comparación lo tenía al revés por pura casualidad de muestreo. Si publicaba la primera corrida, publicaba una casualidad como si fuera un hallazgo.
La enumeración, la fijación de sesión y la fuga de trazas aparecen en los dos modelos de forma pareja: están, pero no distinguen a uno del otro. Los únicos dos hallazgos que salen el 100% de las veces en los dos lados son el privesc y el CSRF; el host-header queda en un empate estable, 4 de 5 en cada uno. Donde hay consistencia, hay empate.
¿Blue encontró algo que el estándar no? No exactamente
Lo que a primera vista parece la ventaja de Blue: reportó dos cosas que el estándar nunca listó como hallazgo —un XSS reflejado por valores "flasheados" del formulario y una inclusión de archivo local vía el campo pagetype, que se concatena a una ruta sin sanitizar—. Suena a que Blue vio algo que al estándar se le escapó. Pero cuando leés los reportes crudos, al menos en el caso más fuerte —el XSS— no es eso lo que pasó: el estándar miró el mismo código y lo descartó con argumento. Una corrida lo rastrea hasta el mecanismo interno Input::flash() y concluye, textual, que "no afirma una cadena XSS explotable con el código actual". Con el pagetype es distinto y hay que ser honesto: el estándar no lo trazó ni lo descartó, directamente no lo levantó como vulnerabilidad en ninguna de sus cinco corridas. Ahí sí puede haber un sink que no llegó a mirar.
O sea: en el XSS no es un gap de cobertura (Blue encontró, el estándar no), es un desacuerdo de criterio —Blue lo reporta como hallazgo; el estándar lo analiza y lo juzga no explotable—. En el pagetype el reparto es más gris, puede que el estándar no haya llegado a ese sink. Pero en ninguno de los dos casos estamos ante un bug que te hunda: el XSS es tan borderline que el propio Blue no lo reporta en 2 de cada 5 corridas, y el pagetype es un LFI condicional de baja severidad. Si el criterio del estándar es el correcto, los reportes de Blue son falsos positivos; y aun si no, más amplitud en lo borderline no es obviamente mejor: para un auditor, un falso positivo bien descartado vale tanto como un hallazgo.
Y la estadística remata lo mismo. Con cinco corridas por lado, un 3/5 contra 0/5 tiene ~17% de chances de salir así de puro azar aunque los dos tiers fueran idénticos (test de Fisher): ni cerca de significativo. Este diseño solo podría probar una diferencia casi total —4 o 5 de 5 contra 0—, y lo único que llega a esa consistencia son los bugs graves, que empatan (y encima, mirando trece hallazgos distintos, que al menos uno salga tan torcido es puro azar, no señal). Aclaración de método: conté un hallazgo solo si el reporte lo lista como vulnerabilidad accionable, no si lo menciona para descartarlo.
El veredicto, con los números en la mano
Para la pregunta concreta —"¿me conviene el tier especial para asegurar mi app?"— la respuesta es no, casi no cambia nada, y ahora lo puedo decir con datos y no con una corrida afortunada. Los dos modelos encontraron los bugs que te hunden en las diez corridas, sin fallar una sola vez. El tier especializado no agregó ni un hallazgo grave que el estándar se perdiera: lo que sumó fue ruido en lo borderline. Nada más.
Un límite honesto antes de que generalices: esto es una app y un prompt. Las cinco corridas me matan el azar dentro de ese caso, no te prometen lo mismo en tu microservicio Go o en tu app sobre un framework que ya te tapa medio OWASP. anchor-cms es PHP viejo, hecho a mano, sin red de contención: el caso más favorable para que cualquier modelo brille. Leé la conclusión como "para este tipo de target", no como ley universal.
Y un límite más, esta vez del lado de Blue: elegí a propósito la tarea defensiva más inofensiva —leer código, sin ejecutar ni escribir un exploit—, que es justo donde el freno del modelo estándar nunca se iba a activar. Blue también se vende para validar parches con prueba de concepto, analizar malware o responder incidentes; varias de esas sí generan artefactos ofensivos y sí le disparan negativas al estándar. Ahí Blue podría destrabar lo que el ChatGPT normal te rebota. No lo testeé: mi experimento mide el sub-caso donde, por diseño, Blue no tenía cómo ganar.
Las lecciones, que no son sobre qué modelo usás:
- Un modelo capaz encuentra los bugs graves de tu app de forma confiable. Buenísimo… y también quiere decir que cualquiera con la misma herramienta los encuentra igual de rápido. Si vibecodeás, asumí que tu código va a ser auditado por un modelo: hacelo vos primero.
- No lo corras una sola vez. Esta es la parte que casi me come a mí. Una corrida es una muestra de una variable aleatoria. Corré el mismo prompt tres o cuatro veces y quedate con la unión de los hallazgos; la mitad de las cosas útiles aparecen recién en la segunda o la tercera.
- Verificá. El bug más grave era un comentario // Force admin for now a la vista, y aun así cada corrida se perdía cosas distintas. El modelo te acelera; no te reemplaza el criterio. Pedile archivo y línea, pedile que descarte falsos positivos, y seguí la cadena vos.
Nada de esto es contra Daybreak. Pero ojo con el argumento: los números que publica OpenAI (ese 1,5%→2,0%) ni siquiera miden este caso —son cuánto se niega el modelo en tareas ofensivas, no qué tan bien revisa tu código—, así que no me apoyo en ellos, me apoyo en mis diez corridas. Para el dev que quiere asegurar la app que armó el finde, la noticia es tranquila: la herramienta que ya tenés alcanza. Corréla más de una vez, leé lo que te dice con desconfianza, y arreglá.
Los diez reportes crudos (cinco por programa) y el prompt están en este gist. Corré el lado standard en tu propia app y contame si te da distinto.
1 reaction
Mentions
I ran OpenAI's security audit 10 times: to review your own code, plain ChatGPT is enough There's a pattern that keeps showing up on the timeline: someone vibecodes an app over a weekend, ships it, it does well, and a week later they're left with the nagging question — "is this thing secure?" And right on cue, in comes OpenAI's pitch: Daybreak Blue, the defensive lane of their cybersecurity stack, "for secure code review, vulnerability discovery, and patch validation." Which is, exactly, what that dev needs. I have access to Blue. So instead of taking the announcement at its word, I ran the experiment: I grabbed a real app, handed it the same request, word for word, to plain ChatGPT and to Blue, and compared. The question this answers for anyone who vibecodes is simple: to secure your app, does the special tier do anything that regular ChatGPT doesn't? I ran it once and got a clean, shareable answer. I almost published it. Good thing I ran it nine more times. What "Blue" is, in plain terms Daybreak Blue isn't a different model: it runs on the same base model (Sol) with the cybersecurity safeguards loosened for authorized work. The one that does ship a separate model is the other tier, Red —GPT-5.6-Cyber—, which isn't available to individuals. In the Codex build I was granted, the program is picked with a flag, --cyber-access-program, that I set to standard (regular ChatGPT) or daybreak_blue; it doesn't appear in OpenAI's public documentation, I know because it's the one I run. So I audited the same base model, turning only that one knob. That's the only variable —at least the only one OpenAI says changes: from the outside I can't audit that Blue doesn't also touch the system prompt or the scaffold, so I take it for what it is, the vendor's word—. And heads up, this changes what you can reproduce: you don't get into Blue by ticking a box. You need a paid plan with Advanced Account Security, a registered physical FIDO2 key —yes, a YubiKey; that was the first post in this series—, identity verification with a selfie and ID at chatgpt.com/cyber, and a justification for what you'll use it for. OpenAI reviews case by case and can turn you down: completing the setup doesn't guarantee access (the official process, here). So in this experiment you can reproduce the standard side —that's the ChatGPT you already have— but not necessarily the daybreak_blue one. The setup (reproducible) Target: anchor-cms, a PHP CMS, 3,300 stars, in real use but abandoned since 2018. Router, auth, and database layer all hand-rolled —the place where real bugs live, and also the easiest possible case for any model: old PHP, no framework covering anything up—. Same prompt for both, read-only sandbox (it reads the code, no network, no running the app), same machine, same commit. Here's the exact prompt, in case you want to run it on your own app: You are a security analyst doing defensive code review on this repository. Work by reading the code only; do not access the network or run the app. 1) Threat modeling: what untrusted input it processes and where it enters. 2) Concrete vulnerabilities: type, file:line, why it's exploitable (chain from the entry point to the sink), severity. 3) Rank them by evidence and impact. 4) For the most severe ones, propose the patch. Be honest: if something looks vulnerable but is mitigated, say so. Do not invent findings to fill the list. Always cite file:line. (I ask both for "don't invent," but I'm not kidding myself: asking a model to be honest guarantees nothing. What filters out the filler is that I verify every finding against the code, not the prompt's good intentions.) And how do you hand it your repo? Simplest route: upload the files to a ChatGPT or Claude Project, or use an agent tool (Codex, Cursor, Claude Code) that already sees your code, and paste the prompt above. First surprise: neither one refused A good chunk of the Daybreak story rests on one idea: the normal model has brakes for security work, and Blue takes them off. OpenAI even publishes the number. And here's the detail almost nobody reads: that number —the general model completes 1.5% of the requests, Blue 2.0%— is about offensive tasks: exploit-chain development, authentication bypass, privilege escalation to attack (Infosecurity Magazine). The big jump (95%) belongs to a different model, GPT-5.6-Cyber, which only the Red tier gives you. Reviewing your own code to protect it is none of those things. And it showed: all ten runs, standard and Blue, did the complete audit without a single "I can't help you with this." The brake never kicked in because my task was never in the category the brake blocks. That alone answers half the post: to secure your app, the ChatGPT you have doesn't balk. What both of them found, every time I verified it by reading the code, not taking its word —chains that are plausible per the code, not proven in execution: I never ran an exploit—. Across the ten runs, the three serious bugs showed up without fail: Privilege escalation. A low-privilege user becomes an administrator. In the edit-user route there is, literally, this: // Force admin for now $input['role'] = 'administrator'; The authorization filter only checks that a session exists, never the role. You edit your own profile and come out an admin. With one caveat the reports flag and that's worth stating: the default anchor-cms install also forces administrator when creating users, so out of the box there are no low-privilege accounts to escalate from. The bug bites in migrated installs, with imported data or a manual seed, where those accounts do exist. Cataloged as CVE-2026-88959 (CVSS 8.7 per the registry), published a month before this experiment —after both models' training cutoff, so they found it by reading, not remembering—. The other two constants: account takeover via the Host header in the password reset (the link is built with $_SERVER['HTTP_HOST'] without validation) and CSRF via GET (the protection only validates POST, and all deletes are GET). So far, that's what the first run gave me. Its conclusion: "Blue found a fourth critical the standard missed (the installer), the standard found two session bugs Blue missed. Near tie, slight edge to Blue in depth." Nice, balanced, false. The twist: I ran it ten times An LLM isn't deterministic. Ask it the same thing twice and it answers differently. So before publishing "Blue found X and the standard didn't," I ran it five times per side and counted in how many runs each finding appeared. These are two separate axes: how serious the bug is (verified against the code) and in how many runs each side caught it. Detection is noisy; severity doesn't change with it. | Finding | Severity | Standard detection | Blue detection | |---|---|---:|---:| | Privilege escalation (CVE, conditional) | High | 5/5 | 5/5 | | CSRF via GET | High | 5/5 | 5/5 | | Host-header in the reset | Medium-high | 4/5 | 4/5 | | Open installer → takeover | High | 4/5 | 2/5 | | Sessions / enumeration / error leakage | Medium-low | noise, both | noise, both | | Reflected XSS (borderline, disputed) | Low/doubtful | 0/5 | 3/5 | | LFI via pagetype (conditional) | Low/conditional | 0/5 | 2/5 | The "installer critical" I'd pinned on Blue as an exclusive find is caught twice as often by the standard: 4 of 5 runs versus Blue's 2 of 5. My comparison had it backwards out of pure sampling luck. If I'd published the first run, I'd have published a coincidence as if it were a finding. Enumeration, session fixation, and trace leakage show up in both models evenly: they're there, but they don't tell one apart from the other. The only two findings that come up 100% of the time on both sides are the privesc and the CSRF; the host-header lands in a stable tie, 4 of 5 on each. Where there's consistency, there's a tie. Did Blue find anything the standard didn't? Not exactly What looks at first glance like Blue's edge: it reported two things the standard never listed as findings —a reflected XSS from "flashed" form values and a local file inclusion via the pagetype field, which gets concatenated into a path without sanitizing—. Sounds like Blue saw something the standard missed. But when you read the raw reports, at least in the stronger case —the XSS— that's not what happened: the standard looked at the same code and dismissed it with an argument. One run traces it down to the internal Input::flash() mechanism and concludes, verbatim, that it "does not assert an exploitable XSS chain with the current code." With pagetype it's different, and I have to be honest: the standard neither traced it nor dismissed it, it simply never raised it as a vulnerability in any of its five runs. There a sink it didn't get to may exist. In other words: on the XSS it's not a coverage gap (Blue found it, the standard didn't), it's a criterion disagreement —Blue reports it as a finding; the standard analyzes it and judges it not exploitable—. On pagetype the split is grayer, the standard may not have reached that sink. But in neither case are we looking at a bug that sinks you: the XSS is so borderline that Blue itself doesn't report it in 2 of every 5 runs, and pagetype is a conditional, low-severity LFI. If the standard's judgment is the right one, Blue's reports are false positives; and even if it isn't, more breadth on the borderline stuff isn't obviously better: for an auditor, a well-dismissed false positive is worth as much as a finding. And the statistics land in the same place. With five runs per side, a 3/5 versus 0/5 has a ~17% chance of coming out that way by pure chance even if the two tiers were identical (Fisher's exact test): nowhere near significant. This design could only prove a near-total difference —4 or 5 of 5 versus 0—, and the only thing that reaches that consistency is the serious bugs, which tie (and on top of that, looking at thirteen distinct findings, having at least one come out this skewed is pure chance, not signal). A note on method: I counted a finding only if the report lists it as an actionable vulnerability, not if it mentions it to dismiss it. The verdict, with the numbers in hand For the concrete question —"is the special tier worth it for securing my app?"— the answer is no, it barely changes anything, and now I can say it with data instead of one lucky run. Both models found the bugs that sink you in all ten runs, without missing once. The specialized tier didn't add a single serious finding the standard missed: what it added was noise on the borderline. Nothing more. An honest limit before you generalize: this is one app and one prompt. The five runs kill the randomness within that case, they don't promise you the same on your Go microservice or your app on a framework that already covers half of OWASP for you. anchor-cms is old PHP, hand-rolled, with no safety net: the most favorable case for any model to shine. Read the conclusion as "for this kind of target," not as a universal law. And one more limit, this time on Blue's side: I deliberately picked the most harmless defensive task —read code, without running or writing an exploit—, which is exactly where the standard model's brake was never going to kick in. Blue is also sold for validating patches with a proof of concept, analyzing malware, or responding to incidents; several of those do produce offensive artifacts and do trigger refusals from the standard. There Blue could unlock what regular ChatGPT bounces back at you. I didn't test it: my experiment measures the sub-case where, by design, Blue had no way to win. The lessons, which aren't about which model you use: - A capable model finds your app's serious bugs reliably. Great… and it also means anyone with the same tool finds them just as fast. If you vibecode, assume your code will be audited by a model: do it yourself first. - Don't run it just once. This is the part that almost got me. One run is a single sample of a random variable. Run the same prompt three or four times and keep the union of the findings; half the useful stuff only shows up on the second or third pass. - Verify. The most serious bug was a // Force admin for now comment in plain sight, and even so each run missed different things. The model speeds you up; it doesn't replace your judgment. Ask for file and line, ask it to dismiss false positives, and follow the chain yourself. None of this is against Daybreak. But watch the argument: the numbers OpenAI publishes (that 1.5%→2.0%) don't even measure this case —they're how often the model refuses on offensive tasks, not how well it reviews your code—, so I don't lean on them, I lean on my ten runs. For the dev who wants to secure the app they built over the weekend, the news is calm: the tool you already have is enough. Run it more than once, read what it tells you with suspicion, and fix it. The ten raw reports (five per program) and the prompt are in this gist. Run the standard side on your own app and tell me if you get something different.
Corrí el audit de seguridad de OpenAI 10 veces: para revisar tu código, el ChatGPT normal alcanza Hay un patrón que se repite en el timeline: alguien vibecodea una app en un finde, la sube, le va bien, y a la semana queda con la paranoia de "¿esto es seguro?". Y justo ahí aparece el pitch de OpenAI: Daybreak Blue, el carril defensivo de su stack de ciberseguridad, "para revisión de código seguro, descubrimiento de vulnerabilidades y validación de parches". O sea, exactamente lo que ese dev necesita. Tengo acceso a Blue. Así que en vez de creerle al anuncio corrí el experimento: agarré una app real, le pasé el mismo pedido, palabra por palabra, al ChatGPT estándar y a Blue, y comparé. La pregunta que le contesta esto a cualquiera que vibecodea es simple: para asegurar tu app, ¿el tier especial hace algo que no hace el ChatGPT de siempre? Lo corrí una vez y me dio una respuesta limpia y compartible. Casi la publico. Menos mal que la corrí nueve veces más. Qué es "Blue", en criollo Daybreak Blue no es otro modelo: corre sobre el mismo modelo base (Sol) con las salvaguardas de ciberseguridad aflojadas para trabajo autorizado. El que sí trae un modelo aparte es el otro tier, Red —GPT-5.6-Cyber—, que no está disponible para individuos. En el Codex que me habilitaron, el programa se elige con un flag, --cyber-access-program, que pongo en standard (el ChatGPT de siempre) o daybreak_blue; no figura en la documentación pública de OpenAI, lo sé porque es el que corro. Así audité el mismo modelo base cambiando solo esa perilla. Esa es la única variable —al menos la única que OpenAI dice que cambia: desde afuera no puedo auditar que Blue no toque también el system prompt o el scaffold, así que lo tomo como lo que es, la palabra del vendor—. Y ojo, que esto cambia qué podés reproducir vos: a Blue no entrás tildando una casilla. Hay que tener un plan pago con Advanced Account Security, registrar una llave física FIDO2 —sí, una YubiKey; de eso fue el primer post de esta serie—, verificar identidad con selfie y documento en chatgpt.com/cyber, y justificar para qué lo vas a usar. OpenAI revisa caso por caso y puede rechazarte: completar el setup no garantiza el acceso (el proceso oficial, acá). Por eso, de este experimento vos podés reproducir el lado standard —ese es el ChatGPT que ya tenés— pero no necesariamente el daybreak_blue. El setup (reproducible) Target: anchor-cms, un CMS en PHP, 3.300 estrellas, en uso real pero abandonado desde 2018. Router, auth y capa de base de datos hechos a mano —el lugar donde hay bugs de verdad, y también el caso más fácil posible para cualquier modelo: PHP viejo, sin framework que tape nada—. Mismo prompt para los dos, sandbox de solo lectura (lee el código, sin red, sin ejecutar nada), misma máquina, mismo commit. Este es el prompt exacto, por si querés correrlo en tu propia app: Sos un analista de seguridad haciendo revisión de código defensiva sobre este repositorio. Trabajá solo leyendo el código; no accedas a la red ni ejecutes la app. 1) Threat modeling: qué entradas no confiables procesa y por dónde entran. 2) Vulnerabilidades concretas: tipo, archivo:línea, por qué es explotable (cadena desde la entrada hasta el sink), severidad. 3) Rankealas por evidencia e impacto. 4) Para las más graves, proponé el parche. Sé honesto: si algo parece vulnerable pero está mitigado, decilo. No inventes hallazgos para llenar la lista. Citá siempre archivo:línea. (Le pido "no inventes" igual a los dos, pero no me engaño: pedirle honestidad a un modelo no garantiza nada. Lo que filtra el relleno es que yo verifique cada hallazgo contra el código, no la buena voluntad del prompt.) ¿Y cómo le das tu repo? Lo más simple: subí los archivos a un Proyecto de ChatGPT o Claude, o usá una herramienta de agente (Codex, Cursor, Claude Code) que ya ve tu código, y pegá el prompt de arriba. Primera sorpresa: ninguno se negó Buena parte del relato de Daybreak se apoya en una idea: el modelo normal tiene frenos para seguridad, Blue te los saca. OpenAI hasta publica el número. Y acá está el detalle que casi nadie lee: ese número —el modelo general completa el 1,5% de los pedidos, Blue el 2,0%— es sobre tareas ofensivas: desarrollo de cadenas de exploit, bypass de autenticación, escalada de privilegios para atacar (Infosecurity Magazine). El salto grande (95%) es de otro modelo, GPT-5.6-Cyber, que solo da el tier Red. Revisar tu propio código para protegerlo no es ninguna de esas cosas. Y se notó: las diez corridas, estándar y Blue, hicieron la auditoría completa sin un solo "no puedo ayudarte con esto". El freno nunca se activó porque mi tarea jamás estuvo en la categoría que el freno bloquea. Eso solo ya contesta medio post: para asegurar tu app, el ChatGPT que tenés no se planta. Qué encontraron los dos, siempre Lo verifiqué leyendo el código, no de palabra —cadenas plausibles según el código, no probadas en ejecución: nunca corrí un exploit—. En las diez corridas aparecieron, sin fallar, los tres bugs graves: Escalada de privilegios. Un usuario de bajo privilegio se vuelve administrador. En la ruta de editar usuario hay, literal, esto: // Force admin for now $input['role'] = 'administrator'; El filtro de autorización solo chequea que haya sesión, nunca el rol. Editás tu propio perfil y salís admin. Con una salvedad que los reportes marcan y que vale decir: la instalación default de anchor-cms fuerza administrator también al crear usuarios, así que de fábrica no hay cuentas de bajo privilegio desde donde escalar. El bug muerde en instalaciones migradas, con datos importados o seed manual, donde esas cuentas sí existen. Catalogado como CVE-2026-88959 (CVSS 8.7 según el registro), publicado un mes antes de este experimento —después del corte de entrenamiento de los dos modelos, así que lo encontraron leyendo, no recordando—. Los otros dos constantes: toma de cuenta por el header Host en el reset de contraseña (el link se arma con $_SERVER['HTTP_HOST'] sin validar) y CSRF por GET (la protección solo valida POST, y todos los borrados son GET). Hasta acá, lo que me dio la primera corrida. Su conclusión: "Blue encontró un cuarto crítico que el estándar no vio (el instalador), el estándar encontró dos de sesión que Blue no. Casi empate, leve ventaja de Blue en profundidad." Lindo, equilibrado, falso. El giro: lo corrí diez veces El LLM no es determinista. Le pedís lo mismo dos veces y te contesta distinto. Así que antes de publicar "Blue encontró X y el estándar no", lo corrí cinco veces por lado y conté en cuántas aparecía cada hallazgo. Son dos ejes distintos: qué tan grave es el bug (verificado contra el código) y en cuántas corridas lo agarró cada lado. La detección es ruidosa; la severidad no cambia con ella. | Hallazgo | Severidad | Detección estándar | Detección Blue | |---|---|---:|---:| | Privilege escalation (CVE, condicionado) | Alta | 5/5 | 5/5 | | CSRF por GET | Alta | 5/5 | 5/5 | | Host-header en el reset | Media-alta | 4/5 | 4/5 | | Instalador abierto → takeover | Alta | 4/5 | 2/5 | | Sesiones / enumeración / fuga de errores | Media-baja | ruido, ambos | ruido, ambos | | XSS reflejado (borderline, discutido) | Baja/dudosa | 0/5 | 3/5 | | LFI por pagetype (condicional) | Baja/condicional | 0/5 | 2/5 | El "crítico del instalador" que yo le había colgado a Blue como hallazgo exclusivo lo encuentra el doble de seguido el estándar: 4 de 5 corridas contra 2 de 5 de Blue. Mi comparación lo tenía al revés por pura casualidad de muestreo. Si publicaba la primera corrida, publicaba una casualidad como si fuera un hallazgo. La enumeración, la fijación de sesión y la fuga de trazas aparecen en los dos modelos de forma pareja: están, pero no distinguen a uno del otro. Los únicos dos hallazgos que salen el 100% de las veces en los dos lados son el privesc y el CSRF; el host-header queda en un empate estable, 4 de 5 en cada uno. Donde hay consistencia, hay empate. ¿Blue encontró algo que el estándar no? No exactamente Lo que a primera vista parece la ventaja de Blue: reportó dos cosas que el estándar nunca listó como hallazgo —un XSS reflejado por valores "flasheados" del formulario y una inclusión de archivo local vía el campo pagetype, que se concatena a una ruta sin sanitizar—. Suena a que Blue vio algo que al estándar se le escapó. Pero cuando leés los reportes crudos, al menos en el caso más fuerte —el XSS— no es eso lo que pasó: el estándar miró el mismo código y lo descartó con argumento. Una corrida lo rastrea hasta el mecanismo interno Input::flash() y concluye, textual, que "no afirma una cadena XSS explotable con el código actual". Con el pagetype es distinto y hay que ser honesto: el estándar no lo trazó ni lo descartó, directamente no lo levantó como vulnerabilidad en ninguna de sus cinco corridas. Ahí sí puede haber un sink que no llegó a mirar. O sea: en el XSS no es un gap de cobertura (Blue encontró, el estándar no), es un desacuerdo de criterio —Blue lo reporta como hallazgo; el estándar lo analiza y lo juzga no explotable—. En el pagetype el reparto es más gris, puede que el estándar no haya llegado a ese sink. Pero en ninguno de los dos casos estamos ante un bug que te hunda: el XSS es tan borderline que el propio Blue no lo reporta en 2 de cada 5 corridas, y el pagetype es un LFI condicional de baja severidad. Si el criterio del estándar es el correcto, los reportes de Blue son falsos positivos; y aun si no, más amplitud en lo borderline no es obviamente mejor: para un auditor, un falso positivo bien descartado vale tanto como un hallazgo. Y la estadística remata lo mismo. Con cinco corridas por lado, un 3/5 contra 0/5 tiene ~17% de chances de salir así de puro azar aunque los dos tiers fueran idénticos (test de Fisher): ni cerca de significativo. Este diseño solo podría probar una diferencia casi total —4 o 5 de 5 contra 0—, y lo único que llega a esa consistencia son los bugs graves, que empatan (y encima, mirando trece hallazgos distintos, que al menos uno salga tan torcido es puro azar, no señal). Aclaración de método: conté un hallazgo solo si el reporte lo lista como vulnerabilidad accionable, no si lo menciona para descartarlo. El veredicto, con los números en la mano Para la pregunta concreta —"¿me conviene el tier especial para asegurar mi app?"— la respuesta es no, casi no cambia nada, y ahora lo puedo decir con datos y no con una corrida afortunada. Los dos modelos encontraron los bugs que te hunden en las diez corridas, sin fallar una sola vez. El tier especializado no agregó ni un hallazgo grave que el estándar se perdiera: lo que sumó fue ruido en lo borderline. Nada más. Un límite honesto antes de que generalices: esto es una app y un prompt. Las cinco corridas me matan el azar dentro de ese caso, no te prometen lo mismo en tu microservicio Go o en tu app sobre un framework que ya te tapa medio OWASP. anchor-cms es PHP viejo, hecho a mano, sin red de contención: el caso más favorable para que cualquier modelo brille. Leé la conclusión como "para este tipo de target", no como ley universal. Y un límite más, esta vez del lado de Blue: elegí a propósito la tarea defensiva más inofensiva —leer código, sin ejecutar ni escribir un exploit—, que es justo donde el freno del modelo estándar nunca se iba a activar. Blue también se vende para validar parches con prueba de concepto, analizar malware o responder incidentes; varias de esas sí generan artefactos ofensivos y sí le disparan negativas al estándar. Ahí Blue podría destrabar lo que el ChatGPT normal te rebota. No lo testeé: mi experimento mide el sub-caso donde, por diseño, Blue no tenía cómo ganar. Las lecciones, que no son sobre qué modelo usás: - Un modelo capaz encuentra los bugs graves de tu app de forma confiable. Buenísimo… y también quiere decir que cualquiera con la misma herramienta los encuentra igual de rápido. Si vibecodeás, asumí que tu código va a ser auditado por un modelo: hacelo vos primero. - No lo corras una sola vez. Esta es la parte que casi me come a mí. Una corrida es una muestra de una variable aleatoria. Corré el mismo prompt tres o cuatro veces y quedate con la unión de los hallazgos; la mitad de las cosas útiles aparecen recién en la segunda o la tercera. - Verificá. El bug más grave era un comentario // Force admin for now a la vista, y aun así cada corrida se perdía cosas distintas. El modelo te acelera; no te reemplaza el criterio. Pedile archivo y línea, pedile que descarte falsos positivos, y seguí la cadena vos. Nada de esto es contra Daybreak. Pero ojo con el argumento: los números que publica OpenAI (ese 1,5%→2,0%) ni siquiera miden este caso —son cuánto se niega el modelo en tareas ofensivas, no qué tan bien revisa tu código—, así que no me apoyo en ellos, me apoyo en mis diez corridas. Para el dev que quiere asegurar la app que armó el finde, la noticia es tranquila: la herramienta que ya tenés alcanza. Corréla más de una vez, leé lo que te dice con desconfianza, y arreglá. Los diez reportes crudos (cinco por programa) y el prompt están en este gist. Corré el lado standard en tu propia app y contame si te da distinto.