Cela fait un an qu'un groupe de fournisseurs de sécurité : Aikido Security, Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, ont forké Semgrep pour créer Opengrep. L'objectif sous-jacent était simple : maintenir les capacités d'analyse statique disponibles en open source et créer le moteur le plus avancé.
Le projet s'est concentré sur quatre domaines de travail qui étaient difficiles ou impossibles au sein de Semgrep CE à l'époque : la migration vers OCaml 5 avec parallélisme à mémoire partagée, l'introduction de l'analyse de taint intra-fichier inter-fonctions, l'extension du support linguistique (y compris Visual Basic, Apex et Elixir), et l'activation du support natif de Windows. Semgrep a depuis suivi avec sa propre migration vers OCaml 5 et son support Windows, reflétant des priorités techniques similaires.
Un an plus tard, ces changements commencent à montrer des résultats mesurables, tout en restant entièrement compatibles avec les règles et configurations existantes :
- Des scans 25 à 74 % plus rapides lors de l'exécution d'ensembles de règles complets sur de grands dépôts
- Jusqu'à 2 fois plus rapide pour l'analyse de taint, permettant des contrôles de sécurité de flux de données plus approfondis
- 1,74 million de téléchargements binaires depuis les releases GitHub
- Plus de 2 000 étoiles GitHub
- 10 entreprises de sécurité utilisant Opengrep en production
Mais la première année d'un fork open source ne se résume pas à la livraison de fonctionnalités. Il s'agit de bâtir la confiance dans le projet, de prouver que les objectifs derrière le fork tiennent dans le temps, d'établir une gouvernance et d'améliorer les pratiques de sécurité à mesure que le projet mûrit. Cela est détaillé dans notre manifeste et dans le README de notre dépôt.
Cet article revient sur ce qui a fonctionné, ce qui nécessitait des améliorations et ce qui attend Opengrep.
Questions-réponses des mainteneurs
Aujourd'hui, Opengrep est maintenu par Dimitris Mostrous, Maciej Piróg et Corneliu Hoffman.
Dans cette session de questions-réponses, nous leur posons toutes les questions importantes concernant Opengrep.
Q. Qu'est-ce que le fork a permis qui n'était pas possible au sein de Semgrep à l'époque ?
R. Le fork nous a permis de prendre plusieurs décisions architecturales qui auraient été difficiles au sein du projet amont existant.
Premièrement, nous avons migré le moteur vers OCaml 5 avec un parallélisme à mémoire partagée. À l'époque, Semgrep utilisait encore un modèle de concurrence basé sur des forks, ce qui rendait certaines améliorations, comme le support de Windows, extrêmement difficiles. Le passage à OCaml 5 a établi une meilleure base pour les améliorations de performance et le support multiplateforme. En conséquence, nous avons pu introduire le support natif de Windows.
Ensuite, nous avons rendu l'analyse de taint inter-fonctions disponible en open source pour l'utilisation par tout fournisseur tiers. Dans Opengrep, elle est disponible via le flag --taint-intrafile, incluant le support des fonctions d'ordre supérieur à travers plusieurs langages.
Nous avons également étendu le support des langages, en ajoutant Visual Basic, et en activant Apex et Elixir dans le moteur open source. Le support de taint pour Clojure a également été ajouté.
Enfin, le fork nous a permis de supprimer la télémétrie et les dépendances de services propriétaires.
Q. Où puis-je constater une différence mesurable entre Opengrep et Semgrep CE ?
R. Opengrep est plus rapide pour l'analyse des règles de recherche et l'analyse des règles de taint. Il offre une meilleure détection de taint, avec plus de résultats dans les scénarios multi-sauts (par exemple 25 contre 5 sur ComfyUI avec des règles de taint). Il est également plus facile à exécuter dans un plus large éventail d'environnements. Opengrep est livré sous forme de binaire autonome sans dépendance Python, supporte plus de langages prêts à l'emploi, et introduit des fonctionnalités telles que les timeouts par règle, les timeouts dynamiques basés sur la taille des fichiers, et les annotations d'ignorance configurables.
Q. Quels travaux d'ingénierie avez-vous entrepris la première année ?
R. Derrière les améliorations de performance et les nouvelles capacités se cachait un travail d'ingénierie considérable :
- 43 versions livrées
- 1 116 commits à travers 318 pull requests
- 1 546 fichiers modifiés
- 21 contributeurs impliqués dans le projet
La majeure partie du développement a été menée par les trois mainteneurs principaux, mais le projet a également commencé à attirer des contributions externes. Au cours de la première année, 17 contributeurs externes ont soumis 29 PR. Les contributions externes incluent le suivi des flux de données (taint tracking) et des améliorations linguistiques (fonctions d'étendue Kotlin), l'infrastructure de distribution (script d'installation) et des améliorations de sortie (fingerprinting). La barrière à l'entrée est élevée : la base de code représente environ 200 000 lignes d'OCaml, et contribuer à une fonctionnalité linguistique nécessite de comprendre comment les langages sont analysés, traduits en AST générique et comment fonctionnent les représentations intermédiaires et le moteur de taint. Développer la base de contributeurs externes pour 2026 est un objectif clé pour nous.
Q. Qu'avons-nous manqué ?
R. Nous n'avons pas sécurisé le nom du package sur pypi et les wheels distribuées lors de notre release. Combiné à une mauvaise configuration, cela a créé une voie pour qu'un utilisateur malveillant puisse détourner le package.
Gouvernance et durabilité à long terme
L'équipe de mainteneurs (Dimitris Mostrous, Maciej Piróg et Corneliu Hoffman) est responsable de la direction technique du projet, y compris l'examen des contributions, la maintenance des releases et l'orientation de la feuille de route.
Opengrep a débuté comme un effort collaboratif entre plusieurs entreprises de l'écosystème de la sécurité qui partageaient l'objectif de maintenir des capacités d'analyse statique avancées disponibles en open source. Aujourd'hui, le projet est géré par l'équipe de mainteneurs et développé ouvertement sur GitHub, avec des discussions sur la feuille de route et des décisions techniques visibles par la communauté.
À l'avenir, l'objectif est de continuer à étendre la communauté autour d'Opengrep tout en maintenant une gouvernance transparente.
Opengrep est publié sous la licence LGPL-2.1, garantissant que le moteur et ses dérivés restent ouverts.
Pourquoi Opengrep est important à l'ère de l'analyse de sécurité par IA
Les scanners basés sur l'IA sont probabilistes. La même entrée peut produire des sorties différentes entre les exécutions, en fonction de l'état du modèle, de l'échantillonnage et du contexte. C'est acceptable pour la recherche de nouvelles vulnérabilités, mais cela crée de réels problèmes dans les pipelines CI/CD : des résultats qui varient entre les exécutions sapent la reproductibilité, compliquent la conformité et érodent la confiance dans les outils. Opengrep produit les mêmes résultats à partir du même code et des mêmes règles, à chaque fois. Cette cohérence est ce qui permet aux résultats d'analyse de fonctionner comme une porte de pipeline, de résister à un audit et de donner aux développeurs une raison d'agir sur les découvertes.
Il existe également un écart pratique. Les scanners basés sur l'IA nécessitent généralement des appels API, du calcul GPU, ou les deux. Des tests menés par James Berthoty chez Latio ont montré qu'un modèle probabiliste passait 17 minutes et 155 000 tokens à trouver un problème qu'Opengrep détectait en 30 secondes. Opengrep s'exécute localement, ne nécessite aucun service externe et fonctionne sur des règles explicites que les équipes peuvent inspecter et ajuster. Pour les classes de vulnérabilités connues exécutées à chaque commit, les avantages économiques sont évidents.
Les pipelines de sécurité les plus robustes combinent les deux approches. L'analyse déterministe s'exécute en premier, détectant les schémas connus rapidement et de manière cohérente, puis le raisonnement de l'IA gère le triage, l'évaluation de l'exploitabilité et la priorisation. Par exemple, Opengrep peut alimenter la couche SAST, et l'IA peut se superposer pour supprimer les faux positifs et évaluer la gravité en contexte. La couche déterministe devient plus précieuse dans un pipeline alimenté par l'IA car l'IA a besoin d'un signal cohérent pour raisonner.
À mesure que les agents IA et les assistants de codage s'intègrent aux workflows de développement, ils ont besoin d'outils qu'ils peuvent appeler par programme avec une sortie déterministe, des résultats structurés et un comportement prévisible à chaque invocation. Opengrep correspond bien à ce modèle et peut s'intégrer aux workflows d'IA par programme ou en utilisant notre compétence d'agent officielle. De plus, les agents de codage peuvent être utilisés pour définir des règles qui peuvent ensuite être utilisées pour scanner efficacement et à grande échelle avec Opengrep.
Quelle est la prochaine étape pour Opengrep ?
Maintenant que l'architecture de base est en place, la prochaine phase d'Opengrep se concentre sur l'expansion des capacités du moteur et l'amélioration de l'utilisabilité. Beaucoup de nos priorités proviennent directement des retours des utilisateurs en production et des contributeurs de la communauté.
L'une des plus grandes priorités est l'analyse de taint inter-fichiers, permettant au moteur de suivre comment les données non fiables circulent à travers plusieurs fichiers plutôt que dans un seul fichier. Cela améliorera considérablement la détection des vulnérabilités complexes dans les bases de code réelles.
Une autre étape importante est la suppression du wrapper Python restant, pour évoluer vers un binaire OCaml entièrement autonome, et simplifier l'installation et l'utilisation en CI. Notre feuille de route comprend également la prise en charge de nouveaux langages, des améliorations aux grammaires de langage existantes et une distribution plus large via des gestionnaires de packages tels que Homebrew, Winget et apt.
Notre feuille de route est ambitieuse, mais l'objectif reste de construire un moteur d'analyse statique rapide et performant, qui reste ouvertement disponible pour les développeurs et les équipes de sécurité.
