Este artíoculo ha sido publicado por Hamid Kashfi en X
Llevo unos 22 años realizando una amplia gama de pruebas de penetración y auditorías (más de 400 proyectos). Así que algo sé del tema. Pero sigo considerando que las pruebas de penetración automatizadas están obsoletas. Aunque no como podrías pensar. Inicialmente escribí un borrador más extenso, pero al final lo descarté y dejé que Gemini lo acortara y perfeccionara, ¿por qué no?
¿Por qué las pruebas de penetración automatizadas están muertas?
Está obsoleto, al igual que lo estaba hace 10 años el uso de herramientas automatizadas como Nessus y Core Impact y la entrega de informes de 50 páginas. La nueva era de la automatización impulsada por IA está reviviendo precisamente ese enfoque de bajo valor.
No estoy en contra de la IA; mejorará. Yo mismo pago ocasionalmente más de 1.000 dólares al mes en tokens. Ya funciona para muchas cosas, pero aún no es escalable para realizar pruebas de penetración eficientes. No porque los tokens sean demasiado caros (bajarán de precio) ni porque los modelos no sean fiables (mejorarán; XBow es un ejemplo). Está obsoleta por distintas razones interrelacionadas.
1. El problema del ruido y la fatiga
Del mismo modo que se ignoraban los antiguos informes con decenas o cientos de hallazgos válidos, esta nueva era de problemas generados por IA también será ignorada. Actualmente, un informe puede contener 2 o 3 hallazgos clave. Pronto, agentes de IA analizarán su red a fondo y generarán 100 problemas graves y perfectamente válidos.
Si llevas cinco años realizando pruebas trimestrales a clientes de Fortune 50/500 y has obtenido resultados similares una y otra vez, sabes a qué me refiero. La priorización de las medidas correctivas y el cansancio que esto genera son un problema grave. Al final te das cuenta de que lo que vendemos (hacking, pruebas, seguridad) no es la prioridad de las grandes empresas. Es una obligación, a menudo por motivos de cumplimiento normativo, entre otras cosas.
No juzgues a un CISO por archivar un informe con todas las vulnerabilidades en rojo y solucionar solo cinco problemas al día siguiente, la semana siguiente, el mes siguiente o el año siguiente. Tu "hallazgo crítico" es simplemente una decisión de negocio.
Su funcionamiento es más bien similar a: "¿Nos costará un millón de dólares si se explota?". Si la respuesta es no, no se categoriza, prioriza ni gestiona como crítico, porque hacerlo inicia una compleja cadena de acciones internas que, por sí misma, consume tiempo y dinero.
Por lo tanto, en muchos casos, la razón por la que las pruebas de penetración no son eficientes no se debe a la falta de pruebas, sino a la falta de prioridad empresarial. No necesitas una prueba de concepto funcional (generada por un humano o un LLM) para abordar esto.
Obtener acceso a una shell en un sistema que inherentemente no es crítico para el negocio en una infraestructura, no lo convertirá mágicamente en una prioridad. Esta es una gran promesa que ofrecen las startups de pruebas de penetración automatizadas con IA. Sin duda funciona, y pueden generar acceso a shells sin parar, pero eso no resolverá ningún problema que no se haya abordado ya con las pruebas de penetración tradicionales.
2. El verdadero cuello de botella
La industria de la seguridad acaba de empezar a ofrecer a sus clientes un respiro del ruido de los informes de pruebas automatizadas, centrándose en la investigación manual exhaustiva. Por fin, lo normal es entregar solo media docena de hallazgos realmente importantes, en lugar de tonterías como la falta de una cabecera HSTS.
Espero que esta nueva ola de pruebas automatizadas con IA no traiga de vuelta los informes de Nessus o Core Impact, que ahora solo son más precisos. Ah, se me olvidaba: ya hemos vivido una era centrada en la detección automática, la validación basada en exploits y la notificación de vulnerabilidades. No digo que vayamos hacia el mismo destino, pero se parece demasiado.
Es mucho más fiable y mucho más interesante que un script de Python que razona con un bucle IF para decidir si explotar o no un exploit de SMB1. ¿Significa eso que deberíamos dejar de buscar y notificar cosas de esta manera? No necesariamente.
El principal problema no es la precisión de los resultados. Bueno, lo fue durante un tiempo a mediados de la década de 2000, pero mejoramos y las herramientas se perfeccionaron. El problema radica en que quienes reciben estas automatizaciones e informes no están automatizados. El proceso y el personal que gestiona estos hallazgos no han evolucionado al mismo ritmo que las herramientas. No importa cuántos problemas críticos se detecten y se exploten; siguen siendo gestionados por personas, tratados como decisiones empresariales y revisados caso por caso.
3. Las pruebas de caja negra son ineficientes
Generar 50 hallazgos válidos mediante Nessus, Burp Scanner o sus equivalentes basados en LLM simplemente no es eficiente. Una prueba de caja negra es inherentemente ineficiente hoy en día porque no encuentra ni reporta los problemas en su origen. Solo encuentra y reporta síntomas que se repiten constantemente. ¿Alguna vez has accedido a la plataforma de gestión de vulnerabilidades Qualys o Tenable de una empresa? ¡Te aseguro que no es una imagen agradable! ¡Esos son los resultados máximos de las pruebas de penetración automatizadas a gran escala!
Por mucho que repitas una prueba de penetración de caja negra, siempre encontrarás problemas nuevos y recurrentes. ¿No me crees? Pregúntale a Fortinet. Siguen publicando parches para SQLi, CMDi, RCE y corrupción de memoria básica mensualmente, año tras año.
Todos ellos descubiertos y explotados mediante pruebas de caja negra por tus APT favoritos. Sí, eso también es una forma de prueba. Simplemente no comparten sus hallazgos con el proveedor. Fortinet no es un caso aislado. Si la solución fuera esta, las plataformas de recompensas por errores y negocios similares no estarían tan bien.
Generan enormes ganancias, tanto para ellos como para los cazadores de errores, aprovechándose de que durante más de dos décadas, como industria, no hemos solucionado de forma adecuada y fundamental algunos de estos problemas.
Por cierto, si una empresa ha seguido el camino correcto de madurez (en seguridad) antes de exponerse a las plataformas de recompensas por errores, significa que ya ha superado múltiples rondas de todo tipo de pruebas de penetración. ¡Y aun así, la gente sigue encontrando cosas interesantes, muchísimas!
No entremos en el tema de que "ya éramos conscientes del problema" ni en discusiones interminables. Además, si las pruebas automatizadas basadas en IA son tan buenas y representan el futuro (de hecho, lo son), surge la pregunta de por qué se les prohíbe operar de forma autónoma en plataformas de recompensas por errores. ¿Se debe al ruido? ¿Acaso estas plataformas están monopolizando el mercado para sus propias implementaciones de agentes?
4. El método eficiente: Ingeniería de seguridad
Bien, ¿cuál es la forma más eficiente de hacer las cosas entonces? Me alegra que lo preguntes. La ingeniería de seguridad es la respuesta más breve. Consulta con cualquier empresa de consultoría y pentesting respetable. Verás que la mayoría de sus proyectos con clientes no son pruebas de caja negra.
Las consultoras típicas prefieren las auditorías de caja blanca: revisan el código, las configuraciones, la infraestructura como código o la postura de seguridad en la nube. Básicamente, vendemos ingeniería de seguridad como un servicio.
La idea es obtener el máximo rendimiento en el menor tiempo posible, generalmente una o dos semanas. No se les contrata para resolver problemas sencillos, sino para profundizar en ellos. Detectan problemas lógicos o complejas cadenas de problemas con un impacto inesperado. Es probable que su JIRA ya esté repleto de hallazgos generados por sus propias herramientas automatizadas.
Curiosamente, si revisas algunos de sus informes, verás que en los informes centrados en la ingeniería de seguridad no se incluyen pruebas de concepto ni demostraciones reales de explotación exitosa. La prueba ya está en el código. La explotación es una tarea redundante y que consume mucho tiempo, sin ningún valor añadido real para el cliente. ¿En un equipo rojo? ¡Por supuesto! Pero en pruebas de penetración, no tanto.
Estadísticamente, y por experiencia propia, se encuentran más y mejores vulnerabilidades al leer el código o realizar ingeniería inversa del sistema, en comparación con explorar a ciegas algo expuesto en la red.
Te centras en los componentes clave y localizas la causa raíz. Cuando detectas un patrón, dejas de informar casos individuales y te dedicas a describir la naturaleza de la práctica insegura repetida.
Identificas la causa raíz en el código. Si dispones de tiempo y el cliente también puede dedicarle tiempo, puedes ofrecer soluciones de detección y mitigación a largo plazo: una herramienta de fuzzing, una consulta CodeQL, una recomendación de cambio para CI/CD, etc.
En cambio, las típicas pruebas de penetración de caja negra se pueden resumir en pocas palabras: parchea tus sistemas, actualiza tus dependencias, audita tus contraseñas, evita el phishing y sigue las recomendaciones de seguridad. Luego, corrige esto, esto, esto, esto, esto, esto, esto y esto. Estarás bien hasta el año que viene, cuando volvamos a realizar la prueba y te digamos lo mismo, con nuestra plantilla de informe actualizada y un lenguaje ligeramente mejorado.
5. IA + SAST: El verdadero punto de inflexión
Aquí es donde las cosas empiezan a pintar bien. ¡Nunca habíamos sido tan eficientes y razonablemente fiables a gran escala a la hora de estudiar, comprender el código y encontrar problemas en el código y la configuración!
Hemos implementado diversas versiones de soluciones SAST (Pruebas de Seguridad de Aplicaciones Estáticas) y DAST (Pruebas de Seguridad de Aplicaciones Dinámicas). Si bien estas soluciones mejoraron su escalabilidad, también lo hicieron los falsos positivos y los recursos humanos necesarios para revisar los resultados. CodeQL, Semgrep y herramientas similares han mejorado considerablemente y ahora forman parte de la mayoría de nuestros proyectos, ya que funcionan bien una vez optimizadas.
¿En qué se diferencia el SAST impulsado por IA de las pruebas de penetración automatizadas con IA? En el caso de las pruebas de penetración clásicas (automatizadas), contábamos con una solución parcialmente funcional que escalaba, pero no resolvía las causas raíz; simplemente señalaba los síntomas a gran escala.
En el caso del SAST impulsado por IA, gracias a la naturaleza de las pruebas de caja blanca y a la creciente precisión de los modelos para comprender el código, se puede profundizar en el análisis a un costo y tiempo muy razonables: encontrar la causa raíz de los problemas, identificar todas sus variantes, generar una prueba de concepto y, como colofón, ¡proporcionar una solución! Si bien aún requiere cierta intervención humana, el valor es inmenso.
En Google, OpenAI y otras organizaciones, existen sistemas que consumen tokens de forma excesiva. Muchos han experimentado con procesos similares internamente, obteniendo un retorno de la inversión de 10, 50 o 100 veces mayor en valor potencial de errores en comparación con el coste de los tokens utilizados.
Compárese esto con el enfoque de caja negra: "Tras varias horas de pruebas a ciegas, envié 100 solicitudes a este punto de conexión para confirmar una inyección SQL. Aquí tienen un enlace a OWASP y una prueba de concepto en Python. Para ahorrar tokens, les dejo a ustedes y a sus desarrolladores la tarea de encontrar las otras 100 variantes de este problema".
Resulta que con 200 dólares en tokens puedes o bien hacer funcionar tu agente de pruebas de caja negra hasta que encuentre algunos errores de forma remota, explotarlos y considerarlo una victoria, o bien gastar la misma cantidad de dinero y una fracción del tiempo para encontrar, clasificar, explotar, analizar variantes, parchear e informar sobre una docena de ellos consumiendo código.
Estos monstruos que consumen tokens crearán, y de hecho ya han creado, su propia cadena de cuellos de botella y problemas de ruido. Probablemente muchos de ustedes hayan oído hablar o participado en alguna discusión sobre FFMPEG vs. Google AI. Pero, por suerte, ya contamos con una solución (casi) funcional. Es menos arriesgado permitir que un LLM envíe una solicitud de extracción que dejar que gestione la infraestructura de red y borre una o dos bases de datos en el proceso.
Conclusión
Por favor, no se enfaden conmigo cuando diga que las pruebas de penetración, en su forma clásica tal como las conocemos, incluso con un cambio de motor de IA, están muertas.
No está del todo muerto. Deben seguir coexistiendo diferentes enfoques de pruebas, y las plataformas de recompensas por errores continuarán creciendo. Pero, al final, si medimos los resultados, especialmente con la trayectoria que están siguiendo las pruebas SAST y DAST impulsadas por IA, será muy difícil que el enfoque de caja negra logre alcanzarlo en términos de eficiencia e impacto a largo plazo.
En 2025, tras presenciar las increíbles hazañas de las APT, si aún te preguntas si tu red es vulnerable a ataques, necesitas un toque de atención. La respuesta es SIEMPRE sí. Estarás en mejor posición si te centras en el CÓMO, analizando cada caso individualmente, como suele ser el enfoque de las pruebas de caja negra. Pero si buscas una solución más eficaz y a largo plazo para identificar y resolver problemas, las pruebas de caja negra (automatizadas) probablemente sean uno de los métodos menos eficientes.
Saber que estamos condenados a sufrir una brecha de seguridad de una forma u otra no hace que esas pruebas sean irrelevantes. Simplemente significa que es mejor centrarse en lo que sucede después de una brecha y mejorar en ese aspecto. ¿SOC impulsado por LLM? ¿XDR que consumen tokens? ¿Despliegue impulsado por IA siguiendo las mejores prácticas de seguridad? Por ejemplo, ¡Google anunció su Agentic SOC! Eso debería significar algo, considerando la dirección que están tomando.
Sea lo que sea que esté por venir, me intriga. Simplemente no apostaría por agentes de LLM usando Nmap y lanzando payloads a ciegas hasta que uno funcione. Si identifican automáticamente el objetivo, obtienen una copia local para ingeniería inversa o auditoría, encuentran una vulnerabilidad y luego la explotan (¿Hola, XBow?), ¡por supuesto! Me apunto. Pero, pensándolo bien, ¿no se está adentrando eso en el terreno de SAST?
Como dato adicional, le pedí a ChatGPT que revisara todo el historial de OWASP TOP 10 desde sus inicios. Al parecer, las clases de errores simplemente cambian de posición. Ocasionalmente aparecen nuevos, ¡pero nunca desaparecen! ¿Cuántas pruebas de penetración y exploits más necesitamos para enseñar a la gente cómo manejar correctamente un ../../..?
Fuente: Hamid Kashfi