La protection des secrets doit évoluer avec le logiciel

Aujourd’hui, un pull request sur trois sur GitHub implique un agent d’IA. Il y a un an, ce chiffre était inférieur à un sur 10. Si ce rythme se maintient, dans les deux prochaines années, la plupart du code poussé sur GitHub pourrait être écrit par un agent. Une grande partie ne sera peut-être jamais entièrement lue par un humain.

Si les développeurs et les agents vont plus vite, nous avons la responsabilité de garantir que la protection suive le rythme accéléré de création de code. Cela signifie prévenir davantage de fuites avant qu’elles ne se produisent et rendre la réponse aux expositions restantes moins dépendante de l’effort humain manuel.

C’est un tournant décisif pour les secrets divulgués. Les développeurs ne deviennent pas plus négligents ; ils sont dépassés par le rythme. Les outils qui permettent aux développeurs de créer plus de logiciels devraient également prendre en charge une plus grande partie du travail de protection.

Dans cet essai, je partage les neuf trimestres de données qui étayent cette affirmation. Je présente également le classifieur affiné que nous avons construit avec Microsoft Applied Sciences pour étendre la push protection aux secrets non structurés. Le modèle évalue tout un ensemble de secrets candidats en moins de deux millisecondes et pourrait plus que doubler le nombre de secrets que nous pouvons prévenir.

Dépassés, pas négligents

Un nouveau secret apparaît dans du code publiquement visible environ une fois toutes les deux secondes, un chiffre qui double chaque année depuis trois ans. Le débat public saute rapidement à la conclusion selon laquelle l’IA a rendu les développeurs négligents.

Entre le 2e trimestre 2024 et le 2e trimestre 2026, les pushes analysés ont augmenté de 2.84 fois alors que les pushes contenant des identifiants ont augmenté de 2.59 fois. Sur neuf trimestres complets de données, nous n’avons détecté aucune tendance statistiquement significative concernant la prévalence par push. Dans le même temps, nous avons trouvé des données suggérant que, plus que jamais, les développeurs comprennent le risque d’expositions accidentelles et sont moins disposés à accepter ce risque. Sur la même période, la part des blocages sur le chemin de push outrepassés par les développeurs est passée linéairement de 6.63% à 3.93%. Ces chiffres remettent en cause l’affirmation courante selon laquelle les agents rendent les développeurs plus négligents.

À taux constant, doubler l’activité double les expositions attendues. Si chaque exposition nécessite la même réponse humaine, la charge de travail double également. Le temps moyen pour révoquer manuellement un secret se situe autour de 40 jours; environ un sur cinq a pris plus de 90 jours. Nous accélérons la création de logiciels tandis que des identifiants exposés peuvent rester utilisables pendant des semaines ou des mois, car la remédiation humaine ne peut pas évoluer au même rythme que le développement.

Dire aux développeurs d’être plus prudents ne peut pas, à lui seul, résoudre ce problème. À mesure que le volume de code augmente, nous devons prévenir davantage d’expositions et réduire l’effort humain requis par celles qui subsistent, si le développement logiciel doit rester durable.

La prévention évolue avec la puissance de calcul

J’ai passé les dernières années à travailler sur le secret scanning chez GitHub et l’année écoulée en tant que responsable produit de ce domaine. Notre plus grand impact est venu de la mise en relation entre la détection et les systèmes capables d’agir.

Le catalogue de GitHub couvre plus de 150 partenaires techniques grâce à notre programme de partenariat de secret scanning. Grâce à notre programme de partenaires, nous travaillons avec les émetteurs de secrets participants pour construire des détecteurs et signaler les expositions publiques afin qu’ils puissent réagir. Au 2e trimestre 2026, le scan public a signalé avec succès une moyenne de 26 correspondances d’identifiants par seconde, observations répétées incluses. Une fois notifiés, un grand nombre de ces partenaires révoquent immédiatement le jeton : clés API OpenAI, identifiants de compte Google Cloud, webhooks Slack, jetons utilisateur Hugging Face, clés SendGrid, etc. Le propriétaire peut encore devoir remplacer le jeton, mais la révocation peut avoir lieu sans attendre qu’un développeur trouve et traite une alerte GitHub.

La push protection intervient plus tôt. Elle bloque les identifiants reconnaissables avant leur entrée dans l’historique du dépôt, donnant au développeur ou à l’agent la possibilité de corriger la modification avant qu’il n’y ait une exposition à examiner. Nous travaillons avec nos partenaires techniques pour augmenter autant que possible les taux de précision de leurs détecteurs, jusqu’à ce que nous soyons suffisamment confiants pour protéger ces secrets par push par défaut pour la communauté des développeurs.

Grâce aux efforts de nos partenaires, au cours du mois dernier, un secret a été bloqué par la protection contre les pushes au moins une fois par seconde. En ce qui concerne les identifiants liés à l'émetteur, GitHub bloque plus de secrets qu'il n'en laisse passer. Je suis fier de la banalité que nous avons donnée à cette expérience pour les développeurs.

La remédiation s'adapte au nombre de personnes

En incluant des types de secrets supplémentaires, la protection contre les pushes stoppe environ 30% des secrets nouvellement détectés avant qu'ils n'entrent dans l'historique du dépôt. Nous trouvons les 70% restants après que l'identifiant a malheureusement déjà été compromis. Et :

1. La prévention s'adapte à la puissance de calcul, mais la remédiation s'adapte toujours au nombre de personnes.
2. Refuser un push coûte de la puissance de calcul ; nettoyer un secret déjà perdu dans un historique visible coûte du temps et de l'attention à un développeur.
3. À mesure que la quantité de code augmente, nous devons prévenir davantage d'expositions et réduire l'effort humain requis par celles qui subsistent, sinon le volume de vulnérabilités introduites deviendra intenable.

Dire aux développeurs d'être plus attentifs ne peut pas résoudre ce déséquilibre. Reconnaître davantage de ces secrets, plus tôt dans les flux de développement, est un travail que la plateforme doit assumer.

Résoudre le problème à quatre corps

Avant qu'un secret ne franchisse la limite de l'envoi (push), le coût de son arrêt est faible, et la décision est binaire : bloquer ou autoriser. Après son franchissement, la même chaîne peut permettre de s'authentifier auprès d'un système réel, et le coût devient illimité.

Dans de nombreux cas, notre seul indice de détection peut être le code environnant et le contexte général. Un token émis par un fournisseur peut avoir un préfixe reconnaissable. Un mot de passe de base de données interne peut être totalement non structuré, sans aucun motif identifiable. Nous utilisions déjà le contexte pour trouver ces secrets après leur publication ; le problème consistait à équilibrer ce jugement contextuel avec d'autres facteurs.

Nous appelons cela le « problème à quatre corps » pour la protection des secrets : précision, latence, débit et coût sont des contraintes couplées. La prévention doit valoir le temps d'un développeur. Un constat pouvant convenir à une revue ultérieure ne justifie pas forcément de bloquer un push. Un faux positif interrompt un développeur et rend le prochain blocage plus difficile à croire. Un contrôle trop lent, trop coûteux ou difficile à faire évoluer limite la fréquence à laquelle il peut être exécuté.

Protection en un clic en moins de 2 ms

Notre nouveau classifieur ModernBERT évalue les secrets candidats dans leur contexte, sans générer de code ni de texte. Il est non seulement plus précis que les pipelines existants basés sur des LLM, mais il est aussi incroyablement rapide, évaluant des lots de candidats en moins de deux millisecondes. Il est également extrêmement rentable, suffisamment pour être exécuté à grande échelle dans le chemin critique.

L'inclusion de notre modèle dans la protection push nous permet de plus que doubler le nombre de secrets que nous sommes capables de prévenir. La fonctionnalité est actuellement en préversion privée. Plus tard ce mois-ci, la fonctionnalité sera disponible pour les organisations disposant de GitHub Secret Protection sur Enterprise Cloud et GitHub Teams. Elle consommera des crédits IA.

Nous apportons également le modèle sur des surfaces de développement au-delà de la poussée.

• À partir d'aujourd'hui, tout organisation avec détection des secrets par IA veulent être automatiquement mis à jour le nouveau modèle. Les alertes ouvertes à partir de ces analyses post-push restent incluses dans l’achat de l’analyse des secrets par une organisation, sans coût supplémentaire.
• Le modèle sera également livré avec GitHub Enterprise Server 3.23 en préversion publique, apportant les alertes détectées par l’IA aux clients de Secret Protection même dans les environnements air-gapped.
• Nous ajoutons le classificateur à la /security-review commande pour Copilot CLI et Copilot App, afin que les utilisateurs de Copilot puissent traiter les secrets avant un push sans même avoir besoin du plan GitHub Secret Protection d’une organisation. L’utilisation de crédits IA sera attribuée à GitHub Secret Protection dans vos statistiques d’utilisation de l’IA.

Pour l’avenir

L’avenir que nous voulons est celui où les développeurs peuvent confier davantage de travail aux agents sans superviser chaque requête, et celui où le nombre de personnes dont une organisation a besoin pour protéger ses identifiants ne croît plus avec le volume de code qu’elle écrit. Nous devons à la communauté des développeurs les mêmes progrès dans la protection des logiciels que ceux que nous apportons à leur production.

Nous voulons que les gens construisent plus de logiciels. Notre capacité à les protéger doit croître avec notre capacité à les créer.

La publication La protection des secrets doit évoluer avec le logiciel est apparu en premier sur The GitHub Blog.