Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

La semana pasada, Manoj Nair, director de tecnología de Snyk, conversó en vivo con Alon Krifcher, director de IA aplicada en Anthropic, sobre la próxima ola de ataques autónomos. Manoj volvió una y otra vez a una idea: el huracán de la IA ya llegó, y ahora queda decidir si tu defensa puede operar a la misma velocidad que la amenaza.

Los ataques ya son agénticos, al igual que el código que los escribe. En miles de entornos empresariales reales, Snyk observa que la cantidad de nuevos problemas de seguridad introducidos crece más del doble cada trimestre, mientras que los equipos cierran uno por cada seis problemas nuevos. El informe de amenazas más reciente de CrowdStrike registró el tiempo de propagación más rápido: 27 segundos. Ahora, el promedio se mide en minutos, no en meses. Antes, desarrollar vulnerabilidades de día cero tomaba mucho tiempo, y explotarlas, todavía más, lo que daba tiempo a los equipos de defensa. Justamente eso es lo que los atacantes autónomos les han quitado.

Sin embargo, Manoj no cree que todo esté perdido. Piensa que la respuesta es más sencilla de lo que la gente espera y que ya está dando resultados en las empresas más grandes con las que conversa. Si los ataques autónomos exigen una defensa a velocidad de máquina, sostiene, se necesitan cuatro acciones en paralelo, no en secuencia: Descubrir → Corregir → Validar → Prevenir. Puedes empezar en cualquier punto de ese ciclo. La mayoría de las empresas empieza por la lista de pendientes que ya tiene, porque todas tienen una.

Ahí es donde cambia el cálculo del riesgo. El modelo anterior era: probabilidad por impacto. El impacto no ha cambiado mucho, pero la probabilidad sí. Ahora, un atacante puede encadenar de forma económica y agéntica tres vulnerabilidades, cada una clasificada como baja o media, y convertirlas en algo que ya no es ni bajo ni medio. Volver a priorizar todo no es la respuesta, explica Manoj. La respuesta es empezar por las aplicaciones de mayor impacto y probarlas como lo haría realmente un atacante autónomo. Por eso Snyk creó Evo Continuous Offensive Security. Uno de los primeros clientes lo probó contra una aplicación que había salido sin hallazgos de una prueba de penetración esa misma semana. Snyk encontró todo lo que había detectado el evaluador, además de dos o tres problemas que el equipo tuvo que corregir ese mismo día. No es una idea teórica, dice Manoj. Ya está en funcionamiento.

En cuanto a la lista de pendientes, algunos clientes de Snyk, entre ellos Labelbox y Relay Networks, han contado públicamente cómo llegaron a cero pendientes combinando Skills con agentes de corrección basados en Claude. Otro cliente de Fortune 10 dijo lo mismo. Si eso es cierto a esa escala, afirma, «ya nos ocuparemos de la lista de pendientes» dejó de ser un plan creíble.

La prevención es la parte de la que Manoj está más orgulloso, porque es donde empezó Snyk. La empresa se fundó con la idea de corregir los problemas de seguridad cuando se crean, en lugar de hacerlo después. Pero el punto de creación cambió. Para la mayoría de las empresas con las que conversa, ahora es un agente. Por eso Snyk creó Snyk Studio: para darle a ese agente el mismo contexto de seguridad que tendría un buen desarrollador, justo cuando escribe código y con la rapidez necesaria para que el agente no busque una forma de eludirlo. Hoy, casi 1.500 clientes lo usan en producción. Hace poco, Manoj hizo una demostración: le pidió a un agente que creara un lector de códigos QR y le presentó con honestidad dos paquetes posibles, uno abandonado desde hacía una década y otro actualizado y seguro. El agente eligió el correcto sin que una persona tuviera que intervenir.

Manoj sostiene que nada de esto funciona si se considera que es responsabilidad exclusiva de Snyk, y quiere ser claro sobre los límites de lo que puede hacer un socio como Anthropic. Anthropic trabaja arduamente para impedir que sus modelos se utilicen como armas en la capa de inteligencia. Pero ese trabajo tiene un límite: la superficie que sus barreras de protección no alcanzan, como las credenciales expuestas, los componentes mal configurados o un agente o equipo que no sabe qué paquetes o Skills incorporó por el camino. En los casi 3.000 clientes que hoy usan la lista de materiales de IA de Snyk, la empresa observa una proporción cercana a tres modelos por cada componente agéntico. Cada uno de esos componentes es un lugar donde puede ocultarse un riesgo si nadie lo supervisa. Este verano, Snyk aplicó el mismo enfoque para ayudar a proteger una de las implementaciones de código en la nube más grandes del mundo: 50.000 desarrolladores, con análisis continuo de Skills integrado desde el primer día.

Si te quedas con una sola idea de todo esto, dice Manoj, mide un dato: la cantidad de nuevos hallazgos frente a los hallazgos cerrados en tus aplicaciones principales. Todo lo demás que aparece en un panel de seguridad —como los tickets abiertos, los análisis ejecutados o el personal contratado— cambia porque hiciste algo. Esa proporción solo cambia cuando el programa realmente evoluciona. Si está en seis a uno y sigue empeorando, estás acumulando inventario, no mejorando la seguridad. Si puedes, mide un segundo dato: qué proporción de las correcciones propuestas se integra sin que una persona tenga que reescribirlas. Esa es la verdadera limitación de rendimiento y te indica hasta qué punto tu proceso de corrección es agéntico en la práctica, frente a lo que te gustaría.

El mercado cambia en cuestión de semanas, dice Manoj. La guía anterior es un punto de partida, no la meta final, y espera que evolucione como lo ha hecho todo este sector durante el año desde que Snyk lanzó Studio. Lo que no ha cambiado ni cambiará es la convicción que comparten Manoj y Alon: los atacantes solo tienen que ganar una vez, y la única defensa real consiste en crear suficientes capas para no dejarles ninguna oportunidad.

¿Quieres escuchar la conversación completa? Mira la sesión a pedido con Manoj Nair y Alon Krifcher.