Es ist ein Jahr her, dass eine Gruppe von Sicherheitsanbietern: Aikido Security, Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, Semgrep geforkt hat, um Opengrep zu erstellen. Das zugrunde liegende Ziel war einfach: statische Analysefunktionen als Open Source verfügbar zu halten und die fortschrittlichste Engine zu entwickeln.
Das Projekt konzentrierte sich auf vier Arbeitsbereiche, die zu diesem Zeitpunkt in Semgrep CE schwierig oder unmöglich waren: die Migration zu OCaml 5 mit Shared-Memory-Parallelität, die Einführung einer intrafile Cross-Function Taint-Analyse, die Erweiterung der Sprachunterstützung (einschließlich Visual Basic, Apex und Elixir) und die Ermöglichung nativer Windows-Unterstützung. Semgrep hat seitdem mit seiner eigenen OCaml-5-Migration und Windows-Unterstützung nachgezogen, was ähnliche technische Prioritäten widerspiegelt.
Ein Jahr später beginnen diese Änderungen messbare Ergebnisse zu zeigen, wobei sie vollständig kompatibel mit bestehenden Regeln und Konfigurationen bleiben:
- 25–74 % schnellere Scans beim Ausführen vollständiger Regelsätze über große Repositories hinweg
- Bis zu 2× schnellere Taint-Analyse, die tiefere Data-Flow-Sicherheitsprüfungen ermöglicht
- 1,74 Millionen Binär-Downloads von GitHub-Releases
- Über 2.000 GitHub-Sterne
- 10 Sicherheitsunternehmen, die Opengrep in der Produktion einsetzen
Aber im ersten Jahr eines Open-Source-Forks geht es nicht nur um die Bereitstellung von Features. 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 mit der Reifung des Projekts zu verbessern. Dies ist in unserem Manifest und in der README in unserem Repo dargelegt.
Dieser Beitrag beleuchtet, was funktioniert hat, was verbessert werden musste und was als Nächstes für Opengrep ansteht.
Q&A mit den Maintainern
Heute wird Opengrep von Dimitris Mostrous, Maciej Piróg und Corneliu Hoffman gepflegt.
In diesem Q&A stellen wir ihnen alle wichtigen Fragen rund um Opengrep.
F. Was hat der Fork ermöglicht, was zu diesem Zeitpunkt innerhalb von Semgrep nicht möglich war?
A. Der Fork ermöglichte es uns, mehrere architektonische Entscheidungen zu treffen, die innerhalb des bestehenden Upstream-Projekts schwierig gewesen wären.
Zuerst migrierten wir die Engine auf OCaml 5 mit Shared-Memory-Parallelismus. Zu diesem Zeitpunkt verwendete Semgrep noch ein Fork-basiertes Parallelitätsmodell, was bestimmte Verbesserungen wie die Windows-Unterstützung extrem schwierig machte. Der Wechsel zu OCaml 5 legte eine bessere Grundlage für Leistungsverbesserungen und plattformübergreifende Unterstützung. Infolgedessen konnten wir native Windows-Unterstützung einführen.
Dann haben wir die Cross-Function-Taint-Analyse als Open Source für die Nutzung durch jeden Drittanbieter verfügbar gemacht. In Opengrep ist sie über das --taint-intrafile-Flag verfügbar, einschließlich Unterstützung für Higher-Order-Funktionen über mehrere Sprachen hinweg.
Wir haben auch die Sprachunterstützung erweitert, indem wir Visual Basic hinzugefügt und Apex und Elixir in der Open-Source-Engine aktiviert haben. Clojure Taint-Unterstützung wurde ebenfalls hinzugefügt.
Schließlich ermöglichte uns der Fork, Telemetrie und proprietäre Service-Abhängigkeiten zu entfernen.
F. Wo kann ich einen messbaren Unterschied zwischen Opengrep und Semgrep CE sehen?
A. Opengrep ist sowohl beim Scannen von Suchregeln als auch beim Scannen von Taint-Regeln schneller. Es bietet eine bessere Taint-Erkennung mit mehr Funden in Multi-Hop-Szenarien (zum Beispiel 25 vs. 5 auf ComfyUI mit Taint-Regeln). Es ist auch einfacher, in einer größeren Bandbreite von Umgebungen auszuführen. Opengrep wird als eigenständiges Binärpakt ohne Python-Abhängigkeit ausgeliefert, unterstützt mehr Sprachen out-of-the-box und führt Funktionen wie Timeouts pro Regel, dynamische Timeouts basierend auf Dateigröße und konfigurierbare Ignore-Annotationen ein.
F. Welche technischen Arbeiten wurden im ersten Jahr durchgeführt?
A. Hinter den Leistungsverbesserungen und neuen Funktionen steckte eine beträchtliche Menge an technischer Arbeit:
- 43 Releases ausgeliefert
- 1.116 Commits in 318 Pull Requests
- 1.546 Dateien geändert
- 21 Mitwirkende am Projekt beteiligt
Der Großteil der Entwicklung wurde von den drei Kern-Maintainern geleitet, aber das Projekt hat auch begonnen, externe Beiträge anzuziehen. Im ersten Jahr reichten 17 externe Mitwirkende 29 Pull Requests ein. Die externen Beiträge umfassen Taint Tracking und Sprachverbesserungen (Kotlin Scope Functions), Verteilungsinfrastruktur (Installationsskript) und Ausgabeoptimierungen (Fingerprinting). Die Einstiegshürde ist hoch: Die Codebasis umfasst etwa 200.000 Zeilen OCaml, und das Beitragen einer Sprachfunktion erfordert ein Verständnis dafür, wie Sprachen geparst, 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 erweitern.
F. Was ist schiefgelaufen?
A. Wir haben den Paketnamen auf pypi nicht gesichert und Wheels in unserem Release verteilt. In Kombination mit einer Fehlkonfiguration eröffnete dies einem bösartigen Benutzer die Möglichkeit, das Paket zu kapern.
Governance und langfristige Nachhaltigkeit
Das Maintainer-Team (Dimitris Mostrous, Maciej Piróg und Corneliu Hoffman) ist für die technische Ausrichtung des Projekts verantwortlich, einschließlich der Überprüfung von Beiträgen, der Pflege von Releases und der Steuerung der Roadmap.
Opengrep begann als kollaborative Anstrengung mehrerer Unternehmen im Sicherheits-Ökosystem, die das gemeinsame Ziel verfolgten, fortschrittliche statische Analysefunktionen als Open Source verfügbar zu halten. Heute wird das Projekt vom Maintainer-Team betreut und offen auf GitHub entwickelt, wobei Roadmap-Diskussionen und technische Entscheidungen für die Community sichtbar sind.
Zukünftig ist es das Ziel, die Community rund um Opengrep weiter auszubauen, während eine transparente Governance beibehalten wird.
Opengrep wird unter der LGPL-2.1-Lizenz veröffentlicht, was sicherstellt, dass die Engine und ihre Derivate Open Source bleiben.
Warum Opengrep im Zeitalter der KI-Sicherheitsanalyse wichtig ist
KI-Scanner sind probabilistisch. Dieselbe Eingabe kann zwischen verschiedenen Läufen unterschiedliche Ausgaben erzeugen, abhängig vom Modellzustand, Sampling und Kontext. Das ist gut für die Jagd nach neuen Schwachstellen, aber es schafft echte Probleme in CI/CD-Pipelines: Ergebnisse, die sich zwischen den Läufen ändern, untergraben die Reproduzierbarkeit, erschweren die Compliance und untergraben das Vertrauen in die Tools. Opengrep liefert jedes Mal dieselben Ergebnisse aus demselben Code und denselben Regeln. Diese Konsistenz macht die Scan-Ausgabe zu einem Pipeline-Gate, hält einer Prüfung stand und gibt Entwickelnde einen Grund, auf die Ergebnisse zu reagieren.
Es gibt auch eine praktische Lücke. KI-Scanner erfordern typischerweise API-Aufrufe, GPU-Berechnungen oder beides. Tests von James Berthoty bei Latio zeigten, dass ein probabilistisches Modell 17 Minuten und 155.000 Tokens 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 ausgeführt werden, ist die Wirtschaftlichkeit klar.
Die robustesten Sicherheitspipelines kombinieren beides. Deterministisches Scanning läuft zuerst, um bekannte Muster schnell und konsistent zu erkennen, dann übernimmt die KI-Logik die Triage, die Bewertung der Ausnutzbarkeit und die Priorisierung. Zum Beispiel kann Opengrep die SAST-Schicht antreiben, und KI kann darüber liegen, um Fehlalarme zu unterdrücken und die Schwere im Kontext zu bewerten. Die deterministische Schicht wird in einer KI-gestützten Pipeline wertvoller, da KI ein konsistentes Signal benötigt, um darauf aufzubauen.
Wenn KI-Agenten und Coding Assistants Teil von Entwicklungsworkflows werden, benötigen sie Tools, die sie programmatisch mit deterministischer Ausgabe, strukturierten Ergebnissen und vorhersehbarem Verhalten bei jeder Aufrufung nutzen können. Opengrep passt gut zu diesem Muster und kann programmatisch oder durch die Nutzung unseres offiziellen Agent Skills in KI-Workflows integriert werden. Darüber hinaus können Coding Agents verwendet werden, um Regeln zu definieren, die dann mit Opengrep effizient und skalierbar gescannt werden können.
Wie geht es weiter mit Opengrep?
Nachdem die Kernarchitektur nun etabliert ist, 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 Produktionsnutzern und Mitwirkenden in der Community.
Eine der größten Prioritäten ist die Interfile 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 einem vollständig eigenständigen OCaml-Binary und die Vereinfachung der Installation und CI-Nutzung. Unsere Roadmap umfasst auch neue Sprachunterstützung, Verbesserungen an bestehenden Sprachgrammatiken und eine breitere Distribution über Paketmanager wie Homebrew, Winget und apt.
Unsere Roadmap ist ehrgeizig, aber der Fokus bleibt auf dem Aufbau einer schnellen, leistungsfähigen statischen Analyse-Engine, die Entwickelnden und Sicherheitsteams offen zur Verfügung steht.
