clidey/deptrustCLI- und MCP-Server, der Paketversionen in 14+ Ökosystemen auf bekannte Schwachstellen prüft, darunter npm, PyPI, crates.io, Go-Module und GitHub Actions. Integriert sich über Hooks und Skills in KI-Agenten.
__ __ __
___/ /___ ___ / /________ _______/ /_
/ _ / __ \/ _ \/ __/ ___/ / / / ___/ __/
/ __/ /_/ / __/ /_/ / / /_/ (__ ) /_
\__,_/\____/ .___/\__/_/ \__,_/____/\__/
/_/
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.
Unterstützte Ökosysteme:
@clidey/uxgroupId:artifactIdvendor/packageowner/repo sowie Tags, Branch-Refs oder Commit-SHAs als Versionendeptrust 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:
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 hatskipped_providers: konfigurierte Anbieter, die übersprungen wurden, weil das Ökosystem nicht unterstützt wirdadvisory_coverage: full, partial, none oder erroradvisory_coverage_reason: kurze Erklärung für den Abdeckungswertregistry_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 wurderegistry_verification_reason: der Registry-Fehler, wenn die Verifizierung nicht verfügbar warEine 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-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.
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: