Fuite de secrets (secret scanning)
Une fuite de secrets expose clés d'API, tokens ou mots de passe hors du coffre prévu : dépôt Git, image Docker, historique de commits, bucket mal configuré.
Une fuite de secrets survient quand une donnée d'authentification, clé d'API, token, mot de passe, certificat privé, se retrouve exposée hors du coffre-fort prévu pour elle. Les vecteurs sont d'une banalité désarmante : un fichier de configuration commité par erreur, une clé restée dans l'historique Git après un "nettoyage" du fichier courant, une image Docker publique qui embarque des variables d'environnement, un bucket de stockage laissé ouvert, ou du JavaScript de production qui contient un token en clair.
Ce qui rend le sujet brûlant, c'est la vitesse d'exploitation. Des robots surveillent en permanence les dépôts publics et les registres ; une clé cloud poussée sur GitHub est typiquement testée en quelques minutes. Contrairement à une vulnérabilité qu'il faut savoir exploiter, un secret valide s'utilise tel quel : c'est un accès direct, sans effraction, et les compromissions majeures de ces dernières années commencent très souvent ainsi.
La parade porte un nom, le secret scanning : détecter en continu les secrets exposés dans le code, les historiques, les artefacts et les actifs publics, puis révoquer et faire tourner chaque secret trouvé, car un secret exposé un jour est un secret grillé. Notre page pilier sur les fuites de secrets détaille vecteurs et remédiation, et le module Leaks & Secrets Detection traque ces expositions sur votre périmètre.
Révoquer d'abord, comprendre ensuite
L'ordre des gestes décide de l'impact. Un secret exposé est compromis à l'instant où il devient public, même si aucune utilisation n'apparaît dans les journaux : on révoque et on fait tourner la clé en premier, on enquête après. Retirer le fichier du dépôt ne sert à rien, l'historique Git conserve l'objet, les forks aussi, et les moteurs de recherche de code en gardent copie. Réécrire l'historique complique la vie de l'équipe sans rendre le secret sûr. Les deux seules questions qui comptent sont ce que la clé permettait de faire, et pendant combien de temps elle a été exposée, ce que les journaux d'accès du fournisseur permettent souvent de trancher.
Empêcher la prochaine
Trois barrières se posent, par coût croissant. Un contrôle avant commit, sur le poste du développeur, attrape l'essentiel des accidents. Un contrôle côté serveur, à la réception des commits, rattrape ceux qui contournent le premier, volontairement ou non. Un balayage périodique de l'historique complet et des artefacts, images de conteneurs et paquets publiés compris, exhume la dette déjà accumulée. Le reste est architectural : des secrets à durée de vie courte, injectés au démarrage depuis un coffre, plutôt que des clés permanentes qu'on finit toujours par recopier quelque part. Le SAST attrape ceux qui sont écrits en dur dans le code, pas ceux publiés hors du dépôt.
Questions fréquentes
Faut-il réécrire l'historique Git après une fuite ?
Ce n'est pas la priorité et cela ne rend pas le secret sûr. On révoque d'abord. La réécriture peut se justifier ensuite pour assainir un dépôt privé, en sachant qu'elle casse les clones existants et n'atteint pas les copies déjà faites.
Combien de temps avant qu'une clé publiée soit utilisée ?
Très peu. Des robots surveillent en permanence les dépôts publics et les registres de paquets, et testent automatiquement les identifiants qu'ils y trouvent. On raisonne en minutes, pas en jours.
Un dépôt privé met-il à l'abri ?
Il réduit l'exposition, il ne l'annule pas. Un dépôt privé peut être rendu public par erreur, cloné par un partenaire, ou accessible depuis un compte compromis. Un secret n'a pas sa place dans le code, quel que soit le niveau de confidentialité du dépôt.