Área de investigación · Desarrollo de software Agentic
Cuando los agentes de código también programan: proteger de forma verificable el código y la cadena de herramientas
Los agentes de código escriben código, ejecutan comandos en el terminal e integran servidores MCP y skills. Así, la superficie de ataque abarca desde el código generado, pasando por el harness, hasta las extensiones y los pipelines. Investigamos dónde el análisis de código asistido por IA ayuda de forma demostrada y dónde se vuelve vulnerable, y lo trasladamos a un Secure SDLC en el que el modelo de lenguaje asesora, no controla.
- Agentes de código y harness
- Slopsquatting
- AI SAST
- Validación de explotabilidad
- DAST con LLM acotado
- Secure SDLC
- Seguridad de pipelines CI/CD
- Deep Dives
- 8
- Whitepapers
- 5
- Soluciones
- 2
Del asistente al agente: la cadena de herramientas se convierte en superficie de ataque
La IA genera hoy gran parte del código nuevo — Google indica un 75 % — y ese código introduce vulnerabilidades con una frecuencia mediblemente mayor: según Veracode, el 45 % de las muestras de IA suspende la prueba de seguridad. Al mismo tiempo, el asistente que sugiere se convierte en un agente que instala en el terminal, invoca servidores MCP y carga skills. Además, los modelos de lenguaje inventan nombres de paquetes que no existen y que los atacantes pueden registrar; desde 2025, esto se denomina slopsquatting.
El 29 de octubre de 2026 demostró lo vulnerable que es la cadena de herramientas: a través del marketplace del editor de código Cursor se distribuyó una versión manipulada de la extensión de Claude Code con una puerta trasera SSH, bajo el identificador auténtico anthropic.claude-code. Nuestro análisis del 31 de octubre de 2026 indica pasos de comprobación y medidas. Las extensiones se ejecutan con los derechos del usuario que ha iniciado sesión y llegan al código fuente, a las credenciales y a los terminales; esta cadena de suministro en los equipos de desarrollo rara vez se controla con el mismo rigor que los servidores o los pipelines de compilación.
En el lado del análisis, encontrar vulnerabilidades se convierte en una commodity: Google Big Sleep reportó veinte zero-days reales en 2025, y los finalistas de la DARPA AI Cyber Challenge encontraron en agosto de 2025, de forma totalmente autónoma, el 86 % de las vulnerabilidades introducidas. Sin embargo, en zero-days realmente inéditos, incluso los modelos frontier siguen fallando, y la clasificación LLM ingenua sin contexto apenas supera a una moneda al aire. La IA complementa las capas de verificación, no las sustituye: según este principio trabajan VamiAppSec y VamiDAST.
Preguntas abiertas de la práctica
- 01
¿Cómo se revisa el código escrito por asistentes de IA y agentes de código?
Nuestro enfoque
Como el código humano — con revisión, SAST, pruebas y comprobación de dependencias —, pero centrándose en las clases en las que el código de los asistentes falla de forma predecible: autorización, aislamiento entre inquilinos, gestión de errores. Para ello, los code owners reciben una guía. También se revisan los riesgos de agentes y de prompts en el repositorio, por ejemplo archivos de reglas con caracteres invisibles que las personas no ven en la revisión, pero que el modelo sí sigue.
- 02
¿Puede un modelo de lenguaje sustituir al SAST basado en reglas?
Nuestro enfoque
No. El SAST basado en reglas sigue siendo la higiene básica reproducible en cada commit, y solo esta capa sirve como gate en el build. El AI SAST con razonamiento semántico lo aplicamos de forma dirigida en repositorios de alto valor, por ejemplo contra la autorización rota y los fallos en la lógica de negocio. Los hallazgos de la IA reciben una pista de auditoría y revisiones humanas por muestreo, porque los juicios de los LLM varían entre ejecuciones.
- 03
¿Cómo se convierte un hallazgo en el código en una prioridad sólida?
Nuestro enfoque
Mediante una cadena de prueba: una regla o un modelo marca un punto, y después se comprueban la alcanzabilidad, la exposición real y la explotabilidad en el sistema en funcionamiento. Lo que hay detrás de la ruta decide el orden de corrección. Por eso acordamos SLA según la explotabilidad y no solo según el CVSS, y entregamos las rutas confirmadas con los pasos de reproducción a los code owners.
- 04
¿Cuánto modelo de lenguaje admite una prueba dinámica de seguridad?
Nuestro enfoque
Lo mínimo necesario, y nunca al mando. En VamiDAST, un motor determinista controla cada escaneo; un LLM solo asesora en exactamente tres puntos acotados, y sin LLM los detectores deterministas siguen funcionando. Cada hallazgo está respaldado con el payload y la evidencia de la respuesta; los sistemas en producción solo se prueban en modo pasivo o seguro y solo con autorización.
Lo que constatamos
- 01
Lo que se ataca es el harness, no el modelo
Un agente de código consta de modelo y harness, desde los archivos de reglas, pasando por el terminal y los servidores MCP, hasta los skills, los secretos y la red. Los ataques documentados afectan casi siempre a este harness; la serie de investigación IDEsaster encontró más de 30 vulnerabilidades con 24 CVE en IDE con IA. Allí donde los fabricantes aplicaron correcciones, no lo hicieron en el modelo, sino en el harness.
- 02
Quien compromete el build alcanza todos los artefactos entregados
Los pipelines de CI/CD concentran permisos sobre repositorios, registros de paquetes y entornos cloud. En la Poisoned Pipeline Execution basta con acceder al sistema de código fuente para manipular el build. Son eficaces los runners aislados sin secretos para el código no revisado, las configuraciones de CI desde ramas protegidas y las credenciales OIDC de corta duración en lugar de secretos estáticos.
Fuente: Seguridad de pipelines CI/CD
- 03
El triaje con LLM está demostrado, pero el propio analista de IA se convierte en objetivo
Detrás de un escáner determinista, un filtro LLM reduce las falsas alarmas de forma consistente: en el OWASP Benchmark, un 88,6 % con un 3,1 % de pérdida de recall. Al mismo tiempo, el modelo procesa comentarios, README e issues como entrada: los comentarios adversarios engañan a los detectores LLM en más del 90 % de los casos. Quien emplea IA en el análisis de código la convierte así, a su vez, en superficie de ataque.
Fuente: AI SAST
- 04
El momento de entrega decide la eficacia del SAST
En Meta, la tasa de corrección de los escaneos nocturnos por lotes era casi nula. Cuando el mismo análisis pasó a aparecer como comentario en la revisión de código del diff, subió a más del 70 %, con el mismo motor y la misma tasa de falsas alarmas. Google solo admite en la revisión los análisis cuya tasa efectiva de falsas alarmas se mantiene por debajo del 10 %. Los hallazgos surten efecto allí donde los desarrolladores ya trabajan.
Fuente: SAST
Cómo procedemos
Separamos de forma sistemática lo que es verificable de forma determinista, dónde asesora un modelo de lenguaje y dónde deciden las personas: desde el harness del agente de código, pasando por la pull request, hasta la aplicación en ejecución.
Análisis del harness de agentes de código
Registrar como relaciones de confianza los archivos de reglas, las entradas, el terminal, los servidores MCP, los skills, los gestores de paquetes, los secretos, el repositorio y la red, y protegerlos fuera del modelo.
Tres capas del análisis de código
SAST basado en reglas en cada commit, AI SAST con razonamiento semántico en repositorios de alto valor, análisis con modelos frontier basado en el riesgo y periódico.
Validación de explotabilidad
Del hallazgo a la explotabilidad, pasando por la alcanzabilidad y la exposición: los hallazgos se confirman en el sistema en funcionamiento antes de fijar prioridades.
DAST con un LLM estrictamente acotado
VamiDAST: motor determinista, un LLM asesora en exactamente tres puntos acotados; pruebas tras el inicio de sesión, BOLA/IDOR con una segunda identidad, cada hallazgo con la evidencia de la respuesta.
Endurecimiento de pipelines
El OWASP Top 10 CI/CD Security Risks como matriz de verificación: runners aislados sin secretos para el código no revisado, credenciales OIDC de corta duración, artefactos firmados con provenance según SLSA.
Estándares y Security Champions
OWASP ASVS 5.0, CWE Top 25 y NIST SSDF como criterio de referencia, OWASP SAMM para el nivel de madurez; los Security Champions anclan el conocimiento de seguridad en cada equipo de desarrollo.
Cómo empezar
- 1Inventariar la cadena de herramientasRegistrar agentes de código, extensiones, servidores MCP, fuentes de paquetes y pipelines, y clasificar los repositorios según su exposición y su clase de datos.
- 2Definir capas y gatesDeterminar por repositorio qué análisis se ejecuta y con qué cadencia; los Quality Gates en GitLab, GitHub o Azure DevOps bloquean los hallazgos críticos.
- 3Confirmar hallazgos y aportar evidenciasConfirmar la explotabilidad en el sistema, entregar las correcciones a los code owners y generar por release evidencias para el CRA, NIS2 y las auditorías de clientes.
Deep Dives, whitepapers y análisis
Deep Dives 8
Whitepapers 5
Slopsquatting & Coding-Agenten für CISOs — proteger la cadena de suministro de software con IA
Seguridad impulsada por IA en el pipeline CI/CD
CI/CD Pipeline Security: cómo los atacantes se apoderan de su pipeline — y cómo recuperarla
OWASP Top 10 CI/CD Security Risks — Guía práctica con crosswalk de cumplimiento
Secure Coding en la era de la IA: el CWE Top 25 (2025) y Secure-by-DesignDel área a la implantación
Áreas de investigación relacionadas
Agentes de código en el equipo: ¿está protegida la cadena de herramientas?
Revisamos los permisos de los agentes, las extensiones, los gates del pipeline y su análisis de código, y le mostramos dónde la verificación asistida por IA ofrece en su caso el mayor efecto palanca, con evidencias trazables.