Sicherheit & Datenverarbeitung

📄 Lieber offline? Diese Anleitung als PDF herunterladen.

DepCheck ist ein Sicherheitswerkzeug und wird deshalb an den Maßstäben eines Sicherheitswerkzeugs gemessen. Diese Seite legt klar dar, wie es Sie authentifiziert, was es mit den Daten macht, die Sie ihm senden, und was den Cert-IX-Perimeter verlässt — und was nicht.

Authentifizierung

• Jede Anfrage an https://mcp.cert-ix.com/depcheck muss einen gültigen API-Schlüssel als Authorization: Bearer <key> mitführen. Anfragen ohne einen solchen erhalten 401; das Backend bekommt niemals unauthentifizierten Verkehr zu Gesicht.
• Schlüssel werden pro Client von Ihrem Cert-IX-Kundenteam ausgestellt. Behandeln Sie einen Schlüssel wie ein Passwort: bewahren Sie ihn in der Konfiguration Ihres MCP-Clients oder einem Secret-Store auf, niemals in der Versionsverwaltung, und rotieren Sie ihn, wenn er möglicherweise durchgesickert ist.
• Der gesamte Verkehr läuft über TLS. Senden Sie Schlüssel oder Manifeste niemals über einfaches HTTP.

Ratenbegrenzung & Missbrauchsschutz

Der gehostete Endpunkt erzwingt Grenzwerte am Edge (Host-nginx), bevor irgendeine Arbeit erledigt wird:

Geltungsbereich	Grenzwert
Pro API-Schlüssel	20 Anfragen/Sekunde (kurzer Burst bis 40), 20 gleichzeitige Verbindungen
Pro Quell-IP	40 Anfragen/Sekunde (Burst 80), 40 gleichzeitige Verbindungen

Das Überschreiten eines Grenzwerts liefert 429 Too Many Requests — warten Sie ab und versuchen Sie es erneut. Diese Obergrenzen liegen deutlich über der normalen Agentennutzung (eine Handvoll Prüfungen pro Bearbeitung); sie existieren, um Fluten zu stoppen, nicht um echte Arbeit zu drosseln.

Wiederholte Authentifizierungsfehler werden als Missbrauch gewertet: eine IP, die in einem kurzen Zeitfenster viele 401-Antworten erzeugt, wird vorübergehend gesperrt (fail2ban). Ein Inhaber eines gültigen Schlüssels läuft niemals hier hinein, denn ein korrekter Schlüssel liefert nie 401.

Was Sie senden und was damit geschieht

Die Werkzeuge von DepCheck sind schreibgeschützte Abfragen. Hier steht genau, wofür jede Art von Eingabe verwendet wird:

Sie senden	Was DepCheck damit macht
Eine Paketkoordinate (ecosystem, name, version)	Schlägt sie gegen die Advisory-Daten nach und gibt passende Advisories zurück.
Einen Manifest-Body (manifest_content)	Parst ihn im Arbeitsspeicher, um Paar-Angaben aus Paketname/-version zu extrahieren, und schlägt diese dann nach. Er wird verwendet, um Ihr Ergebnis zu erzeugen, und wird nicht als gespeichertes Dokument persistiert.
Eine Advisory-/CVE-ID	Schlägt deren Details oder Exploit-Informationen nach.

DepCheck extrahiert Koordinaten (welche Pakete, welche Versionen) aus einem Manifest — es braucht, will oder analysiert Ihren Quellcode nicht, und der gehostete Server hat überhaupt keinen Zugriff auf Ihr Dateisystem (deshalb nimmt er Manifesttext entgegen, keinen Pfad).

Welche Betriebsdaten aufbewahrt werden

Für den Betrieb des Dienstes bewahrt DepCheck ausschließlich aggregierte Zähler auf — Gesamtanfragen, Fehler, laufende Anzahl sowie Aufrufzähler pro Werkzeug / pro Client für Kapazität und Monitoring. Diese Zähler halten fest, dass ein Client ein Werkzeug aufgerufen hat, nicht die Paketnamen, Versionen oder Manifestinhalte im Aufruf. Sie werden über einen internen, token-geschützten /metrics-Endpunkt bereitgestellt, der aus dem öffentlichen Internet niemals erreichbar ist.

Datenresidenz — wo die Advisory-Daten liegen

Das ist der Teil, der für eine souveräne Aufstellung entscheidend ist:

• Advisory-Daten werden zuerst aus dem souveränen Advisory-Spiegel von Cert-IX (osv-advisories) ausgeliefert, der innerhalb des Cert-IX-Clusters gehostet und mit CISA KEV- und EPSS-Exploit-Informationen aus den clustereigenen Indizes angereichert wird. Bei einem Spiegel-Treffer — dem Normalfall — verlässt Ihre Abfrage niemals die Cert-IX-Infrastruktur.
• Live-Fallback: Wenn der Spiegel keine Antwort hat (eine sehr neue Advisory oder ein Paket, das der Spiegel noch nicht indiziert hat), greift DepCheck aus Korrektheitsgründen auf die öffentliche osv.dev-API zurück. suggest_safe_version verwendet zusätzlich deps.dev, um die Releases eines Pakets aufzuzählen. In diesen Fallback-Fällen wird die Paketkoordinate (ecosystem, name und version) an diesen öffentlichen Dienst gesendet, um die Antwort aufzulösen.
• Was niemals an Dritte gesendet wird: Ihr Manifest als Dokument, Ihr Quellcode, Ihr API-Schlüssel oder Ihre Identität. Nur die minimale Koordinate, die zur Beantwortung einer Abfrage nötig ist, wird jemals weitergeleitet, und auch nur bei einem Spiegel-Fehltreffer.

Sie möchten keine externen Aufrufe?

Betreiben Sie DepCheck lokal über stdio gegen den souveränen Spiegel (oder einen Offline-Snapshot). In dieser Konfiguration werden Abfragen gegen den Spiegel aufgelöst, ohne öffentlichen Fallback-Verkehr — geeignet für Air-Gap- oder Hochsicherheitsumgebungen. Siehe Erste Schritte → Option 2.

Netzwerkaufstellung (gehostet)

• Dem Endpunkt ist Host-nginx vorgelagert, das den einzigen Ingress bildet und Authentifizierung, Ratenbegrenzung und TLS-Terminierung übernimmt.
• Der DepCheck-Container wird nur auf dem Host-Loopback veröffentlicht und liegt in einem dedizierten Docker-Netzwerk für einen einzelnen Dienst — andere Plattformdienste können ihn nicht direkt erreichen, und er kann sie nicht erreichen.
• Der MCP-Endpunkt (/depcheck) ist der einzige öffentlich exponierte Pfad. Betriebspfade (/metrics, Health) sind ausschließlich intern.

Compliance-Hinweise

• DepCheck verarbeitet Paketkoordinaten und Advisory-Identifikatoren — technische Metadaten, keine personenbezogenen Daten. Ein von Ihnen übermitteltes Manifest wird vorübergehend geparst, um diese Koordinaten zu extrahieren, und wird nicht als gespeichertes Dokument aufbewahrt.
• API-Schlüssel identifizieren einen Client/eine Organisation und dienen der Zugriffskontrolle und der aggregierten Ratenabrechnung — nicht der Profilbildung.
• Das Design „souveräner Spiegel zuerst“ hält die Aktivität zur Abhängigkeitsprüfung standardmäßig innerhalb der EU-/Cert-IX-Infrastruktur, wobei der öffentliche Fallback auf die minimale Koordinate beschränkt bleibt, die für die Korrektheit erforderlich ist.

Wenn Sie einen Auftragsverarbeitungszusatz oder eine Residenzgarantie für eine regulierte Arbeitslast benötigen, sprechen Sie mit Ihrem Cert-IX-Kundenteam über eine dedizierte oder vollständig offline betriebene Bereitstellung.

Checkliste bewährter Praktiken

• ✅ Speichern Sie den API-Schlüssel in der Secret-Konfiguration Ihres MCP-Clients, nicht im Repository.
• ✅ Rotieren Sie den Schlüssel bei Personalwechseln oder vermuteter Offenlegung.
• ✅ Scannen Sie Lockfiles für die installierte Wahrheit, nicht nur Manifeste mit Bereichen.
• ✅ Scannen Sie regelmäßig erneut — „heute sauber“ heißt nicht „für immer sauber“.
• ✅ Beheben Sie exploited-markierte Funde zuerst (siehe Werkzeugreferenz → get_cve_intel).
• ✅ Behalten Sie DepCheck als eine Schicht bei — kombinieren Sie es mit Review, SAST und geringstmöglichen Rechten.