Microsoft afirma que el laboratorio Frontier Offensive Research & Generative Exploitation, conocido por sus siglas FORGE, pasó de poner a prueba la capacidad de la inteligencia artificial para encontrar vulnerabilidades difíciles a estudiar qué se necesita para convertir esos descubrimientos en correcciones listas para distribuir. Entre mayo y septiembre de 2026, el laboratorio ayudó a descubrir vulnerabilidades en Windows a las que se asignaron 140 identificadores CVE, 52 de las cuales se abordaron en las actualizaciones de seguridad de septiembre de 2026.
El trabajo también se extendió al software de código abierto; los equipos de FORGE presentaron alrededor de 155 informes verificados internamente en 23 proyectos, incluido el kernel de Linux. Según Microsoft, 93 informes correspondientes a 14 proyectos o familias de proyectos recibieron un reconocimiento o una aceptación documentada por parte de los mantenedores en el momento de preparar el material. Además, uno de los informes sobre Linux presentados a través de la iniciativa Akrites de la Linux Foundation se convirtió en el primer informe de la iniciativa que terminó con la integración de una corrección en el kernel de Linux.
De la capacidad máxima a la operación a gran escala
La primera lección es que el éxito de un modelo a la hora de encontrar un fallo complejo no garantiza la producción de correcciones a un ritmo equivalente. Aumentar el número de verificadores puede elevar el número de candidatos, pero no necesariamente incrementa el número de resultados confirmados o correcciones publicadas. Si los informes llegan más rápido de lo que el Microsoft Security Response Center puede revisarlos, se acumula una lista de espera que consume tiempo de los expertos, especialmente cuando los informes se repiten o carecen de pruebas reproducibles.
Por ello, FORGE se centra en un resultado reproducible, no únicamente en el número de exploraciones o informes. El laboratorio utiliza la plataforma multimodelo MDASH para organizar el trabajo, junto con generadores de pruebas de explotabilidad o pruebas de concepto, la construcción de herramientas de prueba y la búsqueda de entradas que provoquen el comportamiento defectuoso. Microsoft señala que un proyecto interno que empleó algoritmos deterministas, como el análisis del árbol de sintaxis abstracta, redujo los informes duplicados aproximadamente un 45% en varias exploraciones del mismo código.
Invertir en eliminar la incertidumbre, no en aumentar el texto
Microsoft considera que medir la eficiencia únicamente por el número de tokens que produce el modelo conduce a un criterio engañoso. Un informe breve puede ser ambiguo y costoso de investigar, mientras que un análisis más extenso puede justificar la ruta de ejecución y reducir el coste total. La decisión práctica consiste en determinar qué le falta al investigador: el llamador de la función, la configuración de compilación, el reproductor ejecutable o la explicación causal, y después orientar el siguiente paso específicamente a cerrar esa brecha.
MDASH combina modelos avanzados con otros destilados, verificadores especializados y herramientas de análisis de código, con la posibilidad de dirigir las tareas rutinarias a modelos menos costosos y escalar las preguntas no resueltas a modelos más potentes. Sin embargo, Microsoft subraya que esta política sigue siendo una hipótesis que requiere medición, porque el filtrado temprano podría excluir vulnerabilidades reales.
La verificación y la corrección como un ciclo de aprendizaje continuo
Según el planteamiento, la verificación y la corrección no deben tratarse como una etapa posterior al descubrimiento de la vulnerabilidad. Cada resultado debe pasar por la verificación automatizada, la revisión humana, el desarrollo de la corrección y las pruebas de regresión, y las evidencias de cada etapa deben volver al sistema. Incluso el fracaso de la verificación puede ser útil si registra el motivo del fallo, como la imposibilidad de acceder a la ruta, una configuración de compilación incorrecta, la ausencia de control del atacante sobre las entradas o la duplicación del informe.
En un experimento con el kernel de Linux, los agentes de verificación produjeron pruebas de apoyo para 627 resultados, mientras que el coste medio de crear una prueba de concepto para 182 resultados confirmados de tipo crash fue de 3,61 dólares de coste del modelo y 21,5 minutos por cada caso exitoso. En seis casos en los que se probó la posibilidad de escalar privilegios localmente mediante la generación automatizada de exploits, el promedio fue de 8,56 dólares y 25,4 minutos. Las evaluaciones utilizaron GPT-5.5 y no incluyeron los costes de la exploración inicial, los casos fallidos ni la investigación humana y la preparación de las correcciones.
¿Qué significa esto para los equipos de seguridad?
La conclusión más importante de estos resultados es que la métrica de éxito de los sistemas agénticos de descubrimiento de vulnerabilidades no debería detenerse en el número de resultados. Microsoft propone hacer un seguimiento del número de fallos confirmados, los informes duplicados y rechazados, la antigüedad de la lista de espera, el tiempo transcurrido entre el descubrimiento y la corrección, además del coste de los modelos y el tiempo de revisión humana. Asimismo, el trabajo en proyectos de código abierto requiere respetar los procesos de cada proyecto para la divulgación, la revisión y la corrección, y no limitarse a enviar más informes.
En la práctica, la fuente identifica un cambio en el cuello de botella: la capacidad para encontrar el fallo se ha convertido en una parte del problema, mientras que cada vez es más importante conectar la investigación con los entornos de compilación, los binarios, las configuraciones, las herramientas de prueba y los sistemas de CI/CD. Los límites de los resultados siguen siendo claros; las cifras sobre el coste de la verificación excluyen etapas humanas importantes, y convertir los resultados de la investigación en una corrección aceptada depende de los mantenedores y del contexto de cada proyecto. Por tanto, el material no demuestra que la automatización sustituya la revisión de ingeniería, sino que la presenta como un medio para reducir el trabajo repetitivo mientras se mantiene en manos humanas la responsabilidad del criterio de seguridad y la corrección.