Las herramientas de seguridad deterministas, a estas alturas, se han convertido en una parte tan habitual de la seguridad que, durante mucho tiempo, no nos planteamos las alternativas. Con la IA convirtiéndose en un componente central de la seguridad con modelos probabilísticos, es hora de revisar el determinismo y aclarar para qué se necesita. De lo contrario, ¿por qué no empezar a reemplazarlo todo con IA?
En resumen, necesitamos el determinismo por su predictibilidad y eficiencia. Las herramientas deterministas como SAST ofrecen el mismo resultado cada vez que se ejecutan sobre el mismo elemento, de forma eficiente. Por lo tanto, son útiles en una pipeline de CI/CD, defendibles en una auditoría de cumplimiento y sientan las bases para todo lo demás. La IA es excelente para el razonamiento lógico, pero, debido a su impredecibilidad, es mejor reservarla para casos en los que no se necesitan resultados repetibles.
A medida que más herramientas probabilísticas aparecen en el mercado, queremos desglosar cómo el determinismo crea prácticas de seguridad sostenibles, cómo la IA ofrece nuevas posibilidades y cómo ambas pueden combinarse para lograr el máximo impacto.
Cuando las herramientas de seguridad necesitan ser predecibles
Algunas tareas de seguridad exigen consistencia y auditabilidad por encima de todo. Esta necesidad de predictibilidad se manifiesta en todo el flujo de trabajo de seguridad.
Cuando un escáner marca un hallazgo, un desarrollador necesita confiar lo suficiente en él para actuar a las 11 de la noche. Cuando una pipeline de CI/CD bloquea un despliegue, ese bloqueo debe resistir el escrutinio. En una pipeline, su escáner se ejecuta en cada commit o pull request. Si marca 12 problemas el lunes y 9 el martes sobre un código idéntico, eso no es bueno. Los resultados de su pipeline ya no son fiables. Los desarrolladores empiezan a ignorar las alertas porque la señal es inconsistente, y no se puede utilizar la salida del escaneo como una puerta significativa para las fusiones.
De manera similar, las pruebas de regresión dependen de la reproducibilidad. Cuando se corrige una vulnerabilidad y se vuelve a escanear, un resultado limpio debe significar que está realmente solucionada, no que el modelo la haya omitido en esta ejecución. La detección de líneas base y de desviaciones también depende de ello, ya que necesitan saber si un nuevo hallazgo refleja un cambio real en la base de código o simplemente una variación en el escáner.
La predictibilidad también es necesaria para el cumplimiento normativo. Los auditores desean hallazgos consistentes y explicables a lo largo del tiempo, con un registro claro de qué se detectó, cuándo y por qué. Un escáner que produce resultados diferentes en distintas ejecuciones no puede ofrecer eso.
El coste práctico de la falta de fiabilidad en la seguridad degrada lentamente la confianza en las propias herramientas hasta que nadie se toma en serio los hallazgos. La reproducibilidad, la auditabilidad y las bajas tasas de falsos positivos deben ser la base en la que un equipo de seguridad pueda confiar.
Herramientas de seguridad deterministas
SAST es una herramienta de seguridad determinista por excelencia que busca patrones y vulnerabilidades conocidos. Piense en secretos codificados, CVEs conocidos, vulnerabilidades de dependencias y patrones de inyección. Funciona analizando el código en un árbol de sintaxis abstracta y rastreando cómo los datos controlados por el usuario se mueven a través de la aplicación desde los puntos de entrada hasta donde se utilizan. Un hallazgo se remonta a una regla específica que un humano escribió y revisó, y la regla coincide o no. Ejecute el mismo escáner en el mismo código mil veces y obtendrá los mismos hallazgos.
La repetibilidad es lo que hace que las herramientas deterministas sean adecuadas para la parte inicial de una pipeline (son consistentes). Son auditables porque un humano escribió las reglas, y puede ejecutarlas en cada commit sin preocuparse de que resulte demasiado costoso.
DAST también se sitúa en el extremo determinista del espectro. Ejecuta un conjunto definido de simulación de ataques contra una aplicación en vivo y devuelve resultados consistentes y repetibles. Es una comprobación de línea base útil, ya que es más rápido y económico que el pentesting de IA (por ahora). Sin embargo, como cualquier herramienta determinista, solo encuentra aquello para lo que tiene una prueba.
Ciertamente no estamos diciendo que la seguridad determinista, o incluso solo una salida predecible, sea siempre mejor. La otra cara de lo que hace que las herramientas deterministas sean fiables es también donde se encuentran sus limitaciones. Solo encuentran aquello para lo que tienen una regla, por lo que los patrones de ataque novedosos, los fallos lógicos matizados y las vulnerabilidades que requieren comprender el contexto de negocio quedan fuera del alcance de un escáner determinista.
Las herramientas deterministas por sí solas tampoco podrán indicar qué problemas son más importantes en un contexto dado. Algunas herramientas deterministas incluyen un análisis de alcanzabilidad básico (esencialmente un rastreo estático del grafo de llamadas) que puede confirmar si una función vulnerable es realmente invocada. Pero, ¿y si queremos saber si este hallazgo es explotable en nuestra aplicación específica, dados nuestros flujos de datos y lógica de negocio? Pues bien, ese tipo de análisis de alcanzabilidad y priorización requiere una capa de razonamiento adicional más allá de la coincidencia de patrones.
Herramientas de seguridad probabilísticas
Gracias al auge de los LLM, ahora disponemos de nuevas herramientas de seguridad impulsadas por IA, como escáneres de IA, triaje automatizado y pentesting agéntico, que son de naturaleza probabilística. Las herramientas probabilísticas (o herramientas basadas en modelos) no operan con reglas fijas. En su lugar, tratan el código como texto y razonan sobre él.
Debido a que no están ligadas a patrones fijos, una IA sigue la lógica a través de las funciones, infiere la intención y puede descubrir vulnerabilidades. Los fallos de lógica de negocio requieren comprender lo que el código intenta hacer, no solo lo que dice literalmente. Las herramientas probabilísticas sobresalen en esto, y la IA sigue mejorando. La IA puede encontrar nuevas clases de vulnerabilidades y errores dependientes del contexto que antes habrían requerido una revisión humana experta para ser detectados.
Sin embargo, por su naturaleza, estos modelos probabilísticos son impredecibles e inconsistentes. Los resultados pueden (y probablemente lo harán) variar entre ejecuciones. Los LLM generan resultados prediciendo el siguiente token más probable basándose en distribuciones de probabilidad sobre sus datos de entrenamiento, lo que significa que la misma entrada puede producir resultados diferentes dependiendo de la temperatura, el comportamiento de muestreo y lo que haya en la ventana de contexto. Esta variación está bien, incluso es útil, para el pentesting y la búsqueda de nuevas vulnerabilidades. Pero para sus pipelines de CI/CD, no lo es.
También hay un problema de costes cuando se intenta utilizar un modelo de razonamiento probabilístico como escáner de código general en cada commit. James Berthoty de Latio realizó algunas pruebas informales que mostraron que un modelo de IA probabilístico tardaba 17 minutos y 155.000 tokens en descubrir un problema que Opengrep, un motor SAST determinista, encontró en 30 segundos. En cada pull request de una base de código activa, esa compensación no tiene sentido.
Por qué necesitamos ambos
Sin embargo, cuando se combinan modelos deterministas y probabilísticos, y se utiliza cada método según sus puntos fuertes, obtenemos una pipeline de seguridad cuyo todo es mayor que la suma de sus partes. En la práctica, se desea un escaneo determinista ejecutándose en cada commit, detectando clases de vulnerabilidades conocidas de forma rápida y consistente, y luego el razonamiento de IA se sitúa encima, gestionando el triaje y el contexto.
Juntos, cubren el espectro desde "lo que sabemos que es peligroso" hasta "lo que aún no hemos pensado en buscar". Esperamos que esta última categoría crezca. A medida que la IA se integre en más bases de código y los atacantes obtengan acceso a las mismas capacidades de razonamiento, muchas vulnerabilidades aún no tendrán una regla escrita para ellas, por lo que necesitaremos herramientas que puedan seguir el ritmo.
Otra razón por la que se necesitan ambas herramientas es que cubren los mismos problemas en diferentes niveles. DAST y el pentesting de IA, por ejemplo, operan en diferentes capas del mismo problema. DAST destaca en las comprobaciones rápidas y deterministas que deben ejecutarse continuamente. Es necesario saber lo antes posible si se tienen puertos abiertos obvios o páginas que no deberían ser públicas. El pentesting de IA es más lento y cuesta más por ejecución, pero opera a una profundidad fundamentalmente diferente. Un IDOR que requiere tres pasos autenticados para ser alcanzado no aparecerá en un escaneo DAST, pero sí en un buen pentest de IA. Se pueden resolver rápidamente los problemas sencillos con DAST, y luego el pentesting de IA se encarga de los más complejos.
Cómo Aikido utiliza ambos
Hemos construido Aikido bajo la premisa de que el escaneo determinista y el impulsado por IA resuelven problemas diferentes en distintas capas de la pila. Desde el primer día, elegimos utilizar la herramienta que producía los mejores resultados en cada paso.
La base determinista es Opengrep, el motor de análisis de código de código abierto que Aikido ayuda a liderar y mantener. Además, hemos desarrollado análisis de taint y conjuntos de reglas curados lo suficientemente precisos como para integrarse directamente en las pipelines de CI/CD sin generar ruido.
Donde nos encanta la seguridad probabilística es en dar sentido a estos datos. El razonamiento de IA se sitúa sobre la base determinista, abordando los problemas a los que las reglas no pueden mapear. En Aikido, esto ocurre a través de AutoTriage, que se sitúa después de los escaneos SAST y toma decisiones sobre la explotabilidad y la gravedad que un motor de reglas no puede hacer por sí solo.
AutoTriage se ejecuta en dos etapas. Primero, el motor de alcanzabilidad de Aikido filtra los falsos positivos antes de que un LLM examine el código. Comprueba si las rutas de código vulnerables son realmente alcanzables, si existe sanitización entre la fuente y el sumidero, y si la dependencia afectada se utiliza en producción o solo en herramientas o pipelines. Este primer paso por sí solo suprime una parte significativa de las alertas en comparación con un escáner SAST promedio.
Para los casos complejos que superan ese filtro, los modelos de razonamiento entran en acción y evalúan los flujos de control y datos en contexto. Internamente, descubrimos que este enfoque identifica correctamente aproximadamente el doble de falsos positivos en casos complejos en comparación con los enfoques sin razonamiento. Un hallazgo de inyección SQL podría ser degradado de forma segura porque la entrada proviene de una fuente upstream de confianza. Una inyección NoSQL en un endpoint de inicio de sesión se eleva a crítica porque la ruta de ataque es trivial y el impacto es directo.
La razón por la que esto funciona es el control del contexto. Ejecutar un LLM sobre una base de código completa y pedirle que encuentre vulnerabilidades es lo que produce resultados inconsistentes. El modelo pierde el hilo, amplía sus conjeturas y su tasa de falsos positivos aumenta. El enfoque de Aikido restringe lo que la IA ve antes de que razone. El análisis de taint rastrea cómo los datos controlados por el usuario se mueven a través de la aplicación, y la conciencia de los endpoints le da al modelo el stack trace completo y la intención del código. ¿Es una API web? ¿Una herramienta de línea de comandos? ¿Qué se supone que debe hacer? Con ese contexto fijado, la IA no está adivinando. Está evaluando una pregunta específica y acotada. Así es como se obtiene el poder de razonamiento de la IA sin renunciar a la reproducibilidad.
Finalmente, dado que los modelos de IA son muy adecuados para encontrar patrones de ataque complejos y basados en la lógica, los hemos encontrado altamente efectivos para el pentesting. Aikido Attack es pentesting de IA que aplica el razonamiento probabilístico en la aplicación en vivo. Los agentes completan las pruebas en horas en lugar de semanas y encuentran regularmente fallos lógicos más profundos, incluyendo IDORs, bypasses de autenticación y falsificación de firmas electrónicas, algunos de los cuales incluso los testers humanos pasan por alto. Y ahora, con Aikido Infinite, los agentes pueden realizar pentesting en cada lanzamiento.
Para los verdaderos positivos confirmados, de SAST o pentesting, Aikido también utiliza la IA para razonar sobre la solución. AutoFix genera un parche dirigido y abre una pull request, otra capacidad de IA que requiere razonamiento y contexto para llevarse a cabo.
En Aikido, el determinismo gestiona la cobertura predecible a escala. La IA gestiona las decisiones que las reglas no pueden tomar.
¿Qué sigue?
La seguridad necesita tanto la fiabilidad determinista como la creatividad de la IA. El determinismo ofrece resultados consistentes, auditables y fiables a escala, mientras que la IA proporciona la profundidad, creatividad, persistencia y razonamiento para eliminar falsos positivos, reducir el ruido y encontrar vulnerabilidades inusuales. Tanto las herramientas probabilísticas como las deterministas tienen limitaciones, pero el verdadero problema surge cuando se utilizan en el lugar equivocado. Las cosas se van a desmoronar cuando se coloca un motor de razonamiento en un trabajo que necesita un comparador de patrones (o viceversa).
La dirección general es más clara que cualquier categoría de producto individual. Las herramientas deterministas están mejorando porque la IA se sitúa ahora sobre ellas, gestionando la priorización, el triaje y las correcciones que las reglas por sí solas no podían realizar. Las herramientas probabilísticas están mejorando en la detección de fallos lógicos complejos y rutas de ataque novedosas, y con el tiempo, también serán más rentables. Pero para las comprobaciones continuas de referencia, la economía del escaneo determinista no va a desaparecer. Se busca algo rápido, consistente y económico que se ejecute en cada commit, y eso sigue siendo un comparador de patrones.
Los equipos que construyen la postura de seguridad más duradera son los que utilizan herramientas deterministas y probabilísticas en el orden y los lugares correctos, sin apostar por una sola.
