Los agentes de seguridad de Snyk siguen una regla: el que escribe la corrección nunca la califica

Si un agente de programación escribe una función vulnerable y se le pregunta a un segundo agente, construido sobre un modelo similar, si la función es segura, ¿qué tan independiente es esa segunda opinión? El propio benchmark de Snyk da una razón para dudar: en lo que llama VulnBench, las revisiones de seguridad con LLM reportaron un hallazgo que desapareció en la siguiente ejecución el 49.7% de las veces. Un revisor que cambia de opinión la mitad de las veces no es un control.

La respuesta de Snyk, en el lanzamiento de Evo Agentic AppSec el 15 de octubre, se resume en una frase de sus líderes: “El generador no puede ser el validador”. Los agentes hacen el trabajo; los motores deterministas de Snyk, como Snyk Code y Snyk Open Source, se invocan como herramientas para verificarlo; y su producto de pruebas ofensivas ataca la aplicación en ejecución para confirmar que las correcciones se mantienen. “Ninguno de los agentes califica su propio trabajo”, dice el anuncio.

Qué se anunció y qué tan listo está cada componente

Evo es un conjunto de agentes especializados, y no todos tienen la misma madurez. Leer el lanzamiento como “Snyk ahora lo arregla todo con agentes” sería un error.

Evo, por disponibilidad

Clientes seleccionadosDisponibilidad general (GA)

1. Preview experimentalCode Scanning Agent, Dependency Firewall, Agentic Security Review
2. Preview abiertoRemediation Agent, empezando con problemas de Snyk Open Source
3. GASecrets Detection, Agentic Development Security, Continuous Offensive Security

• El Code Scanning Agent combina el razonamiento del modelo con análisis estático para buscar fallos lógicos como control de acceso roto.
• El Dependency Firewall bloquea paquetes maliciosos o fuera de política en el momento de la instalación, incluido el slopsquatting, donde los atacantes publican paquetes con nombres que los modelos tienden a alucinar.
• Agentic Security Review revisa todo un repositorio con un modelo de aplicación, un modelo de amenazas y hallazgos respaldados por evidencia.
• El Remediation Agent ejecuta el bucle de corrección en código nuevo y en el backlog.

La aprobación sigue a la consecuencia

Snyk traza una línea que vale la pena copiar. La prevención dentro del agente de programación, atrapar un problema antes de que se escriba el código, no necesita aprobación humana. La remediación del código existente sí: una corrección que podría romper la compilación se pone en cola para aprobación, no se fusiona. Los desarrolladores aprueban las correcciones, y los líderes de AppSec gobiernan los agentes y auditan sus decisiones. Resumen de Snyk: “Los agentes hacen el trabajo. Algo independiente prueba que se mantiene. Los humanos son dueños del estándar.”

Esa es la misma frontera que GitHub trazó el mismo día, cuando puso Agentic Autofix y AI Scan en disponibilidad general (GA) sin permitir que ninguno de los dos fusionara o bloqueara nada. Dos proveedores llegando a un mismo diseño en una semana es una señal de dónde cree la industria que debe detenerse la autoridad de seguridad de la IA.

¿Independiente de qué, exactamente?

“La verificación independiente” es fácil de afirmar, así que vale la pena preguntar qué hace que una verificación sea independiente:

1. Un método diferente. Un motor de reglas, una suite de pruebas o un intento de explotación falla de maneras distintas a un modelo de lenguaje. Otro modelo, con un prompt diferente, a menudo no lo hace.
2. Un dueño diferente. El equipo que ajusta el verificador no debería ser el equipo medido por cuántas correcciones se entregan.
3. Repetibilidad. Ejecutar la misma verificación dos veces y obtener la misma respuesta. La cifra de VulnBench de Snyk es la advertencia sobre las verificaciones que fallan esta prueba.

Este es el principio que defendimos para sistemas regulados: la prueba tiene que venir de fuera del modelo. Snyk lo aplica a la seguridad de aplicaciones y lo convierte en una característica del producto.

Lea los números como de Snyk

El lanzamiento incluye muchas cifras reportadas por el proveedor: problemas críticos y de alta severidad nuevos multiplicados por diez en un año, alrededor de ocho vulnerabilidades nuevas introducidas por cada una corregida, y su Remediation Agent produciendo correcciones fusionables el 90% de las veces frente al 59.6% de los LLM solos en su benchmark VulnBump. Snyk también informa que el 36% de casi 4,000 skills de agentes que auditó tenían al menos un fallo de seguridad, lo que importa para cualquiera que comparta skills entre agentes. Ninguna de estas ha sido replicada de forma independiente.

Para los compradores, la prueba útil no es un número aislado. Es si un proveedor puede mostrar, para cada agente que vende, qué mecanismo independiente verifica la salida de ese agente, quién aprueba lo que cambia y qué sucede cuando los dos no están de acuerdo.