Modell / Datensatz
lintsinghua/DeepAudit avatar
lintsinghua/DeepAudit

DeepAudit: Multi-Agenten-Code-Audit mit Sandbox-PoC-Verifikation

Projektüberblick: DeepAudit ist eine Open-Source-Multi-Agent-Sicherheitsplattform für die Schwachstellensuche, mit automatisierter PoC-Validierung und Berichts-Export, inklusive privatem Ollama-Einsatz.

7.020 Sterne850 ForksPythonAGPL-3.0
GitHub

Auf einen Blick

Was ist das?
Das Python-Projekt DeepAudit von lintsinghua orchestriert mehrere KI-Agenten für Code-Sicherheitsaudits, prüft verdächtige Stellen in einer Docker-Sandbox nach und wirbt mit 49 selbst gefundenen CVE-Nummern. AGPL-3.0-Lizenz und rechtliche Nutzungsbeschränkungen grenzen den Einsatzzweck klar ein.
Für wen ist es gedacht?
DeepAudit eignet sich für Sicherheitsteams und Forschende, die über einfaches SAST hinausgehen wollen, denn der Verification-Agent führt PoC-Skripte in einer Docker-Sandbox aus und sortiert Fehlalarme aus. Wer sensible Codebasen prüft, sollte laut README Ollama mit lokalen Modellen wie Qwen2.5 oder DeepSeek-Coder anbinden, da Code sonst an den gewählten LLM-Anbieter gesendet wird.
Darf ich es kommerziell nutzen?
Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 11 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich Python, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Warum DeepAudit vier Agenten statt einer Regelengine einsetzt

Herkömmliche SAST-Werkzeuge kämpfen laut README mit drei Problemen: hohen Fehlalarmraten, blinden Flecken bei Geschäftslogik und fehlender Verifikation der gemeldeten Funde. DeepAudit aus dem Haus lintsinghua greift das auf, indem es das audit als Zusammenarbeit mehrerer KI-Agenten organisiert, die Rollen wie Orchestrator, Recon, Analysis und Verification übernehmen.

Der Einstieg ist bewusst niedrig gehalten: Man importiert ein Projekt über GitHub, GitLab oder Gitea, und die Plattform erkennt den Technologie-Stack automatisch, analysiert Risiken, generiert Exploit-Skripte, verifiziert sie und schreibt daraus einen Bericht. Die Projektstruktur besteht aus einem FastAPI-Backend mit den Agent-Modulen und einem React-Frontend mit Zustand als Statusverwaltung.

Damit richtet sich das System an Neulinge wie an erfahrene Prüfer gleichermaßen. Das README nennt als Ziel, dass jeder ein AI-Hacker-Team zur Verfügung hat; die technische Umsetzung liegt in der Orchestrierung und der automatisierten Nachprüfung jedes Funds.

Der Auditablauf von der Rekonstruktion bis zum Bericht

Der Workflow läuft laut README in fünf Phasen ab. Zuerst nimmt der Orchestrator die Aufgabe an und erstellt einen Auditplan. Danach scannt der Recon-Agent die Projektstruktur und identifiziert eingesetzte Frameworks. In der dritten Phase kombiniert der Analysis-Agent RAG-Wissensanreicherung mit AST-Analyse, um potenzielle Schwachstellen zu lokalisieren.

Die vierte Phase ist der markanteste Unterschied zu klassischen Scannern: Der Verification-Agent schreibt selbst PoC-Skripte und führt sie in einer Docker-Sandbox aus, mit Selbstkorrektur und Wiederholungen bei Fehlschlägen. Ein Fund gilt damit erst als bestätigt, wenn sich ein Exploit tatsächlich ausführen ließ, was die Fehlalarmquote drücken soll.

Zum Abschluss aggregiert der Orchestrator alle Ergebnisse und erzeugt einen Bericht, der sich laut Funktionsliste nach PDF, Markdown oder JSON exportieren lässt. Das Regelwerk knüpft an die OWASP Top 10 an, und Prompt-Vorlagen lassen sich zur Laufzeit konfigurieren.

49 CVE-Nummern als Beleg aus der Praxis

Das README führt eine konkrete Erfolgsbilanz an: Die geschlossene Variante von DeepAudit habe 49 CVE-Nummern und 6 GHSA-Sicherheitshinweise in 17 bekannten Open-Source-Projekten hervorgebracht. Diese Zahlen sind Selbstauskunft des Projekts, verweisen aber auf nachprüfbare Einträge in der NVD und bei GitHub.

Zu den belegten Funden gehören sechs Schwachstellen im Projekt OpenClaw, darunter eine Signaturprüfungs-Umgehung mit CVSS 8.6, Codeausführung mit 8.5 und Offenlegung von Zugangsdaten mit 6.9. Bei Zentao PMS wurde eine Rechteausweitung mit CVSS 9.1 dokumentiert, bei Dataease JNDI-Injections mit 9.8.

Weitere Einträge betreffen PowerJob, Jimureport, H2o-3, Newbee-mall, das Macrozheng-Mall-Beispielprojekt und wiederholte XSS-Funde in O2oa. Die Funde werden den Teammitgliedern @lintsinghua und @ez-lbz zugeschrieben. Zur genauen Methodik je Audit schweigt das README; die Workflow-Beschreibung ist die einzige Grundlage.

Deployment mit einer Befehlszeile und lokale Modelle über Ollama

Für den Schnellstart empfiehlt das README einen Einzeiler, der vorgefertigte Docker-Images zieht: curl -fsSL https://raw.githubusercontent.com/lintsinghua/DeepAudit/v3.0.0/docker-compose.prod.yml | docker compose -f - up -d. Für Nutzer in China existiert eine beschleunigte Variante über einen Nanjing-Universitäts-Spiegel.

Wer selbst entwickeln will, braucht Python 3.11 oder neuer, Node.js 20 oder neuer, PostgreSQL 15 oder neuer und Docker. Das Backend startet nach uv sync mit uvicorn app.main:app --reload, das Frontend nach pnpm install mit pnpm dev. Hardware- und Cloud-Anforderungen spezifiziert die Dokumentation nicht.

Auf der Modellseite unterstützt DeepAudit internationale Anbieter wie OpenAI GPT-4o, Claude 3.5 Sonnet, Google Gemini Pro und DeepSeek V3, chinesische Plattformen wie Tongyi Qwen, Zhipu GLM-4, Moonshot Kimi und Doubao sowie lokale Modelle über Ollama, etwa Llama3, Qwen2.5, CodeLlama, DeepSeek-Coder und Codestral. Relay- und Proxy-Endpunkte für die API werden ebenfalls unterstützt.

Die Lizenz AGPL-3.0 und ihre Folgen für den Betrieb

DeepAudit steht unter AGPL-3.0. Diese Lizenz erlaubt Kopieren, Verbreiten und Modifizieren, verlangt aber bei Netzwerkservernutzung die Offenlegung des eigenen Quellcodes. Wer also eine abgewandelte DeepAudit-Instanz Dritten als Webservice anbietet, muss die Änderungen freigeben; für interne Unternehmensaudits ohne Weitergabe bleibt das irrelevant.

Das README enthält außerdem eine rechtliche Erklärung: Unbefugte Schwachstellentests, Penetrationstests oder Sicherheitsbewertungen sind untersagt. Das Projekt sei ausschließlich für Cybersicherheitsforschung, Lehre und Lernen bestimmt, und Nutzer tragen allein die Verantwortung für ihr Handeln.

Ein Datenschutz-Hinweis verdient Beachtung: Beim Audit wird Code an die Server des gewählten LLM-Anbieters gesendet. Für vertrauliche Codebasen empfiehlt das README deshalb die lokale Anbindung über Ollama, womit der Datenfluss im eigenen Netzwerk bleibt.

Fazit: Für wen DeepAudit in den Prüfstack passt

DeepAudit passt in Stacks, in denen klassische Scanner zwar laufen, aber zu viele unbestätigte Meldungen produzieren. DerVerification-Agent mit Docker-Sandbox adressiert genau diese Lücke, weil ein Bericht nur Funde enthält, deren PoC-Skripte tatsächlich liefen. Sicherheitsabteilungen mit eigenen Forschungsprojekten bekommen zudem einen dokumentierten Arbeitsfluss, der Rekonstruktion, Analyse und Nachprüfung trennt.

Ungeeignet ist das Werkzeug, wo eine Prüfung ohne Quellcodezugriff oder unter strikten Compliance-Vorgaben ohne Cloud-LLMs stattfinden soll, sofern nicht Ollama mit Modellen wie DeepSeek-Coder eingerichtet wird. Auch wer Software unter einer Lizenz weiterverbreiten will, die mit AGPL-3.0 nicht kompatibel ist, wird gebremst.

Das Projekt zählt rund 6.900 Sterne, die aktuelle Version v3.0.4 stammt vom Januar 2026. Wer es ausprobieren will, startet mit dem docker-compose.prod.yml-Einzeiler aus dem README und sollte danach in der Projektverwaltung einen GitHub-Import eines kleinen Testrepositorys anlegen, um die Agenten-Zusammenarbeit in den Audit-Flow-Protokollen live zu beobachten.

Redaktionelles Fazit

DeepAudit eignet sich für Sicherheitsteams und Forschende, die über einfaches SAST hinausgehen wollen, denn der Verification-Agent führt PoC-Skripte in einer Docker-Sandbox aus und sortiert Fehlalarme aus. Wer sensible Codebasen prüft, sollte laut README Ollama mit lokalen Modellen wie Qwen2.5 oder DeepSeek-Coder anbinden, da Code sonst an den gewählten LLM-Anbieter gesendet wird.

Offizielle Quellen

  1. Official README
  2. Project repository
  3. Release notes
Community-Notizen

Community-Notizen