OpenHack macht KI-Bugsuche prüfbar statt magisch

Worum es geht

Hadrian hat am 25. Mai 2026 OpenHack öffentlich gemacht: ein MIT-lizenziertes, quelloffenes Workspace-System für source-guided Vulnerability Research. Es ist kein weiterer Chatbot, der Code liest und am Ende ein Urteil ausspuckt. OpenHack legt stattdessen jeden Schritt einer Sicherheitsprüfung als Datei ab: Recon-Ergebnisse, Routing-Einheiten, Szenarien, Szenario-Resultate, Finding-Kandidaten, Triage-Entscheidungen, finale Findings und Logs.

Das ist deshalb interessant, weil KI in der Sicherheitsarbeit oft an einer Vertrauensfrage scheitert. Wenn ein Modell behauptet, eine kritische Lücke gefunden zu haben, müssen Teams wissen: Woher kommt diese Vermutung? Wurde sie geprüft? Wer hat den nächsten Schritt freigegeben? OpenHack versucht genau diese Kette sichtbar zu machen.

Was OpenHack tatsächlich macht

OpenHack läuft innerhalb eines Coding-Harnesses wie Claude Code, Codex, Cursor oder eines eigenen Runners. Das Harness liefert Modellzugriff, Terminal, Repository-Zugriff und die Umgebung. OpenHack liefert die robuste Arbeitsordnung: Es erstellt eine Run-Struktur, sammelt Review-Oberflächen, erzeugt Szenarien, lässt Experten-Agenten diese Szenarien prüfen und führt anschließend eine separate Triage durch.

Der Kern ist eine schmale Zustandskette: Recon Item → Routing Unit → Scenario → Scenario Result → Finding Candidate → Triage Decision → Finding. Ein Mensch genehmigt die Phasenübergänge. Dadurch wird aus einer wilden Agenten-Schleife ein überprüfbarer Prozess. Optional können Semgrep-Regeln Hinweise für die Recon-Phase liefern; laut Projektbeschreibung werden diese Treffer aber nur als Hinweise behandelt, nicht automatisch als bewiesene Schwachstellen.

Warum das wichtig ist

Die Sicherheitsbranche steht gerade zwischen zwei Extremen. Auf der einen Seite können Coding-Agenten große Codebasen schneller durchsuchen als einzelne Analysten. Auf der anderen Seite erzeugen sie falsche Positives, übersehen Kontext oder halluzinieren Exploit-Pfade. OpenHack setzt an der Stelle an, an der echte Sicherheitsteams leben: nicht bei der großen Demo, sondern beim reproduzierbaren Beleg.

Der veröffentlichte Workflow benennt zwölf Experten-Familien, die unter anderem an OWASP-Top-10-Kategorien, MITRE-Begriffen und CWE-Klassen ausgerichtet sind. Das ist kein Beweis, dass OpenHack automatisch bessere Findings liefert. Es ist aber ein starkes Signal: Die Agentenarbeit wird in bekannte Sicherheitskategorien übersetzt, statt als proprietäre Blackbox verkauft zu werden. Für Open-Source-Projekte und kleinere Teams ist die MIT-Lizenz außerdem wichtig, weil sie Experimente ohne großes Budget ermöglicht.

Einfach erklärt

Stell dir eine Wohnungsabnahme vor. Ein schlechter Prüfer läuft durch die Räume und sagt am Ende: „Hier gibt es Probleme.“ Ein guter Prüfer macht Fotos, notiert den Raum, beschreibt den Schaden, lässt offene Fragen bestätigen und trennt Vermutung von Befund. OpenHack versucht, KI-Bugjagd genau in diese zweite Form zu bringen: Jeder Hinweis bekommt einen Ort, eine Begründung und eine Entscheidung.

Praktisches Beispiel

Ein Team betreibt eine interne Web-App mit 140.000 Zeilen Code, 38 API-Routen und drei Upload-Funktionen. Ein OpenHack-Lauf könnte zuerst die Routen, Auth-Grenzen und Parser-Einstiege sammeln. Danach erzeugt der Router zum Beispiel 18 Szenarien: Zugriff ohne Rolle, unsichere Dateiendungen, fehlende Größenlimits oder Injection-Pfade.

Ein Experten-Agent prüft ein Upload-Szenario und findet einen möglichen Pfad-Traversal-Fall. Das wird nicht sofort als Schwachstelle veröffentlicht. Zuerst entsteht ein Finding-Kandidat mit Belegen. Danach entscheidet eine getrennte Triage, ob der Befund akzeptiert, herabgestuft, als Duplikat markiert oder verworfen wird. So kann ein Security Lead später nachvollziehen, warum aus 18 Szenarien vielleicht nur zwei echte Findings wurden.

Einordnung und Grenzen

• OpenHack ersetzt keine erfahrenen Sicherheitsprüfer. Es strukturiert Arbeit, aber ein Mensch muss Scope, Risiko und Belege bewerten.
• Die Qualität hängt stark vom Harness, Modell, Repository-Zugriff und den Prompts ab. Ein schlechter Lauf bleibt ein schlechter Lauf, auch wenn die Dateien ordentlich aussehen.
• Der Ansatz passt besser zu Quellcode-Prüfungen als zu reinem Blackbox-Pentesting. Laufzeitverhalten, Produktlogik und Produktionsdaten können trotzdem fehlen.

Der wichtigste Punkt ist nüchtern: OpenHack macht KI-Sicherheitsarbeit nicht automatisch wahr. Es macht sie besser prüfbar. Und genau das ist bei sicherheitskritischen Agenten oft wertvoller als die nächste laute Modellbehauptung.

SEO- und GEO-Schlüsselbegriffe

OpenHack, Hadrian, AI vulnerability research, source-guided security review, AI security, OWASP Top 10, MITRE ATT&CK, Semgrep, coding agents, Claude Code, Codex, Cursor