Cela fait un an qu'un groupe de fournisseurs de solutions de sécurité : Aikido , Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, ont créé une branche de Semgrep développer 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 axes de travail qui étaient alors difficiles, voire impossibles à mener au sein de Semgrep : la migration vers OCaml 5 avec le parallélisme en mémoire partagée, l'introduction d'une analyse de contamination interfonctions au sein d'un même fichier, l'élargissement de la prise en charge des langages (notamment Visual Basic, Apex et Elixir), et la mise en place d'une prise en charge native de Windows. Semgrep depuis poursuivi ses efforts en menant sa propre migration vers OCaml 5 et en assurant la prise en charge de Windows, reflétant ainsi des priorités techniques similaires.
Un an plus tard, ces changements commencent à porter leurs fruits, tout en restant parfaitement compatibles avec les règles et les configurations existantes :
- Des analyses jusqu'à 25 à 74 % plus rapides lors de l'exécution de jeux de règles complets sur de grands référentiels
- Une analyse des contaminations jusqu'à deux fois plus rapide, permettant des contrôles de sécurité plus approfondis du flux de données
- 1,74 million de téléchargements de fichiers binaires à partir des versions publiées sur GitHub
- Plus de 2 000 étoiles sur GitHub
- 10 entreprises de sécurité qui utilisent Opengrep en environnement de production
Mais la première année d'un fork open source ne se résume pas à la mise en place de fonctionnalités. Il s'agit avant tout d'instaurer la confiance dans le projet, de démontrer que les objectifs à l'origine du fork résistent à l'épreuve du temps, de mettre en place une gouvernance et d'améliorer les pratiques de sécurité à mesure que le projet mûrit. Ces principes sont exposés dans notre manifeste et dans le fichier README de notre dépôt.
Cet article revient sur ce qui a bien fonctionné, ce qui doit être amélioré et les prochaines étapes pour Opengrep.
Questions-réponses avec le responsable du projet
Aujourd'hui, Opengrep est géré par Dimitris Mostrous, Maciej Piróg et Corneliu Hoffman.
Dans cette rubrique « Questions-réponses », nous leur posons toutes les questions importantes concernant Opengrep.
Q. Qu'est-ce que ce fork a permis de réaliser qui n'était pas possible au sein de Semgrep l'époque ?
A. Cette bifurcation nous a permis de prendre plusieurs décisions architecturales qui auraient été difficiles à mettre en œuvre au sein du projet en amont existant.
Tout d'abord, nous avons migré le moteur vers OCaml 5 en intégrant le parallélisme en mémoire partagée. À l'époque, Semgrep encore un modèle de concurrence basé sur les processus fils, ce qui rendait certaines améliorations, telles que la prise en charge de Windows, extrêmement difficiles à mettre en œuvre. Le passage à OCaml 5 a permis de poser des bases plus solides pour améliorer les performances et assurer la compatibilité multiplateforme. Nous avons ainsi pu introduire une prise en charge native de Windows.
Nous avons ensuite mis à disposition en open source une analyse des contaminations interfonctionnelles, accessible à tout fournisseur tiers. Dans Opengrep, cette fonctionnalité est accessible via l'option --taint-intrafile et prend en charge les fonctions d'ordre supérieur dans plusieurs langages.
Nous avons également étendu la prise en charge des langages, en ajoutant Visual Basic et en activant Apex et Elixir dans le moteur open source. La prise en charge de la fonctionnalité « taint » de Clojure a également été ajoutée.
Enfin, ce fork nous a permis de supprimer les dépendances liées à la télémétrie et aux services propriétaires.
Q. Où puis-je constater une différence notable entre Opengrep et Semgrep ?
A. Opengrep s'avère plus rapide tant pour l'analyse des règles de recherche que pour celle des règles de contamination. Il offre une meilleure détection des contaminations, avec davantage de résultats dans les scénarios à plusieurs sauts (par exemple, 25 contre 5 sur ComfyUI avec les règles de contamination). Il est également plus facile à exécuter dans un plus large éventail d'environnements. Opengrep est fourni sous forme de binaire autonome sans dépendance Python, prend en charge davantage de langages dès l'installation et introduit des fonctionnalités telles que les délais d'expiration par règle, les délais d'expiration dynamiques basés sur la taille des fichiers et les annotations d'ignorance configurables.
Q. Quels travaux d'ingénierie avez-vous réalisés au cours de la première année ?
A. Derrière ces gains de performance et ces nouvelles fonctionnalités se cache un travail d'ingénierie considérable :
- 43 versions livrées
- 1 116 commits répartis sur 318 pull requests
- 1 546 fichiers modifiés
- 21 contributeurs ont participé au projet
Le développement a principalement été mené par les trois responsables 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 pull requests. Ces contributions externes portent notamment sur le suivi des contaminations et les améliorations du langage (fonctions de portée Kotlin), l'infrastructure de distribution (script d'installation) et les améliorations au niveau de la sortie (empreinte digitale). La barrière à l'entrée est élevée : la base de code compte environ 200 000 lignes d'OCaml, et contribuer à une fonctionnalité du langage nécessite de comprendre comment les langages sont analysés, traduits en AST générique, ainsi que le fonctionnement des représentations intermédiaires et du moteur de traçage des contaminations. L'un de nos principaux objectifs est d'élargir la base de contributeurs externes d'ici 2026.
Q. Où t'es-tu trompé ?
A. Nous n'avons pas protégé le nom du paquet sur PyPI et avons distribué des fichiers Wheel dans notre version. Associé à une erreur de configuration, cela a permis à un utilisateur malveillant de détourner le paquet.
Gouvernance et viabilité à long terme
L'équipe de maintenance (Dimitris Mostrous, Maciej Piróg et Corneliu Hoffman) est chargée de la direction technique du projet, notamment de l'examen des contributions, de la gestion des versions et de l'orientation de la feuille de route.
Opengrep est né d'une initiative collaborative entre plusieurs entreprises de l'écosystème de la sécurité, qui partageaient l'objectif de maintenir à disposition des capacités d'analyse statique avancées en open source. Aujourd'hui, le projet est piloté par une équipe de responsables et développé de manière ouverte sur GitHub, les discussions relatives à la feuille de route et les décisions techniques étant accessibles à la communauté.
À l'avenir, l'objectif est de continuer à développer la communauté autour d'Opengrep tout en maintenant une gouvernance transparente.
Opengrep est distribué sous licence LGPL-2.1, ce qui garantit que le moteur et ses dérivés restent libres.
Pourquoi Opengrep est-il si important à l'ère de l'analyse de sécurité basée sur l'IA ?
Les scanners basés sur l'IA fonctionnent selon un modèle probabiliste. Une même entrée peut générer des résultats différents d'une exécution à l'autre, en fonction de l'état du modèle, de l'échantillonnage et du contexte. Cela convient pour la recherche de nouvelles vulnérabilités, mais pose de réels problèmes dans les pipelines CI/CD : des résultats qui varient d'une exécution à l'autre compromettent 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. C'est cette cohérence qui permet aux résultats de l'analyse de servir de filtre dans le pipeline, de résister à un audit et de donner aux développeurs une raison d'agir sur la base des résultats.
Il existe également un problème d'ordre pratique. Les scanners basés sur l'IA nécessitent généralement des appels API, des ressources de calcul GPU, ou les deux. Des tests réalisés par James Berthoty chez Latio ont montré qu'un modèle probabiliste mettait 17 minutes et utilisait 155 000 jetons pour détecter un problème qu'Opengrep avait repéré en 30 secondes. Opengrep s'exécute localement, ne nécessite aucun service externe et fonctionne selon des règles explicites que les équipes peuvent inspecter et ajuster. Pour les classes de vulnérabilités connues analysées à chaque commit, les avantages économiques sont évidents.
Les pipelines de sécurité les plus performants combinent ces deux approches. Une analyse déterministe est d'abord effectuée, permettant de détecter rapidement et de manière cohérente les modèles connus, puis le raisonnement basé sur l'IA se charge du triage, de l'évaluation de la vulnérabilité et de la hiérarchisation. Par exemple, Opengrep peut alimenter la SAST , tandis que l'IA peut être intégrée en amont pour réduire les faux positifs et évaluer la gravité en tenant compte du contexte. La couche déterministe prend toute son importance dans un pipeline basé sur l'IA, car celle-ci a besoin de signaux cohérents pour pouvoir raisonner.
À mesure que les agents IA et les assistants de codage s'intègrent aux flux de travail de développement, ils ont besoin d'outils qu'ils peuvent appeler par programmation, garantissant un résultat déterministe, des résultats structurés et un comportement prévisible à chaque invocation. Opengrep répond parfaitement à ces critères et peut s'intégrer aux flux de travail IA par programmation ou via notre compétence d'agent officielle. De plus, les agents de codage peuvent être utilisés pour définir des règles qui permettront ensuite d'effectuer des analyses efficaces et à grande échelle à l'aide d'Opengrep.
Quelle est la prochaine étape pour Opengrep ?
L'architecture de base étant désormais en place, la prochaine étape d'Opengrep consistera à étendre les capacités du moteur et à améliorer son ergonomie. Bon nombre de nos priorités découlent directement des retours d'expérience des utilisateurs en production et des contributeurs de la communauté.
L'une des principales priorités est l'analyse de contamination inter-fichiers, qui permet au moteur de suivre la circulation des données non fiables entre plusieurs fichiers, et non plus uniquement au sein d'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 consiste à supprimer le wrapper Python restant, à évoluer vers un binaire OCaml entièrement autonome et à simplifier l'installation et l'utilisation de l'intégration continue (CI). Notre feuille de route prévoit également la prise en charge de nouveaux langages, des améliorations des grammaires existantes et une diffusion plus large via des gestionnaires de paquets tels que Homebrew, Winget et apt.
Notre feuille de route est ambitieuse, mais notre priorité reste la mise au point d'un moteur d'analyse statique rapide et performant, qui restera accessible gratuitement aux développeurs et aux équipes de sécurité.
