open·kritt organisiert KI-gestützte Sicherheitsprüfungen

Worum es geht

open·kritt ist eine offene, selbst hostbare Plattform für Sicherheitsforscher und Entwickler, die Quellcode mit KI-Agenten auf Schwachstellen untersuchen wollen. Das Projekt wurde im Juli 2026 auf GitHub veröffentlicht und steht unter der AGPL-3.0-Lizenz. Statt einem Modell pauschal ein ganzes Repository zu übergeben, zerlegt das Tool die Analyse in kleinere, klar umrissene Schritte.

Das ist praktisch, weil automatisierte Sicherheitsprüfungen oft zwei gegensätzliche Probleme haben: Sie erzeugen viele unbrauchbare Hinweise oder übersehen Fehler, deren Nachweis mehrere Arbeitsschritte verlangt. open·kritt versucht, Analyse, Validierung, Priorisierung und Berichterstellung in einem nachvollziehbaren Ablauf zu verbinden.

Was open·kritt tatsächlich macht

Nutzer bauen wiederverwendbare Workflows aus fokussierten Prompts. Diese Schritte können parallel durch Codex oder Claude Code ausgeführt werden. Als Ziel dienen lokale oder entfernte Repositories samt Abhängigkeiten. Anschließend führt die Plattform Ergebnisse zusammen, entfernt doppelte Funde und ordnet sie nach einer konfigurierbaren Schwerebewertung.

Für die Validierung lassen sich Skripte ausführen, Tests kompilieren und Beweise für eine Schwachstelle erstellen. Modellzugänge können über eine Codex-Anmeldung oder über OpenAI, Anthropic und OpenRouter eingebunden werden. Die Oberfläche läuft lokal; die dokumentierte Einrichtung benötigt Git, Docker Compose und Node.js ab Version 20.

Wichtig ist die technische Grenze: Der Backend-Dienst bringt laut Projektdokumentation keine eigene Anwendungsauthentifizierung mit. Die Standardports binden zwar an 127.0.0.1, doch das System gehört nicht ungeschützt ins öffentliche Netz.

Warum das wichtig ist

Ein guter Sicherheitsfund besteht nicht nur aus einer Vermutung. Teams müssen den betroffenen Code lokalisieren, die Ausnutzbarkeit prüfen, ähnliche Hinweise zusammenführen und eine verständliche Übergabe an Entwickler erstellen. Genau an diesen Übergängen verlieren allgemeine Chat-Assistenten häufig Kontext.

open·kritt macht die einzelnen Schritte sichtbar und wiederholbar. Das ist besonders für AppSec-Teams, Bug-Bounty-Forscher und Entwickler interessant, die eigene Prompts, Modelle und Infrastruktur kontrollieren möchten. Die AGPL-Lizenz erlaubt Prüfung und Selbstbetrieb des Codes, verpflichtet bei netzwerkbasierter Weiterentwicklung aber zur Bereitstellung des geänderten Quellcodes. Vor einer betrieblichen Einführung sollte die Lizenz deshalb juristisch und organisatorisch geprüft werden.

Der Anbieter verweist außerdem auf mehr als 1,5 Millionen US-Dollar Bug-Bounty-Auszahlungen des Forschungsteams unter dem Namen Blockian. Diese Selbstauskunft ist ein Hinweis auf Praxiserfahrung, ersetzt jedoch keine unabhängige Wirksamkeitsmessung des Produkts.

Einfach erklärt

Man kann sich open·kritt wie eine Werkstattprüfung für ein Auto vorstellen. Ein einzelner Mechaniker hört nicht nur kurz auf den Motor und schreibt „möglicherweise kaputt“. Mehrere klar definierte Prüfstationen kontrollieren Bremsen, Elektrik und Flüssigkeiten, bestätigen Auffälligkeiten und führen doppelte Meldungen zu einem gemeinsamen Befund zusammen.

Die KI-Agenten sind dabei die Prüfstationen. Der menschliche Sicherheitsforscher bleibt der Meister, der den Ablauf festlegt, gefährliche Tests begrenzt und entscheidet, ob ein Fund wirklich belastbar ist.

Praktisches Beispiel

Ein Team betreibt eine Webanwendung mit 250.000 Codezeilen und möchte vor einem Release die Authentifizierung prüfen. Es erstellt einen Workflow mit fünf Schritten: Angriffsfläche erfassen, Sitzungslogik untersuchen, verdächtige Stellen priorisieren, reproduzierbare Tests ausführen und bestätigte Funde dokumentieren.

Vier Agenten bearbeiten getrennte Teilbereiche. Sie liefern zunächst 32 Hinweise. Die Deduplizierung fasst ähnliche Meldungen zu zwölf Kandidaten zusammen. Validierungsskripte bestätigen drei Fehler; neun bleiben unbewiesen oder erweisen sich als Fehlalarm. Erst dann prüft ein erfahrener Mensch die Beweise und entscheidet über Priorität und Behebung. Diese Zahlen sind ein fiktives Beispiel, keine veröffentlichte Leistungskennzahl von open·kritt.

Einordnung und Grenzen

Erstens laufen werkzeugfähige Agenten als Root in kurzlebigen Job-Containern. Sie erhalten beschreibbare Kopien des Repositories und direkten Internetzugang. Ein manipuliertes Repository oder ein fehlerhafter Befehl kann deshalb erheblichen Schaden verursachen. Die Entwickler empfehlen einen dedizierten Docker-Host oder eine virtuelle Maschine.

Zweitens ist ein KI-Fund kein Beweis für eine ausnutzbare Schwachstelle. Modelle können Datenflüsse falsch verstehen, Tests unvollständig ausführen oder überzeugende Fehlalarme formulieren. Veröffentlichung, Ticketpriorität und produktive Änderungen brauchen menschliche Prüfung.

Drittens verursacht der Betrieb Aufwand und Modellkosten. Teams müssen Prompts pflegen, Schlüssel schützen, Container überwachen und Ergebnisse vergleichen. Wer nur einen kleinen Codebestand gelegentlich scannt, ist mit etablierten statischen Analysewerkzeugen möglicherweise schneller. open·kritt ersetzt außerdem weder klassische SAST- und Dependency-Scanner noch manuelle Pentests.

Der sinnvolle nächste Test ist daher klein: eine nicht produktive Repository-Kopie in einer isolierten VM, ein eng begrenzter Workflow und ein Vergleich der bestätigten Funde mit vorhandenen Scannern.

SEO- und GEO-Schlüsselbegriffe

open·kritt, Kritt AI, KI-Sicherheitsprüfung, AppSec, Schwachstellenanalyse, Security Agents, selbst gehostete KI, Codex, Claude Code, AGPL-3.0, Docker, Code Security