Le modèle de GitHub pour la détection de secrets : Trouver plus de secrets avec moins de bruit

acceptation plus élevée

précision pondérée par propriétaire des alertes

temps médian d'exécution des analyses plus faible

analyse après push

coût de service plus faible

Modèle compact vs. appels LLM distants

L'analyse des secrets fonctionne mieux lorsque les développeurs ont confiance dans les résultats trouvés. Si on en détecte trop peu, de vraies informations d'identification peuvent rester dans un dépôt. Si on alerte trop souvent, les développeurs peuvent perdre du temps à examiner des chaînes qui ne sont pas des secrets.

Les secrets génériques rendent cet équilibre particulièrement difficile. Une même chaîne peut être une véritable information d'identification ou un espace réservé de documentation, si bien que sa détection exige de comprendre le code et le texte environnants.

Pour relever ce défi, nous avons entraîné un classifieur de secrets spécifiquement adapté aux besoins du produit GitHub : distinguer les véritables informations d'identification de leurs sosies tout en répondant aux exigences de rapidité et d'efficacité de l'analyse à grande échelle.

Dans notre article complémentaire, La protection des secrets doit évoluer avec le logiciel, nous expliquions pourquoi la protection des secrets doit suivre le rythme du développement accéléré par l'IA. Ici, nous coulisses du classifieur contextuel qui propulse cet effort : comment nous l'avons conçu, entraîné et évalué pour trouver plus de vrais secrets avec moins de bruit.

Ce que nous avons activé

L'analyse des secrets de GitHub opère à deux moments clés :

• La protection lors des push aide à empêcher les secrets d'entrer dans un dépôt en analysant les modifications avant qu'un push ne soit accepté, offrant aux développeurs la possibilité de traiter le résultat détecté.
• L'analyse après push fonctionne une fois le code validé, en analysant en continu le contenu du dépôt et en créant des alertes lorsque des secrets potentiels sont détectés, afin que les développeurs et les équipes de sécurité puissent les examiner et les remédier.

Nous avons développé un classifieur rapide qui a réduit le temps médian d'exécution des analyses après push de 86 % par rapport à la précédente chaîne de traitement basée sur un LLM. Cette efficacité a rendu possible l'extension de la détection de secrets génériques à la protection lors des push, en renvoyant des résultats avant que les développeurs ne poussent leurs modifications, et pas seulement après que le code a été validé.

Pourquoi les secrets sont difficiles à détecter

Les informations d'identification structurées incluent souvent un préfixe, une longueur, un alphabet ou une somme de contrôle distinctifs. Les secrets génériques, pas nécessairement. Leur syntaxe chevauche celle des identifiants de build, des sommes de contrôle, des hachages de ressources, des valeurs d'exemple et d'autres chaînes non sensibles. Le contexte est le signal déterminant.

Ces cas sont des négatifs difficiles : des chaînes qui correspondent à un motif d'identifiant mais qui ne sont pas des identifiants utilisables. Ajouter plus de règles peut en supprimer certains, mais chaque exception risque de masquer un véritable secret. Un classifieur appris peut au contraire utiliser des signaux tels que le chemin de fichier, le type de secret, les noms de variables et le code ou le texte à proximité.

C'est pourquoi nous avons livré un nouveau scanner utilisant un pipeline à deux étapes :

1. Génération de candidats: des filtres regex analysent le contenu à la recherche de secrets potentiels avec un rappel élevé. Cette étape est optimisée pour détecter rapidement et de manière déterministe de grandes familles de motifs ressemblant à des identifiants.
2. Classification contextuelle: Un classifieur ModernBERT affiné évalue chaque candidat et son contexte environnant. Il est entraîné à reconnaître les signaux qui distinguent les vrais secrets des faux positifs, notamment les valeurs d'espace réservé, les exemples, les extraits de documentation, le contenu généré et les identifiants non sensibles. Comme le modèle est petit et efficace à exécuter sur notre infrastructure d'inférence, il coûte beaucoup moins cher à servir et est plus simple à faire évoluer qu'un pipeline basé sur un LLM.

Impact :

• Amélioration de 11.5 % de l'acceptation par les utilisateurs, réduisant les faux positifs.
• Temps d'exécution de la détection de secrets post-push 86% plus rapide.
• Plus de 98% d'économies de coûts par rapport au pipeline basé sur les LLM.

Comment fonctionne notre pipeline

Lorsque le contenu est analysé, les motifs regex jettent un large filet et signalent tout ce qui ressemble à un identifiant, afin qu'aucun vrai secret ne soit manqué au départ. Chaque candidat est ensuite transmis à un classifieur ModernBERT affiné, qui lit la valeur en tenant compte de son chemin de fichier, des noms de variables et du code environnant. Le classifieur estime la probabilité qu'il s'agisse d'un vrai secret. Les résultats à haute confiance deviennent des alertes, et les ressemblances telles que les espaces réservés, les fixtures de test et les sommes de contrôle sont filtrées avant d'atteindre les développeurs.

ÉTAPE 1

Scanner

Contenu du dépôt, commits, pull requests et autres surfaces analysées.

ÉTAPE 2

Générer des candidats

Les motifs regex identifient les jetons, clés et chaînes de caractères ressemblant à des identifiants possibles.

ÉTAPE 3

Classer

Un ModernBERT affiné évalue candidat + contexte et attribue la probabilité d'un véritable secret.

ÉTAPE 4

Alerter ou supprimer

Les résultats à haute confiance avancent ; les faux positifs probables sont filtrés.

Le choix de conception important est que le modèle ne remplace pas l'analyse déterministe. Il la complète au contraire. Les expressions régulières restent l'outil approprié pour trouver rapidement les chaînes candidates. Le classifieur est utilisé là où l'apprentissage automatique apporte le plus de valeur : distinguer « ressemble à un secret » de « est probablement un vrai secret ».

Un problème de négatifs difficiles : des secrets qui semblent presque réels

La plupart des faux positifs ne sont pas aléatoires. Ce sont des négatifs difficiles : des chaînes qui correspondent à un schéma d'identifiant sans être des identifiants utilisables. En font partie les espaces réservés de documentation, les exemples jouets dans les tests, les valeurs expurgées, les identifiants non sensibles et les fixtures générées. Ces cas sont faciles à faire correspondre pour une regex, mais difficiles à supprimer pour un système purement fondé sur des règles sans perdre accidentellement de vrais secrets.

ModernBERT est utile parce qu'il peut lire le candidat avec le code et le texte environnants, offrant une compréhension contextuelle comparable à celle d'un LLM sans la latence et la charge de calcul liées à la génération de sortie en langage naturel. Par exemple, un candidat entouré de mots comme « example », « dummy », « fake » ou « replace-me » peut présenter un risque plus faible qu'un candidat assigné à une variable d'environnement dans un fichier de déploiement. Le classifieur apprend ces différences contextuelles à partir d'exemples étiquetés plutôt que d'exiger des ingénieurs qu'ils encodent chaque exception sous forme de règle supplémentaire.

Nous avons choisi ModernBERT parce qu'il correspond bien à cette charge de travail : il est compact, efficace et parfaitement adapté à la classification de textes proches du code. Pour la détection de secrets, le modèle doit prendre une décision calibrée sur de courtes fenêtres candidates avec un haut débit et une faible latence.

Cela fait d'un classifieur à encodeur affiné une forme de service plus adaptée qu'un LLM polyvalent pour cette étape du pipeline. Le modèle peut être entraîné directement sur notre frontière de décision, et évalué à l'aide des mêmes métriques de rappel et de précision qui comptent pour la qualité de la détection de secrets.

Comment nous avons formé

Le défi consistait à trouver des données représentatives pour les cas où la syntaxe seule est trompeuse. La stratégie d'entraînement et d'évaluation combine trois sources :

• Des exemples issus de produits provenant de dépôts GitHub, en utilisant les retours de l'expérience de détection de secrets et une validation humaine supplémentaire.
• Candidats d'expressions régulières à haut rappel issus des données de dépôts GitHub, y compris des exemples annotés par des humains et des étiquettes faibles utilisées pour élargir la couverture.
• Des exemples synthétiques ciblant les cas rares et difficiles, tels que les secrets de documentation, les fixtures de test, les clés publiques, les sommes de contrôle, les imitations structurées et les paires presque identiques.

Les lignes synthétiques passent une validation déterministe et une revue de qualité basée sur des modèles avant leur inclusion. L'entraînement met l'accent sur les vrais secrets, les faux positifs réalistes et les négatifs difficiles qui déroutent fréquemment les approches reposant uniquement sur des expressions régulières. Chaque entrée du modèle comprend la valeur candidate, le chemin du fichier, le type de secret et une quantité limitée de contexte environnant. Nous sélectionnons les seuils par une évaluation hors ligne, puis nous validons le comportement sur un trafic de type production avant un déploiement plus large.

Avant de diviser les données, nous avons regroupé les lignes partageant un dépôt, une valeur candidate ou un exemple, afin que des quasi-duplicatas ne puissent pas apparaître à la fois dans l'entraînement et dans l'évaluation.

L'entraînement s'est concentré sur les cas qui comptent le plus pour la qualité des alertes : de vrais secrets, de faux positifs réalistes et des négatifs difficiles que les regex détectent fréquemment. La représentation en entrée comprend la chaîne candidate du secret, le chemin du fichier, le type et une quantité limitée de contexte environnant. La sortie est un score de classification utilisé par le scanner pour décider si le candidat doit poursuivre le processus.

Nous avons optimisé le compromis produit : préserver ou améliorer le rappel tout en réduisant les faux positifs et le coût de service. En pratique, cela signifie que le seuil du classifieur est sélectionné à l'aide d'une évaluation hors ligne, puis validé sur un trafic proche de la production avant le déploiement.

Le principe d'entraînement le plus important était de faire voir au modèle les exemples trompeurs. Nous avons inclus des candidats syntaxiquement similaires à de vrais secrets mais sémantiquement différents, afin que le modèle apprenne non seulement à quoi ressemble un secret, mais aussi à quoi ressemble un faux positif dans son contexte.

Le modèle entraîné est exporté au format ONNX avec une quantification 8 bits, ce qui permet une inférence rapide.

Résultats de l'évaluation

Nous avons évalué l'impact du nouveau pipeline en production en deux étapes : d'abord par rapport à la ligne de base de production sur le même trafic public, puis via une expérience A/B client.

• Évaluation hors ligne : Lors de l'analyse post-push, le nouveau pipeline a atteint 13 % de précision en plus et 19 % de rappel en plus que le pipeline LLM précédent lorsqu'il a été évalué sur le même trafic public. 
• Évaluation en ligne : Nous avons ensuite validé si ces améliorations de qualité se traduisaient en résultats clients grâce à une expérience A/B par rapport au pipeline LLM précédent. L'acceptation pondérée par propriétaire de dépôt a augmenté de 11,5 %. Nous pondérons l'acceptation par propriétaire de dépôt afin de réduire l'influence des clients qui résolvent en masse de grands volumes d'alertes d'un coup, ce qui pourrait sinon fausser une simple moyenne. 

Emportez ceci avec vous

Le meilleur outil de sécurité est celui que les développeurs ont suffisamment confiance pour utiliser. Une meilleure précision signifie moins d'alertes distraites. Un meilleur rappel signifie que davantage de vrais secrets sont détectés. Un coût plus faible signifie que nous pouvons continuer à améliorer la couverture sans rendre l'analyse prohibitivement coûteuse.

Pour les développeurs et les équipes de sécurité, cela devrait se traduire par moins de faux positifs et des retours plus rapides dans les endroits où les secrets sont le plus susceptibles d'être introduits : les commits, les pull requests et les flux de travail de développement quotidiens.

Les systèmes hybrides sont puissants. Les regex nous offrent vitesse, transparence et une large couverture des candidats. ModernBERT nous apporte une compréhension du contexte apprise et une réduction des faux positifs. La combinaison surpasse chacune des approches utilisée seule pour cette contrainte produit.

Nous avons également appris que la taille d'un modèle n'est pas la même chose que son utilité. Un classifieur affiné plus petit peut être la bonne réponse lorsque la tâche est étroite, la frontière de décision est mesurable et l'efficacité de service est critique.

C'est une étape vers un secret scanning plus précis, plus évolutif et plus facile à utiliser. Pour l'avenir, nous nous concentrons sur deux domaines :

• Construire une roue d'amélioration continue. Nous utiliserons des boucles de retour de production pour identifier de nouveaux faux négatifs et faux positifs, transformant les signaux du monde réel en données d'entraînement et d'évaluation de meilleure qualité.
• Explorer de nouvelles architectures de modèles. Nous étudions des approches capables d'effectuer la détection et l'extraction de secrets en une seule étape, réduisant la complexité du pipeline tout en préservant la précision et l'échelle.

Remerciements

Un immense merci aux équipes d'ingénierie, de science et de produit de GitHub et Microsoft qui ont contribué à construire les données d'entraînement, la suite d'évaluation, la pile de service et le plan de déploiement de ce nouveau scanner de secrets.

La publication Le modèle de détection de secrets de GitHub : Trouver plus de secrets avec moins de bruit est apparue en premier sur The GitHub Blog.