La Inteligencia Artificial aceleró el descubrimiento de bugs en el software y expuso que el modelo clásico de gestión de vulnerabilidades fue diseñado para un mundo que ya no existe.
Durante años, la gestión de vulnerabilidades funcionó con una lógica simple. Alguien encontraba una falla; alguien la reportaba; el fabricante la analizaba; se le asignaba un CVE; se publicaba un parche; la empresa lo probaba y, si todo salía bien, se instalaba el parche y... vulnerabilidad patcheada.
Era un sistema lento, burocrático y lleno de fricción. Pero esa fricción también era parte del equilibrio. Había tiempo.
Tiempo entre el descubrimiento y la explotación. Tiempo entre el advisory y el exploit público. Tiempo entre el parche y el ataque masivo. Tiempo para probar, discutir, aprobar, coordinar una ventana de mantenimiento y rezar para que nada se rompiera en producción.
Bueno, ya vimos que, en nuestro nueva era de la IA, ese tiempo se contrajo abruptamente.
En el campo de la ciberseguridad, la IA ya no sólo sirve para resumir alertas, escribir reglas de detección o ayudar a un analista del SOC a sacarse de encima los falsos positivos. Ahora también sirve para encontrar fallas de seguridad en forma dinámica y con mucha eficiencia.
Ya todos leimos que Claude Mythos Preview, el modelo de Anthropic, fue un LLM potenciado por agentes (denominado frontier model) que no sólo puede hallar bugs leyendo el código, también puedde razonar sobre flujos complejos, encontrar vulnerabilidades de forma dinámica, hacer pruebas reproduciendo fallas y, en algunos casos, hasta crear exploits. Todo a velocidades de IA.
Tan serios fueron los resultados, que la gente de Antropic hizo algo que se le viene pidiendo a los dueños de las IAs hace tiempo y nadie hace caso, que paren, que detengan el avance un tiempo, que no difundan el código todavía. En este caso, la empresa lo hizo, incluyendo Mythos en el Proyecto Glasswing y no lo abrió al público general. Encerró al genio en una botella y sólo le permite el acceso controlado a organizaciones seleccionadas para que internamente aceleren la búsqueda y remediación de sus vulnerabilidades.
Sin embargo, Mythos no es el único. Existen otros modelos similares como GPT-5.5-Cyber, Gemini 3 Pro con Big Sleep, TrendAI’s ÆSIR, y otros... Todo esto lleva a que hoy la capacidad de descubrir vulnerabilidades se está súper-acelerando, mientras que la capacidad de corregirlas sigue atada a procesos humanos, legales, técnicos y operativos.
Hasta ahora, encontrar vulnerabilidades era una tarea cara. Requería investigadores especializados, reversing, fuzzing, lectura manual de código, tiempo, intuición y paciencia. Todo eso se hacía con esfuerzo humano y herramientas de software para asistirlo. Hoy el paradigma cambió, la IA hace eso a velocidades impensadas, y eso cambia la economía del ataque.
Para un atacante, más vulnerabilidades encontradas significan más oportunidades. Para un defensor, más vulnerabilidades encontradas pueden significar otra cosa: más trabajo, más tickets, más falsos positivos, más presión sobre desarrollo, más reuniones de priorización y más sistemas que nadie se anima a tocar porque para el negocio la consigna siempre fue "lo que anda no se toca".
Ante el cambio de velocidad y de escala, el dato que se llevaba en un dashboard al directorio respondía a la pregunta: ¿cuántas fallas existen? Y esa pregunta hoy se convierte en: ¿cuántas fallas podemos corregir de forma segura antes de que alguien las explote?.
Porque corregir no es apretar un botón.
Por eso hoy el viejo (...hasta el mes pasado…) modelo de gestión de vulnerabilidades, quedó abruptamente corto. CVE, CVSS, advisories, disclosure coordinado y patch management siguen siendo necesarios. Pero fueron diseñados para otra velocidad. Para un mundo donde la detección era lenta y la remediación, aunque difícil, podía seguirle el ritmo.
Ese equilibrio hoy se rompió.
Lo que aparece ahora es una nueva deuda técnica: la deuda de remediación. No se trata solamente de tener sistemas vulnerables. Se trata de acumular vulnerabilidades que la organización conoce, entiende, prioriza… pero no puede corregir con la velocidad necesaria.
Y esa deuda puede ser más peligrosa que la ignorancia.
Porque cuando una vulnerabilidad es conocida, el reloj empieza a correr. Si además la IA ayuda a convertir hallazgos en pruebas reproducibles, el margen se achica todavía más. Los atacantes no necesitan esperar un exploit público prolijo. Pueden automatizar reconocimiento, analizar versiones, buscar patrones y priorizar víctimas.
¿Y entonces? ¿ahora qué?
Si se pudo crear un modelo de IA que encuentre vulnerabilidades a velocidades supersónicas, también se debería crear uno para remediarlas. La IA también debería ayudar a cerrar el ciclo: reproducir la falla, generar un parche candidato, probarlo, verificar que el exploit ya no funcione, revisar regresiones y entregar evidencia clara para que un humano apruebe.
Desde que el mundo es mundo, romper siempre fue mucho más fácil que reparar o construir. Y acá es igual. Un modelo pude encontrar una vulnerabilidad, crear el parche y explotarla, pero no hay un modelo que pueda arreglarla automáticamente, el proceso es más complejo.
Una línea de producción defensiva debería consistir de varias etapas. Un agente que detecte. Otro que reproduzca. Otro que proponga un fix. Otro que corra tests. Otro que valide compatibilidad. Otro qur genere el reporte para la revisión humana. Y recién ahí el equipo humano decide si aplica el parche, cuándo lo aplica y cómo reduce el riesgo de romper el proceso de negocio.
Por suerte, esto no es sólo una idea, ya hay varias iniciativas que están trabajando en este sentido.
DARPA, por ejemplo, impulsó el AI Cyber Challenge para crear sistemas capaces de encontrar y parchear vulnerabilidades en software crítico. OpenSSF incorporó OSS-CRS como framework para construir sistemas autónomos basados en LLM orientados a bug-finding y bug-fixing. Google publicó trabajo sobre parches asistidos por IA usando Gemini para corregir bugs encontrados por sanitizers. OpenAI presentó Aardvark como un investigador de seguridad basado en agentes que detecta, valida y ayuda a corregir vulnerabilidades.
El trabajo no es fácil, y hay que hacerlo con mucho cuidado. Los fixes que cree la IA tienen que ser seguros y eso no es fácil de verificar.
Porque generar un parche malo puede ser peor que dejar una falla sin corregir durante unas horas más. Un bug puede demostrarse con un caso específico. Un parche tiene que funcionar para todos los casos razonables, mantener compatibilidad, no romper APIs, no degradar performance y no introducir vulnerabilidades nuevas.
Pero además de las herramientas de IA que nos ayuden a patchear y remediar, todo el proceso y el framework tienen que estar muy bien armados para que el mecanismo funcione.
En el caso de Argentina y en buena parte de América Latina, el golpe puede ser más fuerte. Muchas organizaciones todavía tienen inventarios incompletos, software legacy, proveedores críticos poco visibles, procesos de cambio pesados y equipos de seguridad saturados. En ese contexto, la IA no sólo acelera al atacante. También expone la lentitud estructural del defensor.
Con este nuevo esquema, el inventario ya no hay que hacerlo por compliance sino por supervivencia. Sin saber qué software se usa, qué dependencias tiene, qué versiones están expuestas y qué proveedor sostiene cada componente crítico, no hay forma de responder a velocidad.
La priorización también tiene que cambiar. CVSS sirve, pero no alcanza. La pregunta no es sólo qué tan grave es una vulnerabilidad, sino si es explotable contra mi entorno, desde dónde, con qué privilegios, sobre qué activo de negocio y en cuánto tiempo real puedo corregirla.
Y parchear tiene que dejar de ser una excepción traumática. En este nuevo esquema, los procesos de testing automatizado, los despliegues progresivos, los mecanismos de rollback y ambientes de prueba confiables se van a volver tan importantes como el firewall, el EDR o el SIEM.
Como dijimos antes, romper es siempre más fácil que arreglar. Sabemos que en esta carrera los atacantes siempre están adelantados a los defensores. Sin embargo, es bueno que ambos usemos las mismas armas, de esta forma podremos mantener la pelea medianamente equilibrada.
*Por Carlos Benítez, CISO de Platinum Ciber