GitGuardian fait la chasse aux secrets dans les dépôts de code

Comment fonctionne GitGuardian ?

Encore faut-il savoir de quels secrets on parle. « L’on entend par secrets des clés d’authentification numérique, mais aussi parfois des certificats ou des fichiers de configurations qui peuvent contenir plusieurs clés privées », explique-t-il. GitGuardian assure détecter 350 types de clés différentes en sus d’une quinzaine de fichiers dits sensibles.

Chez GitGuardian, chacun de ces secrets est couvert par un détecteur, c’est-à-dire un « ensemble d’instructions que le moteur de détection de GitGuardian va exécuter pour trouver un secret ».

Certains de ces détecteurs sont spécifiques, par exemple les clés d’accès AWS IAM. Certains sont développés à la demande d’un client, d’autres sont génériques. Il peut s’agir de clés de chiffrement, de clés API, des clés privées, d’accès à des bases de données, etc.

Les détecteurs se composent de trois parties. Selon l’éditeur, le « prévalidateur » permet d’écarter les documents qui ne contiennent « sûrement pas » de secrets. Le « matcheur » doit permettre d’extraire des chaînes de caractères « candidates » pouvant contenir un secret, par exemple des expressions régulières ou des chaînes de connexions. Enfin, le « postvalidateur » filtre ces candidats pour s’assurer qu’ils disposent de certaines propriétés, suivant le contexte ou l’entropie de la chaîne de caractères.

La gestion de la profusion de détecteurs et de leur efficacité est un défi pour GitGuardian.

« Tout l’enjeu pour nous est à la fois de détecter des éléments en quantité et en même temps faire de la ségrégation », indique Carole Winqwist, Chief Marketing Officer chez GitGuardian. « Sinon, vous avez trop de faux positifs ou de faux négatifs. C’est un équilibre subtil à atteindre ».

La CMO évoque ici une notion spécifique à l’algorithmie, et un des problèmes récurrents pour les spécialistes de la détection de vulnérabilités. Dans le domaine de la classification automatique, les notions d’accuracy, de précision et de rappel sont particulièrement prégnantes. L’accuracy permet de mesurer le taux de prédictions correctes sur l’ensemble des valeurs présentes dans une matrice de confusion. La précision est une métrique pour indiquer les performances d’un modèle de machine learning dans une catégorie spécifique, tandis que le rappel permet d’évaluer combien de fois un modèle est capable de détecter un objet d’une catégorie spécifique.

Selon GitGuardian, l’accuracy n’est pas une mesure idéale pour évaluer la performance de son moteur de règles. La startup cherche donc à avoir un haut taux de précision et un haut taux de rappel, c’est-à-dire un faible nombre de fausses alertes, et un faible nombre de secrets non identifiés.

« Nous ne voulons pas atteindre le zéro faux positif, ça n’existe pas, c’est même dangereux ».

Suivant les cas, GitGuardian détecte 80 à 90 % des secrets. « Nous ne voulons pas atteindre le zéro faux positif, ça n’existe pas, c’est même dangereux », prévient Carole Winqwist. « Faire zéro faux positif, cela veut dire que vous faites trop de ségrégation, vous allez potentiellement laisser passer certains faux positifs qui n’en sont pas ».

La précision serait plus faible sur les secrets génériques, qui ont besoin d’être contextualisés. Le développeur a alors le choix de valider ou non la détection.

Le fait que GitGuardian teste son moteur de règles sur des dépôts publics lui permet de rapidement éprouver ses détecteurs sur de gros jeux de données. En 2021, il affirmait scanner 2,5 millions de commits publics… par jour. « Cela nous permet également de voir apparaître et d’intégrer les nouvelles technologies », affirme la CMO.

La startup utilise par ailleurs plusieurs techniques heuristiques pour trouver les clés chiffrées présentes dans les dépôts afin de ne pas les notifier comme des fuites.

Généralement, les analyses sont réalisées en amont d’un nouveau commit par un développeur (pré-push, pré-commit). GitGuardian permettrait d’abaisser « jusqu’à 80 % le volume de secrets » qui atterrissent dans les dépôts.

 Si GitGuardian détecte une fuite, il prévient rapidement le responsable de cette erreur, peu importe si l’utilisateur dispose la version gratuite ou payante de la solution. En entreprise, la solution peut être connectée aux produits ITSM, SIEM, aux messageries et autres systèmes de tickets via des connecteurs dédiés (Slack, Splunk, PagerDuty) ou des webhooks.

En outre, GitGuardian propose une interface pour aider les équipes DevOps et AppSec à piloter la remédiation. Elle doit permettre d’identifier les applications concernées par un secret, de suivre les équipes ou les individus les plus susceptibles de fuiter des clés, de prévoir les étapes de remédiation avant une rotation des secrets compromis.

En revanche, la remédiation n’est jamais automatique. « La rotation d’une clé ne peut pas s’effectuer sans prévenir les autres équipes, il y a le risque de faire tomber une ou plusieurs applications en production », signale Ziad Ghalleb.

Une dimension supplémentaire s’ajoute : la profondeur d’analyse appliquée par la startup. GitGuardian se dit agnostique des systèmes de gestion de versions (VSC) tant qu’ils reposent sur le projet Git. Plus précisément, son offre est compatible avec GitHub, GitHub Enterprise, GitLab, Azure DevOps et Bitbucket. La startup s’apprête également à scanner les fichiers de configuration d’Infrastructure as Code, des images Docker et se penche sur les flux Jira.

« Ce qui est un peu complexe avec Git, c’est que le secret est toujours là. Même si l’on retire un secret dans une version du code, quelqu’un qui manipule assez bien Git pourrait le retrouver dans une version précédente », explique Ziad Ghalleb. « Il faut donc effectuer la détection sur plusieurs couches pour ensuite enlever toute trace du secret, l’invalider, le révoquer et effectuer la rotation de la clé ».

GitGuardian recommande d’effectuer un scan de l’historique du VSC afin de trouver les secrets présents dans les dépôts. Ceux-ci pourraient être encore actifs.

« Ce n’est pas parce que le secret n’est plus présent dans la dernière version de la branche master qu’il a disparu ».

« Ce n’est pas parce que le secret n’est plus présent dans la dernière version de la branche master qu’il a disparu », renchérit Carole Winqwist.

Aussi, l’éditeur insiste sur le fait qu’un système de gestion de versions privé n’est pas à l’abri des attaquants.

« Le ratio de secrets dans le code par dépôt est largement supérieur en dépôts internes qu’en dépôts publics », remarque la CMO. « Il y a l’illusion d’être protégé, d’être chez soi. Mais le jour où un attaquant s’introduit chez vous, c’est fini ».

Un train d’avance aux États-Unis, une prise de conscience en France

Personne ne serait à l’abri des fuites de secrets. Pas même les géants de la technologie. Ziad Ghalleb cite les cas de Nvidia, d’Uber, de Samsung, de Twitch (filiale d’Amazon), ou encore de Microsoft. Ces cas ont été fortement médiatisés.

Il faut toutefois noter que les grands groupes et les entreprises américaines ont pris la mesure du problème, selon GitGuardian. Environ 75 % de ses revenus sont réalisés aux États-Unis. En premier lieu, ce sont les éditeurs et les fournisseurs qui se sont mis à utiliser la solution. Datadog, Talend, Snowflake ou encore Mirantis font partie des « early adopters ».

« En France, les entreprises sous-traitent beaucoup aux ESN. Il y a une espèce d’ignorance du client final qui considère que ces aspects sont gérés par son intégrateur : c’est la boîte noire ! ».

En France, la prise de conscience, et le démarrage commercial de GitGuardian ont été plus lents. « En France, les entreprises sous-traitent beaucoup aux ESN. Il y a une espèce d’ignorance du client final qui considère que ces aspects sont gérés par son intégrateur : c’est la boîte noire ! », signale Carole Winqwist. « Elles se rendent compte qu’elles sont désormais exposées ».

De manière générale, GitGuardian remarque une croissance des déploiements. La startup indique que ses clients entreprise comptaient en moyenne entre 200 et 1 000 développeurs. « Nous avons signé des comptes à plus de 8 000 développeurs », note la CMO.

Cependant, les clients de GitGuardian qui se lancent dans cet inventaire sur les dépôts privés doivent assimiler une nouvelle logique. « Il y a réellement deux dynamiques différentes entre les dépôts publics et privés. D’un côté, il faut agir rapidement pour réduire la fenêtre d’exposition du secret. De l’autre, cela implique plusieurs parties prenantes et des projets d’envergure », remarque Ziad Ghalleb.

« L’installation de GitGuardian est généralement rapide. Quand nous avons connecté les 8 000 développeurs, ça a été l’avalanche », raconte Carole Winqwist. « Tout à coup, ils ne pouvaient plus ignorer le problème. Il faut traiter l’historique : que faire après avoir détecté 20 000 secrets ? »

Suivant les conseils de GitGuardian, l’entreprise assainit d’abord ses pratiques quotidiennes pour éviter au maximum l’empilement de nouveaux secrets. « Ensuite, nous mettons en place des bonnes pratiques pour sélectionner les champions, pour traiter les problématiques de secrets orphelins, pour hiérarchiser les efforts, etc. », illustre la Chief Marketing Officer. Un tel nettoyage n’est pas une sinécure. « Cela peut prendre des mois, voire des années ».  

Toutefois, la startup n’a pas vocation à conseiller les entreprises. Pour ce faire, elle se rapproche d’Orange Business Services et de sa filiale OCD, ou encore d’Atos. GitGuardian a déjà mis un partenariat similaire au Japon avec un distributeur.

GitGuardian a levé 12 millions de dollars en série A en 2019, puis 44 millions en série B en 2021.