Workflows d'agent

📄 Vous préférez hors ligne ? Téléchargez ce guide au format PDF.

DepCheck prouve sa valeur lorsqu'il s'exécute à l'intérieur de la boucle d'édition d'un agent, et non après coup. Cette page est le manuel de jeu que Cert-IX utilise sur son propre monorepo, distillé pour que vous puissiez l'appliquer au vôtre.

La discipline fondamentale : vérifier avant d'ajouter

La règle est simple et c'est tout l'enjeu :

Avant d'écrire une dépendance dans un manifeste — ou de l'épingler ou de la mettre à niveau — vérifiez-la avec DepCheck. Si elle est vulnérable, choisissez plutôt la version sûre.

Câblé de cette manière, une version vulnérable n'atterrit jamais en premier lieu. Il n'y a pas de boucle « le scanner l'a détectée en CI un jour plus tard, il faut maintenant défaire le changement », parce que la mauvaise version n'a jamais été choisie.

La boucle

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?

Intégration dans les instructions d'un agent

Le moyen le plus fiable de faire respecter cela par un agent est de placer la règle dans ses instructions de projet (un CLAUDE.md, un .cursorrules, un prompt système d'agent ou l'équivalent). Voici la politique exacte que Cert-IX livre dans son 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.

Adaptez la liste des manifestes et les noms d'outils à votre stack ; c'est la forme qui compte.

Cas d'usage courants

Ajouter une nouvelle dépendance

« Ajoute un client Redis à ce service Go. »

L'agent résout un candidat (github.com/redis/go-redis/v9 à une certaine version), appelle check_package et — s'il est propre — l'écrit. Sinon, il appelle suggest_safe_version et écrit celle-ci. Vous obtenez une dépendance sûre du premier coup.

Auditer un service existant

« Les dépendances de ce service sont-elles sûres ? »

L'agent lit le lockfile et appelle scan_dependencies. Il renvoie uniquement les paquets vulnérables et leurs cibles de mise à niveau, ordonnés de sorte que les problèmes exploités dans la nature apparaissent en premier. L'agent propose les montées de version ; vous les examinez et les appliquez.

Trier un résultat bruyant

Tous les avis de sécurité ne comptent pas selon la manière dont votre code utilise un paquet. Lorsqu'un scan renvoie quelque chose de limite :

1. get_advisory(id) — lisez le vecteur CVSS et le chemin de code affecté. Votre utilisation le touche-t-elle ?
2. get_cve_intel(id) — est-il listé dans la KEV ou à EPSS élevé ? Si oui, peu importe à quel point le chemin paraît étroit ; traitez-le comme urgent.

Cela permet à l'équipe de corriger les choses réellement dangereuses au lieu de courir après chaque résultat à faible signal.

Pourquoi cela vaut mieux que le seul scan en CI

Le scan en CI reste utile comme filet de sécurité — mais à lui seul il est réactif : la version vulnérable est déjà commitée, la PR est déjà ouverte, et un humain doit revenir en arrière. DepCheck-dans-la-boucle est préventif : l'agent ne choisit jamais la mauvaise version, il n'y a donc rien à défaire. Utilisez les deux — prévenir au moment de l'écriture, vérifier au moment du merge.

Limites honnêtes à prendre en compte dans la conception

• DepCheck rapporte ce que les bases de données d'avis de sécurité connaissent au moment de la recherche. Re-scannez périodiquement ; de nouveaux avis apparaissent pour des versions qui étaient « propres » hier.
• Il vérifie les dépendances déclarées, pas les subtilités de résolution transitive au-delà de ce que le lockfile encode, et il n'analyse pas le code de votre application.
• Un résultat 0 vulnerabilities signifie rien de connu, pas sûreté prouvée. Conservez vos autres contrôles (SAST, revue, moindre privilège) — DepCheck élimine le connu-mauvais, il ne certifie pas l'inconnu.

Consultez Sécurité et traitement des données pour savoir ce qui quitte le périmètre lorsque l'agent effectue ces appels.