Hamid Kashfi, con más de 20 años de experiencia en pruebas de penetración y auditorías (más de 400 proyectos), afirma que las pruebas de penetración automatizadas están obsoletas. Aunque no como se podría pensar inicialmente, el autor descartó un borrador más extenso para dejar que Gemini lo acortara y perfeccionara.
¿Por qué las pruebas de penetración automatizadas están muertas?
Las herramientas automatizadas como Nessus o Core Impact ya estaban en desuso hace 10 años, al igual que los informes de 50 páginas. La nueva era impulsada por IA está reviviendo ese enfoque de bajo valor. No se trata de la falta de tokens ni de modelos inestables, sino de distintas razones interrelacionadas.
1. El problema del ruido y la fatiga
Los informes actuales suelen contener 2 o 3 hallazgos clave. Pronto, agentes de IA analizarán redes en profundidad y generarán 100 problemas graves y válidos. Si llevas cinco años realizando pruebas trimestrales a clientes de Fortune 50/500, sabrás que los resultados son similares una y otra vez.
La priorización de las medidas correctivas y el cansancio generan 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.
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 o el mes siguiente. Tu «hallazgo crítico» es simplemente una decisión de negocio.
El funcionamiento es similar a: «¿Nos costará un millón de dólares si se explota?». Si la respuesta es no, no se categoriza ni gestiona como crítico, porque hacerlo inicia una compleja cadena de acciones internas que 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.
2. El verdadero cuello de botella
La industria de la seguridad acaba de 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.
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.
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.
El principal problema no es la precisión de los resultados. 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.
Si accedes 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.
4. El método eficiente: Ingeniería de seguridad
Bien, ¿cuál es la forma más eficiente de hacer las cosas entonces? 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.
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.
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!
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.
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.