Seguridad ofensiva continua: el camino que llevamos años recorriendo

Las pruebas de penetración con IA están viviendo un gran momento.

Bueno, varios momentos, en realidad. Cada dos semanas, otro proveedor anuncia algo, o una herramienta de pruebas de penetración impulsada por LLM supera algún benchmark con un objetivo que nadie conoce; otra presentación afirma que por fin está irrumpiendo un nuevo «estándar de oro»... Han sido semanas movidas.

Pero debajo de todo el ruido hay una razón de peso por la que esto está ocurriendo en todas partes y al mismo tiempo: la misma capacidad de razonamiento que acaba de hacer comercialmente viables las pruebas de penetración con IA es la que ahora tienen los atacantes. Los atacantes autónomos ya están explorando las superficies de las aplicaciones continuamente, a velocidad de máquina y con una frecuencia que los equipos de defensa no pueden igualar.

La carrera ahora consiste en determinar si tus pruebas de seguridad ofensiva encuentran las fallas antes que la IA ofensiva de un atacante. Los anuncios de los proveedores no son la verdadera historia: solo muestran cómo el mercado se está poniendo al día con un problema que ya llegó.

Después de varios años trabajando en Snyk API & Web, nuestro producto de pruebas de seguridad dinámicas, me siento reivindicado con el anuncio de Snyk de Seguridad Ofensiva Continua. Quiero aprovechar esta publicación para hacer algo más que anunciarla: quiero explicar por qué llevamos años recorriendo el camino que va de las pruebas de seguridad dinámicas a las pruebas de penetración con IA, y por qué, en mi opinión sincera, quienes intenten construir lo segundo sin una base en lo primero se toparán rápidamente con un límite.

Detectables por heurística vs. dependientes del contexto

Esta es la distinción inicial, clave para entender nuestro argumento.

Las vulnerabilidades detectables por heurística son las que se manifiestan ante herramientas deterministas. SAST busca patrones en el código fuente, mientras que DAST adopta el enfoque opuesto: envía cargas útiles a una aplicación o API en ejecución y observa las respuestas: mensajes de error, retrasos, diferencias de comportamiento y cosas por el estilo. Sondear, observar, inferir. La inyección SQL, el cross-site scripting, el uso incorrecto de API y los patrones clásicos de inyección se manifiestan de forma confiable a través de comportamientos que las heurísticas pueden reconocer. Con los años, los escáneres y las herramientas DAST se han vuelto muy buenos en esto. Hoy se detectan de forma confiable cientos de clases de vulnerabilidades de esta categoría a lo largo del SDLC, y eso es un gran logro. 

Las vulnerabilidades dependientes del contexto son algo completamente distinto. BOLA o IDOR, filtraciones de datos entre inquilinos, elusión de la autenticación y, sobre todo, vulnerabilidades encadenadas, en las que varias fallas medias y altas se combinan para formar una ruta de explotación crítica. Ninguna de ellas tiene una firma heurística que puedas detectar mediante sondeos. No puedes escribir una regla, ni en SAST ni en DAST, que diga «El usuario A no debería poder leer la factura del usuario B»: esa regla depende de lo que se supone que debe hacer tu aplicación. La vulnerabilidad está en la brecha entre el comportamiento esperado y el comportamiento real, y no hay sondeo, carga útil ni firma que pueda inferir la intención desde afuera.

Por eso las pruebas de penetración siempre han estado dirigidas por personas. Hasta hace poco, solo las personas podían adquirir la comprensión contextual necesaria para encontrar esta segunda clase. Las heurísticas detectan firmas o comportamientos; los pentesters encuentran lo que solo se revela en contexto. Por atractivo que suene, no es un eslogan: así ha funcionado esta disciplina desde que existe.

Y esa es la línea que acaba de cruzar la IA.

El linaje que realmente importa

Este es el secreto a voces: todos los motores DAST confiables de la última década fueron creados por personas que venían del pentesting. El motor de Snyk API & Web no fue la excepción. El equipo que lo creó llevaba años encontrando fallas manualmente y lo diseñó en torno a lo que hacen realmente los pentesters: reconocimiento, sondeo, observación, razonamiento, escalamiento, validación... todo el proceso. Sin embargo, en ese entonces no podíamos imitar todo lo que hacen los pentesters. Faltaba el razonamiento, que es precisamente lo que ahora podemos hacer, porque los LLM entienden el contexto y pueden razonar.

Ese legado explica por qué nuestra detección de BOLA, que lanzamos el año pasado, funciona como funciona. No busca coincidencias con una lista de firmas, porque BOLA no tiene una firma: es una cadena de sondeos de autorización guiada por el razonamiento estructural sobre cómo se relacionan los objetos de la API con las identidades. Es una búsqueda automatizada de fallas que cruza el umbral de «¿Qué hace el código?» a «¿Qué se supone que debe hacer y puedo subvertir esa intención?»

Lleva meses funcionando en producción para nuestros clientes. Es la prueba de que se puede recorrer el camino de DAST a las pruebas basadas en razonamiento. Y no es casualidad que lleváramos mucho tiempo pensando en crear la versión con IA antes de que las «pruebas de penetración con IA» se convirtieran en una categoría que atrajera inversiones.

Qué cambió y por qué ahora

Lo que cambió no es el objetivo, sino el costo.

Antes, razonar a escala requería un pentester humano. Entre 20.000 y 50.000 dólares por evaluación. En promedio, dos semanas calendario. La ventana de cobertura se cerraba en cuanto se entregaba el informe, momento en que la aplicación ya había tenido tres lanzamientos más.

Así eran las pruebas de penetración manuales: irremplazables, pero limitadas por lo mismo que limita cualquier oficio artesanal: el tiempo de las personas. Tu prueba de penetración cubre quince días al año. ¿Qué pasa durante los otros trescientos cincuenta?

La IA cambia los números, pero no la disciplina. Ahora, un modelo lo bastante capaz también puede realizar el paso de razonamiento que antes solo podía hacer un pentester, de forma repetible y a una fracción del costo.

Y hay una tercera superficie de ataque que creó la propia IA

Todo lo anterior se refiere a una superficie de ataque que existe desde que existen las aplicaciones web: las vulnerabilidades detectables por heurística y las dependientes del contexto que describimos en el código, las API y las arquitecturas tradicionales. La IA cambia el modelo de pruebas, pero no cambia los objetivos: llevan dos décadas siendo materia de pruebas de penetración.

También existe una superficie de ataque completamente nueva, creada por la propia IA, que no existía hace apenas cinco años.

Aplicaciones integradas con LLM, agentes de IA que invocan herramientas, chatbots conectados a datos de clientes. Flujos de recuperación que extraen información de fuentes que un atacante puede envenenar, inyección de prompts o uso indebido. Exfiltración de datos a través de las salidas del modelo, o jailbreaks que convierten un agente de atención al cliente en un actor privilegiado con acceso que nunca debería haber tenido. El artículo de Manoj describió una versión de esto: un agente de IA que invoca una API que nadie había sometido a pruebas de estrés, activado por algo tan sencillo como una dirección de correo electrónico.

No puedes detectar estos ataques con un escaneo, y tampoco son fallas en el sentido arquitectónico tradicional. Se encuentran en la brecha entre lo que se le indicó al LLM que hiciera y lo que un atacante puede convencerlo de hacer. La única forma de encontrarlos es hacerle a la capa integrada con el LLM lo que haría un atacante: sondear, escalar, exfiltrar, abusar.

Esa es la tercera capacidad de Seguridad Ofensiva Continua: Red Teaming de Agentes. Simulación adversarial de varios pasos contra LLM, agentes de IA y las herramientas que invocan. Una herramienta diseñada específicamente para la superficie de ataque que creó la propia IA.

Hay algo que me gusta mucho de cómo está integrado: no es un escaneo aparte que tengas que programar ni otro producto que tengas que comprar. Durante una evaluación, el agente de reconocimiento detecta si el objetivo incluye componentes integrados con LLM y, si los incluye, el módulo de Red Teaming se activa automáticamente. No tienes que saber de antemano qué tipo de superficie de ataque presenta tu aplicación; el sistema lo averigua y ejecuta las pruebas adecuadas en la capa correcta.

Eso importa más de lo que parece al principio. Hoy, la mayoría de las organizaciones tienen IA en algún lugar de su cartera de aplicaciones, pero sus equipos de seguridad no cuentan con un inventario claro. Reconocer primero y probar lo que se encuentra es el único modelo que puede escalar cuando «¿Dónde se ejecuta la IA en producción?» es una pregunta cuya respuesta cambia constantemente.

Esa es, entonces, la superficie de ataque: las fallas en las arquitecturas tradicionales y el nuevo terreno que la IA acaba de crear sobre ellas. La pregunta más difícil es qué se necesita para realizar bien pruebas ofensivas contra ambas, de forma continua y a escala empresarial. La respuesta no es apuntar un LLM a una URL objetivo y dejar que resuelva todo desde cero. Hay cuatro aspectos que marcan la diferencia.

Contexto de la plataforma

El enfoque ingenuo de las pruebas de penetración con IA es empezar desde cero. Apuntar el LLM a una URL, dejarlo rastrear, dejarlo adivinar, permitir que consuma recursos en enumeraciones irrelevantes y esperar que finalmente encuentre algo. Y, peor aún, no puede distinguir un hallazgo teórico de uno que realmente se pueda explotar en tu stack, porque no puede ver tu código, tus dependencias, tus escaneos anteriores, tu entorno de despliegue ni tus límites de confianza. Ese es el ciclo de una demo, pero no es así como deberían funcionar las pruebas de seguridad de nivel de producción.

Sin embargo, la versión de Snyk es diferente. Seguridad Ofensiva Continua parte de todo lo que la plataforma ya sabe sobre tu aplicación: hallazgos de SAST, dependencias de SCA, inventarios de activos, escaneos DAST anteriores y señales de riesgo de toda la plataforma. Todo esto alimenta al pentester de IA antes de que envíe una sola solicitud.

Eso cambia lo que hace la IA desde el primer día. En lugar de «Averigua qué es esta aplicación y encuentra vulnerabilidades,», las instrucciones pasan a ser «Esta aplicación tiene estos componentes, estas dependencias, estos hallazgos anteriores, estos endpoints accesibles y este perfil de riesgo. Ahora busca lo que aún no está cubierto». El LLM deja de adivinar y se pone a trabajar.

Como dijimos en el anuncio de esta semana: «Snyk es diferente porque ya conocemos tu código». Esa es la propuesta de valor de la plataforma en siete palabras. Todas las demás herramientas de pruebas de penetración con IA parten de cero; nosotros empezamos donde terminó el trabajo de tus herramientas actuales.

Por eso tampoco creo que las soluciones puntuales de este tipo tengan mucho futuro: no puedes agregar esta capa a un producto nuevo. Requiere una década de contexto acumulado que llega desde motores que han encontrado vulnerabilidades reales en entornos reales de clientes.

Pruebas dinámicas híbridas y detección con LLM

Este es el aspecto de ingeniería que la mayoría de los nuevos competidores pasan por alto, y donde creo que muchos tendrán problemas cuando sus periodos de financiamiento se crucen con sus facturas de tokens.

La forma ingenua, una vez más, de crear pruebas de penetración con IA es usar solo un LLM, apuntarlo al objetivo y dejar que resuelva todo. Eso funciona en las demos, pero no es económicamente sostenible.

Cada carga útil que prueba un LLM contra un endpoint de XSS cuesta tokens. ¿Cada parámetro sometido a fuerza bruta, cada variación, cada reintento? Tokens, tokens y más tokens. Las pruebas dinámicas hacen ambas cosas de forma exhaustiva y determinista, por unos centavos. Quemar tokens de modelos de frontera en el catálogo de errores es lo que significa «subsidiado con márgenes negativos», y los proveedores que hoy siguen esa estrategia descubrirán qué significa la economía unitaria el día que tengan que ser rentables.

El modelo arquitectónico correcto no consiste en tener dos capas trabajando en paralelo, sino en usar un LLM como cerebro de la evaluación y las pruebas dinámicas como una de las herramientas a su disposición. Cuando hay que comprobar XSS, inyección SQL o configuraciones incorrectas, el LLM no enumera las cargas útiles por su cuenta: recurre a las pruebas dinámicas, que llevan años haciendo precisamente eso, de forma exhaustiva, determinista y por unos centavos.

Así, el LLM puede dedicar sus tokens a lo que solo un LLM puede hacer: razonar sobre la lógica de negocio, encontrar fallas de autorización y conectar hallazgos individuales para descubrir rutas de explotación reales. Ahí es donde se concentra la mayor parte del cómputo. El terreno conocido sigue recorriéndose de forma determinista, mientras que cada dólar de cómputo se destina a la superficie de razonamiento, donde más se necesita.

Esa es la arquitectura desde el primer día, no una meta de nuestra hoja de ruta. Por eso, en mi opinión, crear esto sin un motor de pruebas de seguridad dinámica debajo es un problema mucho más difícil de lo que parece desde afuera.

Narrativas de ataque, no listas de alertas

El resultado de un escáner tradicional es una lista de vulnerabilidades ordenadas por nivel de gravedad, con trazas de pila o solicitudes HTTP adjuntas. Los equipos de seguridad llevan varios años ahogándose en estas listas. CVSS 9.8 junto a CVSS 9.6, junto a CVSS 9.4... y, en algún lugar de la lista, una ruta de explotación real que combina dos de ellas con un tercer hallazgo de baja gravedad que el equipo descartó hace meses.

Las vulnerabilidades de clase dependiente del contexto que describí antes casi nunca aparecen como hallazgos independientes; aparecen en combinaciones: una brecha de autorización en un endpoint, una falla lógica en la forma en que la API genera identificadores y una sesión obsoleta que el proceso de limpieza no detectó. Son tres hallazgos que parecen inofensivos por separado, pero que, en conjunto, pueden provocar una filtración de datos.

Continuous Offensive Security no entrega los hallazgos en una lista. Los entrega como cadenas de explotación: la ruta real desde el acceso inicial hasta el impacto, con el historial de solicitudes y respuestas como prueba. Todo es reproducible y auditable. Una historia sobre lo que un atacante podría hacer realmente con esta aplicación, no una hoja de cálculo de 400 filas que alguien tiene que revisar un viernes por la tarde.

Colleen Carroll, directora sénior y responsable de seguridad de la información en Emburse, expresó este punto desde la perspectiva de la demanda en nuestro anuncio:

“Los equipos de seguridad buscan soluciones que les ayuden a priorizar los riesgos reales, no solo a gestionar más alertas. Continuous Offensive Security de Snyk ofrece a los equipos una visibilidad más clara de las vulnerabilidades explotables y de cómo se encadenan, lo que les permite avanzar más rápido, reducir la exposición y respaldar la innovación con confianza.”

Esa es la diferencia entre «Esto es lo que encontramos» y «Así podrían usar esto en tu contra».

Plataforma de ejecución de IA para empresas

La parte que requiere un trabajo de ingeniería serio y casi nunca aparece en los titulares es ejecutar agentes de IA de forma responsable en sistemas que están a un salto de red de producción.

Gobernanza, aplicación de límites de alcance, contexto persistente durante operaciones prolongadas y reproducibilidad para validar y volver a examinar un hallazgo. Trazas de razonamiento para que un equipo de seguridad pueda auditar cómo se llegó a una conclusión. Toda la capa que transforma «un LLM probando cosas» en algo que una organización de seguridad empresarial realmente ejecutaría contra una aplicación.

La llamamos AI Security Harness. Es la parte de Continuous Offensive Security que está detrás de ese titular. También es donde reside la mayor parte de la dificultad real. Y, una vez más, es donde la trayectoria importa. Crear esta capa es más difícil que crear la IA que se ejecuta sobre ella, y las organizaciones que llevan años realizando pruebas de penetración y pruebas de seguridad dinámica a escala empresarial tienen una ventaja considerable frente a quienes recién se suman.

También es donde tomamos una decisión de arquitectura deliberada que otras soluciones no pueden replicar fácilmente: Continuous Offensive Security no funciona con un único modelo de frontera. AI Security Harness coordina varios modelos de vanguardia, modelos de nivel defensor y otros modelos abiertos y propietarios, ajustados con el tiempo. Para nosotros, esto constituye una decisión de arquitectura sobre cómo debe construirse un sistema de IA de nivel empresarial.

Continuous Offensive Security ejecuta un sistema de seguridad ofensiva multimodelo diseñado específicamente para las pruebas de penetración empresariales. Los modelos de frontera realizan la evaluación con el harness ofensivo de Snyk; un modelo de validación dedicado actúa como evaluador independiente y confirma que los hallazgos sean explotables antes de presentarlos; y la inteligencia de la plataforma de Snyk fundamenta cada ataque en el contexto real de la aplicación. El resultado es un sistema optimizado para la precisión, no para el ruido.

Qué significa esto

Gabriel Brolo, ingeniero de seguridad sénior en Yalo, lo expresó hace poco con más claridad de la que yo podría:

«El volumen y el ritmo del código generado por IA han superado por completo el modelo de pruebas de penetración que la mayoría hemos usado durante años. No podemos resolver una superficie de riesgo continua simplemente programando más pruebas. Necesitamos pruebas ofensivas que sigan el ritmo de la forma en que desarrollamos software hoy, con suficiente contexto para enfocarse en lo que realmente se puede explotar, no solo en lo que es teóricamente posible. Este tipo de capacidad permitirá que los equipos comprendan mejor su panorama de amenazas y sus riesgos reales, para mitigarlos de forma más eficaz».

Para los clientes de Snyk API & Web, Continuous Offensive Security no es una compra aparte, sino la siguiente capa de la misma ruta de pruebas externas que ya ejecuta Dynamic Security Testing. El escáner cubre los problemas detectables mediante heurísticas; la IA, los que dependen del contexto; y Red Teaming, la superficie de ataque específica de la IA en cuanto el reconocimiento detecta un LLM en la pila tecnológica. La misma postura de seguridad, ampliada para cubrir los componentes reales de tus aplicaciones actuales.

Para el mercado, la pregunta deja de ser «¿Necesitas pruebas de penetración con IA?» (y bueno, creemos que sí) y pasa a ser «¿Qué solución de pruebas de penetración con IA debería elegir?»

Ahora que por fin anunciamos Continuous Offensive Security esta semana, nuestra intención es que quienes hoy evalúan soluciones de pruebas de penetración con IA, comparan opciones, asisten a demostraciones y tratan de decidir en quién confiar, sepan que una de las respuestas viene de las mismas personas que han estado en este espacio desde mucho antes de que siquiera existiera.

Si leíste la publicación de Manoj sobre la superficie de ataque que está creando la IA y mi artículo anterior sobre cómo deben evolucionar las pruebas dinámicas para seguirle el ritmo, este es el tercer capítulo, y la conexión entre ellos es evidente. Siempre estuvo ahí y llevábamos tiempo insinuándola.

Pronto compartiremos más novedades en Black Hat. ¡Nos vemos allá!