¿La prevención es, en esencia, un problema ya resuelto?

Detener el despliegue de nuevos problemas de seguridad en código generado por agentes es, arquitectónicamente, un problema resuelto. La prevención consiste en impedir que una nueva vulnerabilidad del código llegue a producción en cualquier punto del proceso de desarrollo y lanzamiento, lo que incluye, entre otras cosas, evitar que se introduzca en una rama de funcionalidades. Hay puntos diferenciados en el ciclo de vida del desarrollo agéntico en los que puede introducirse seguridad, cada uno adecuado para un tipo distinto de control, y la correspondencia entre ellos se conoce bien. Aplicarla dentro de una organización mientras el ciclo de vida del desarrollo de software está cambiando activamente hace que esa correspondencia sea difícil de aplicar.

No puedes resolverlo todo con prompts

La versión idealizada de la seguridad en el desarrollo agéntico es una única instrucción: decirle al agente que escriba código seguro, colocarla en el prompt del sistema o en la configuración del arnés, y dejarlo trabajar.

Figura 1. La instrucción que parece un control.

Las directrices en la ventana de contexto sí cambian lo que produce un agente, y el efecto es suficientemente real como para basarse en él, pero una instrucción no es una restricción. Cambia la probabilidad de lo que se escribe, pero no lo decide. Esto se aplica tanto a una regla de una sola línea como a una skill cuidadosamente redactada. Es una propiedad del funcionamiento de estos modelos (que consideran todas las entradas y juzgan su prioridad relativa), independientemente de la calidad de tu prompt.

El código generado por IA sigue siendo susceptible a las mismas clases de vulnerabilidades que siempre ha tenido el código escrito por humanos. Una instrucción por sí sola no cambia eso, ni lo hará ninguna cantidad de trabajo de diseño de prompts. Por tanto, la pregunta útil es dónde colocar todo lo demás.

«Shift in» es el nuevo «shift left»

Los tres costes aumentan a medida que la seguridad se desplaza hacia fuera, alejándose del momento en que se escribe el código.

Figura 2. Los tres aumentan juntos a medida que la seguridad se desplaza hacia fuera.

Los tokens son el más evidente. El coste de un análisis determinista es un error de redondeo junto al de una llamada al modelo, y la diferencia aumenta cada vez que le pides a un modelo que razone sobre una parte mayor del código base.

La atención humana es el segundo. Un problema detectado mientras un agente aún está trabajando nunca se convierte en un ticket, nunca entra en triaje y nunca interrumpe a alguien que está repartido entre varias tareas.

El tercero es acertar con la corrección. Un agente que trabaja en los bucles internos aún conserva el prompt y la especificación originales, por lo que, al corregir algo, puede confirmar que el resultado sigue siendo funcional y seguro, porque sabe qué debía hacer el código. Si envías el mismo hallazgo hacia fuera, ese contexto desaparece. La corrección debe restablecerse desde fuera, mediante pruebas unitarias, pruebas de humo y pruebas de integración que se ejecutan antes y durante la CI.

Un agente que amplía una funcionalidad existente también depende del conjunto de pruebas en los bucles internos, porque necesita saber que no ha roto algo que no ha visto. Pero depende menos de él, ya que aún conserva el prompt y puede razonar sobre lo que debía hacer el cambio en lugar de inferir la intención a partir de lo que resulte pasar. Cuanto más lejos se desplaza una corrección, más carga recae únicamente sobre la cobertura.

Ese es el argumento para llevar la seguridad hacia dentro. La razón por la que no ocurre por sí sola es que la presión en sentido contrario es más fuerte.

La seguridad genera fricción

Nada de esto es nuevo. La seguridad cuesta tiempo, y dedicar tiempo al flujo de trabajo de un desarrollador siempre ha sido la parte difícil de este trabajo. Por eso Snyk fue pionera con éxito en el shift left en DevSecOps hace diez años.

La era agéntica lo amplifica en lugar de cambiarlo. Las organizaciones están respaldando la adopción de IA basándose en múltiplos de productividad de los desarrolladores. Y cuando la expectativa es un cambio radical en el rendimiento, cualquier cosa que ralentice el ciclo no es una cuestión de compensaciones. Se elimina.

Por tanto, la pregunta no es si añadir controles de seguridad, sino dónde puede ubicarse cada uno sin costar más de lo que ahorra.

El ciclo de vida es una pila de bucles

El modelo de bucles de Laurie Voss es una de las descripciones más claras de cómo se crea software actualmente: un conjunto de bucles anidados, cada uno de los cuales se cierra con su propia señal.

• El bucle de ejecución completa una instrucción y termina al recibir feedback del entorno, ya sea el resultado de una prueba, una respuesta de una API o el contenido de un archivo.

• El bucle de tareas completa una especificación.

• El bucle de producto se lanza.

• El bucle de sistema mejora el conjunto durante días y semanas.

• El bucle de supervisión es donde una persona establece objetivos, asigna un presupuesto y decide qué importa.

Figura 3. La pila de bucles, basada en What the hell is a loop, anyway?

Dentro de los bucles de ejecución y de tareas, el trabajo sigue abierto, y un hallazgo aún puede corregirse antes de que el bucle se complete sin intervención humana. Desde el bucle de producto hacia fuera, debe existir una confianza significativa en la cobertura de pruebas; de lo contrario, es necesaria la revisión humana.

Antes de desarrollar esta idea, hay dos salvedades. Primero, la adopción es desigual: existe un espectro de adopción del desarrollo agéntico, incluso dentro de las empresas. Muchos equipos no ejecutan agentes en cada uno de estos bucles, y muchos todavía tienen personas trabajando bien dentro de los bucles internos, en lugar de limitarse a la supervisión. Los bucles se mantienen en cualquier caso, porque describen cuándo se cierra una parte del trabajo, no quién la cerró.

Y segundo, si eliminamos el vocabulario agéntico, gran parte de esto es la forma en que se ha creado software durante mucho tiempo: iteras sobre un cambio, terminas una unidad de trabajo, lanzas, mejoras el sistema y alguien decide qué merece hacerse después. Lo que ha cambiado es la velocidad y quién (o qué) está frente al teclado.

Los riesgos que puedes identificar de antemano

Algunos riesgos son totalmente predecibles: inyección SQL, cross-site scripting, secretos codificados de forma rígida, valores predeterminados de criptografía débiles y las configuraciones incorrectas más habituales de la infraestructura como código. Sabemos exactamente qué buscamos, y se puede indicar a un agente cómo evitarlo antes de que escriba una línea.

El control consiste en proporcionar directrices en el contexto del agente: prompts del sistema, configuración del arnés y skills que cubran los riesgos que un equipo más desea evitar que se produzcan. Es el control más barato disponible, porque el coste se paga una vez en el espacio de la ventana de contexto, en lugar de por cada problema comprobado. No se ejecuta nada ni se evalúa nada; las directrices simplemente están ahí.

Parte de esto ya está implementado sin que nadie tenga que desplegar nada. Los arneses incluyen prompts del sistema que contienen algunas de estas directrices de forma predeterminada. Por ejemplo, Anthropic documenta los prompts del sistema de cada uno de sus modelos. Además, muchas organizaciones están creando registros compartidos de skills, a veces con skills específicas de las aplicaciones que describen cómo trabajan sus propios equipos, lo que significa que una skill de seguridad no es un tipo nuevo de artefacto que distribuir. Es otra entrada en algo que ya existe.

El límite aquí es el contexto. Cada instrucción compite con las que ya están en la ventana, y cargar toda la gama de clases de vulnerabilidades en el contexto de un agente diluye las directrices más importantes en favor de riesgos que rara vez aparecen. Hay que racionar, lo que significa que otra cosa debe detectar lo que se deja fuera. Y el contexto solo es la mitad de la restricción. Incluso con espacio ilimitado, algunos riesgos no pueden expresarse en una instrucción, porque cuando se redactó nadie sabía que existían.

Los problemas sobre los que nadie podía haber informado al agente

Cuando los desarrolladores o los agentes seleccionan un paquete, a menudo eligen la versión más reciente porque está actualizada y hace lo que necesitan. Si esa misma semana se revelara una vulnerabilidad en esa versión, ninguno de los dos lo sabría. El modelo no se entrenó con ella. Ninguna skill podría haberla cubierto, porque la revelación no existía cuando se escribió la skill. Esperar que la prevención mediante instrucciones resuelva esto no es una exigencia razonable para nadie.

Luego está todo lo que se racionó en la etapa anterior. La larga cola de riesgos que no puede incluirse en un prompt del sistema o una skill sin contaminar el contexto, pero que es completamente real y perfectamente detectable. Desde la posición del agente, estas dos categorías de riesgo son el mismo problema: nunca se le indicó que estuviera atento a ellas.

Ambas necesitan una prueba que se ejecute de forma exhaustiva, en lugar de selectiva, que se active mientras el trabajo sigue abierto y que devuelva resultados con la suficiente rapidez como para que el agente siga ahí y pueda actuar sobre ellos. Y no debería detenerse al encontrar algo. Si el agente puede corregir lo que revela la prueba y volver a ejecutarla, el bucle se cierra sin que tenga que intervenir una persona, que es la única versión de esto que sobrevive al contacto con un equipo que mide el rendimiento.

Trusted Output Assurance (parte de Evo Agentic Development Security) lo hace mediante hooks y la CLI. Un análisis se activa cuando se escriben archivos y de nuevo cuando el agente termina el trabajo planificado, de modo que los problemas recién introducidos salen a la luz y se corrigen antes de que se cierre la especificación, todo dentro de los bucles internos. Las comprobaciones del estado de los paquetes, el análisis de secretos y la defensa contra código malicioso se ejecutan por la misma vía.

Un agente que corrige todo lo que recibe a veces reescribe código funcional para satisfacer un hallazgo que nunca fue real. Esa es una de las razones por las que esta etapa corresponde a motores deterministas y no probabilísticos, y hace que la tasa de falsos positivos sea algo que debe probarse al elegir qué se ejecuta. También debes comprender qué ocurre cuando el motor y el agente discrepan sobre un hallazgo detectado. Snyk optimiza para ambas cosas. Un control solo merece ocupar un lugar en los bucles internos si acierta con la frecuencia suficiente como para actuar sin supervisión. Cuando la confianza es menor, el hallazgo debe situarse más hacia fuera.

Un control como este vale exactamente lo que vale su adopción, y la adopción es donde la seguridad en los bucles internos siempre ha tenido dificultades, porque dependía de que cada desarrollador la configurara. Ahora esa parte es sencilla. Las organizaciones distribuyen Trusted Output Assurance mediante MDM a los equipos de los desarrolladores y lo incorporan a las plantillas de sandbox, de modo que ya está presente allí donde se genera código, y lo que se ejecuta en cada máquina aparece de forma centralizada, en lugar de tener que aceptarse basándose únicamente en la confianza.

Con qué tienen dificultades los motores rápidos y deterministas

Los fallos de autorización y de lógica de negocio son un problema distinto. Autorización rota a nivel de objeto, IDOR, fallos de aislamiento entre tenants y abusos en varios pasos. Estas clases se conocen bien, y los motores basados en reglas son realmente malos detectándolas, porque el fallo es semántico, no sintáctico. Nada en el código parece incorrecto. Lo incorrecto es la relación entre las cosas.

El análisis basado en LLM del código base ensamblado es lo que funciona en este caso. En la práctica actual, eso significa que una organización le pide a un modelo que busque, ya sea manualmente o como una invocación de agente activada en una canalización, a veces mediante un proveedor y a veces apuntando directamente un modelo de frontera al repositorio.

Ejecuta la misma revisión de seguridad cinco veces sobre el mismo código, y casi la mitad de lo que el modelo encuentra por sí solo aparece en solo una de las cinco ejecuciones. Eso es Snyk VulnBench JS 1.0, medido en 300 ejecuciones de la misma revisión.

Esos informes aislados no son incorrectos, y VulnBench documenta muchos que parecen lagunas genuinas de cobertura, no ruido. Pero una sola ejecución no constituye una decisión. La confianza debe obtenerse mediante la repetición, por lo que este es el primer punto en el que el coste por hallazgo se convierte en una partida real, en lugar de un error de redondeo.

Lo que cambia en esta etapa no es cuánto tarda un análisis, sino cuánto debe examinar. Todos los controles anteriores son incrementales. Una skill se activa cuando el agente recurre a un patrón. Un análisis cubre el único archivo que se acaba de escribir, en lugar de las docenas que se modifican durante una sesión. Cada uno se integra en un trabajo que ya estaba sucediendo. El análisis semántico del código base ensamblado no puede hacerlo, porque no hay nada sobre lo que razonar hasta que las piezas están juntas; por tanto, se ejecuta como un paso propio y su coste se añade al bucle en lugar de absorberse dentro de él. El tiempo que ese bucle ya empleó fue el agente trabajando, no tiempo libre para esperar, y una pasada completa puede duplicar fácilmente su duración. Eso presupone un resultado limpio: todo lo que encuentre debe corregirse y el análisis debe volver a ejecutarse, por lo que el coste se acumula en lugar de sumarse. Por todo ello, esto ocurre después de que el agente haya pasado a otra cosa.

Cada uno de esos ciclos también depende más de la suite de pruebas. Para entonces, el prompt ya ha desaparecido, así que la cobertura es lo único que se interpone entre una corrección de seguridad y una funcionalidad rota, y cada nueva ejecución le pide que vuelva a resistir. En la mayoría de las organizaciones, la cobertura no se acerca al nivel necesario para que una corrección se integre sin supervisión, por lo que una persona termina revisándola.

Esto es exactamente hacia donde se dirige Snyk con el futuro de la AppSec agéntica. Habrá más novedades al respecto en un futuro próximo.

Lo que solo aparece bajo un ataque (previo a producción)

La última categoría solo aparece cuando algo está en ejecución. Cadenas de explotación de varios pasos, abuso de flujos de trabajo, inyección de prompts contra un agente desplegado, rutas de exfiltración de datos que existen únicamente por la forma en que tres componentes interactúan en tu entorno.

El control es la evaluación adversarial: pentesting y red teaming de IA contra una aplicación real. Se conocen los tipos de debilidades que se investigan, pero el trabajo es exploratorio. La aplicación es el punto de partida y los límites no se fijan de antemano, así que lo que aparece es aquello que el sistema termina permitiendo.

Aquí es donde Evo Continuous Offensive Security encaja, y conviene especificar qué es lo que hace el trabajo, porque no es un escáner con un modelo añadido. Un agente de pentesting orquestador ejecuta subagentes especializados contra un objetivo activo. Un agente validador independiente cuestiona lo que informan los demás y construye un exploit funcional para demostrarlo. Esta última parte es importante porque las pruebas exploratorias basadas en modelos producen hallazgos que suenan plausibles a menos que algo los obligue a sostenerse, por lo que cada hallazgo se entrega como una prueba de concepto ejecutable en lugar de una hipótesis.

Tres de esos subagentes (lógica de negocio, control de acceso y autorización, y encadenamiento de exploits) trabajan en las mismas categorías semánticas que necesita la etapa anterior. Ya se está trabajando en convertir estos motores y otros similares en productos integrados en los flujos de trabajo de la etapa anterior, a medida que esos flujos se consolidan.

Puede ejecutarse contra preproducción como una barrera de lanzamiento o inmediatamente después de un lanzamiento para informar sobre qué debe hacerse a continuación. Históricamente, esto era un ejercicio de cumplimiento anual o semestral. Ahora las organizaciones lo ejecutan con mucha más frecuencia, lo cual es lo correcto, porque los adversarios no siguen un calendario de auditorías.

No hay nada que atacar hasta que algo está en ejecución, y esa es precisamente la razón por la que esto no puede ocurrir antes.

Qué sabía el agente y cuándo podía actuar

Cada control anterior depende de las mismas dos cosas: si se le podría haber indicado al agente antes de que escribiera el código y si la respuesta llega mientras aún conserva el prompt. Esas dos preguntas sitúan los cuatro controles y explican por qué la secuencia no es una cuestión de preferencia. Cada control se describe en uno de los cuatro recuadros siguientes.

Figura 4. Los cuatro controles, en el orden que determinan las dos respuestas.

Por qué esto es más difícil en la práctica

El plan es sencillo. Operarlo dentro de una organización real no lo es, y las razones tienen muy poco que ver con la seguridad.

La mayoría de las organizaciones aún no tienen un ciclo de vida de desarrollo agéntico consolidado. Las herramientas, los harnesses y la arquitectura que están estandarizando siguen cambiando, a veces de un trimestre a otro. El panorama de proveedores avanza igual de rápido, por lo que, incluso cuando se ha tomado una decisión, existe una verdadera reticencia a comprometerse con algo que se parezca a una decisión irreversible. Todo eso se manifiesta como una falta de claridad en la responsabilidad, porque cuando la forma del ciclo de vida aún está cambiando, también lo está la cuestión de quién es responsable de cada parte. Las fallas de autorización y lógica tienden a no pertenecerle a nadie en particular hasta que un incidente se las asigna a alguien.

Nada de esto requiere empezar de cero, y esa es la parte que conviene tener presente. Casi todas las organizaciones ya cuentan con una barrera de seguridad previa al despliegue, y esa barrera hace un trabajo real. No es algo que haya que eliminar mientras resuelves el resto. Estos puntos de integración se superponen a lo que ya existe y pueden adoptarse uno a uno, en el orden que corresponda al punto en que realmente se haya consolidado tu ciclo de vida. Incorporar el análisis determinista al ciclo no requiere haber resuelto quién es responsable de las pruebas adversariales.

El segundo suele recibir menos importancia de la debida. En los ciclos internos, un control que devuelve el trabajo a una persona ya ha fracasado, al igual que uno que produce una cola de pull requests creadas por IA para que alguien las revise. Ambos toman una comprobación de seguridad y la convierten en el backlog de otra persona, que es donde los controles se desactivan discretamente.

Más adelante, es más difícil evitar a una persona. La cobertura de pruebas en la mayoría de las organizaciones está muy lejos del nivel necesario para confiar en que una corrección autónoma se integre, así que alguien la revisa, y ese es el estado honesto de las cosas hoy, no un fallo de las herramientas. Los harnesses son cada vez mejores a la hora de ejecutar la suite sin prompts, y la cobertura también aumenta cuando los agentes escriben las pruebas, pero nadie debería planificar como si alguna de esas dos condiciones ya se hubiera alcanzado. Es otra razón para detectar lo que puedas mientras el agente aún conserva el prompt, porque ese es el único lugar en el que no hace falta una persona.

El primero y el tercero son lo que permite empezar de forma segura mientras el terreno sigue cambiando. Un control que puedes poner en marcha en una tarde, reconfigurar de forma centralizada o eliminar por completo es uno que puedes adoptar antes de haber definido cómo es tu ciclo de vida. Ahora mismo, esa propiedad vale más que cualquier capacidad individual.

Trusted Output Assurance se distribuye mediante MDM y mantiene su configuración de forma centralizada, por lo que cambiar lo que se ejecuta no implica editar las políticas de Jamf o Intune ni reescribir scripts de despliegue. Continuous Offensive Security necesita las URL de tus aplicaciones y un conjunto de credenciales, así que no hay que desarrollar nada antes de que devuelva resultados. Ninguna de las dos opciones te compromete con una arquitectura que aún no hayas definido.

Prevención ahora, remediación después

La prevención está resuelta en el sentido que importa. Los puntos existen, los controles existen y se sabe qué control corresponde a cada lugar. Pero hacerlo requiere trabajo, y el (AI)SDLC sigue evolucionando bajo nuestros pies.

La remediación es otra historia. El análisis determinista dentro del ciclo evita que adoptes un paquete con una versión conocida como vulnerable en el momento de adoptarlo. No hace nada con respecto al paquete que adoptaste hace ocho meses (o incluso hace ocho años) y que recibió un CVE la semana pasada. Ese backlog crece desde dos direcciones a la vez: años de hallazgos acumulados que nunca se corrigieron y un flujo continuo de nuevas divulgaciones que afectan al código ya en producción. Una buena prevención no lo reduce, pero evita que empeore.

Este problema merece una conversación propia. Mientras tanto, la prevención está disponible ahora y el primer paso es más pequeño de lo que parece: elige el punto más estable de tu ciclo de vida y añade el control adecuado.