deptrust

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

deptrust es una CLI que comprueba las versiones de paquetes en busca de vulnerabilidades conocidas en npm, PyPI, crates.io, módulos de Go, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions y más.

Funciona localmente como CLI y como servidor MCP. Llama directamente a las APIs públicas de los registros de paquetes y a las de OSV; no hay ningún servicio de deptrust alojado en el que confiar o que configurar.

Esta herramienta nació de la frustración que supone que los agentes de IA utilicen constantemente versiones antiguas.

Contenido

• Alcance
• Uso de la CLI
• Instalación
• Configuración de agentes
• Configuración manual de MCP
• Herramientas MCP
• Uso solo con skill
• Solución de problemas

Alcance

Ecosistemas compatibles:

• npm, incluidos los paquetes con ámbito (scoped) como @clidey/ux
• PyPI
• Cargo / crates.io
• Módulos de Go
• RubyGems
• NuGet
• Maven, con nombres de paquete groupId:artifactId
• Packagist / Composer, con nombres de paquete vendor/package
• pub.dev
• CocoaPods
• Hex.pm
• Hackage
• GitHub Actions, con nombres de paquete owner/repo y etiquetas, referencias de rama o SHAs de commit como versiones

deptrust actualmente informa de vulnerabilidades conocidas y ofrece una recomendación sencilla:

Severidad máxima conocida	Recomendación
critical	block
high	block
medium / unknown	review
low	allow
none found	allow

allow significa que no se encontró ninguna vulnerabilidad conocida bloqueante en las fuentes de datos públicas. No demuestra que un paquete sea seguro.

deptrust también emite señales de riesgo que no son CVEs. Por ejemplo, una versión publicada en las últimas 72 horas se marca para revisión para que un agente no instale a ciegas una versión recién publicada.

Los proveedores de avisos se consultan en paralelo:

• OSV
• GitHub Advisory Database, incluidos los avisos revisados y los avisos de malware

La cobertura de proveedores varía según el ecosistema. Si deptrust puede resolver los metadatos del registro pero ningún proveedor de vulnerabilidades configurado es compatible con ese ecosistema, devuelve unknown en lugar de tratar el paquete como seguro.

Cobertura de proveedores:

Ecosistema	Metadatos del registro	OSV	GitHub Advisory DB
npm	sí	sí	sí
PyPI	sí	sí	sí
Cargo / crates.io	sí	sí	sí
Módulos de Go	sí	sí	sí
RubyGems	sí	sí	sí
NuGet	sí	sí	sí
Maven	sí	sí	sí
Packagist / Composer	sí	sí	sí
pub.dev	sí	sí	sí
CocoaPods	sí	no	sí
Hex.pm	sí	sí	sí
Hackage	sí	sí	no
GitHub Actions	sí	sí	sí

La salida JSON incluye campos de cobertura de avisos:

• checked_providers: los proveedores de vulnerabilidades que deptrust consultó realmente
• skipped_providers: los proveedores configurados que se omitieron porque el ecosistema no es compatible
• advisory_coverage: full, partial, none o error
• advisory_coverage_reason: una breve explicación del valor de cobertura
• registry_verification: verified cuando los metadatos del registro confirmaron la versión, o unverified cuando una comprobación de versión exacta continuó tras un fallo transitorio del registro
• registry_verification_reason: el error del registro cuando la verificación no estuvo disponible

Una comprobación de versión exacta sigue consultando a los proveedores de avisos cuando la verificación del registro no está disponible temporalmente. Ese resultado siempre es no instalable y nunca recibe una recomendación allow. Las comprobaciones de latest, paquetes desconocidos y versiones definitivamente inexistentes siguen requiriendo una resolución satisfactoria del registro.

Las solicitudes HTTP reintentan las respuestas 429, 502, 503 y 504 hasta un máximo de tres intentos. Los reintentos usan breves retardos exponenciales y respetan los valores Retry-After de hasta dos segundos; las esperas más largas solicitadas por el servidor fallan rápidamente para que la CLI no se cuelgue. El agotamiento de los reintentos de avisos hace que el resultado sea incompleto e impide una recomendación allow.

Autenticación con la API de GitHub

Las solicitudes a la API de GitHub Advisory Database y de GitHub Actions pueden usar un token de GitHub App de corta duración y con privilegios mínimos. En CI, pásalo a través de DEPTRUST_GITHUB_TOKEN:

DEPTRUST_GITHUB_TOKEN="$GITHUB_APP_TOKEN" deptrust check npm lodash 4.17.20

La precedencia de credenciales es DEPTRUST_GITHUB_TOKEN, GITHUB_TOKEN y luego GH_TOKEN. Para uso local, el respaldo opcional de GitHub CLI se habilita explícitamente con DEPTRUST_GITHUB_AUTH=gh deptrust check ...; ejecuta gh auth token sin preguntar. Si no hay ninguna credencial disponible, DepTrust continúa sin autenticación. Un fallo por límite de tasa o por permisos de la API de GitHub produce unknown con diagnósticos y nunca se trata como un éxito solo con OSV.

DepTrust nunca almacena, empaqueta, guarda en caché, registra, hace telemetría ni emite tokens de GitHub. Las cabeceras de autenticación solo se envían a https://api.github.com.

Uso de la CLI

Comprueba una versión exacta:

deptrust check npm lodash 4.17.20

Ejemplo de respuesta normal:

npm [email protected]: 2 known vulnerabilities found
recommendation: block
risk_score: 80

Comprueba la última versión:

deptrust check pypi requests latest

Devuelve JSON:

deptrust check --json cargo serde latest

Comprueba un módulo de Go:

deptrust check go golang.org/x/crypto latest

Comprueba 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

Comprueba 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

Para GitHub Actions, los SHAs de commit completos se tratan como fijados (pinned). Las etiquetas semver completas como v4.2.2 se aceptan sin una señal adicional de fijación. Las etiquetas solo con versión mayor como v4 y las referencias de rama como main son refs válidas, pero deptrust añade una señal de revisión porque pueden moverse.

Ejemplo de respuesta JSON: