El código que escribe la IA es estocástico: el mismo prompt da cada vez un código distinto, y si le pedimos a otra IA que lo revise, la revisión también lo es. Un día detecta el bug y al siguiente no. Las herramientas de este tema son lo contrario: analizadores deterministas. Sobre el mismo código dan siempre el mismo informe, con reglas conocidas, y terminan con un código de salida que dice si pasa o no.
Por eso se meten en el bucle del agente como un sensor: el agente escribe, lanza la herramienta, lee el informe, corrige y vuelve a lanzarla hasta que pasa. La IA revisa lo que no se puede escribir como regla; lo que sí se puede, lo comprueba la herramienta.
| Herramienta | Qué comprueba | Dónde se usa en el curso |
|---|---|---|
| SonarQube | Calidad: bugs, code smells, duplicación, cobertura, complejidad | Servidor local en Docker y ./mvnw sonar:sonar |
| Snyk | Seguridad: vulnerabilidades en el código propio y en las dependencias | CLI snyk |
| Aikido Safe Chain | Que no se instale un paquete con malware | Envuelve npm, npx, pip, uv… |
SonarQube analiza el proyecto con miles de reglas por lenguaje y lo compara con una quality gate: un conjunto de condiciones que el código nuevo tiene que cumplir. La que trae por defecto, Sonar way, pide sobre el código nuevo:
Es justo lo que se le escapa a la IA: el método copiado y pegado con un cambio, la clase de 600 líneas, el código nuevo sin test.
La Community Build es gratuita y se arranca en local con Docker:
docker run -d --name sonarqube -p 9000:9000 sonarqube:community
SONAR_TOKEN.
./mvnw verify sonar:sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.token=$SONAR_TOKEN -Dsonar.qualitygate.wait=true
npx @sonar/scan -Dsonar.host.url=http://localhost:9000 -Dsonar.token=$SONAR_TOKEN -Dsonar.projectKey=pedidos-web -Dsonar.qualitygate.wait=true
Las piezas:
verify: compila y pasa los tests antes de analizar. Sin él, Sonar no tiene los resultados de los tests.-Dsonar.qualitygate.wait=true: espera a que el servidor evalúe la quality gate y, si no pasa, la orden falla. Es lo que la convierte en una puerta para el agente: no tiene que interpretar nada, mira el código de salida.-Dsonar.projectKey: el nombre del proyecto en el servidor. En Maven no hace falta: usa el groupId:artifactId del pom.xml.jacoco-maven-plugin con el objetivo report en la fase verify.
Cuando la puerta falla, el agente necesita saber qué ha fallado. No hace falta un MCP: la API web lo da con curl.
curl -s -H "Authorization: Bearer $SONAR_TOKEN" "http://localhost:9000/api/issues/search?components=es.fpmislata:pedidos&resolved=false&ps=100"
Y se le dice en AGENTS.md cuándo usarlo:
- Antes de dar una tarea por terminada, ejecuta `./mvnw verify sonar:sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.token=$SONAR_TOKEN -Dsonar.qualitygate.wait=true`. - Si falla, consulta las incidencias con `curl -s -H "Authorization: Bearer $SONAR_TOKEN" "http://localhost:9000/api/issues/search?components=es.fpmislata:pedidos&resolved=false&ps=100"`, corrígelas y vuelve a lanzarlo. No marques una incidencia como falso positivo: dímelo.
Snyk busca vulnerabilidades de seguridad en dos sitios distintos, cada uno con su orden:
snyk code test (SAST): el código que hemos escrito. Inyección SQL, XSS, path traversal, secretos escritos en el código…snyk test (SCA): las dependencias del pom.xml o el package.json, y las que arrastran. La librería que la IA ha puesto en una versión con un CVE conocido porque es la que recordaba.Se instala y se autentica una vez (el plan gratuito vale, con un límite de análisis al mes):
npm install -g snyk snyk auth
Y se lanza desde la raíz del proyecto:
snyk code test --severity-threshold=medium snyk test --severity-threshold=medium
--severity-threshold=medium: solo informa, y solo falla, por lo de severidad media o más. Las de severidad baja son sobre todo ruido.0 sin vulnerabilidades, 1 con vulnerabilidades, 2 o 3 si el análisis no ha podido hacerse. Igual que con Sonar, el agente no interpreta: mira si ha salido 0.snyk test necesita el proyecto compilado: en Maven, que las dependencias estén resueltas (./mvnw install al menos una vez); en Angular, el package-lock.json. Si no, termina con 2 o 3 y el agente puede tomarlo por «no hay nada».
La regla en AGENTS.md es la que recomienda la propia Snyk, adaptada a la terminal:
- Después de escribir o modificar código, ejecuta `snyk code test --severity-threshold=medium`. - Después de añadir o cambiar una dependencia, ejecuta `snyk test --severity-threshold=medium`. - Si encuentra vulnerabilidades en lo que has escrito o añadido, corrígelas y repite hasta que no haya ninguna nueva. Si termina con código 2 o 3, el análisis no se ha hecho: dímelo.
Los modelos se inventan nombres de paquetes que suenan bien, y hay quien registra esos nombres en npm o PyPI con malware dentro esperando a que un agente los instale (slopsquatting). Un agente con permiso para ejecutar npm install lo instala sin que nadie lo vea.
Aikido Safe Chain se pone delante de npm, npx, yarn, pnpm, bun, pip, uv y poetry y bloquea la descarga de cualquier paquete marcado como malware. También rechaza las versiones publicadas hace menos de 48 horas, que es cuando se cuelan las versiones comprometidas de paquetes legítimos. Es gratuito y no necesita cuenta.
curl -fsSL https://github.com/AikidoSec/safe-chain/releases/download/1.5.26/install-safe-chain.sh -o /tmp/install-safe-chain.sh \ && echo "9e4af7107f06d9c0d758cb08fb36804c2af88e24972f3a9d3f8c2bd0ca002adf /tmp/install-safe-chain.sh" | sha256sum -c - \ && sh /tmp/install-safe-chain.sh \ && rm /tmp/install-safe-chain.sh
Para comprobar que funciona, este paquete de prueba tiene que quedar bloqueado:
npm install safe-chain-test
.bashrc o el .zshrc, y la shell en la que el agente ejecuta órdenes no siempre los carga. Pídele que ejecute npm safe-chain-verify: tiene que responder OK: Safe-chain works!. Si no, el agente instala sin protección aunque en tu terminal funcione.
/api/issues/search).-Dsonar.*.Arranca SonarQube en Docker y analiza un proyecto Spring Boot que hayas hecho con el agente. Rellena la tabla con lo que da el primer análisis:
| Métrica | Valor |
|---|---|
| Bugs | |
| Code smells | |
| Vulnerabilidades | |
| Security hotspots | |
| Cobertura | |
| Duplicación |
Añade al AGENTS.md la regla de Sonar y pide al agente una funcionalidad nueva. Comprueba que lanza el análisis antes de terminar y que, si la quality gate falla, corrige hasta que pasa. Anota cuántas vueltas ha dado y qué incidencias ha corregido.
Lanza snyk test y snyk code test sobre el mismo proyecto. Para cada vulnerabilidad de severidad media o más, anota si está en el código o en una dependencia y cómo se corrige.
Instala Safe Chain y comprueba con npm safe-chain-verify que funciona desde el agente. Después pídele que instale safe-chain-test y copia lo que responde.