La inteligencia artificial (IA) está cambiando la seguridad ofensiva, pero no ha cambiado el estándar más importante: un hallazgo debe probarse antes de que sea útil. Las herramientas asistidas por IA pueden leer código rápidamente, generar cargas útiles, resumir superficies de ataque, explicar API desconocidas y ejecutar flujos de trabajo de prueba repetitivos a una velocidad impresionante. Esta es una verdadera ventaja para los equipos de seguridad. También crea un nuevo tipo de presión, porque la industria ahora puede producir más productos que parezcan más vulnerables que nunca.
El problema es que la producción no es lo mismo que la evidencia. Un informe generado puede parecer pulido, incluir una clasificación de gravedad e incluso contener una prueba de concepto que parezca razonable a primera vista. Nada de eso prueba que el error exista en el entorno implementado. Nada de esto demuestra explotabilidad, impacto o riesgo. En las pruebas ofensivas, la parte difícil nunca ha sido escribir algo que parezca un informe de vulnerabilidad. Lo difícil es demostrar lo que realmente es cierto.
Esa distinción se vuelve más importante a medida que la IA se vuelve más común en los flujos de trabajo de seguridad. La IA puede acelerar el descubrimiento, pero la validación aún depende del conocimiento: conocimiento de los sistemas, protocolos, comportamiento de las aplicaciones, límites de identidad, corrupción de la memoria, lógica empresarial y todos los detalles de implementación que separan una teoría plausible de un exploit real. El futuro de la seguridad ofensiva no pertenecerá a personas que se limiten a producir el mayor número de hallazgos. Pertenecerá a personas y equipos que puedan demostrar lo que importa.
La industria ya está viendo el costo de la producción superficial de IA
Las señales de alerta ya son visibles. Los mantenedores y los programas de recompensas por errores han estado lidiando con una oleada de informes generados por IA de baja calidad, a menudo presentados con evidencia escasa, lenguaje modelado y poca validación significativa. Bugcrowd abordó públicamente este patrón en sus cambios de política en torno a los envíos generados por IA, describiendo una clase de informes que parecían pulidos pero creaban una carga de clasificación innecesaria en lugar de una señal de seguridad útil.
Esto no es sólo un problema de recompensas por errores. Es una vista previa de lo que sucede en cualquier lugar donde se utiliza la IA para crear hallazgos de seguridad sin suficiente juicio humano detrás de ellos. Si una herramienta puede generar un artículo convincente en segundos, las organizaciones recibirán más informes, más alertas y más reclamaciones. A menos que esas afirmaciones sean validadas, el resultado no es una mayor seguridad. Es una cola más grande.
Los equipos de seguridad ya están sobrecargados con resultados de escaneo, alertas de dependencia, problemas de configuración de la nube y hallazgos de cumplimiento. Agregar a eso especulaciones generadas por IA no ayuda a menos que el listón de calidad suba al mismo tiempo. Un hallazgo debe responder claramente a preguntas básicas: qué sucedió, cómo se reprodujo, qué controla el atacante, qué límite se cruzó y cuál es el impacto demostrado. Sin eso, el informe puede ser interesante, pero no está preparado para impulsar acciones de ingeniería.
“Parece vulnerable” no es lo mismo que vulnerable
Uno de los hábitos más peligrosos en las pruebas ofensivas es confundir un patrón sospechoso con una vulnerabilidad validada. La IA puede empeorar ese hábito porque es buena para explicar por qué algo podría estar mal. Un modelo puede ver la entrada del usuario cerca de una consulta de base de datos y describir la inyección de SQL. Es posible que vea una URL recuperada y sugiera SSRF. Puede ver una API peligrosa en una ruta de código y describir la ejecución remota de código. A veces el modelo apunta a un problema real. Otras veces, faltan las condiciones que deciden si el tema importa.
Un evaluador todavía tiene que demostrar la accesibilidad. ¿La entrada controlada por el atacante realmente llega a la operación peligrosa? ¿Se requiere autenticación? ¿Se aplica la autorización en otro lugar? ¿Está habilitada la característica vulnerable? ¿La configuración de producción expone la ruta del código? ¿La aplicación normaliza, codifica, desinfecta o rechaza la carga útil antes de que importe? ¿El problema cruza un límite de confianza o simplemente afecta una ruta interna sin ningún impacto práctico en la seguridad?
Estas preguntas son donde comienza la verdadera seguridad ofensiva. También es allí donde la automatización superficial a menudo falla. La IA puede generar hipótesis rápidamente, pero las hipótesis no son hallazgos. Un buen evaluador trata los resultados de la IA como una pista para investigar, no como una conclusión para transmitir.
Por qué el conocimiento sigue siendo importante
Los mejores profesionales de la seguridad ofensiva son valiosos porque entienden los sistemas, no porque puedan ejecutar herramientas. Las herramientas siempre han sido parte del trabajo, pero el rendimiento de las mismas nunca ha sido suficiente. Un escáner web puede identificar un parámetro que refleja la entrada. Un analizador estático puede señalar una función peligrosa. Un fuzzer puede provocar un accidente. Un modelo de lenguaje puede describir una ruta de ataque plausible. En todos los casos, alguien todavía necesita entender qué significa la señal.
Esa comprensión generalmente se obtiene mediante la repetición. Los investigadores senior pasaron años haciendo el trabajo manualmente: rastreando solicitudes, leyendo fuentes, aplicando ingeniería inversa a binarios, depurando fallas, escribiendo códigos de explotación, rompiendo flujos de autenticación y aprendiendo cómo fallan los sistemas reales. Ese proceso construye memoria e instinto. Le enseña al practicante cuándo un hallazgo es probablemente real, cuándo una herramienta está siendo engañada y cuándo un pequeño error puede volverse grave si se encadena con otra cosa.
Este tipo de conocimiento es difícil de falsificar. Aparece en las preguntas que hace un evaluador. Se muestra en la forma en que se escribe un informe. Se demuestra si el evaluador puede explicar la ruta del exploit sin esconderse detrás de un lenguaje genérico. Lo más importante es que aparece cuando falla el primer intento. Una persona que entiende el sistema puede adaptarse. Una persona que sólo acepta la explicación de la herramienta a menudo se queda estancada.
La IA puede hacer que los buenos evaluadores sean más rápidos, pero también puede oxidar a las personas
Existe una preocupación real entre los profesionales experimentados de que la dependencia excesiva de la IA pueda oxidar a la gente. Este no es un argumento contra la IA. Es un argumento de aprendizaje humano. Cuando una herramienta responde a todas las preguntas al instante, resulta tentador dejar de recordar detalles. Cuando escribe la primera versión de cada guión, resulta tentador dejar de practicar. Cuando explica cada ruta de código, carga útil, falla y mensaje de error, resulta tentador dejar de construir el modelo mental usted mismo.
Esa conveniencia tiene un costo. La seguridad ofensiva recompensa la profundidad, el reconocimiento de patrones y el recuerdo técnico. Los hallazgos más difíciles a menudo surgen al reconocer que un comportamiento en un área viola un supuesto en otra parte. Provienen de saber cómo han fallado antes los analizadores, marcos, asignadores, proveedores de identidad y sistemas de autorización. Surgen de ver la conexión entre pequeños detalles que no parecen importantes de forma aislada.
Si los practicantes dejan de ejercitar esos músculos, pierden parte de la habilidad que los hace efectivos. El riesgo no es que la IA inutilice a los profesionales de la seguridad. El riesgo es que la gente deje que la IA piense demasiado y demasiado pronto, y luego confundan fluidez con competencia. Las indicaciones son útiles, pero no reemplazan el juicio.
La mayoría de las pruebas asistidas por IA todavía utilizan técnicas familiares
Gran parte del marketing de seguridad de la IA puede hacer que parezca que el aprendizaje automático está descubriendo vulnerabilidades a través de algún tipo de razonamiento completamente nuevo. A veces, los modelos muestran patrones que un ser humano podría pasar por alto, especialmente en bases de código grandes y desconocidas. Eso es útil. Pero en muchos flujos de trabajo prácticos de pruebas ofensivas, las técnicas subyacentes aún son familiares: enumerar puntos finales, inspeccionar parámetros, rastrear el flujo de datos, comparar comportamientos autenticados y no autenticados, generar cargas útiles, ejecutar fuzzers, observar respuestas y determinar si el estado de la aplicación cambió de una manera relevante para la seguridad.
En otras palabras, muchos sistemas basados en IA están orquestando técnicas de prueba conocidas a escala. Pueden planificar, ejecutar, observar e iterar más rápido que un humano que hace todo a mano. Se trata de una mejora significativa, pero no elimina la necesidad de comprender el resultado. Si el sistema informa de un error de autorización, alguien todavía tiene que saber si la relación entre objetos es importante. Si informa un error de corrupción de memoria, alguien todavía tiene que razonar sobre la accesibilidad, el contexto del fallo, las mitigaciones y la explotabilidad. Si informa una debilidad de la API, alguien aún tiene que determinar si el comportamiento observado viola el modelo de confianza de la aplicación.
El uso más valioso de la IA no es reemplazar esas decisiones. Su objetivo es reducir el trabajo mecánico a su alrededor para que los evaluadores expertos puedan dedicar más tiempo al análisis y la validación.
Cómo se ve una buena validación
Un hallazgo ofensivo validado debe ser específico, reproducible y vinculado al impacto. No debería requerir que el lector adivine por qué es importante el tema. El informe debe dejar la ruta del exploit lo suficientemente clara como para que un ingeniero pueda reproducirla y un líder de seguridad pueda comprender el riesgo. Eso no significa que cada número necesite una dramática cadena de exploits o una prueba de concepto al estilo de una película. Significa que la evidencia debe respaldar la afirmación.
Para las pruebas asistidas por IA, los equipos deben trazar una línea clara entre las pistas y los hallazgos validados. Una pista es algo que vale la pena investigar. Un hallazgo validado es algo que ha sido probado y comprobado. Mezclar esas categorías crea confusión y hace perder tiempo. Un buen flujo de trabajo puede utilizar absolutamente la IA para generar clientes potenciales, pero la promoción del cliente potencial al hallazgo debería requerir evidencia.
Lista de verificación de validación práctica
Un estándar de validación práctico no tiene por qué ser complicado. Antes de que una pista se convierta en un hallazgo informado, el evaluador debería poder responder preguntas como estas:
- ¿Qué comportamiento específico se observó y dónde ocurrió?
- ¿Qué entrada, identidad o estado controlado por el atacante se requería?
- ¿Qué límite de seguridad se cruzó, como autenticación, autorización, arrendamiento, confianza, privilegios o seguridad de la memoria?
- ¿Qué pasos exactos reproducen el comportamiento en el entorno objetivo?
- ¿Cuál es el impacto demostrado, no sólo el peor de los casos teóricos?
- ¿Qué evidencia muestra que el problema es accesible y relevante en la configuración implementada?
- ¿Qué debería cambiar una solución y cómo puede el equipo confirmar que funciona?
Este tipo de lista de verificación ayuda a mantener a la IA en el papel correcto. Puede ayudar a producir candidatos, sugerir ideas para pruebas y acelerar la reproducción. No se debe permitir omitir el paso en el que un ser humano verifica la afirmación con la realidad.
El papel humano sigue siendo técnico
Una de las realidades subestimadas de las plataformas de seguridad de IA es que la validación humana sigue siendo muy importante entre bastidores. Esto no debería sorprendernos. La seguridad ofensiva siempre ha requerido juicio, y el juicio es especialmente importante cuando los hallazgos adquieren consecuencias. La persona que revisa la evidencia tiene que decidir si la ruta de explotación es realista, si el entorno importa, si el problema es aislado o encadenable y si la afirmación de gravedad está justificada.
Ésta no es sólo una función administrativa de control de calidad. Es un trabajo técnico. Las fallas de autorización a menudo dependen de la lógica empresarial y las relaciones entre objetos. Las vulnerabilidades de API pueden requerir comprender cómo interactúan los roles, los inquilinos y los recursos. La corrupción de la memoria requiere razonamiento sobre el estado de falla, el control, las mitigaciones y las primitivas de explotación. Los hallazgos en la nube dependen en gran medida de la identidad, las políticas de confianza y el comportamiento específico del servicio. La IA puede ayudar con todo esto, pero no elimina la necesidad de contar con alguien que sepa lo que está mirando.
Cuanto mayor es el impacto de un hallazgo, más importante se vuelve el papel humano. Las organizaciones no quieren adivinar con certeza cuándo el resultado puede afectar las prioridades de ingeniería, la confianza del cliente, las obligaciones de cumplimiento o las decisiones de riesgo de los ejecutivos. Necesitan pruebas.
Evitar el impacto exagerado
Los informes generados por IA también pueden exagerar la gravedad. La entrada reflejada no es una secuencia de comandos entre sitios hasta que se demuestre la ejecución de la secuencia de comandos. Una recuperación de URL no es SSRF significativa hasta que el evaluador pueda mostrar acceso a algo que el atacante no debería alcanzar. Una función peligrosa no es la ejecución remota de código a menos que se pueda demostrar su accesibilidad, control y ejecución. Estos errores no sólo son vergonzosos; erosionan la confianza entre los equipos de seguridad y los equipos de ingeniería. Sucede con bastante frecuencia que un hallazgo obtenga una calificación CVSS 9.8, cuando en realidad puede que ni siquiera sea un hallazgo.
Los investigadores experimentados tienen cuidado con el impacto porque saben que hay que ganárselo. Un error en una función exclusiva para administradores no conlleva el mismo riesgo que un error no autenticado en Internet. Una falla puede ser una denegación de servicio, una ruta hacia la ejecución de código o simplemente un problema de confiabilidad no explotable, según el contexto. Una verificación faltante en una ruta de código puede ser grave o puede estar protegida por un control en otro lugar. La única manera de saberlo es validarlo.
Una buena validación evita tanto la subnotificación como la sobreinformación. Ayuda a los evaluadores a evitar llorar, pero también les brinda la evidencia necesaria para presentar un caso sólido cuando el problema es realmente grave. Tenable también planteó recientemente desafíos en este espacio, incluido el hecho de que a menudo hay combinaciones contextuales críticas que también se pasan por alto.
Cómo deberían utilizar los equipos la IA sin perder habilidades
El objetivo correcto no es evitar la IA. La tecnología es demasiado útil para eso. El objetivo correcto es utilizarlo de una manera que fortalezca las pruebas ofensivas en lugar de debilitar a las personas que las realizan. La IA debería ayudar a los evaluadores a moverse más rápido, explorar más hipótesis y reducir el trabajo repetitivo. No debería convertirse en un sustituto del aprendizaje de cómo se comportan los sistemas.
Los líderes de seguridad pueden fomentar ese equilibrio estableciendo expectativas en torno a la evidencia y la capacitación. Los evaluadores junior aún deberían aprender los fundamentos antes de subcontratar gran parte del proceso. Los evaluadores experimentados deberían utilizar la IA como multiplicador de fuerza, no como autoridad. Los equipos deben revisar no sólo si se generó un hallazgo, sino también si el evaluador puede explicarlo y reproducirlo. Esa explicación es donde la verdadera comprensión se hace visible.
Un programa saludable de pruebas ofensivas asistido por IA debería recompensar el impacto validado sobre el volumen. Debería medir la calidad de la señal, no sólo encontrar el recuento. Debería preservar la práctica manual en áreas como manipulación de solicitudes, revisión de código, depuración, desarrollo de exploits, modelado de amenazas y análisis de impacto. También debería utilizar la IA como herramienta de enseñanza: cuando el modelo sugiere un problema, el evaluador debe preguntar por qué, probar la afirmación y aprender del resultado.
El estándar no ha cambiado: demuéstrelo
La IA seguirá mejorando. Los agentes mejorarán en la navegación por aplicaciones, la lectura de códigos, la generación de cargas útiles y la documentación de resultados. Parte de este progreso será realmente impresionante y los equipos de seguridad deberían aprovecharlo. Pero la seguridad ofensiva no puede convertirse en un juego de volumen en el que cada teoría plausible se convierta en la carga de clasificación de alguien más.
El estándar central del campo sigue siendo simple: demostrarlo. Demuestre que el error existe. Demuestre que el atacante puede alcanzarlo. Demuestre el impacto. Demostrar el riesgo empresarial. Demuestre que la solución funciona. La IA no baja ese estándar. En todo caso, aumenta la importancia de hacerla cumplir, porque ahora es más fácil que nunca producir resultados convincentes pero no probados.
Los mejores investigadores y equipos de la próxima década no serán los que rechacen la IA. Serán ellos quienes combinen la automatización con el criterio técnico, utilizando la máquina para acelerar el trabajo sin darle la última palabra. Saber cuándo detenerse, inspeccionar, probar y pensar seguirá siendo una ventaja competitiva. El conocimiento sigue siendo importante porque la validación sigue siendo importante, y en seguridad ofensiva, la validación es la diferencia entre el ruido y la verdad.
Ampliaré este tema en SEC660: Pruebas de penetración avanzadas, escritura de exploits y piratería ética en SANS Network Security 2026. La actualización de nuestro curso combina la comprensión manual de temas complejos, como la escritura de exploits, e instruye cómo aprovechar la IA para ayudar a automatizar tareas específicas.
Regístrese para SANS Network Security aquí.
Nota: Este artículo ha sido escrito y contribuido por expertos.y Stephen Sims, miembro de SANS.
