Le manque de références augmente : 28,65 millions de secrets détectés en 2025 et risque plus élevé IA

La sécurité des identifiants - clés, jetons et secrets qui relient les utilisateurs, les services et maintenant les agents de l'IV - est devenue le point d'échec le plus exposé de la plupart des organisations. Les données spécifiques recueillies par les fournisseurs et les rapports publics montrent que les fuites augmentent non seulement en nombre, mais qu'elles s'étendent dans l'environnement où résident ces titres : dépôts publics et internes, systèmes collaboratifs et équipes de développement elles-mêmes. Pour comprendre le risque réel, il est essentiel de commencer par la détection : sans un inventaire fiable de ce qu'il existe, où ils sont et ce qu'ils permettent, toute tentative d'atténuation sera partielle et tardive.

Faits confirmés pertinents : GitGuardian a signalé 28,65 millions de nouveaux secrets codés en dur détectés dans les engagements publics de GitHub en 2025, soit une augmentation de 34 % par année, et a noté une augmentation de 81 % des titres de compétence filtrés liés aux services d'AI. Cette recherche montre également que les dépôts internes sont environ six fois plus susceptibles que le public de contenir au moins un secret, et qu'environ 28 % des incidents secrets proviennent de systèmes de collaboration et de productivité qui ne sont pas contrôlés par le code source. De plus, le rapport 2026 de Verizon indique que les lettres de créance engagées représentaient 22 % du vecteur d'accès initial dans les lacunes étudiées. Ces sources dessinent une image cohérente : la surface d'attaque liée aux références est étendue par des environnements gérés et non gérés. Pour les rapports ci-dessus, voir l'analyse de GitGuardian et du Verizon DBIR: GitGuardian et Verizon DBIR.

Techniquement, le problème a plusieurs couches. Tout d'abord, les références apparaissent dans différents endroits : dans l'histoire de Git (pas seulement dans la dernière version), dans les branches ou les fourchettes, dans les tickets et les conversations, et sur le disque du développeur. Deuxièmement, la validité de ces pouvoirs dure souvent : les tests de revalidation montrent que les pouvoirs confirmés valides en 2022 étaient toujours actifs dans 64 % des cas en janvier 2026. Troisièmement, l'arrivée d'agents IA intégrés dans les flux de développement a créé de nouveaux organismes qui peuvent lire des fichiers, exécuter des commandes et connecter des services : ces agents ont des contextes d'authentification qui multiplient les points d'exposition. Enfin, les nouvelles familles d'infostealers (par exemple, les campagnes publiques à la fin de 2025 qui ont affecté les paramètres) ont fait des équipes de développement une priorité; une analyse d'un incident a montré 33 185 secrets uniques sur 6 943 machines engagées, dont près de la moitié contenant plus de 10 secrets, illustrant la densité et la valeur de la télémétrie locale.

À qui ça sert ? À toute organisation qui produit des logiciels ou consomme des services cloud : équipement de développement, opérations, sécurité, et tout « citoyen développé » à l'aide d'outils d'automatisation ou d'agents d'IA. Elle a également un impact sur la chaîne d'approvisionnement : un titre filtré dans un projet personnel, un dépôt interne ou un paramètre peut être la clé d'entrée pour atteindre des environnements productifs ou des fournisseurs externes. Le problème n'est pas théorique: la durée moyenne des déplacements latéraux et de l'exploitation des attaquants a été considérablement réduite; les études de l'écosystème de cybersécurité soulignent que les lacunes criminelles peuvent grimper en quelques minutes, ce qui rend impossible de compter uniquement sur des réponses humaines lentes (voir, par exemple, l'analyse de CrowdStrike et d'autres sur les temps de rupture eCrime).

Incidences pratiques: un titre divulgué peut permettre un accès direct à l'infrastructure critique (cloud, dépôts, bases de données), une persistance silencieuse par une rotation insuffisante et une montée latérale dans le réseau. En outre, la lecture automatique de logiciels malveillants à la recherche de secrets dans les terminaux transforme n'importe quelle machine avec accès à plusieurs services en un multiplicateur de risque. Pour compliquer l'image, de nombreuses organisations ne savent pas quelle fraction de l'inventaire des titres de compétence est liée à un propriétaire, à une politique d'expiration ou à une charge de travail productive, ce qui rend difficile l'établissement de priorités en matière d'assainissement sans interrompre les systèmes critiques.

Mesures spécifiques et hiérarchisées à prendre par le lecteur (organisations et responsables techniques) : d'abord, établir une détection continue qui combine l'analyse des dépôts (y compris l'historique), la surveillance publique des engagements et la découverte des paramètres. Cela signifie intégrer des outils de détection dans CI / CD et EDR / MDM pour révéler des secrets qui n'atteignent pas le contrôle central. Deuxièmement, enrichir chaque découverte par contexte : vérifier la validité du secret, identifier le propriétaire de l'utilisation, cartographier les permissions associées et lister les unités ou les charges de travail qui l'utilisent, afin que la réponse puisse être sélective et sécurisée. Troisièmement, donner la priorité à la rotation ou à la révocation des titres de compétence en fonction de la validité et de la portée des permis, et non seulement du nombre de fois où le secret est apparu. Quatrièmement, appliquer des mécanismes d'authentification temporaires et moins privilégiés : déplacer les lettres d'identité dans des coffres à secrets éphémères, adopter des rôles et des jetons limités, et permettre à MFA d'appliquer. Cinquièmement, limiter ce que les agents IA et les intégrations externes peuvent lire ou exécuter : définir les autorisations minimales pour les modèles et les agents, séparer les environnements d'implémentation et utiliser les politiques de contrôle des données contextuelles (par exemple, restreindre l'accès aux fichiers sensibles des agents). Enfin, implémentez la détection post-exposition: alertes automatiques à l'utilisation anormale des clés et des livres de lecture qui annulent et remplacent les lettres d'identité tout au long de la chaîne.

Limites et points encore incertains: certaines mesures publiées proviennent d'analyses effectuées dans des dépôts publics et de séries de données spécifiques; par conséquent, l'ampleur totale du problème dans les environnements privés peut varier et devrait rester sous-estimée. L'efficacité de certaines mesures (par exemple, bloquer les agents d'IA dans certains contextes) dépend de l'architecture et de la manière dont ces agents sont intégrés. En outre, l'évolution rapide des logiciels malveillants spécialisés dans le vol de secrets implique que les tactiques défensives doivent être constamment revues; il n'y a pas de solutions uniques, mais une combinaison d'inventaire, de contrôle et d'automatisation qui réduit la fenêtre d'exposition.

En résumé: la première priorité est de détecter avec pleine portée et riche contexte. Sans cet inventaire, il n'existe aucun moyen fiable de remédier et de prévenir. La détection devrait couvrir les dépôts (y compris les dépôts historiques), l'espace public et les paramètres de développement; la médiation devrait être guidée par la validité et les permissions; et la prévention devrait se concentrer sur les titres éphémères, les privilèges les moins importants et les contrôles plus stricts sur les agents de développement et les environnements. Pour approfondir la nature et l'évolution du problème, les lecteurs peuvent consulter les rapports de recherche des fournisseurs et des analyses sectorielles comme ceux de GitGuardian et Verizon DBIR : GitGuardian - État des secrets Sprawl 2026 et Verizon DRIR 2026.