Flussi di lavoro con gli agenti

📄 Preferisci offline? Scarica questa guida in PDF.

DepCheck dà il meglio di sé quando viene eseguito all'interno del ciclo di modifica di un agente, non come un ripensamento. Questa pagina è il manuale operativo che Cert-IX usa sul proprio monorepo, distillato così da poterlo applicare al tuo.

La disciplina fondamentale: controlla prima di aggiungere

La regola è semplice ed è tutto ciò che conta:

Prima di scrivere una qualsiasi dipendenza in un manifest — o di fissarne o aggiornarne una — controllala con DepCheck. Se è vulnerabile, scegli invece la versione sicura.

Cablato in questo modo, una versione vulnerabile non arriva mai in primo luogo. Non esiste alcun ciclo del tipo "uno scanner l'ha intercettata in CI un giorno dopo, ora annulla la modifica", perché la versione difettosa non è mai stata scelta.

Il ciclo

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?

Inserirla nelle istruzioni di un agente

Il modo più affidabile per far sì che un agente lo faccia è inserire la regola nelle sue istruzioni di progetto (un CLAUDE.md, un .cursorrules, un system prompt dell'agente o equivalente). Questa è l'esatta policy che Cert-IX distribuisce nel suo 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.

Adatta l'elenco dei manifest e i nomi degli strumenti al tuo stack; ciò che conta è la struttura.

Casi d'uso comuni

Aggiungere una nuova dipendenza

"Aggiungi un client Redis a questo servizio Go."

L'agente individua un candidato (github.com/redis/go-redis/v9 a una certa versione), chiama check_package e — se è pulito — lo scrive. In caso contrario, chiama suggest_safe_version e scrive quella. Ottieni una dipendenza sicura al primo tentativo.

Verificare un servizio esistente

"Le dipendenze di questo servizio sono sicure?"

L'agente legge il lockfile e chiama scan_dependencies. Ritorna con soltanto i pacchetti vulnerabili e i relativi target di aggiornamento, ordinati in modo che i problemi sfruttati in the wild siano per primi. L'agente propone gli aggiornamenti; tu li rivedi e li applichi.

Assegnare le priorità a un risultato rumoroso

Non tutti gli advisory contano per il modo in cui il tuo codice usa un pacchetto. Quando una scansione restituisce qualcosa di borderline:

1. get_advisory(id) — leggi il vettore CVSS e il percorso di codice interessato. Il tuo utilizzo lo tocca?
2. get_cve_intel(id) — è presente nella lista KEV o ha un EPSS elevato? Se sì, non conta quanto stretto sembri il percorso; trattalo come urgente.

Questo mantiene il team concentrato sulla correzione delle cose che sono davvero pericolose invece di rincorrere ogni risultato a basso segnale.

Perché questo è meglio della sola scansione in CI

La scansione in CI vale comunque la pena come rete di sicurezza — ma da sola è reattiva: la versione vulnerabile è già stata committata, la PR è già aperta, e una persona deve tornare indietro. DepCheck nel ciclo è preventivo: l'agente non sceglie mai la versione difettosa, quindi non c'è nulla da annullare. Usa entrambi — previeni al momento della scrittura, verifica al momento del merge.

Limiti onesti da tenere presenti nella progettazione

• DepCheck riporta ciò che i database degli advisory conoscono al momento della ricerca. Riesegui la scansione periodicamente; nuovi advisory compaiono per versioni che erano "pulite" ieri.
• Controlla le dipendenze dichiarate, non le sfumature della risoluzione transitiva oltre ciò che il lockfile codifica, e non analizza il codice della tua applicazione.
• Un risultato 0 vulnerabilities significa nulla di noto, non dimostrato sicuro. Mantieni i tuoi altri controlli (SAST, revisione, minimo privilegio) — DepCheck rimuove ciò che è notoriamente difettoso, non certifica l'ignoto.

Consulta Sicurezza e gestione dei dati per capire cosa lascia il perimetro quando l'agente effettua queste chiamate.