El software cambia continuamente, la validación de seguridad no. Esto está creando una brecha tal que, en industrias reguladas como la banca, los ciclos de lanzamiento a menudo se ralentizan no porque la ingeniería no pueda avanzar más rápido, sino porque la validación no puede seguir el ritmo.
En general, la industria está de acuerdo en que las pruebas de instantáneas no son suficientes; nuestra encuesta a 200 CISOs y 200 líderes de ingeniería reveló que el 79% está preocupado de que los problemas pasen desapercibidos entre las pruebas de penetración programadas, mientras que el 85% afirma que los hallazgos están desactualizados al menos en ocasiones. Pero nadie (al menos hasta ahora) puede ponerse de acuerdo sobre cómo el pentesting continuo lo reemplaza en la práctica.
¿Qué significa el pentesting continuo?
En un hilo reciente de Reddit, alguien planteó una pregunta aparentemente sencilla:
“¿Alguien está realmente haciendo pentesting continuo en lugar de auditorías anuales?”
Nadie se puso de acuerdo sobre lo que realmente significaba el “pentesting continuo”. Solo en un hilo, el pentesting continuo pasó de significar “escaneo automatizado glorificado” a pruebas manuales completas realizadas con mayor regularidad. Otras definiciones incluían compromisos regulatorios extensos o pruebas por lanzamiento centradas en los cambios. También hubo varios comentaristas descontentos que claramente se habían sentido defraudados por empresas que habían comercializado un verdadero producto continuo, solo para ofrecer algo completamente diferente.
Antes de profundizar en esto, acordemos la definición que utilizaremos para el pentesting en este artículo. Ejecutar escaneos de vulnerabilidades en cada lanzamiento no es pentesting. Las pruebas ofensivas reales requieren razonar sobre el comportamiento de la aplicación, explorar flujos de trabajo autenticados, encadenar rutas de ataque y validar la explotabilidad mediante ataques reales. El pentesting continuo solo tiene sentido si la propia prueba es significativa.
Donde el pentesting humano deja de escalar
El instinto correcto es que el pentesting continuo debe seguir los cambios. Cuando algo cambia, hay que validarlo. Esto a menudo se denomina “pruebas delta”.
Pero la objeción a esto, como señala el hilo anterior, es que no todos los cambios justifican pruebas, y puede ser difícil decidir qué cambios importan, cómo fijar el precio en consecuencia, cómo utilizar mejor a las personas para que estén disponibles “a demanda” y cómo asegurarse de que no se está probando solo ruido.
Los pentesters o equipos rojos poseen una creatividad y un juicio de los que puede que carezcan las herramientas de pentesting, pero se enfrentan a una situación difícil, que cada vez lo es más. El factor limitante no es su calidad, sino que no pueden aplicar ese pensamiento a gran escala y a la velocidad a la que cambia la superficie de ataque.
Están limitados por las horas, tienen que reconstruir el contexto del sistema cada vez que lo prueban, y eso sin tener en cuenta la planificación, coordinación y los informes necesarios para cada pentest.
Aquí radica la cuestión; un modelo basado únicamente en la coordinación humana no puede escalar al ritmo actual de despliegue. Aquí es donde el pentesting de IA continuo puede ayudarles.
Pero incluso con la IA, hay matices. Continuo no significa probarlo todo todo el tiempo; eso sería un enorme desperdicio de recursos. Que se pueda, no significa que se deba. El pentesting de IA continuo puede determinar si un cambio afecta significativamente a la superficie de ataque o a la postura de seguridad, y solo iniciar las pruebas cuando esto ocurra.
El compromiso forzado entre cobertura y profundidad
Uno de los mayores dilemas para los testers experimentados es decidir cuánto centrarse en la amplitud frente a la profundidad. Si intentan cubrir una gran superficie rápidamente, se centran en clases de vulnerabilidades comunes y patrones de ataque conocidos. Pueden detectar varios problemas, pero tendrán menos tiempo para profundizar en otras interacciones, donde pueden acechar problemas de mayor gravedad. Por otro lado, si profundizan en su lugar, centrándose en rutas de ataque complejas y encadenando comportamientos a través de la aplicación, inevitablemente cubren menos del sistema en general.
Los sistemas modernos agravan este problema porque son más grandes, están más interconectados y se actualizan con mayor frecuencia.
Por eso las vulnerabilidades más profundas, como los fallos lógicos, el control de acceso roto o las cadenas de exploits de varios pasos, son notoriamente difíciles de detectar de forma consistente. En nuestra investigación, más de la mitad de los líderes de seguridad e ingeniería afirman que los fallos lógicos más profundos y las vulnerabilidades de varios pasos a menudo se pasan por alto en los proyectos de pentesting tradicionales.
Eso no es una crítica a las habilidades de los pentesters; es un reflejo de las limitaciones bajo las que operan.
Pero también refuerza la misma conclusión: la validación continua no consiste solo en realizar pruebas con más frecuencia. Se trata de obtener la cobertura adecuada al hacerlo.
El pentesting continuo puede encargarse de la deriva de la superficie para que los equipos ofensivos experimentados puedan centrarse en los activos más críticos.
El pentesting continuo tiene un problema de arquitectura
Muchas herramientas se centran en el pentesting automatizado y en la generación de ataques. El verdadero desafío para el pentesting continuo es construir un sistema capaz de ejecutar pruebas ofensivas de forma continua contra una aplicación en constante cambio.
En primer lugar, la arquitectura debe permitir un contexto de sistema suficiente. Esto significa visibilidad de la arquitectura de la aplicación, las API, el código fuente y la configuración de la infraestructura, para que se puedan explorar rutas de ataque realistas. Si una herramienta solo ve los endpoints expuestos, pasará por alto rutas de ataque que se ejecutan a través de la comunicación interna de servicios.
En segundo lugar, el sistema necesita entender cuándo deben ejecutarse las pruebas. Esto significa detectar los cambios que realmente afectan a la superficie de ataque y activar las pruebas cuando estos se producen. Sin esto, las pruebas «continuas» se ejecutan constantemente y desperdician recursos, o recurren a escaneos programados que pasan por alto los cambios que introducen riesgo.
En tercer lugar, las aplicaciones modernas implican miles de interacciones entre roles, endpoints y servicios. Esas rutas deben explorarse en paralelo en lugar de una a una. Un sistema que realiza pruebas secuencialmente nunca terminará de validar una aplicación moderna antes del siguiente despliegue, por lo que los componentes importantes quedarán sin probar.
En cuarto lugar, los hallazgos deben validarse mediante una explotación real para garantizar que los resultados reflejan vulnerabilidades que son realmente alcanzables y reproducibles; los equipos ya tienen que lidiar con demasiados falsos positivos, no necesitan más.
En quinto lugar, el sistema necesita cerrar el ciclo. El descubrimiento continuo solo importa si las vulnerabilidades pueden corregirse y verificarse con la misma rapidez. Esto significa generar orientación para la remediación, validar las correcciones una vez aplicadas y volver a probar el sistema para garantizar que el problema se ha resuelto realmente.
Y finalmente, el sistema debe aplicar límites de ejecución estrictos, asegurando que las pruebas se mantengan dentro del alcance y no puedan afectar a sistemas no relacionados (consulte nuestro artículo sobre cómo nos aseguramos de que nuestros agentes de pentesting de IA no se salgan del alcance).
Sin ninguno de los puntos anteriores, el pentesting continuo se convierte en poco más que un escaneo automatizado.
El modelo está cambiando
La industria no está confundida sobre si el pentesting necesita evolucionar. Pero no está del todo claro cuál es el nuevo modelo. La vacilación es comprensible. El pentesting tradicional sigue funcionando, simplemente no fue diseñado para software que cambia constantemente.
Sabemos que ejecutar escáneres con más frecuencia no resuelve el problema. Programar más pentests tampoco. La validación tiene que cambiar tan a menudo como lo hace el software.
Pero necesita probar las cosas correctas cuando cambian, mantener la profundidad esperada de un trabajo ofensivo real y asegurar que la superficie de ataque no se desvíe silenciosamente entre las evaluaciones.
Cuando eso ocurre, los equipos rojos pueden centrarse en el trabajo que requiere su experiencia: rutas de ataque complejas, debilidades sistémicas y los activos más críticos.
El pentesting continuo no reemplaza a los equipos ofensivos, les proporciona la cobertura que nunca tuvieron.
¿Quiere ver cómo es el pentesting continuo en la práctica?
Aikido Infinite prueba cada cambio significativo en su aplicación, explora rutas de ataque reales, valida la explotabilidad y verifica las correcciones antes de que el código llegue a producción.
Empiece el pentesting en 5 minutos o reserve una demostración para ver cómo funciona realmente el pentesting continuo.
