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 agenticas en profundidad. Esas revisiones «agentescas» 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; revisiones de código en tiempo real ( análisis de código con IA ), a las que el mercado suele referirse como«IA SAST», que analizan la lógica de una base de código sin necesidad de desplegarse en ningún sitio; o revisiones de código 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
Estas cuatro herramientas no son competidoras. Cada una funciona de manera diferente, y 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», « análisis de código con IA » y «AI Pentest» se basan en el razonamiento lógico y la intención, detectando lo que « SAST » no puede detectar desde un punto de vista estructural, 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: análisis de código con IA. El mismo razonamiento que en Deep PR Review, aplicado a todo el repositorio en lugar de a un cambio cada vez. Este alcance lo 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 las 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.
análisis de código con IA comprueba la intención y la lógica, sin un entorno en producción
En lugar de buscar coincidencias en patrones, análisis de código con IA (lo que en el mercado se suele denominar « SAST o de 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 controlador de ruta 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 monorepos que abarcan front-end, back-end e 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 Deep PR Review a nivel de PR, pero la diferencia radica en que Deep PR Review detecta problemas en cada cambio, comparando una solicitud de incorporación de cambios (pull request) con el conjunto del código fuente. Por su parte, « análisis de código con IA » analiza todo el código fuente de una sola vez, por lo que resulta más adecuado para cambios importantes y lanzamientos completos (es el paso recomendado en «Cómo empezar»), mientras que Deep PR Review se encarga del análisis continuo a nivel de PR a partir de entonces.
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 la que haría un desarrollador al echar un vistazo rápido en busca de errores evidentes que a una revisión exhaustiva. análisis de código con IA integra ese mismo modelo en un sistema que ejecuta tareas de reconocimiento, busca en paralelo y valida de forma independiente en todos los repositorios, y esa coordinación es la que explica la mayor parte de la diferencia real en el número de errores detectados.
La disyuntiva entre el análisis tradicional SAST y análisis de código con IA no se reduce únicamente al coste. El razonamiento sobre 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 funcionamiento sobre la que actuar, los resultados se priorizan en función de su probabilidad de ser reales, en lugar de confirmarse mediante la ejecución. La velocidad y el determinismo de SAST son los que permiten integrarlo directamente en CI/CD, por lo que análisis de código con IA resulta más adecuado para cambios significativos y lanzamientos importantes que para 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 « análisis de código con IA ». 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 reales 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 trataremos con más detalle en la siguiente sección). análisis de código con IA puede deducir que existe un fallo de lógica de negocio, como un IDOR, a partir del código; 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 análisis de código con IA no exige, ya que lee directamente desde la fuente. Una vez que se dispone de 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; de ahí que, en cuanto a coste de computación, una prueba de penetración se sitúe por encima tanto de SAST como de análisis de código con IA .
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. análisis de código con IA no puede sustituir a una prueba de penetración en vivo cuando el cumplimiento normativo lo exige, pero realizarla previamente puede resultar beneficioso. Corregir los fallos lógicos antes de la prueba de penetración auditada supone que habrá menos incidencias que detectar en la prueba en vivo, 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 resultados que obtiene (así como el coste de llevarlas a cabo). De las 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 técnicas (el razonamiento basado en el acceso al código fuente que se ofrece en análisis de código con IA) 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, en la sección «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?
análisis de código con IA analiza tu código sin ejecutarlo. Es capaz de detectar que una solicitud llega a una operación peligrosa y que nada la detiene por el camino, y la señala como vulnerable. Como 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 algo que el modelo no podía 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. análisis de código con IA llega a código al que una prueba de penetración nunca tiene acceso, como todo lo 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 análisis de código con IA señala, una vez que existe un objetivo real contra el que realizar la prueba.
¿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 « análisis de código con IA », ejecutándola sobre el código existente para detectar lo que hasta ahora había pasado desapercibido. No hay que 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 nada más esté en marcha. Añadir a partir de ahí la revisión en profundidad de las solicitudes de incorporación de cambios (PR) evita que esa base se salte cuando se implementa código nuevo, detectando problemas de lógica de negocio en cada solicitud de incorporación de cambios sin necesidad de un entorno en 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 diariamente entre la « análisis de código con IA » y la «Deep PR Review». Aplicar primero las capas de análisis 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 detectan 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 conjuntamente, 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 que se fusione. « análisis de código con IA » 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 las cuatro herramientas de forma escalonada, en lugar de elegir entre ellas.
