open·kritt prüft Quellcode mit spezialisierten Sicherheitsagenten

Worum es geht

open·kritt ist eine quelloffene, selbst hostbare Arbeitsumgebung für die automatisierte Schwachstellenforschung in Quellcode. Statt einem Sprachmodell pauschal ein ganzes Repository vorzulegen, zerlegt das Werkzeug eine Prüfung in kleinere Aufgaben, verteilt sie auf Agenten und führt die Ergebnisse als priorisierte Befunde zusammen. Das Projekt gehört Kritt und steht unter der AGPL-3.0-Lizenz.

Die aktuelle Version 1.4.1 erschien am 16. August 2026. Für Nutzer ist weniger das Veröffentlichungsdatum entscheidend als die Kombination aus grafischer Oberfläche, wiederverwendbaren Prüfabläufen, mehreren Modellanbietern und einem strukturierten Export. Das macht open·kritt zu einem konkreten Werkzeug für Sicherheitsteams und nicht bloß zu einer Forschungsdemo.

Was open·kritt tatsächlich macht

Ein Team baut in open·kritt einen Prüfablauf aus fokussierten Prompts. Diese Schritte können parallel mit Codex, Claude Code oder Grok Build laufen. Das Werkzeug analysiert lokale oder entfernte Repositories sowie Abhängigkeiten, vereinheitlicht die Befunde, entfernt Dubletten und lässt eigene Regeln für die Schweregrade zu. Nachgelagerte Skripte können einen Verdacht validieren, einen Machbarkeitsnachweis erzeugen oder einen Bericht vorbereiten.

Abgeschlossene Läufe lassen sich mitsamt strukturierten Daten, Berichten und Nachweisen als ZIP Archiv exportieren. Für Server ohne grafische Oberfläche gibt es zusätzlich eine Kommandozeile. Beim Modellzugang haben Betreiber mehrere Möglichkeiten: Anmeldung mit Codex oder eigene Zugänge zu OpenAI, Anthropic, DeepSeek, OpenRouter beziehungsweise xAI. Das Werkzeug selbst läuft per Docker Compose und benötigt außerdem Git sowie Node.js ab Version 20.

Warum das wichtig ist

Allgemeine Modellprompts liefern bei großen Codebasen oft lange, doppelte oder schlecht überprüfbare Listen. open·kritt versucht, dieses Problem als Arbeitsablauf zu behandeln: Eine Aufgabe sucht etwa nach fehlerhafter Autorisierung, eine weitere verfolgt Datenflüsse und eine dritte prüft nur aussichtsreiche Befunde praktisch. Das kann Sicherheitsfachleuten helfen, die knappe Prüfzeit auf belastbarere Kandidaten zu konzentrieren.

Die Selbsthostung ist ebenfalls relevant. Quellcode, Prüflogik und Ergebnisdaten können in der eigenen Umgebung bleiben. Allerdings bedeutet das nicht, dass sämtliche Daten lokal bleiben: Die gewählten Modellanbieter erhalten die für ihre Aufgaben notwendigen Inhalte. Welche Daten übertragen werden, hängt daher von der Konfiguration und den Verträgen mit diesen Anbietern ab.

Die offene AGPL Lizenz ermöglicht eine technische Prüfung des Systems und verlangt bei netzwerkbasierten Änderungen grundsätzlich, den entsprechenden Quellcode bereitzustellen. Unternehmen sollten vor einer internen Anpassung klären, wie diese Pflicht zu ihrem Einsatz passt.

Einfach erklärt

Eine Sicherheitsprüfung mit nur einem allgemeinen Prompt ähnelt einem einzigen Handwerker, der ein ganzes Haus in einem Rundgang begutachten soll. open·kritt organisiert stattdessen mehrere Fachleute: Eine Person prüft die Elektrik, eine die Türen und eine die Wasserleitungen. Danach werden doppelte Hinweise aussortiert und die wichtigsten Schäden noch einmal praktisch getestet. Der Bauleiter bleibt trotzdem ein Mensch, denn auch ein ordentlich sortierter Bericht kann falsche Befunde enthalten.

Praktisches Beispiel

Ein Team möchte ein Repository mit 80.000 Codezeilen vor einer Veröffentlichung prüfen. Es erstellt vier Schritte: Zugriffsrechte untersuchen, Eingaben bis zur Datenbank verfolgen, Abhängigkeiten sichten und die zehn am höchsten bewerteten Verdachtsfälle validieren. open·kritt führt die fokussierten Aufgaben parallel aus, vereinigt gleichartige Meldungen und exportiert die verbleibenden Befunde.

Angenommen, aus 34 Rohmeldungen werden nach der Zusammenführung 15 unterschiedliche Kandidaten. Die Validierung bestätigt drei, verwirft sieben und lässt fünf offen. Das Beispiel ist bewusst fiktiv und kein Leistungsversprechen. Sein Zweck ist der Arbeitsablauf: Das Team erhält eine prüfbare Warteschlange, muss aber jeden bestätigten Fund fachlich bewerten und die Behebung separat testen.

Einordnung und Grenzen

Erstens besitzt der offene Stack laut Projektdokumentation keine eingebaute Anwendungsauthentifizierung und bindet standardmäßig nur an 127.0.0.1. Er gehört in ein privates Netz und nicht unverändert ins öffentliche Internet.

Zweitens laufen werkzeugfähige Agenten als Root in kurzlebigen Jobcontainern, mit beschreibbaren Repositorykopien und direktem Internetzugang. Für unbekannten oder feindlichen Code empfiehlt das Projekt deshalb einen eigenen Docker Host oder eine isolierte virtuelle Maschine.

Drittens ersetzt die Ausgabe weder eine manuelle Sicherheitsprüfung noch einen reproduzierbaren Machbarkeitsnachweis. Agenten können Schwachstellen übersehen, harmlose Stellen falsch einstufen oder beim Validieren riskante Befehle ausführen. Kosten und Datenschutz hängen außerdem vom ausgewählten Modellanbieter ab.

Der nächste sinnvolle Test ist daher klein: ein nicht vertrauliches Testrepository in einer isolierten Umgebung prüfen, die Befunde manuell nachstellen und erst danach über echte Produktquellen entscheiden.

SEO- und GEO-Schlüsselbegriffe

open·kritt, Kritt, KI Sicherheitswerkzeug, Quellcodeprüfung, Schwachstellenforschung, selbst gehostete KI, Coding Agents, Codex, Claude Code, DevSecOps, AGPL-3.0, Docker Compose