La semana pasada pasaron dos cosas con unas cuarenta y ocho horas de diferencia, y lo único que impidió que se leyeran como una sola noticia es que salieron de gabinetes de prensa distintos.
El 1 de septiembre OpenAI dijo en voz alta que GPT-6 Astra es el primer modelo que ha construido que llega a Crítico en el eje de ciberseguridad de su propio Preparedness Framework. No Alto. Crítico — el tope de la escala, el nivel que ese documento se escribió para describir y que hasta ahora nunca había tenido que usar.
Al día siguiente Google sacó Gemini 3.8 Flash Cyber, el hermano especializado en seguridad de su nuevo Flash, y lo metió detrás de un programa de acceso llamado Fairwind que la semana anterior no existía.
Misma semana, misma forma. Un modelo que encuentra fallos de verdad en código de verdad, y una puerta con portero.
La cobertura se fue casi entera a la capacidad, que es la mitad alarmante y me parece justo. Yo quiero hablar de la puerta.
Lo que compró el nivel Crítico
El número de OpenAI: sobre un benchmark interno montado con veinte vulnerabilidades de severidad alta del motor V8 de Google, Astra no se limitó a reencontrar las conocidas. Sacó dos que no estaban en el conjunto, las encadenó, se escapó del sandbox y ejecutó comandos en la máquina anfitriona. Sin que nadie le fuera llevando paso a paso. En los benchmarks publicados sacó un 100% en ExploitBench y llegó ahí bastante más eficiente en tokens que GPT-5.6 Sol.
El número de Google es menos cinematográfico y, si te ganas la vida escribiendo código, más interesante: en pruebas de seguridad sobre Chrome, Flash Cyber produjo 2,6 veces más parches correctos que el mejor modelo comercial que evaluaron, con tasas internas de acierto por encima del 70% en veinte lenguajes. No «encontró un fallo que da miedo» — arregló fallos, a un ritmo que aguanta una revisión.
Esa diferencia de encuadre te dice que las dos empresas leen la misma capacidad de forma distinta. OpenAI ha sacado algo que le da miedo. Google ha sacado algo que quiere venderle a los defensores. Las dos tienen razón.
Y el matiz que se cae de casi todos los resúmenes: las cifras de titular de Astra son Astra con acceso Daybreak, no el modelo de tu desplegable. Lo que le llega a una API key normal está limitado a revisión de código y parcheo, y se niega a escribir pruebas de concepto. Así que ese 100% pertenece a una configuración que casi seguro no tienes.
Dos puertas, un mismo diseño
Capas, básicamente.
OpenAI lo parte en dos. Daybreak Blue es el nivel defensivo aburrido sobre los modelos de siempre: revisión de código, triaje de vulnerabilidades, validación de parches. Daybreak Red es donde viven los modelos ciber especializados — pruebas de concepto, pentesting, red teaming — detrás de una aprobación aparte y más estricta. La capacidad ofensiva de nivel Crítico arranca con un grupo alfa descrito como organizaciones responsables de proteger infraestructura digital crítica (el gobierno de EE. UU., socios que ya estaban dentro) antes de abrirse a Blue, que ahora mismo se lee como la cola de acreditaciones de un congreso de vendors: Accenture, IBM, CrowdStrike, Cisco, Sophos, Cloudflare.
Fairwind es una sola puerta con una lista más larga de quién puede llamar: gobiernos y autoridades nacionales de ciberseguridad, operadores de infraestructura crítica, plataformas tecnológicas de base, mantenedores de software ampliamente usado, laboratorios académicos que hacen benchmarking defensivo. Google dice que ya hay más de 650 organizaciones dentro.
Y luego los controles. Esta es la parte que yo imprimiría. Para tener acceso Fairwind pasas verificación de antecedentes, pones autenticación a nivel de usuario con MFA resistente a phishing por delante, restringes el uso a tus equipos internos de ciberseguridad, respuesta a incidentes o pentesting, registras qué empleados lo tocan y para qué, y no lo compartes, redistribuyes ni revendes.
Léelo como mantenedor.
«Restringe el acceso a tu equipo interno de respuesta a incidentes»
Yo soy el equipo interno de respuesta a incidentes. También soy el equipo de pentesting, el revisor y el que le da a merge. Y no es un chiste sobre ir con lo justo: eso es buena parte del árbol de dependencias que desplegaste el martes pasado.
Los dos programas nombran explícitamente a los mantenedores de open source, y lo dicen en serio. OpenAI ha puesto mil millones de dólares detrás de Daybreak for Frontline Defenders, que lista a los mantenedores junto a potabilizadoras, ayuntamientos y ONG sin recursos, con acceso subvencionado y formación de verdad. Google da prioridad a los mantenedores de software ampliamente usado. Nadie se ha olvidado de nosotros, y quiero dejarlo por escrito, porque la versión perezosa de este post es «los laboratorios grandes ignoran el open source» y esta vez no es verdad.
Pero una elegibilidad escrita como lista de controles es un filtro con forma, y la forma es tener un departamento de cumplimiento. Una verificación de antecedentes es algo que una empresa le hace a un empleado. «Restringe el acceso al equipo X» presupone un organigrama con más de una casilla. Registrar accesos presupone que alguien revisa el registro. Nada de eso es hostil. Todo eso lo ha escrito gente que solo ha aprovisionado software a empresas.
El proyecto de una persona del que dependen cincuenta mil builds es elegible sobre el papel y, en la práctica, tiene que convertirse en una institución durante un fin de semana para rellenar el formulario. Alguno lo hará. La mayoría no, por lo mismo por lo que la mayoría nunca llegó a generar el SBOM.
Y «ampliamente usado» está aguantando ahí un peso enorme sin hacer ruido. Todas las dependencias que reventaron en la última década eran, el día antes, no obviamente ampliamente usadas.
El bucle que lo vuelve de verdad irritante
Esto es lo que lo lleva de «una pena» a «espera un momento».
Los mantenedores ya reciben la salida de estos modelos. En volumen.
Daniel Stenberg cerró el bug bounty de curl en enero porque se ahogaba en slop generado por IA: informes seguros de sí mismos, detallados y completamente inventados. Esa mitad se contó mucho. La segunda se contó menos. Los modelos mejoraron. Los informes dejaron de ser falsos. Stenberg le atribuye hoy a las herramientas asistidas por IA más de cien correcciones reales en curl — fallos que habían sobrevivido a años de fuzzing, sanitizers, análisis estático y auditorías humanas pagadas.
Y el ritmo pasó de un informe asistido por IA a la semana a uno cada dieciocho horas. Su propia preocupación es la correcta: una avalancha de informes buenos sigue siendo una avalancha, y ningún proyecto ha recibido mantenedores extra para absorberla.
O sea que el mantenedor ya está aguas abajo de la capacidad. Cualquier desconocido con una API key está pasando algo por su código y escribiendo el informe. La lista de acceso no cambia eso — nunca gobernó la dirección de entrada. Lo que gobierna es si el mantenedor puede pasar la misma clase de herramienta por su propio árbol primero, un domingo, y meter los arreglos antes de que llegue la cola.
Eso es lo que se me queda del revés. No «herramienta peligrosa bajo llave». Bajo llave solo en el lado que recibe.
La asimetría de la que no se sale cerrando puertas
La defensa honesta de una lista de acceso es que sube el suelo de esfuerzo. Y lo sube. Prefiero que exista a que no: un generador de cadenas de exploit de frontera en el plan gratuito sería sencillamente idiota.
Pero cerrar protege la mejor herramienta, y el ataque no necesita la mejor herramienta. Nadie necesita un 100% en ExploitBench. Necesitas un fallo, en una cosa, que un objetivo concreto ejecute de verdad. El segundo mejor, el tercero, un modelo de pesos abiertos seis meses por detrás y sin formularios de por medio: eso es una tarde perfectamente aprovechable para cualquiera con malas intenciones y sin prisa.
Es la defensa la que necesita el techo, porque la defensa tiene que cubrirlo todo. Lo que significa que una lista de acceso empuja la asimetría en la dirección equivocada por construcción, y todo el mundo lo sabe, y no hay una respuesta mejor evidente, que es la razón por la que este post no termina con una.
Por cierto, dos personas de la propia órbita de OpenAI dijeron las partes incómodas en voz alta. Yona Shavit preguntó públicamente si el buen comportamiento de Astra durante las evaluaciones venía de que el modelo sabía qué se esperaba de él. Steven Adler señaló que el Preparedness Framework actualizado ha dejado discretamente de exigir pruebas de seguridad sobre modelos afinados. Ninguna de las dos es un «te pillé». Las dos son el tipo de pregunta que quieres que haga alguien a quien no le pagan por hacerla.
Y el reloj sigue corriendo
Una cosa más y lo dejo.
Hace cuatro días escribí sobre el reloj de veinticuatro horas del CRA — el trozo del Reglamento de Ciberresiliencia que dice que si una vulnerabilidad de tu producto se está explotando activamente tienes un día para contarlo, por un formulario web, a partir del día 11.
Mismo mantenedor. Misma semana. Obligado por ley a triar y notificar en veinticuatro horas; fuera del perímetro de verificación de la herramienta que le ayudaría a hacerlo. Nadie diseñó eso. Dos procesos perfectamente razonables, redactados en edificios distintos, aterrizando sobre la misma persona cansada con nueve días de diferencia.
En fin
La capacidad es real y la disciplina de publicación me parece defendible. Yo también la habría cerrado, y no tengo un mecanismo mejor que ofrecer.
Lo que me gustaría es que alguien se diera cuenta de que «los mantenedores de open source son elegibles» y «los mantenedores de open source pueden entrar de verdad» son dos frases distintas, y que todo lo que hay entre ellas está hecho de controles que dan por supuesto un empleador. Una vía de aval a través de una fundación que ya existe. Algo que pueda pasar una persona. Cualquier cosa que no exija una política de verificación de antecedentes gestionada por la propia persona a la que hay que verificar.
Mientras tanto: tus dependencias se están escaneando con herramientas mejores que las que sus mantenedores tienen permiso para ejecutar. Ese es el estado del arte de esta semana.
Vete a leer algo que mantengas. No va a venir nadie.
Comentarios