Sicherheit und Datenverarbeitung

SecCheck ist ein Sicherheitswerkzeug und wird deshalb an den Maßstäben eines Sicherheitswerkzeugs gemessen. Diese Seite legt klar dar, wie er Sie authentifiziert, was er protokolliert und was den Cert-IX-Perimeter verlässt — und was nicht.

Authentifizierung und Berechtigungen

• Jede Anfrage an https://mcp.cert-ix.com/seccheck muss einen gültigen API-Schlüssel als Authorization: Bearer <key> tragen. Anfragen ohne ihn erhalten 401; das Backend sieht niemals unauthentifizierten Verkehr.
• Schlüssel sind kostenlos und im Self-Service erhältlich: Fordern Sie einen unter cert-ix.com/tools/seccheck-mcp an, bestätigen Sie Ihre E-Mail-Adresse, und der Schlüssel kommt per E-Mail. Ein Self-Service-Schlüssel gehört zur Community-Edition, ist 90 Tage gültig und lässt sich über die Erinnerungs-E-Mail verlängern, die vor seinem Ablauf verschickt wird. Behandeln Sie einen Schlüssel wie ein Passwort: in der Konfiguration Ihres MCP-Clients oder einem Secret-Store aufbewahren, niemals in der Versionsverwaltung, und bei möglichem Leck rotieren.
• Der gesamte Verkehr läuft über TLS. Senden Sie Schlüssel nicht über unverschlüsseltes HTTP.

Ihre Edition reist mit Ihrem Schlüssel — und das ist der Teil, den man verstehen sollte:

Berechtigungen werden am Edge aufgelöst, pro Anfrage

Der Cert-IX-Edge authentifiziert Ihren Schlüssel und setzt dann Ihre Berechtigungen auf der weitergeleiteten Anfrage — bedingungslos, bei jeder Anfrage, auch wenn sie leer sind. Ein Aufrufer kann seine eigene Stufe also nicht behaupten, indem er selbst Berechtigungsangaben mitsendet: Was Sie senden, wird überschrieben, bevor das Backend es sieht.

Der Server verweigert im Hosted-Modus den Start, wenn eine prozessweite Lizenzdatei konfiguriert ist — eine einzige Umgebungsvariable würde sonst jeden Aufrufer auf einmal hochstufen. Berechtigungen kommen aus Ihrem Schlüssel, eine Anfrage nach der anderen, oder gar nicht.

Liefert ein Werkzeug einen unerwarteten Beschränkungsfehler, rufen Sie license_status auf — es meldet genau, was Ihre Zugangsdaten freischalten.

Ratenbegrenzung und Missbrauchsschutz

Der gehostete Endpunkt setzt Grenzen am Edge (Host-nginx) durch, bevor überhaupt Arbeit anfällt:

Geltungsbereich	Grenze
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

Die IP-Grenzen greifen vor der Authentifizierung, sodass auch unauthentifizierte Fluten begrenzt sind.

Das Überschreiten einer Grenze liefert 429 Too Many Requests mit einem Retry-After-Header. Beachten Sie ihn und warten Sie exponentiell; ein wohlerzogener Client bleibt bequem unter 10 Anfragen/Sekunde pro Schlüssel. Diese Obergrenzen liegen weit über normaler Agentennutzung — eine Handvoll Suchen und ein bis zwei Ladevorgänge je Aufgabe — und sollen Fluten stoppen, nicht echte Arbeit ausbremsen.

Wiederholte Authentifizierungsfehler gelten als Missbrauch: Eine IP, die in kurzer Zeit viele 401 erzeugt, wird vorübergehend gesperrt (fail2ban). Ein gültiger Schlüsselinhaber erreicht das nie, denn ein korrekter Schlüssel erzeugt nie ein 401.

Was Sie senden und was damit geschieht

Die Werkzeuge von SecCheck sind schreibgeschützte Abfragen gegen einen festen Korpus. Genau dafür wird jede Art von Eingabe verwendet:

Sie senden	Was SecCheck damit macht
Eine Suchanfrage und Filter	Bewertet sie gegen den Katalog im Arbeitsspeicher und liefert passende Playbook-Kurzfassungen.
Eine Skill-ID	Liefert das SKILL.md dieses Playbooks.
Eine Skill-ID + einen Ressourcenpfad	Liefert diese mitgelieferte Datei, strikt innerhalb des skilleigenen Verzeichnisses aufgelöst.

Sie senden SecCheck niemals Ihren Code, Ihre Logs, Ihre Erkenntnisse oder irgendetwas über Ihre Umgebung — die Werkzeuge nehmen eine Suchzeichenkette und Bezeichner entgegen, sonst nichts. Der gehostete Server hat keinen Zugriff auf Ihr Dateisystem und keine Möglichkeit, in Ihre Systeme zu greifen.

Welche Betriebsdaten aufbewahrt werden

Es gibt zwei Aufzeichnungen, beide bewusst eng gefasst:

• Nutzungsmessung — aggregierte Aufrufzahlen je Werkzeug und je Kunde, für Kapazität und Überwachung. Eine laufende Anzeige, kein Abrechnungsbuch.
• Ein Audit-Datensatz je Werkzeugaufruf, mit dem Werkzeugnamen, nur den Argumentnamen, Ihrer Kundenkennung, Ihrer Stufe und ob der Aufruf fehlschlug.

Suchanfragen werden niemals protokolliert

Der Audit-Datensatz hält fest, dass Sie search_skills mit einem query-Argument aufgerufen haben — nicht, was die Anfrage sagte. Eine Suchanfrage ist Benutzereingabe und kann einen laufenden Vorfall beschreiben; den Schlüssel ohne den Wert festzuhalten macht das Log zum Nachweis für Zugriffsprüfungen statt zu einem Debug-Abzug Ihrer Sicherheitslage.

Beide sind ausschließlich über einen internen, tokengeschützten /metrics-Endpunkt zugänglich, der nie aus dem öffentlichen Internet erreichbar ist und der geschlossen ausfällt — ohne konfiguriertes Token verweigert er die Auslieferung ganz.

Datenresidenz — wo die Inhalte liegen

Für SecCheck ist die Antwort einfach:

• Der gesamte Korpus aus 857 Playbooks ist im SecCheck-Server eingebettet und wird aus dem Arbeitsspeicher ausgeliefert. Suche, Laden und Ressourcenzugriffe werden allesamt von dem Server beantwortet, der die Anfrage erhalten hat.
• SecCheck tätigt zur Laufzeit keine ausgehenden Aufrufe an Drittanbieterdienste. Es gibt keine Upstream-API, keine Rückfallabfrage, keine Telemetrie an einen externen Anbieter — derselbe Server antwortet auch bei vollständig abgeschaltetem Netzwerk. Ihre Anfrage wird in der Cert-IX-Infrastruktur beantwortet und nirgendwohin sonst weitergeleitet.
• Ihr MCP-Client und das KI-Modell dahinter sehen ebenfalls alles, was Ihr Agent sendet und empfängt. Dieser Teil wird von Ihrem Client und Ihrem Modellanbieter bestimmt, nicht von Cert-IX.

Sie möchten einen vollständig offline betriebenen Einsatz?

Betreiben Sie SecCheck lokal über stdio — die Binärdatei trägt den Korpus in sich und benötigt kein Netz, was zu abgeschotteten und besonders sicherheitskritischen Umgebungen passt. Siehe Erste Schritte → Variante 2. Die lokale Binärdatei ist derzeit kein öffentlicher Download – sprechen Sie mit Ihrem Cert-IX-Kundenteam.

Netzwerkaufstellung (gehostet)

• Der Endpunkt liegt hinter Host-nginx, dem einzigen Eingang, der Authentifizierung, Ratenbegrenzung, Berechtigungsauflösung und TLS-Terminierung übernimmt.
• Der SecCheck-Container ist nur auf dem Loopback des Hosts veröffentlicht und daher aus dem Internet ausschließlich über dieses nginx erreichbar.
• Der Go-Server verweigert eine Bindung außerhalb des Loopbacks, sofern sie nicht ausdrücklich erlaubt wird, denn die Anwendungsschicht hat keine eigene Authentifizierung — Authentifizierung ist Aufgabe des Edge, und eine Bindung auf alle Schnittstellen würde einen unauthentifizierten MCP-Server veröffentlichen.
• /seccheck ist der einzige öffentlich exponierte Pfad dieses Servers. Betriebspfade (/metrics) sind rein intern.

Inhaltsintegrität

Ein leerer oder unvollständiger Korpus wäre das „falsch-saubere Urteil" dieses Produkts: search_skills lieferte „keine Treffer", und ein Modell läse das als „diese Sicherheitsarbeit gibt es nicht". Deshalb verweigert der Server den Start im Hosted-Modus bei leerem Katalog, und seine Health-Prüfung meldet „nicht gesund", statt einen solchen auszuliefern — ein Image ohne Korpus kann das Deployment nicht passieren.

Lizenz- und Nennungspflichten

Die Playbooks sind Inhalte Dritter, weitergegeben unter permissiven Lizenzen (Apache-2.0 und MIT); alle Rechte der Originalautoren bleiben gewahrt.

• get_attribution liefert Herkunft, Autor, Lizenzkennung, Projektseite und den vollständigen Lizenztext jeder Bibliothek.
• Wenn Sie Playbook-Inhalte weitergeben — intern in großem Umfang, in einem Produkt oder in einem Kundenergebnis — reproduzieren Sie diese Hinweise. Der Zugang über SecCheck ändert die zugrunde liegenden Lizenzbedingungen nicht.

Compliance-Hinweise

• SecCheck verarbeitet Suchanfragen und Dokumentbezeichner — technische Eingaben, keine personenbezogenen Daten. Die Werte der Anfragen werden nicht aufbewahrt.
• API-Schlüssel identifizieren einen Kunden bzw. eine Organisation, zur Zugriffssteuerung, Berechtigungsauflösung und aggregierten Ratenabrechnung — nicht zur Profilbildung.
• Das Design mit eingebettetem Korpus beantwortet jede Anfrage in der Cert-IX-Infrastruktur: SecCheck selbst hat keinen Drittanbieter-Abfrageweg, aus dem man sich abmelden müsste.

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

Zulässige Nutzung

Die Bibliothek enthält offensives Material — Exploitation, Credential-Angriffe, Post-Exploitation, Web-Angriffsmethodik. Sie wird für autorisierte Sicherheitsarbeit veröffentlicht: eigene Systeme, Aufträge mit schriftlicher Genehmigung, CTFs, Schulungsumgebungen und defensive Forschung.

Sie zum Angriff auf Systeme zu nutzen, die Sie nicht testen dürfen, ist Missbrauch des Dienstes und liegt in Ihrer Verantwortung. Cert-IX kann einen so genutzten Schlüssel widerrufen.

Checkliste guter Praxis

• ✅ Bewahren Sie den API-Schlüssel in der Secret-Konfiguration Ihres MCP-Clients auf, nicht im Repository.
• ✅ Rotieren Sie den Schlüssel bei Personalwechseln oder Verdacht auf Offenlegung.
• ✅ Lassen Sie den Agenten ein NO MATCH deutlich benennen, statt ein Verfahren zu improvisieren (siehe Agenten-Workflows).
• ✅ Lesen Sie ein Playbook, bevor Sie seine Befehle ausführen — es ist eine Anleitung Dritter, geschrieben für den Stack anderer.
• ✅ Hat das Playbook einen Verifikations- oder Validierungsabschnitt, führen Sie ihn aus, bevor Sie die Arbeit als erledigt melden.
• ✅ Reproduzieren Sie die Nennungshinweise, wenn Sie Inhalte weitergeben.
• ✅ Behalten Sie SecCheck als eine Ebene unter mehreren — kombinieren Sie ihn mit Review, Tests und Ihren bestehenden Kontrollen.