Torna agli aggiornamenti
New releaseJul 28, 2026

deptrust v0.14.0

Server CLI e MCP che controlla le versioni dei pacchetti per vulnerabilità note in oltre 14 ecosistemi tra cui npm, PyPI, crates.io, Go modules e GitHub Actions. Si integra con agenti AI tramite hook e skill.

Condividi

deptrust

     __           __                  __
 ___/ /___  ___  / /________  _______/ /_
/ _  / __ \/ _ \/ __/ ___/ / / / ___/ __/
/  __/ /_/ /  __/ /_/ /  / /_/ (__  ) /_
\__,_/\____/ .___/\__/_/   \__,_/____/\__/
           /_/

deptrust è un'interfaccia a riga di comando che controlla le versioni dei pacchetti per vulnerabilità note su npm, PyPI, crates.io, moduli Go, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions e altri.

Funziona localmente come CLI e come server MCP. Chiama direttamente le API dei registry pubblici e di OSV; non esiste un servizio deptrust ospitato da configurare o di cui fidarsi.

Questo strumento nasce dalla frustrazione degli agenti AI che usano costantemente versioni vecchie.

Sommario

Scopo

Ecosistemi supportati:

  • npm, inclusi pacchetti con scope come @clidey/ux
  • PyPI
  • Cargo / crates.io
  • Moduli Go
  • RubyGems
  • NuGet
  • Maven, usando nomi di pacchetto groupId:artifactId
  • Packagist / Composer, usando nomi di pacchetto vendor/package
  • pub.dev
  • CocoaPods
  • Hex.pm
  • Hackage
  • GitHub Actions, usando nomi di pacchetto owner/repo e tag, riferimenti a branch o SHA di commit come versioni

deptrust attualmente segnala vulnerabilità note e fornisce una raccomandazione semplice:

Massima gravità notaRaccomandazione
criticalblocca
highblocca
medium / unknownverifica
lowpermetti
nessuna trovatapermetti

permetti significa che non è stata trovata alcuna vulnerabilità nota bloccante nelle fonti di dati pubbliche. Non prova che un pacchetto sia sicuro.

deptrust emette anche segnali di rischio che non sono CVE. Ad esempio, una versione pubblicata nelle ultime 72 ore viene contrassegnata per verifica in modo che un agente non installi ciecamente una nuova release.

I fornitori di advisory vengono interrogati in parallelo:

  • OSV
  • Database Advisory di GitHub, inclusi advisory recensiti e advisory di malware

La copertura dei fornitori varia per ecosistema. Se deptrust riesce a risolvere i metadati del registry ma nessun fornitore di vulnerabilità configurato supporta quell'ecosistema, restituisce unknown invece di trattare il pacchetto come sicuro.

Copertura dei fornitori:

EcosistemaMetadati registryOSVDB Advisory GitHub
npmsìsìsì
PyPIsìsìsì
Cargo / crates.iosìsìsì
Moduli Gosìsìsì
RubyGemssìsìsì
NuGetsìsìsì
Mavensìsìsì
Packagist / Composersìsìsì
pub.devsìsìsì
CocoaPodssìnosì
Hex.pmsìsìsì
Hackagesìsìno
GitHub Actionssìsìsì

L'output JSON include i campi di copertura degli advisory:

  • checked_providers: fornitori di vulnerabilità che deptrust ha effettivamente interrogato
  • skipped_providers: fornitori configurati saltati perché l'ecosistema non è supportato
  • advisory_coverage: full, partial, none o error
  • advisory_coverage_reason: breve spiegazione del valore di copertura
  • registry_verification: verified quando i metadati del registry hanno confermato la versione, o unverified quando un controllo di versione esatta è proseguito dopo un errore transitorio del registry
  • registry_verification_reason: l'errore del registry quando la verifica non era disponibile

Un controllo di versione esatta interroga comunque i fornitori di advisory quando la verifica del registry non è temporaneamente disponibile. Tale risultato è sempre non installabile e non riceve mai una raccomandazione allow. I controlli per latest, pacchetti sconosciuti e versioni definitivamente inesistenti richiedono ancora una risoluzione riuscita del registry.

Le richieste HTTP ritentano le risposte 429, 502, 503 e 504 fino a tre tentativi totali. I tentativi usano brevi ritardi esponenziali e rispettano i valori Retry-After fino a due secondi; attese più lunghe richieste dal server falliscono rapidamente in modo che la CLI non si blocchi. I tentativi esauriti degli advisory rendono il risultato incompleto e impediscono una raccomandazione allow.

Autenticazione API GitHub

Le richieste al Database Advisory GitHub e alle API di GitHub Actions possono utilizzare un token di GitHub App a breve durata e con privilegi minimi. In CI, passalo attraverso DEPTRUST_GITHUB_TOKEN:

DEPTRUST_GITHUB_TOKEN="$GITHUB_APP_TOKEN" deptrust check npm lodash 4.17.20

La precedenza delle credenziali è DEPTRUST_GITHUB_TOKEN, GITHUB_TOKEN, poi GH_TOKEN. Per uso locale, il fallback facoltativo della CLI GitHub è abilitato esplicitamente con DEPTRUST_GITHUB_AUTH=gh deptrust check ...; esegue gh auth token senza richiedere input. Se non è disponibile alcuna credenziale, DepTrust continua senza autenticazione. Un errore di limite di velocità o permesso dell'API GitHub produce unknown con diagnostica e non viene mai trattato come successo solo OSV.

DepTrust non memorizza mai, raggruppa, mette in cache, registra, teletrasmette né emette token GitHub. Le intestazioni di autenticazione vengono inviate solo a https://api.github.com.

Utilizzo CLI

Controlla una versione esatta:

deptrust check npm lodash 4.17.20

Esempio di risposta normale:

npm [email protected]: 2 vulnerabilità note trovate
raccomandazione: blocca
punteggio_rischio: 80

Controlla l'ultima versione:

deptrust check pypi requests latest

Restituisci JSON:

deptrust check --json cargo serde latest

Controlla un modulo Go:

deptrust check go golang.org/x/crypto latest

Controlla RubyGems, NuGet o Maven:

deptrust check rubygems rails latest
deptrust check nuget Newtonsoft.Json latest
deptrust check maven org.apache.logging.log4j:log4j-core latest

Controlla Packagist, pub.dev, CocoaPods, Hex.pm, Hackage o GitHub Actions:

deptrust check packagist monolog/monolog latest
deptrust check pub http latest
deptrust check cocoapods AFNetworking latest
deptrust check hex plug latest
deptrust check hackage aeson latest
deptrust check github-actions actions/checkout v7.0.0
deptrust check github-actions actions/checkout main

Per GitHub Actions, gli SHA di commit completi vengono trattati come fissati. I tag semver completi come v4.2.2 sono accettati senza un segnale di fissaggio aggiuntivo. I tag solo major come v4 e i riferimenti a branch come main sono riferimenti validi, ma deptrust aggiunge un segnale di verifica perché possono spostarsi.

Esempio di risposta JSON:

Categorie