Es ist nun ein Jahr her, seit eine Gruppe von Sicherheitsanbietern – Aikido , Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, hatten Semgrep geforkt, Semgrep Opengrep zu entwickeln. Das zugrunde liegende Ziel war einfach: statische Analysefunktionen im Open-Source-Bereich verfügbar zu halten und die fortschrittlichste Engine zu entwickeln.
Das Projekt konzentrierte sich auf vier Arbeitsbereiche, die innerhalb von Semgrep zu dieser Zeit schwierig oder unmöglich waren: die Umstellung auf OCaml 5 mit Shared-Memory-Parallelität, die Einführung einer dateiinternen, funktionsübergreifenden Taint-Analyse, die Erweiterung der Sprachunterstützung (einschließlich Visual Basic, Apex und Elixir) sowie die Implementierung nativer Windows-Unterstützung. Semgrep seitdem mit einer eigenen Umstellung auf OCaml 5 und der Einführung von Windows-Unterstützung nachgezogen, was ähnliche technische Prioritäten widerspiegelt.
Ein Jahr später zeigen diese Änderungen erste messbare Ergebnisse, wobei sie weiterhin vollständig mit den bestehenden Regeln und Konfigurationen vereinbar sind:
- 25–74 % schnellere Scans bei der Ausführung vollständiger Regelsätze in großen Repositorys
- Bis zu doppelt so schnelle Taint-Analyse, die umfassendere Sicherheitsprüfungen des Datenflusses ermöglicht
- 1,74 Millionen Downloads von Binärdateien aus GitHub-Veröffentlichungen
- Über 2.000 GitHub-Sterne
- 10 Sicherheitsunternehmen, die Opengrep im Produktivbetrieb einsetzen
Im ersten Jahr eines Open-Source-Forks geht es jedoch nicht nur darum, Funktionen bereitzustellen. Es geht darum, Vertrauen in das Projekt aufzubauen, zu beweisen, dass die Ziele hinter dem Fork langfristig Bestand haben, eine Governance zu etablieren und die Sicherheitspraktiken im Zuge der Reifung des Projekts zu verbessern. Dies wird in unserem Manifest und in der README-Datei in unserem Repository dargelegt.
In diesem Beitrag wird darüber nachgedacht, was gut funktioniert hat, was verbessert werden muss und wie es mit Opengrep weitergeht.
Fragen und Antworten für Betreuer
Heute wird Opengrep von Dimitris Mostrous, Maciej Piróg und Corneliu Hoffman gepflegt.
In diesem Frage-und-Antwort-Teil stellen wir ihnen alle wichtigen Fragen rund um Opengrep.
Frage: Was hat der Fork ermöglicht, was Semgrep innerhalb von Semgrep nicht möglich war?
A. Durch den Fork konnten wir mehrere architektonische Entscheidungen treffen, die innerhalb des bestehenden Upstream-Projekts nur schwer umsetzbar gewesen wären.
Zunächst haben wir die Engine auf OCaml 5 mit Shared-Memory-Parallelität umgestellt. Zu diesem Zeitpunkt Semgrep noch ein auf „Fork“ basierendes Parallelitätsmodell, was bestimmte Verbesserungen wie die Windows-Unterstützung extrem erschwerte. Der Umstieg auf OCaml 5 schuf eine bessere Grundlage für Leistungssteigerungen und plattformübergreifende Unterstützung. Infolgedessen konnten wir native Windows-Unterstützung einführen.
Anschließend haben wir die funktionsübergreifende Taint-Analyse als Open-Source-Lösung für die Nutzung durch beliebige Drittanbieter bereitgestellt. In Opengrep ist sie über das Flag „--taint-intrafile“ verfügbar, einschließlich der Unterstützung für Funktionen höherer Ordnung in mehreren Sprachen.
Außerdem haben wir die Sprachunterstützung erweitert, indem wir Visual Basic hinzugefügt und Apex sowie Elixir in der Open-Source-Engine aktiviert haben. Zudem wurde die Unterstützung für Clojure-Taints hinzugefügt.
Schließlich ermöglichte uns der Fork, Telemetrie und Abhängigkeiten von proprietären Diensten zu entfernen.
Frage: Wo kann ich einen messbaren Unterschied zwischen Opengrep und Semgrep feststellen?
A. Opengrep ist sowohl beim Scannen von Suchregeln als auch beim Scannen von Taint-Regeln schneller. Es bietet eine bessere Taint-Erkennung und liefert mehr Ergebnisse in Multi-Hop-Szenarien (zum Beispiel 25 gegenüber 5 bei ComfyUI mit Taint-Regeln). Außerdem lässt es sich in einer größeren Bandbreite von Umgebungen einfacher ausführen. Opengrep wird als eigenständige Binärdatei ohne Python-Abhängigkeit ausgeliefert, unterstützt von Haus aus mehr Sprachen und bietet Funktionen wie regelbezogene Zeitüberschreitungen, dynamische Zeitüberschreitungen basierend auf der Dateigröße sowie konfigurierbare Ignorier-Annotationen.
Frage: Welche technischen Arbeiten haben Sie im ersten Jahr durchgeführt?
A. Hinter den Leistungssteigerungen und neuen Funktionen stand ein erheblicher technischer Aufwand:
- 43 ausgelieferte Versionen
- 1.116 Commits in 318 Pull-Anfragen
- 1.546 Dateien wurden geändert
- 21 Mitwirkende an dem Projekt
Die Entwicklung wurde größtenteils von den drei Hauptbetreuern geleitet, doch das Projekt zieht mittlerweile auch Beiträge von außen an. Im ersten Jahr reichten 17 externe Mitwirkende 29 Pull-Anfragen ein. Zu den externen Beiträgen zählen Taint-Tracking und Sprachverbesserungen (Kotlin-Scope-Funktionen), die Vertriebsinfrastruktur (Installationsskript) sowie Verbesserungen der Ausgabe (Fingerprinting). Die Einstiegshürde ist hoch: Der Codeumfang beträgt etwa 200.000 Zeilen OCaml, und um eine Sprachfunktion beizusteuern, muss man verstehen, wie Sprachen geparst und in den generischen AST übersetzt werden und wie die Zwischenrepräsentationen und die Taint-Engine funktionieren. Es ist ein wichtiges Ziel für uns, die Basis externer Mitwirkender bis 2026 zu vergrößern.
Frage: Was hast du falsch gemacht?
A. Wir haben den Paketnamen auf PyPI nicht gesichert und bei unserer Veröffentlichung Wheels-Dateien bereitgestellt. In Verbindung mit einer Fehlkonfiguration eröffnete dies einem böswilligen Nutzer die Möglichkeit, das Paket zu kapern.
Führung und langfristige Nachhaltigkeit
Das Betreuerteam (Dimitris Mostrous, Maciej Piróg und Corneliu Hoffman) ist für die technische Leitung des Projekts verantwortlich, einschließlich der Prüfung von Beiträgen, der Pflege der Releases und der Festlegung der Roadmap.
Opengrep entstand aus einer Zusammenarbeit mehrerer Unternehmen im Sicherheitsbereich, die das gemeinsame Ziel verfolgten, fortschrittliche Funktionen zur statischen Analyse als Open-Source-Software verfügbar zu machen. Heute wird das Projekt von einem Betreuerteam geleitet und offen auf GitHub entwickelt, wobei die Diskussionen zur Roadmap und technische Entscheidungen für die Community einsehbar sind.
Mit Blick auf die Zukunft ist es unser Ziel, die Community rund um Opengrep weiter auszubauen und dabei eine transparente Governance zu gewährleisten.
Opengrep wird unter der LGPL-2.1-Lizenz veröffentlicht, wodurch sichergestellt wird, dass die Engine und ihre Derivate offen bleiben.
Warum Opengrep im Zeitalter der KI-basierten Sicherheitsanalyse eine wichtige Rolle spielt
KI-Scanner arbeiten probabilistisch. Dieselbe Eingabe kann je nach Modellzustand, Stichprobenauswahl und Kontext bei verschiedenen Durchläufen zu unterschiedlichen Ergebnissen führen. Das ist für die Suche nach neuen Schwachstellen in Ordnung, verursacht jedoch echte Probleme in CI/CD-Pipelines: Ergebnisse, die sich von Lauf zu Lauf ändern, untergraben die Reproduzierbarkeit, compliance und schwächen das Vertrauen in die Tools. Opengrep liefert jedes Mal die gleichen Ergebnisse aus demselben Code und denselben Regeln. Diese Konsistenz sorgt dafür, dass die Scan-Ergebnisse als Pipeline-Gate fungieren, bei einem Audit Bestand haben und Entwicklern einen Grund geben, auf die Ergebnisse zu reagieren.
Es gibt auch eine praktische Lücke. KI-Scanner erfordern in der Regel API-Aufrufe, GPU-Rechenleistung oder beides. Tests von James Berthoty bei Latio zeigten, dass ein probabilistisches Modell 17 Minuten und 155.000 Token benötigte, um ein Problem zu finden, das Opengrep in 30 Sekunden erkannte. Opengrep läuft lokal, benötigt keine externen Dienste und arbeitet mit expliziten Regeln, die Teams überprüfen und anpassen können. Für bekannte Schwachstellenklassen, die bei jedem Commit überprüft werden, liegen die wirtschaftlichen Vorteile auf der Hand.
Die leistungsstärksten Sicherheitspipelines kombinieren beide Ansätze. Zunächst wird ein deterministischer Scan durchgeführt, der bekannte Muster schnell und konsistent erkennt; anschließend übernimmt die KI-basierte Analyse triage, die Bewertung der Ausnutzbarkeit und die Priorisierung. So kann beispielsweise Opengrep die SAST unterstützen, während die KI darüber angesiedelt ist, um Fehlalarme zu unterdrücken und den Schweregrad im Kontext zu bewerten. Die deterministische Ebene gewinnt in einer KI-gestützten Pipeline an Bedeutung, da die KI konsistente Signale benötigt, um Schlussfolgerungen ziehen zu können.
Da KI-Agenten und Programmierassistenten zunehmend in Entwicklungsabläufe integriert werden, benötigen sie Tools, die sie programmgesteuert aufrufen können und die bei jedem Aufruf deterministische Ausgaben, strukturierte Ergebnisse und vorhersehbares Verhalten liefern. Opengrep entspricht diesen Anforderungen und lässt sich programmgesteuert oder mithilfe unserer offiziellen Agent-Funktion in KI-Workflows integrieren. Darüber hinaus können Programmieragenten dazu verwendet werden, Regeln zu definieren, mit denen sich mithilfe von Opengrep effiziente und groß angelegte Scans durchführen lassen.
Wie geht es weiter mit Opengrep?
Nachdem die Kernarchitektur nun steht, konzentriert sich die nächste Phase von Opengrep auf die Erweiterung der Funktionen der Engine und die Verbesserung der Benutzerfreundlichkeit. Viele unserer Prioritäten ergeben sich direkt aus dem Feedback von Anwendern in der Praxis und Mitwirkenden aus der Community.
Eine der wichtigsten Prioritäten ist die dateiübergreifende Taint-Analyse, die es der Engine ermöglicht, den Fluss nicht vertrauenswürdiger Daten über mehrere Dateien hinweg zu verfolgen, anstatt nur innerhalb einer einzelnen Datei. Dies wird die Erkennung komplexer Schwachstellen in realen Codebasen erheblich verbessern.
Ein weiterer Meilenstein ist die Entfernung des verbleibenden Python-Wrappers, der Übergang zu einer vollständig eigenständigen OCaml-Binärdatei sowie die Vereinfachung der Installation und der Nutzung in der CI. Unsere Roadmap umfasst zudem die Unterstützung neuer Sprachen, Verbesserungen an bestehenden Sprachgrammatiken und eine breitere Verbreitung über Paketmanager wie Homebrew, Winget und apt.
Unsere Roadmap ist ehrgeizig, doch unser Schwerpunkt liegt weiterhin auf der Entwicklung einer schnellen, leistungsfähigen Engine für die statische Analyse, die Entwicklern und Sicherheitsteams weiterhin frei zur Verfügung steht.
