deptrust

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

deptrust ist ein CLI, das Paketversionen auf bekannte Schwachstellen in npm, PyPI, crates.io, Go-Modulen, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions und mehr prüft.

Es läuft lokal als CLI und als MCP-Server. Es ruft öffentliche Paketregistrierungs- und OSV-APIs direkt auf; es gibt keinen gehosteten deptrust-Dienst, dem man vertrauen oder den man konfigurieren müsste.

Dieses Tool entstand aus der Frustration darüber, dass KI-Agenten ständig alte Versionen verwenden.

Inhalt

• Umfang
• CLI-Nutzung
• Installation
• Agent-Setup
• Manuelles MCP-Setup
• MCP-Werkzeuge
• Nur-Skill-Nutzung
• Fehlerbehebung

Umfang

Unterstützte Ökosysteme:

• npm, einschließlich Scoped-Paketen wie @clidey/ux
• PyPI
• Cargo / crates.io
• Go-Module
• RubyGems
• NuGet
• Maven, mit Paketnamen im Format groupId:artifactId
• Packagist / Composer, mit Paketnamen im Format vendor/package
• pub.dev
• CocoaPods
• Hex.pm
• Hackage
• GitHub Actions, mit Paketnamen im Format owner/repo sowie Tags, Branch-Refs oder Commit-SHAs als Versionen

deptrust meldet derzeit bekannte Schwachstellen und gibt eine einfache Empfehlung:

Höchste bekannte Schwere	Empfehlung
critical	block
high	block
medium / unknown	review
low	allow
none found	allow

allow bedeutet, dass in den öffentlichen Datenquellen keine blockierende bekannte Schwachstelle gefunden wurde. Es beweist nicht, dass ein Paket sicher ist.

deptrust gibt außerdem Risikosignale aus, die keine CVEs sind. Beispielsweise wird eine in den letzten 72 Stunden veröffentlichte Version zur Prüfung markiert, damit ein Agent keine brandneue Veröffentlichung blind installiert.

Advisory-Anbieter werden parallel abgefragt:

• OSV
• GitHub Advisory Database, einschließlich geprüfter Advisories und Malware-Advisories

Die Abdeckung der Anbieter variiert je nach Ökosystem. Wenn deptrust die Registry-Metadaten auflösen kann, aber kein konfigurierter Schwachstellen-Anbieter dieses Ökosystem unterstützt, gibt es unknown zurück, anstatt das Paket als sicher zu behandeln.

Abdeckung der Anbieter:

Ökosystem	Registry-Metadaten	OSV	GitHub Advisory DB
npm	yes	yes	yes
PyPI	yes	yes	yes
Cargo / crates.io	yes	yes	yes
Go-Module	yes	yes	yes
RubyGems	yes	yes	yes
NuGet	yes	yes	yes
Maven	yes	yes	yes
Packagist / Composer	yes	yes	yes
pub.dev	yes	yes	yes
CocoaPods	yes	no	yes
Hex.pm	yes	yes	yes
Hackage	yes	yes	no
GitHub Actions	yes	yes	yes

Die JSON-Ausgabe enthält Felder zur Advisory-Abdeckung:

• checked_providers: Schwachstellen-Anbieter, die deptrust tatsächlich abgefragt hat
• skipped_providers: konfigurierte Anbieter, die übersprungen wurden, weil das Ökosystem nicht unterstützt wird
• advisory_coverage: full, partial, none oder error
• advisory_coverage_reason: kurze Erklärung für den Abdeckungswert
• registry_verification: verified, wenn die Registry-Metadaten die Version bestätigt haben, oder unverified, wenn eine Prüfung einer exakten Version nach einem vorübergehenden Registry-Fehler fortgesetzt wurde
• registry_verification_reason: der Registry-Fehler, wenn die Verifizierung nicht verfügbar war

Eine Prüfung einer exakten Version fragt Advisory-Anbieter weiterhin ab, wenn die Registry-Verifizierung vorübergehend nicht verfügbar ist. Dieses Ergebnis ist immer nicht installierbar und erhält niemals eine allow-Empfehlung. Prüfungen auf latest, unbekannte Pakete und definitiv nicht existierende Versionen erfordern weiterhin eine erfolgreiche Registry-Auflösung.

HTTP-Anfragen wiederholen 429-, 502-, 503- und 504-Antworten bis zu insgesamt drei Versuche. Wiederholungen verwenden kurze exponentielle Verzögerungen und beachten Retry-After-Werte von bis zu zwei Sekunden; längere vom Server angeforderte Wartezeiten schlagen schnell fehl, damit das CLI nicht hängen bleibt. Erschöpfte Advisory-Wiederholungen machen das Ergebnis unvollständig und verhindern eine allow-Empfehlung.

GitHub-API-Authentifizierung

GitHub-Advisory-Database- und GitHub-Actions-API-Anfragen können ein kurzlebiges GitHub-App-Token mit minimalen Rechten verwenden. In CI übergibst du es über DEPTRUST_GITHUB_TOKEN:

DEPTRUST_GITHUB_TOKEN="$GITHUB_APP_TOKEN" deptrust check npm lodash 4.17.20

Die Reihenfolge der Anmeldedaten ist DEPTRUST_GITHUB_TOKEN, GITHUB_TOKEN, dann GH_TOKEN. Für die lokale Nutzung wird der optionale GitHub-CLI-Fallback explizit mit DEPTRUST_GITHUB_AUTH=gh deptrust check ... aktiviert; er führt gh auth token ohne Rückfragen aus. Wenn keine Anmeldedaten verfügbar sind, arbeitet DepTrust ohne Authentifizierung weiter. Ein GitHub-API-Rate-Limit oder ein Berechtigungsfehler erzeugt unknown mit Diagnoseinformationen und wird niemals als reiner OSV-Erfolg behandelt.

DepTrust speichert, bündelt, cached, protokolliert, telemetriert oder gibt GitHub-Tokens niemals weiter. Authentifizierungs-Header werden nur an https://api.github.com gesendet.

CLI-Nutzung

Eine exakte Version prüfen:

deptrust check npm lodash 4.17.20

Beispiel für eine normale Antwort:

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

Die neueste Version prüfen:

deptrust check pypi requests latest

JSON zurückgeben:

deptrust check --json cargo serde latest

Ein Go-Modul prüfen:

deptrust check go golang.org/x/crypto latest

RubyGems, NuGet oder Maven prüfen:

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

Packagist, pub.dev, CocoaPods, Hex.pm, Hackage oder GitHub Actions prüfen:

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

Bei GitHub Actions werden vollständige Commit-SHAs als gepinnt behandelt. Vollständige Semver-Tags wie v4.2.2 werden ohne zusätzliches Pinning-Signal akzeptiert. Nur-Major-Tags wie v4 und Branch-Refs wie main sind gültige Refs, aber deptrust fügt ein Review-Signal hinzu, weil sie sich verschieben können.

Beispiel für eine JSON-Antwort: