Flujos de trabajo de agentes

📄 ¿Prefiere sin conexión? Descargue esta guía en PDF.

DepCheck demuestra su valor cuando se ejecuta dentro del bucle de edición de un agente, no como una ocurrencia tardía. Esta página es el manual de estrategias que Cert-IX usa en su propio monorepo, destilado para que puedas aplicarlo al tuyo.

La disciplina central: comprobar antes de añadir

La regla es sencilla y lo es todo:

Antes de escribir cualquier dependencia en un manifiesto —o de fijarla o actualizarla— compruébala con DepCheck. Si es vulnerable, elige en su lugar la versión segura.

Integrado de esta forma, una versión vulnerable nunca llega a entrar en primer lugar. No hay ningún bucle de "el escáner lo detectó en CI un día después, ahora hay que deshacer el cambio", porque la versión defectuosa nunca se eligió.

El bucle

Agent is about to add or bump a dependency
        │
        ▼
  check_package(ecosystem, name, version)
        │
   vulnerable? ──no──▶ write the version, done
        │yes
        ▼
  suggest_safe_version(ecosystem, name)   ← newest zero-advisory release
        │
        ▼
  write the SAFE version instead
        │
        ▼
  (after editing) scan_dependencies(manifest)  ← nothing left vulnerable?

Incorporarlo a las instrucciones de un agente

La forma más fiable de conseguir que un agente haga esto es poner la regla en sus instrucciones de proyecto (un CLAUDE.md, .cursorrules, el prompt de sistema del agente o equivalente). Esta es la política exacta que Cert-IX incluye en su monorepo:

## Dependency safety (DepCheck — MANDATORY)

Before adding, pinning, or upgrading ANY dependency (go.mod, package.json,
Cargo.toml, requirements.txt, pyproject.toml, pom.xml, composer.json), check it
with the DepCheck MCP tools:

- `check_package(ecosystem, name, version)` BEFORE writing a new dependency
  into a manifest.
- If vulnerable, pick the version with `suggest_safe_version(ecosystem, name)` —
  never hand-pick a version with known Critical/High advisories.
- After editing a manifest (or when starting significant work in a service),
  run `scan_dependencies(manifest_path)` and fix what it reports, upgrading to
  the `upgrade_to` versions.
- `get_advisory(id)` for detail when deciding whether a finding is exploitable
  in context.
- Advisories flagged **`exploited`** ("⚠ exploited in the wild — CISA KEV / high
  EPSS") are being actively attacked — fix those FIRST, ahead of
  higher-CVSS-but-unexploited issues. `get_cve_intel(id)` gives the KEV/EPSS/CVSS
  detail for prioritisation.

Versions from ranges (`^`, `~`, `>=`) are checked at their declared minimum —
scan the lockfile for installed truth.

Adapta la lista de manifiestos y los nombres de herramientas a tu stack; lo que importa es la forma.

Jugadas habituales

Añadir una nueva dependencia

"Añade un cliente de Redis a este servicio en Go."

El agente resuelve un candidato (github.com/redis/go-redis/v9 en alguna versión), llama a check_package y —si está limpio— lo escribe. Si no, llama a suggest_safe_version y escribe esa. Obtienes una dependencia segura al primer intento.

Auditar un servicio existente

"¿Son seguras las dependencias de este servicio?"

El agente lee el lockfile y llama a scan_dependencies. Devuelve únicamente los paquetes vulnerables y sus objetivos de actualización, ordenados de modo que los problemas explotados en el mundo real aparezcan primero. El agente propone las actualizaciones; tú las revisas y las aplicas.

Clasificar un resultado ruidoso

No todos los avisos importan según cómo tu código use un paquete. Cuando un análisis devuelve algo dudoso:

1. get_advisory(id) — lee el vector CVSS y la ruta de código afectada. ¿La toca tu uso?
2. get_cve_intel(id) — ¿está listado en KEV o tiene un EPSS alto? Si es así, no importa lo estrecha que parezca la ruta; trátalo como urgente.

Esto mantiene al equipo arreglando las cosas que son realmente peligrosas en lugar de perseguir cada hallazgo de baja señal.

Por qué esto supera al análisis-solo-en-CI

El análisis en CI sigue mereciendo la pena como red de seguridad, pero por sí solo es reactivo: la versión vulnerable ya está confirmada, el PR ya está abierto y un humano tiene que volver atrás. DepCheck-en-el-bucle es preventivo: el agente nunca elige la versión defectuosa, así que no hay nada que deshacer. Usa ambos: prevén en el momento de la escritura, verifica en el momento del merge.

Límites honestos que hay que tener en cuenta al diseñar

• DepCheck informa de lo que las bases de datos de avisos conocen en el momento de la consulta. Vuelve a analizar periódicamente; llegan nuevos avisos para versiones que ayer estaban "limpias".
• Comprueba dependencias declaradas, no los matices de la resolución transitiva más allá de lo que codifica el lockfile, y no analiza el código de tu aplicación.
• Un resultado de 0 vulnerabilities significa nada conocido, no demostradamente seguro. Mantén tus otros controles (SAST, revisión, mínimo privilegio); DepCheck elimina lo conocido-como-malo, no certifica lo desconocido.

Consulta Seguridad y tratamiento de datos para saber qué sale del perímetro cuando el agente realiza estas llamadas.