Sintesi giornaliera. Scansione completata su 8 progetti attivi. Nuove CVE: 2 critiche (CVSS 9.0+), 5 alte (CVSS 7.0-8.9), 3 medie. Critiche: libreria npm auth-utils in 3 progetti, patch 5.4.4 → 5.4.7 (upgrade minor compatibile). Alte: dipendenza Maven logging-core richiede major bump (4.x → 5.x) con modifiche API in 12 punti.
AGENTE · DEPENDENCY WATCHER
Le CVE sulle dipendenze arrivano al team prima che diventino incident.
Dependency Watcher monitora ogni giorno le dipendenze di terze parti dei progetti del cliente (npm, Maven, PyPI, NuGet, RubyGems). Confronta con i database CVE pubblici (NVD, GitHub Advisory). Propone upgrade coerenti con il vincolo di compatibilità del codice del cliente. Alert al security team su severità alta.
Dependency Watcher al lavoro.
Confermato. Upgrade critico pianificato per oggi, major bump schedulo come sprint venerdì.
Decisioni registrate. Prossima scansione: domani mattina.
Perché esiste.
La maggior parte del codice di un'azienda moderna è composta da dipendenze di terze parti (librerie open source, SDK commerciali, framework). Una vulnerabilità identificata su una di queste dipendenze (CVE pubblicata) può esporre l'azienda al rischio di compromissione. Il monitoraggio manuale delle CVE su tutte le dipendenze di tutti i progetti è impraticabile per il volume.
Come scansiona ogni giorno.
Dependency Watcher si attiva con schedulazione giornaliera. Per ciascun progetto del cliente: legge i file di dipendenze (package.json, pom.xml, requirements.txt, .csproj, Gemfile), recupera l'elenco delle versioni utilizzate, confronta con i database CVE pubblici (NVD, GitHub Advisory, registri di settore). Per ciascuna vulnerabilità identificata: classifica la severità (CVSS score), propone l'upgrade alla versione patch, valuta la compatibilità del salto di versione con il codice del cliente.
La decisione resta al team.
La decisione di upgrade resta del team del cliente. L'agente propone PR automatici solo su upgrade pre-approvati di patch e minor; per major il PR è una proposta da rivedere.
Tre figure tecniche che cambiano il modo di gestire le CVE.
Responsabile sicurezza informatica
Vede il quadro complessivo delle vulnerabilità sui progetti aggregato per severità. La capacità di patching si dimensiona sul rischio reale.
10 controlli attivi
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
DevOps lead
Riceve le proposte di upgrade ordinate per severità e con valutazione di compatibilità. Decide le settimane di patching coerenti con la pipeline di sviluppo del team.
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Sviluppatore senior
Si concentra sugli upgrade che richiedono modifiche al codice (major version bump), mentre gli upgrade di patch e minor passano in pipeline standard.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · codice nel perimetro del cliente
12 nuove CVE in una sintesi del mattino, tre decisioni del lead.
Dependency Watcher legge 8 progetti ogni mattina.
Per un'azienda B2B SaaS con 8 progetti attivi, l'agente è schedulato ogni giorno. La sintesi giornaliera arriva al canale Slack del team security. L'agente identifica 12 nuove CVE sui progetti del cliente: 2 critiche, 5 alte, 5 medie.
Tre classi di severità con compatibilità valutata per ognuna.
Le 2 CVE critiche riguardano una libreria npm comune presente in 3 dei 8 progetti. La patch è disponibile con upgrade minor compatibile (nessuna modifica API). L'agente propone l'upgrade immediato. Le 5 CVE alte riguardano una dipendenza Maven. La patch richiede major version bump con modifiche API che interessano diversi punti del codice. L'agente segnala l'upgrade richiesto con il dettaglio dei punti di codice da modificare, propone branch dedicato per la migrazione coerente.
Upgrade oggi, sprint la prossima settimana, backlog per le medie.
La sintesi arriva al security team con la classificazione per severità, gli upgrade proposti, la valutazione di compatibilità. Il responsabile DevOps decide: upgrade immediato delle CVE critiche entro la giornata, sprint dedicato per le CVE alte la settimana successiva, backlog regolare per le medie.
Regole dichiarative del team security, versionate.
Le regole sono dichiarative. Il team security definisce in formato leggibile le soglie di severità per alert immediato, le regole di compatibilità per major version bump, il formato della sintesi. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, tool-rate-limit
- Canali nativi
- Slack, Telegram, HTTP OpenAI-compatible
- Integrazione database CVE
- NVD, GitHub Advisory via webSearch o adapter dedicato in delivery
- Integrazione GitHub, GitLab, Bitbucket
- tool ghPR/ghIssue nativi per GitHub, adapter in delivery per altri
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sul portafoglio dipendenze del cliente
- Registro
- immutabile, interrogabile con client SQL standard (audit DORA, NIS2 ispezionabile)
Domande frequenti sull'agente.
Per upgrade di patch e minor su progetti pre-approvati dal team DevOps, l'agente può proporre il PR automatico che il team rivede e fa il merge. Per upgrade major o su progetti core, l'agente propone l'upgrade come task per sprint dedicato. La decisione di merge resta sempre del team umano.
Snyk, Dependabot e simili forniscono il monitoraggio CVE e le proposte di upgrade come servizio dedicato. Dependency Watcher copre la stessa funzione ma è integrato in Polyant come parte della squadra IT del cliente, condivide il registro audit con gli altri agenti, lavora sotto la governance unica del runtime. Per i clienti che già usano questi strumenti, Dependency Watcher può lavorare in aggregazione con essi oppure sostituirli.
Quando l'upgrade proposto rompe i test del progetto (verificato in CI/CD), l'agente segnala la rottura con il dettaglio dei test falliti. Il responsabile DevOps decide se l'upgrade va in branch dedicato con fix dei test, oppure se va posticipato. La regola di blocco automatico in caso di test rotti è dichiarativa.
Il pattern tipico per Dependency Watcher è 3-6 settimane. Discovery una settimana, configurazione regole di severità e compatibilità 1-2 settimane, integrazione con i repository del cliente 1-2 settimane, hand-off al team security 1 settimana.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Dependency Watcher si configurerebbe sul caso del cliente. Repository, linguaggi, soglie di severità del team.