GitHub : moins de faux positifs dans le scan des secrets

GitHub a publié le 13 octobre 2026, avec une mise à jour le 14, un article sur son nouveau classifieur de détection de secrets. Le problème de départ est simple : un scan qui alerte trop fatigue les développeurs, un scan qui alerte trop peu laisse passer de vrais identifiants. Les secrets génériques compliquent cet équilibre, car la même chaîne peut être un vrai mot de passe ou un simple exemple dans une doc.

Pour trancher, GitHub a entraîné un classifieur dédié à ce besoin : distinguer un vrai identifiant d'un sosie, tout en tenant la vitesse d'un scan à grande échelle. Les chiffres avancés par l'entreprise : +11,5 % d'acceptation pondérée des alertes, 86 % de temps médian de scan en moins et plus de 98 % d'économies de coût par rapport à l'ancien pipeline basé sur un LLM. Ce sont des mesures de GitHub sur son propre système, pas un test indépendant.

Les identifiants structurés ont un préfixe, une longueur ou une somme de contrôle reconnaissables. Les secrets génériques, non : leur syntaxe ressemble à celle d'un identifiant de build, d'un hash d'asset ou d'une valeur d'exemple. Le contexte devient alors le signal décisif. Un mot de passe à côté d'une URL de base de production n'a pas le même poids que la même valeur dans un fichier de test.

GitHub appelle ces cas des hard negatives : des chaînes qui ressemblent à un identifiant sans en être un. Ajouter des règles peut en supprimer quelques-unes, mais chaque exception risque de masquer un vrai secret. D'où le choix d'un modèle appris plutôt que d'une liste d'exceptions toujours plus longue.

Le scan ne remplace pas les regex, il les complète. Première étape : des filtres regex repèrent largement tout ce qui ressemble à un identifiant, pour ne rien rater au départ. Deuxième étape : un classifieur ModernBERT affiné lit chaque candidat avec son chemin de fichier, les noms de variables et le code autour. Il estime la probabilité qu'il s'agisse d'un vrai secret.

Les trouvailles à haute confiance deviennent des alertes ; les sosies comme les placeholders, les fixtures de test ou les checksums sont filtrés avant d'atteindre les développeurs. GitHub précise que le modèle ne remplace pas le scan déterministe : il intervient là où l'apprentissage apporte le plus, c'est-à-dire séparer « ressemble à un secret » de « est probablement un vrai secret ».

La détection de secrets intervient à deux moments : la protection au push, qui scanne les changements avant d'accepter l'envoi, et le scan après commit, qui analyse en continu le contenu du dépôt et crée des alertes. Le classifieur rapide a réduit le temps médian du scan après push de 86 % par rapport à l'ancien pipeline LLM.

Cette efficacité a rendu possible l'extension de la détection des secrets génériques à la protection au push. Selon GitHub, les résultats arrivent ainsi avant que le développeur n'envoie ses changements, et plus seulement après le commit.

GitHub explique avoir préféré ModernBERT à un LLM généraliste pour cette étape. Le modèle est compact, rapide et adapté à une décision calibrée sur de courtes fenêtres de candidats, avec un débit élevé et une faible latence. Il coûte aussi bien moins cher à servir et se met à l'échelle plus simplement.

Le revers, que GitHub reconnaît : le classifieur fait un best effort pour distinguer un vrai secret d'un sosie. Ce n'est pas une garantie. Les chiffres d'acceptation et de coût viennent de l'entreprise elle-même, sur son infrastructure, et ne disent rien de la qualité du scan dans un dépôt particulier.