clidey/deptrustServidor CLI e MCP que verifica versões de pacotes em busca de vulnerabilidades conhecidas em mais de 14 ecossistemas, incluindo npm, PyPI, crates.io, módulos Go e GitHub Actions. Integra-se com agentes de IA por meio de hooks e skills.
__ __ __
___/ /___ ___ / /________ _______/ /_
/ _ / __ \/ _ \/ __/ ___/ / / / ___/ __/
/ __/ /_/ / __/ /_/ / / /_/ (__ ) /_
\__,_/\____/ .___/\__/_/ \__,_/____/\__/
/_/
O deptrust é um CLI que verifica versões de pacotes quanto a vulnerabilidades conhecidas em npm, PyPI, crates.io, módulos Go, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions e outros.
Ele é executado localmente como CLI e como servidor MCP. Ele chama diretamente as APIs públicas de registros de pacotes e da OSV; não existe um serviço deptrust hospedado em que confiar ou que configurar.
Esta ferramenta nasceu da frustração que são agentes de IA usando constantemente versões antigas.
Ecossistemas suportados:
@clidey/uxgroupId:artifactIdvendor/packageowner/repo e tags, referências de branch ou SHAs de commit como versõesO deptrust atualmente reporta vulnerabilidades conhecidas e dá uma recomendação simples:
| Maior gravidade conhecida | Recomendação |
|---|---|
| critical | block |
| high | block |
| medium / unknown | review |
| low | allow |
| none found | allow |
allow significa que nenhuma vulnerabilidade conhecida bloqueante foi encontrada nas fontes de dados públicas. Isso não prova que um pacote é seguro.
O deptrust também emite sinais de risco que não são CVEs. Por exemplo, uma versão publicada nas últimas 72 horas é marcada para revisão para que um agente não instale cegamente uma versão recém-lançada.
Os provedores de avisos são consultados em paralelo:
A cobertura dos provedores varia por ecossistema. Se o deptrust conseguir resolver os metadados do registro, mas nenhum provedor de vulnerabilidades configurado for compatível com aquele ecossistema, ele retorna unknown em vez de tratar o pacote como seguro.
Cobertura dos provedores:
| Ecossistema | Metadados do registro | OSV | GitHub Advisory DB |
|---|---|---|---|
| npm | sim | sim | sim |
| PyPI | sim | sim | sim |
| Cargo / crates.io | sim | sim | sim |
| módulos Go | sim | sim | sim |
| RubyGems | sim | sim | sim |
| NuGet | sim | sim | sim |
| Maven | sim | sim | sim |
| Packagist / Composer | sim | sim | sim |
| pub.dev | sim | sim | sim |
| CocoaPods | sim | não | sim |
| Hex.pm | sim | sim | sim |
| Hackage | sim | sim | não |
| GitHub Actions | sim | sim | sim |
A saída JSON inclui campos de cobertura de avisos:
checked_providers: provedores de vulnerabilidade que o deptrust realmente consultouskipped_providers: provedores configurados ignorados porque o ecossistema não é suportadoadvisory_coverage: full, partial, none ou erroradvisory_coverage_reason: breve explicação para o valor de coberturaregistry_verification: verified quando os metadados do registro confirmaram a versão, ou unverified quando uma verificação de versão exata continuou após uma falha transitória do registroregistry_verification_reason: o erro do registro quando a verificação não estava disponívelUma verificação de versão exata ainda consulta os provedores de avisos quando a verificação do registro está temporariamente indisponível. Esse resultado é sempre não instalável e nunca recebe uma recomendação allow. Verificações de latest, de pacotes desconhecidos e de versões definitivamente inexistentes ainda exigem resolução bem-sucedida do registro.
Requisições HTTP repetem respostas 429, 502, 503 e 504 em até três tentativas no total. As novas tentativas usam atrasos exponenciais curtos e respeitam valores Retry-After de até dois segundos; esperas mais longas solicitadas pelo servidor falham rapidamente para que o CLI não trave. Tentativas de avisos esgotadas tornam o resultado incompleto e impedem uma recomendação allow.
Requisições ao GitHub Advisory Database e à API do GitHub Actions podem usar um token de GitHub App de curta duração e privilégio mínimo. Em CI, passe-o via DEPTRUST_GITHUB_TOKEN:
DEPTRUST_GITHUB_TOKEN="$GITHUB_APP_TOKEN" deptrust check npm lodash 4.17.20
A precedência de credenciais é DEPTRUST_GITHUB_TOKEN, GITHUB_TOKEN e depois GH_TOKEN. Para uso local, o fallback opcional da CLI do GitHub é ativado explicitamente com DEPTRUST_GITHUB_AUTH=gh deptrust check ...; ele executa gh auth token sem solicitar entrada. Se nenhuma credencial estiver disponível, o DepTrust continua sem autenticação. Uma falha de limite de taxa ou de permissão da API do GitHub produz unknown com diagnósticos e nunca é tratada como sucesso somente via OSV.
O DepTrust nunca armazena, agrupa, cacheia, registra em log, telemetra ou emite tokens do GitHub. Os cabeçalhos de autenticação são enviados somente para https://api.github.com.
Verifique uma versão exata:
deptrust check npm lodash 4.17.20
Exemplo de resposta normal:
npm [email protected]: 2 known vulnerabilities found
recommendation: block
risk_score: 80
Verifique a versão mais recente:
deptrust check pypi requests latest
Retorne JSON:
deptrust check --json cargo serde latest
Verifique um módulo Go:
deptrust check go golang.org/x/crypto latest
Verifique RubyGems, NuGet ou Maven:
deptrust check rubygems rails latest
deptrust check nuget Newtonsoft.Json latest
deptrust check maven org.apache.logging.log4j:log4j-core latest
Verifique Packagist, pub.dev, CocoaPods, Hex.pm, Hackage ou 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
Para GitHub Actions, SHAs completos de commit são tratados como fixados (pinned). Tags semver completas como v4.2.2 são aceitas sem um sinal extra de fixação. Tags apenas com a major como v4 e referências de branch como main são refs válidas, mas o deptrust adiciona um sinal de revisão porque elas podem mudar.
Exemplo de resposta JSON: