La IA encuentra los agujeros más rápido

El 4 de noviembre, OpenAI describió una campaña de agentes de IA contra el kernel de Linux, el software que sostiene los teléfonos Android, la infraestructura en la nube y los superordenadores. Durante unos diez días a partir de mediados de octubre, los agentes produjeron exploits funcionales para 948 fallos distintos, cada uno de los cuales podía convertir una cuenta de usuario normal en el control total de una máquina, y escribieron un parche candidato para cada uno. Una semana antes, Google anunció Gemini 4 Carbon y lo entregó primero a ciberdefensores verificados. El tiempo que pasa entre que existe un fallo y alguien lo encuentra se está reduciendo, y los laboratorios quieren que los defensores lleguen antes.

Qué ejecutó OpenAI

El pipeline tenía cinco etapas y funcionaba con un modelo de ciberseguridad que OpenAI lanzó el 5 de noviembre como GPT-6 Cyber. Agentes exploradores seleccionaron 5'034 partes del kernel que merecía la pena auditar, alrededor del 7 por ciento de su código. Agentes analistas las convirtieron en 2'308 hallazgos candidatos en 12 horas. Agentes de triaje intentaron reproducir cada uno en una máquina aislada y lo consiguieron con 1'724, unas tres cuartas partes, y OpenAI dice que solo el 3,1 por ciento de los hallazgos se basaba en un análisis erróneo. Etapas posteriores comprobaron qué fallos podían explotarse y escribieron parches, y varias personas revisaron los resultados antes de que se notificara nada.

La campaña costó 1'213'430 dólares en créditos de API, unos 1'279 dólares por exploit. Los objetivos ejecutaban un Linux de escritorio estándar con sus protecciones habituales activadas. Una campaña en julio con un modelo anterior, GPT-5.6 Sol, había encontrado 166 fallos de este tipo. El modelo nuevo encontró más de cinco veces más, aunque el kernel se había reforzado durante los tres meses intermedios.

Lo que dicen los laboratorios sobre los límites

OpenAI es franca sobre lo que salió mal. En una de las primeras campañas, el pipeline notificó 200 exploits con éxito, y la revisión humana descubrió que 20 de ellos habían logrado el control total a través de un fallo desconocido distinto del que tenían asignado. «Esto sugiere que incluso la explotación con éxito por parte de agentes necesita una validación adecuada», escribió OpenAI, y añadió una comprobación independiente de que cada exploit usaba el fallo asignado. Su lección vale para cualquier trabajo automatizado: «verificar el camino hacia un resultado, además de verificar el resultado en sí».

Los parches también necesitaron trabajo. Los primeros funcionaban, pero a veces añadían código innecesario, ignoraban las convenciones locales o pasaban por alto variantes del mismo fallo, hasta que más instrucciones e iteraciones los mejoraron. OpenAI considera sus cifras de coste «más bien un límite superior». Todas estas cifras son de la propia OpenAI. A 5 de noviembre no habíamos encontrado ninguna auditoría independiente de ellas ni ninguna declaración pública de los mantenedores del kernel sobre este lote.

Primero los defensores

El anuncio de Google del 28 de octubre sigue el mismo patrón. Llama a Gemini 4 Carbon «nuestro modelo más potente, con capacidades de ciberseguridad y de largo horizonte de última generación» e informa de un 88,2 por ciento en SEC-bench Pro para encontrar fallos, un 54,8 por ciento en ExploitGym y un 71,0 por ciento en CWE-bench para corregirlos, todas ellas cifras de la propia Google, medidas sin salvaguardas. El acceso empieza con un subconjunto de ciberdefensores y se amplía por fases a través del Fairwind Program, que según SecurityWeek tiene más de 650 participantes, entre ellos gobiernos y operadores de infraestructuras críticas. Se promete un lanzamiento para desarrolladores, empresas y consumidores «lo antes posible», sin fecha.

Anthropic marcó este patrón con Mythos en abril, y OpenAI lo sigue. GPT-6 Cyber llega primero a un grupo selecto de clientes aprobados de Daybreak Red, su programa de pruebas de seguridad autorizadas, y OpenAI sitúa el modelo en el nivel crítico de ciberseguridad de su propio Preparedness Framework. Su anuncio explica por qué: «Está claro que tenemos una ventana limitada para usar los modelos de frontera para proteger el software».

El lado de los mantenedores

Cada hallazgo acaba en manos de alguien que tiene que corregirlo. En marzo, Greg Kroah-Hartman, uno de los principales mantenedores del kernel, dijo a The Register que los informes hechos con IA habían pasado de ser basura a ser auténticos más o menos un mes antes: «Ahora tenemos informes reales». En mayo, Linus Torvalds escribió que «la continua avalancha de informes de IA básicamente ha hecho que la lista de seguridad sea casi del todo inmanejable», porque mucha gente encuentra los mismos bugs con las mismas herramientas. Su consejo a quienes informan: «Si encontraste un bug con herramientas de IA, lo más probable es que otra persona también lo haya encontrado». En julio, el equipo del kernel publicó 432 CVE en un solo domingo y lunes.

Mientras se ejecutaba el análisis de OpenAI, los mantenedores y otros colaboradores ya estaban corrigiendo muchos de esos mismos fallos: al cabo de diez días, 61 se habían corregido en upstream, 43 tenían parches pendientes y 299 se estaban discutiendo en público. OpenAI dice que siguió las pautas de la comunidad del kernel y que hasta ahora ha comunicado 304 hallazgos críticos con parches candidatos. En nuestra opinión, el recurso escaso es ahora la atención de quienes revisan, prueban y publican las correcciones.

Qué puede hacer una empresa

La mayoría de las empresas simplemente ejecutan el software que recibe estas correcciones, a menudo en grandes lotes. La propia OpenAI saca la conclusión: por ahora, una cuenta con pocos privilegios en un sistema que «no tiene instalados los últimos parches disponibles debe considerarse funcionalmente equivalente a un acceso root para un atacante con muchos recursos». De ahí se derivan cuatro cosas, en nuestra opinión.

Parchea más rápido y conoce lo que ejecutas. Jan Schaumann, arquitecto jefe de seguridad de la información de Akamai, escribió en julio que ya no es viable priorizar cambios individuales del kernel, y dijo a The Register que las «actualizaciones automatizadas, regulares y frecuentes» parecen el único enfoque razonable, por difíciles que resulten para las grandes organizaciones. Eso requiere una lista actualizada de cada servidor, dispositivo y servicio, y de quién actualiza cada uno.

Elige proveedores que parcheen rápido y pregunta cuánto tarda en llegarte una corrección crítica. Pregunta a tus proveedores de software cómo usan estos modelos: si analizan su propio código, cómo verifican lo que notifican los modelos y si participan en programas como Daybreak o Fairwind.

Mantén los datos sensibles en sistemas que controlas, con acceso limitado por rol, para que un fallo en el servicio de otro exponga menos. El control no elimina la obligación de parchear: la hace tuya. OpenAI también recomienda sandboxes y aislamiento para limitar el daño cuando se explota algo.

Dónde estamos

No construimos escáneres de seguridad. Lo nuestro es el último punto de esa lista. Twin, ya disponible, da a los asistentes de una empresa un solo cerebro con acceso por rol, cada escritura autenticada por usuario y cada paso registrado, alojado en Suiza, la UE, Estados Unidos o en el hardware propio de la empresa. Eigna, en acceso anticipado y creado por nuestro socio Eigna Labs, es un modelo privado que funciona en la nube propia de una empresa o en sus propios servidores y está diseñado para funcionar sin conexión en redes cerradas. Como todo lo que ejecuta una empresa, ambos hay que mantenerlos actualizados.