OpenHack: Workflow verwandelt LLMs in strukturierte Sicherheits‑Code‑Reviewer

Durch diese Integration kann ein Sicherheitsscan direkt im normalen Entwicklungsworkflow stattfinden, statt als separater manueller Audit.

Das Kernproblem klassischer LLM‑Codeanalysen

Wenn Entwickler ein Modell einfach bitten, „Schwachstellen im Repository zu finden“, entstehen häufig mehrere Probleme:

• hohe False‑Positive‑Raten – harmlose Patterns werden als Sicherheitslücken markiert
• Halluzinierte Findings, die im Code gar nicht existieren
• Inkonsistente Analysen, abhängig von Prompt oder Kontextfenster

OpenHack versucht, diese Schwächen durch eine klar definierte Methodik zu reduzieren. Statt offener Prompts wird der Analyseprozess in strukturierte Schritte zerlegt.

Szenariobasierte Sicherheitsanalyse

Ein zentrales Konzept von OpenHack ist Scenario‑Based Scoping.

Anstatt das gesamte Projekt ohne Fokus zu durchsuchen, untersucht das Modell gezielt bestimmte Angriffsszenarien. Beispiele:

• Nachverfolgung von Benutzer‑Input durch den gesamten Code
• Suche nach möglichen Local‑File‑Inclusion‑Angriffen (LFI)
• Analyse von Credential‑Speicherung oder Cloud‑Konfigurationen

Diese gezielte Fragestellung hilft dem Modell, sich auf konkrete Angriffspfade zu konzentrieren. Laut Hadrian verbessert das die Qualität der Analyse und reduziert generische oder irrelevante Hinweise.

Getrennte Triage zur Reduktion von Fehlalarmen

Ein weiterer wichtiger Bestandteil ist die Trennung von Entdeckung und Validierung.

Ein typischer OpenHack‑Workflow sieht so aus:

1. Ein KI‑Agent identifiziert eine potenzielle Schwachstelle.
2. Ein zweiter Schritt oder Agent übernimmt die Triage.
3. Erst nach Prüfung der Beweise wird der Fund als echte Sicherheitslücke akzeptiert.

Dieser Ansatz zwingt das System, Belege zu sammeln – etwa konkrete Codepfade, Konfigurationsdetails oder mögliche Exploit‑Ketten – bevor ein Problem gemeldet wird.

Einsatz in Audits für niederländische Behörden

Hadrian berichtet, eine ähnliche Methodik bereits in Sicherheitsanalysen von Open‑Source‑Software eingesetzt zu haben, die von niederländischen Regierungsstellen genutzt wird. Dabei seien innerhalb weniger Stunden hunderte Schwachstellen entdeckt worden.

Ein besonders schwerwiegendes Beispiel aus der Untersuchung:

• eine nicht authentifizierte Local‑File‑Inclusion‑Schwachstelle (LFI)
• Zugriff auf Azure‑Zugangsdaten
• ein möglicher Weg zu Remote Code Execution in einer Azure‑Umgebung

Diese Ergebnisse stammen primär aus Berichten des Herstellers selbst und sollten daher mit Vorsicht interpretiert werden, bis unabhängige Analysen vorliegen.

Warum Hadrian OpenHack veröffentlicht hat

Hadrian hat OpenHack auf GitHub unter der MIT‑Lizenz veröffentlicht. Das Projekt enthält Dokumentation, Prompts, CLI‑Werkzeuge sowie Unterstützung für Python 3.9 und neuer.

Nach Angaben des Unternehmens soll der offene Ansatz dabei helfen, die Möglichkeiten der KI‑gestützten Schwachstellenanalyse auch für Verteidiger zugänglich zu machen. Wenn solche Techniken nur proprietär verfügbar wären, könnten Angreifer langfristig einen Vorteil haben.

Ein Teil eines größeren Trends

OpenHack steht stellvertretend für eine größere Entwicklung in der Software‑Sicherheit: KI‑Agenten durchsuchen Codebasen zunehmend automatisiert nach Sicherheitsproblemen.

Moderne KI‑Entwicklungsumgebungen können bereits:

• große Repositories analysieren
• Architekturzusammenhänge verstehen
• Entwicklungs‑ und Review‑Aufgaben automatisieren

Workflows wie OpenHack versuchen, diese Fähigkeiten in strukturierte Prozesse zu überführen – damit aus allgemeinen Sprachmodellen systematische Sicherheitsprüfer werden, statt unberechenbarer Code‑Reviewer.