En la actualidad existen cuatro formas realmente distintas de buscar vulnerabilidades en una aplicación, y cada una de ellas comprueba algo que las demás, por su propia estructura, no pueden. Esto abarca un espectro que va desde la comparación basada en patrones (conocida como « SAST » tradicional, que compara el código con patrones conocidos) hasta las revisiones agentivas en profundidad. Esas revisiones «agentes» pueden ser señales tempranas (Deep PR Reviews), que analizan cómo un cambio interactúa con el código en otras partes del repositorio; auditorías de seguridad del código (lo que el mercado suele denominar«IA SAST»), que analizan la lógica de una base de código sin necesidad de implementarse en ningún sitio; o revisiones de seguridad en tiempo real ( pentesting de IA), que funcionan de la misma manera, pero sobre un objetivo activo y en ejecución, y demuestran lo que encuentran intentando explotarlo. Este artículo te ayuda a comprender qué herramienta es la más adecuada para cada caso de uso.
TL;DR
Estos cuatro no son competidores. Cada uno funciona de manera diferente, no solo a distintas profundidades. « SAST » es determinista: el mismo código siempre produce el mismo resultado, pero solo para los patrones que ya conoce. Por su parte, «Deep PR Review», «Code Security Audit» y «AI Pentest» se basan en el razonamiento lógico y la intención, detectando lo que « SAST » no puede detectar estructuralmente, en distintos ámbitos y en diferentes momentos del ciclo de vida.
Cobertura: SAST. Amplia, continua y económica. Se ejecuta en cada confirmación, solicitud de incorporación de cambios y patrón conocido. Esta es tu puerta de entrada. También resulta muy valiosa en el IDE, donde puede ejecutarse mientras el desarrollador o el agente está creando código, de modo que obtienes información antes incluso de que se confirme ningún código.
Señal temprana: Revisión exhaustiva de las pull requests. Analiza la lógica de negocio de cada solicitud de incorporación de cambios (pull request), detectando vulnerabilidades de tipo «IDOR» ( control de acceso roto) y otros fallos que tanto « SAST » como una revisión humana rápida pasan por alto. Revisa cada cambio en cuanto se abre, analizando cómo afecta ese cambio a otras partes del código.
Confianza: Auditoría de seguridad del código. El mismo razonamiento que en la revisión en profundidad de las relaciones públicas (Deep PR Review), aplicado a todo el repositorio en lugar de a un cambio cada vez. Este alcance la convierte en la capa adecuada para cambios significativos y objetivos difíciles de probar, ya que permite detectar fallos lógicos reales mucho antes de que exista siquiera un objetivo en producción con el que realizar pruebas.
Prueba: Prueba de penetración con IA. El mismo razonamiento, validado en un sistema en funcionamiento mediante una explotación real. Esto proporciona pruebas claras, en lugar de una estimación, razón por la cual también cumple con los requisitos de cumplimiento normativo.
En conjunto, abarcan todo el ciclo de vida: cada commit, cada cambio significativo y cada lanzamiento que requiera verificación. A continuación se detalla lo que abarca cada uno en la práctica, empezando por la capa base.
Lo que comprueb SAST : patrones conocidos, de forma determinista
Pruebas de seguridad de aplicaciones estáticas detecta patrones de error; por ejemplo, un parámetro corrupto que se introduce en una llamada a la base de datos. Si ejecutas el mismo código dos veces, obtendrás exactamente el mismo resultado.
La limitación es que carece de capacidad de razonamiento. Un motor de reglas no dispone de un modelo de lo que la aplicación está haciendo realmente. En su lugar, lee el código línea por línea, buscando coincidencias con patrones que ya conoce, y no es capaz de distinguir entre datos fiables y no fiables a medida que estos se desplazan por la aplicación.
Tomemos como ejemplo la clásica inyección SQL: una entrada del usuario que se introduce directamente en una consulta. Esto sigue ocurriendo, pero en un código maduro rara vez se presenta de forma tan clara. Los datos no fiables suelen introducirse en algún lugar inofensivo, como un encabezado de solicitud « », y luego pasan por varias funciones no relacionadas antes de llegar a un destino final y volverse peligrosos, a menudo varias capas más abajo. Un escáner de coincidencia de patrones no puede seguir esa ruta. No puede separar los datos fiables de los que no lo son a medida que estos se desplazan, por lo que marca cualquier cosa que se parezca a una inyección, independientemente de si un atacante podría llegar a ella o no. Esas alertas inaccesibles son el origen del ruido, y son la razón por la que la coincidencia de patrones le ha dado a SAST su reputación de falsos positivos.
Pero eso no significa que no se deba utilizar « SAST ». Si « SAST » señala doce problemas el lunes y nueve el martes en un código idéntico, los desarrolladores dejarán de confiar en él. Las investigaciones muestran que el 65 % de los equipos afirman que los falsos positivos les obligan a adoptar comportamientos de riesgo, ya sea retrasando las correcciones, ignorando las alertas o saltándose las comprobaciones, aunque AutoTriage de Aikido está diseñado específicamente para filtrar ese ruido antes de que llegue al desarrollador. Incluso con ese coste, SAST sigue siendo lo suficientemente económico como para controlar cada commit, que es exactamente lo que necesitan la CI/CD, las pruebas de regresión y el cumplimiento normativo.
Deep PR analiza los motivos de un cambio antes de fusionarlo
Revisar un diff por sí solo no permite apreciar cómo se comporta ese cambio una vez que se integra con el resto de la aplicación. Deep PR Review (a menudo denominado «revisión de código con IA» en el sector) está diseñado para ir más allá del diff. En lugar de evaluar un cambio de forma aislada, analiza cómo interactúa ese cambio con el código del resto del repositorio, incluidas las bibliotecas compartidas y los servicios de los repositorios vinculados. Es, en esencia, lo que le pedirías a un ingeniero sénior que hiciera, si tuviera la capacidad para rastrear realmente todas las dependencias antes de aprobar una solicitud de incorporación de cambios (ojalá fuera así). Como resultado, puedes detectar errores como fugas de datos cruzadas o « control de acceso roto » —fallos en la lógica de negocio que ni una revisión humana rápida ni una herramienta de comparación de patrones serían capaces de detectar, ya que nada de ello es visible solo a partir de las líneas modificadas—.
Este tipo de hallazgos suelen aparecer, de otro modo, en una prueba de penetración o en el entorno de producción, semanas o meses después de que se haya escrito el código, cuando la persona que lo escribió ya no está en el proyecto y no dispone del contexto necesario para explicar su decisión. Deep Review los detecta antes, directamente en la propia solicitud de incorporación de cambios, de modo que la persona que introdujo el cambio aún recuerda por qué lo escribió así. Se pueden aportar comentarios directamente en la solicitud de incorporación de cambios, de modo que frases como «esto es intencionado» o «se trata de un falso positivo» aportan claridad sin tener que cambiar de herramienta ni salir de la revisión.
La auditoría de seguridad del código comprueba la intención y la lógica, sin un entorno en producción
En lugar de buscar coincidencias en patrones, Code Security Audit (lo que en el mercado se suele denominar « SAST o con IA») lee tu código fuente y lo analiza tal y como lo haría un ingeniero sénior durante una revisión. Sigue las referencias entre archivos, rastrea una solicitud desde el gestor de rutas hasta la consulta a la base de datos y comprueba si el código hace lo que se supone que debe hacer. Puede hacerlo en un repositorio o en varios repositorios conectados, incluidos los monorrepositorios que abarcan el front-end, el back-end y la infraestructura como código. Lo único que necesita es acceso al repositorio.
El razonamiento permite detectar fallos en la lógica de negocio, algo que un « SAST » no puede hacer. Los IDOR son un buen ejemplo de ello, ya que se requiere razonamiento para saber si un punto final debe limitarse al usuario solicitante o no. Modificar un identificador de usuario para ver el perfil público de alguien podría considerarse un comportamiento esperado. Modificarlo para ver sus mensajes privados o la configuración de su cuenta constituye una infracción. Esa distinción depende de lo que se supone que debe aplicar el punto final, no del recurso en sí mismo, algo para lo que no se puede escribir una regla estática.
Además, no necesita un entorno de producción para hacerlo. No es necesario configurar un entorno de pruebas (es decir, sin flujo de autenticación configurado), ya que la revisión se ejecuta directamente sobre el repositorio de código, lo que significa que puede acceder a elementos a los que una prueba de penetración en entorno de producción no puede llegar, como código oculto tras un indicador de función, rutas exclusivas para administradores sin credenciales proporcionadas y patrones de denegación de servicio que no sería seguro ejecutar en un sistema de producción. El mismo razonamiento se puede aplicar a las aplicaciones móviles, los contratos inteligentes, las aplicaciones de escritorio y, en esencia, a cualquier lenguaje de programación, incluidos los más antiguos o especializados para los que nunca se ha desarrollado un escáner basado en reglas.
Se trata del mismo tipo de razonamiento que aplica la «Revisión en profundidad de las solicitudes de incorporación de cambios» (Deep PR Review) a nivel de solicitud de incorporación de cambios, pero la diferencia radica en que esta última detecta problemas en cada cambio, comparando una solicitud de incorporación de cambios con el conjunto del código fuente. La «Auditoría de seguridad del código», por su parte, analiza todo el código fuente de una sola vez, por lo que resulta más adecuada para cambios importantes y lanzamientos completos (es el paso recomendado para «Empezar»), mientras que la «Revisión en profundidad de las solicitudes de incorporación de cambios» se encarga del análisis continuo a nivel de solicitud de incorporación de cambios posterior.
Conviene dejar claro por qué esto no es lo mismo que pedirle directamente a un modelo que revise tu código. Cuando se le pide directamente a un modelo, este realiza una revisión general, más parecida a un vistazo rápido que hace un desarrollador en busca de errores evidentes que a una revisión exhaustiva. Code Security Audit integra ese mismo modelo en un marco que lleva a cabo un análisis de reconocimiento, busca en paralelo y valida de forma independiente en todos los repositorios, y esa coordinación es lo que explica la mayor parte de la diferencia real en el número de errores detectados.
La disyuntiva entre la « SAST » tradicional y la «Code Security Audit» no se reduce únicamente al coste. El razonamiento a lo largo de toda una base de código requiere más recursos informáticos y más tiempo que la comparación de patrones y, dado que no hay una aplicación en ejecución contra la que realizar pruebas de explotación, los hallazgos se priorizan en función de su probabilidad de ser reales, en lugar de confirmarse mediante la ejecución. SAST Su velocidad y determinismo son los que permiten integrarlo directamente en CI/CD, razón por la cual Code Security Audit se adapta mejor a cambios significativos y lanzamientos importantes que a cada commit. Sin embargo, el coste y la eficiencia de las funciones basadas en agentes mejoran continuamente, por lo que veremos cómo todas estas capacidades de IA se convierten en algo habitual para las organizaciones.
pentesting de IA lee tu código y lo ejecuta en tu aplicación
pentesting de IA, que es lo que es «Aikido Attack», utiliza el mismo enfoque lógico subyacente que «Code Security Audit». Sin embargo, las pruebas de penetración van un paso más allá, ya que se realizan sobre una aplicación en funcionamiento. Esto significa que pueden intentar una explotación real mediante agentes que envían solicitudes auténticas y mapean una superficie de ataque real.
Esa validación en tiempo real es lo que elimina en gran medida el problema de los falsos positivos (que analizaremos con más detalle en la siguiente sección). Code Security Audit puede deducir a partir del código que existe un fallo en la lógica de negocio, como un IDOR; una prueba de penetración puede intentar el ataque contra el sistema en funcionamiento y confirmar si realmente funciona.
Una prueba de penetración requiere un entorno estable, un sistema de autenticación operativo y roles de usuario reales ya configurados, requisitos que la auditoría de seguridad del código no necesita, ya que lee directamente desde el código fuente. Una vez que existe ese entorno, la prueba en sí se ejecuta rápidamente, pero procesar el tráfico en tiempo real y determinar qué hace realmente una interacción concreta sigue suponiendo un coste mayor por ejecución que el análisis de texto; por eso, en cuanto a coste de computación, una prueba de penetración se sitúa por encima tanto de la auditoría de seguridad del código ( SAST ) como de la auditoría de seguridad del código.
Además, una prueba de penetración basada en IA es la única de estas tres que cumple los requisitos de cumplimiento normativo de marcos como SOC 2 e ISO 27001 para una prueba de penetración en vivo. La auditoría de seguridad del código no puede sustituir a una prueba de penetración en vivo cuando el cumplimiento normativo lo exige, pero llevarla a cabo con antelación puede resultar beneficioso. Corregir los fallos de lógica antes de la prueba de penetración auditada supone que la prueba en vivo detecte menos incidencias, con un menor coste por proyecto.
También cabe destacar que conceder a un agente de pruebas de penetración acceso al código fuente (lo que se conoce como «pruebas de caja blanca») modifica significativamente los hallazgos que se obtienen (así como el coste de llevarlas a cabo). En más de 1.000 pruebas de penetración con IA realizadas en la plataforma de Aikido, las pruebas con acceso al código (caja blanca) revelaron una mediana de siete veces más hallazgos de gravedad alta y crítica que las realizadas sin dicho acceso (caja gris), con aproximadamente la mitad del coste computacional por hallazgo. Las pruebas de caja gris necesitaron 31 ejecuciones del agente para detectar una sola vulnerabilidad, frente a las 15 necesarias en el caso de las de caja blanca. Así pues, al combinar eficazmente ambas (el análisis basado en el acceso al código fuente que ofrece la auditoría de seguridad del código) con la explotación en tiempo real de pentesting de IA, se obtiene una visión más completa que con cualquiera de ellas por separado. Esta es una opción fácil de seleccionar en la interfaz de usuario de Aikido Attack, donde se elige «caja blanca».
Si no sabes muy bien cómo evaluar los productos de pruebas de penetración basados en IA, echa un vistazo a nuestra guía para compradores.
¿Por qué se producen más falsos positivos?
Code Security Audit analiza tu código sin ejecutarlo. Es capaz de detectar que una solicitud llega a una operación peligrosa y que no hay nada en el camino que la detenga, por lo que la señala como vulnerable. Dado que trabaja a partir del código fuente en lugar de un objetivo en producción, algunas de las alertas que genera resultarán estar protegidas por algún elemento que el modelo no pudo detectar solo a partir del repositorio.
Una prueba de penetración añade la explotación en tiempo real a ese mismo razonamiento. Pone a prueba la supuesta vulnerabilidad en la aplicación en ejecución e informa de lo que realmente ha funcionado, por lo que sus resultados vienen acompañados de pruebas, en lugar de una estimación.
Al ejecutar ambas, se cubre la brecha en ambas direcciones. La auditoría de seguridad del código llega a partes del código a las que una prueba de penetración nunca accede, como todo aquello que se encuentra detrás de un indicador de funcionalidad o una ruta de administración sin credenciales. Una prueba de penetración confirma lo que la auditoría de seguridad del código señala, una vez que existe un objetivo en producción sobre el que realizar las pruebas.
¿Cuál necesitas?
Adecuación del gasto al riesgo
El presupuesto y la tolerancia al riesgo determinan qué parte de tu patrimonio debe cubrir cada herramienta de gestión.
Un equipo pequeño obtiene una base sólida y rentable solo con la auditoría de seguridad del código, al ejecutarla sobre el código existente para detectar lo que hasta ahora había pasado desapercibido. No es necesario configurar ningún entorno ni configurar la autenticación, lo que la convierte en la capa que puede empezar a cubrir los riesgos antes de que se haya implementado nada más. Incorporar a partir de ahí la revisión en profundidad de las solicitudes de incorporación de cambios (PR) evita que esa base de referencia se vea afectada a medida que se integra nuevo código, detectando problemas de lógica de negocio en cada solicitud de incorporación de cambios sin necesidad de un entorno de producción ni de un ciclo programado de pruebas de penetración.
Una prueba de penetración basada en IA (Aikido Attack) se sitúa por encima de las capas de razonamiento como una validación periódica y en tiempo real —normalmente anual o coincidiendo con lanzamientos importantes— que comprueba el entorno y la configuración completos, en lugar de limitarse únicamente al código. La mayoría de las organizaciones realizan pruebas de penetración con IA con esa periodicidad, a menudo para cumplir requisitos de cumplimiento normativo como SOC 2 o ISO 27001. La « pentesting de IA » continua (Aikido Infinite) se sitúa por encima de ello como un nivel independiente, destinado a equipos cuya postura de seguridad exige que se compruebe la vulnerabilidad de forma continua, en lugar de a intervalos programados, independientemente del tamaño de la empresa.
La mayoría de los equipos se encuentran en algún punto de esta progresión, donde la verdadera cuestión es definir el alcance: qué repositorios y versiones justifican una prueba de penetración programada, y cuáles pueden cubrirse entre sí, en el día a día, mediante una auditoría de seguridad del código y una revisión exhaustiva de las solicitudes de incorporación de cambios. Aplicar primero las medidas de prevención y corregir los problemas antes de la prueba de penetración es una forma de sacar más partido a esa inversión, ya que un objetivo más limpio implica menos hallazgos en la prueba de penetración dedicados a aspectos que se habrían detectado de forma más económica en fases anteriores.
Considera esto como un valor predeterminado inicial que los equipos deben ajustar en función de su propio perfil de riesgo.
En resumen
En la práctica, la cobertura de todo el ciclo de vida implica ejecutar las cuatro herramientas a la vez, en función de las necesidades en cada momento. « SAST » cubre cada commit y cada pull request, y se ejecuta de forma continua. «Deep PR Review» analiza la lógica de negocio de cada cambio en el momento en que se integra, antes de su fusión. «Code Security Audit» amplía ese mismo análisis a todo el repositorio en los cambios significativos, incluso antes de que se implemente nada, y puede detectar errores de configuración o ajustes específicos del entorno que una prueba en producción podría pasar por alto. AI Pentest cubre la validación periódica en tiempo real, la comprobación más exhaustiva disponible y la que exigen los marcos de cumplimiento normativo, con Continuous Pentest disponible para equipos cuya postura de seguridad requiera dicha validación de forma continua, en lugar de a intervalos programados. Los programas de seguridad más sólidos ejecutan los cuatro, en capas, en lugar de elegir entre ellos.
