Zum Hauptinhalt springen
Version: 1.0.0

Agent-Workflows

📄 Lieber offline? Diese Anleitung als PDF herunterladen.

DepCheck zahlt sich aus, wenn es innerhalb der Edit-Schleife eines Agenten läuft, nicht als nachträglicher Gedanke. Diese Seite ist das Playbook, das Cert-IX in seinem eigenen Monorepo verwendet — so aufbereitet, dass Sie es auf Ihr eigenes anwenden können.

Die Kerndisziplin: prüfen, bevor du hinzufügst​

Die Regel ist einfach und sie ist das ganze Spiel:

Bevor Sie irgendeine Abhängigkeit in ein Manifest schreiben — oder sie pinnen oder aktualisieren — prüfen Sie sie mit DepCheck. Ist sie verwundbar, wählen Sie stattdessen die sichere Version.

Auf diese Weise verdrahtet, landet eine verwundbare Version gar nicht erst im Baum. Es gibt keine „Der Scanner hat es einen Tag später in der CI entdeckt, jetzt die Änderung zurückdrehen"-Schleife, weil die schlechte Version nie ausgewählt wurde.

Die Schleife​

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?

Einbinden in die Anweisungen eines Agenten​

Der zuverlässigste Weg, einen Agenten dazu zu bringen, ist, die Regel in seine Projektanweisungen aufzunehmen (eine CLAUDE.md, .cursorrules, einen Agent-System-Prompt oder Äquivalentes). Dies ist genau die Policy, die Cert-IX in seinem Monorepo ausliefert:

## 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.

Passen Sie die Manifest-Liste und die Tool-Namen an Ihren Stack an; auf die Form kommt es an.

Häufige Spielzüge​

Eine neue Abhängigkeit hinzufügen​

„Füge diesem Go-Service einen Redis-Client hinzu."

Der Agent ermittelt einen Kandidaten (github.com/redis/go-redis/v9 in irgendeiner Version), ruft check_package auf und — wenn sauber — schreibt sie. Wenn nicht, ruft er suggest_safe_version auf und schreibt diese. Sie erhalten eine sichere Abhängigkeit beim ersten Versuch.

Einen bestehenden Service auditieren​

„Sind die Abhängigkeiten dieses Service sicher?"

Der Agent liest die Lockfile und ruft scan_dependencies auf. Er kommt mit genau den verwundbaren Paketen und ihren Upgrade-Zielen zurück, so geordnet, dass in-the-wild ausgenutzte Probleme zuerst stehen. Der Agent schlägt die Bumps vor; Sie prüfen und wenden sie an.

Ein rauschbehaftetes Ergebnis triagieren​

Nicht jedes Advisory ist relevant dafür, wie Ihr Code ein Paket verwendet. Wenn ein Scan etwas Grenzwertiges zurückgibt:

  1. get_advisory(id) — lesen Sie den CVSS-Vektor und den betroffenen Code-Pfad. Berührt Ihre Nutzung ihn?
  2. get_cve_intel(id) — ist es KEV-gelistet oder hat es einen hohen EPSS-Wert? Wenn ja, spielt es keine Rolle, wie eng der Pfad aussieht; behandeln Sie es als dringend.

So bleibt das Team dabei, die tatsächlich gefährlichen Dinge zu beheben, statt jedem schwachen Signal-Finding hinterherzujagen.

Warum das besser ist als Scannen-in-der-CI allein​

CI-Scanning ist als Rückfallnetz weiterhin sinnvoll — aber für sich genommen ist es reaktiv: die verwundbare Version ist bereits committet, der PR ist bereits offen, und ein Mensch muss zurückschleifen. DepCheck-in-der-Schleife ist präventiv: der Agent wählt die schlechte Version nie aus, es gibt also nichts zurückzudrehen. Nutzen Sie beides — verhindern zur Autorenzeit, verifizieren zur Merge-Zeit.

Ehrliche Grenzen, um die herum man designen sollte​

  • DepCheck meldet, was die Advisory-Datenbanken zum Zeitpunkt der Abfrage wissen. Scannen Sie regelmäßig erneut; für Versionen, die gestern noch „sauber" waren, landen neue Advisories.
  • Es prüft deklarierte Abhängigkeiten, nicht Feinheiten der transitiven Auflösung jenseits dessen, was die Lockfile kodiert, und es analysiert nicht Ihren Anwendungscode.
  • Ein 0 vulnerabilities-Ergebnis bedeutet nichts bekannt, nicht nachweislich sicher. Behalten Sie Ihre übrigen Kontrollen (SAST, Review, geringste Rechte) — DepCheck entfernt das Bekannt-Schlechte, es zertifiziert nicht das Unbekannte.

Siehe Sicherheit & Datenverarbeitung dazu, was den Perimeter verlässt, wenn der Agent diese Aufrufe tätigt.

War diese Seite hilfreich?