CISA, la fuite GitHub : quand le gendarme laisse les clés sur la porte

Imaginez. Vous êtes l'agence fédérale américaine chargée de protéger les systèmes du gouvernement contre les cyberattaques. Votre mission, c'est de dire aux autres comment se sécuriser. Vous publiez des guides, des alertes, des recommandations sur le top dix des failles à éviter, sur la gestion des secrets, sur la posture zero trust. Et un beau jour, des chercheurs en sécurité découvrent que l'un de vos propres contractants a posté en accès public, sur GitHub, un dépôt nommé Private-CISA. Huit cent quarante-quatre mégaoctets de données, dont des identifiants administratifs Amazon AWS GovCloud, des mots de passe en clair dans un fichier CSV, des certificats SAML Entra ID, des clés SSH, et l'accès à votre dépôt interne de paquets logiciels. Le tout exposé depuis novembre 2025. Six mois.

C'est l'histoire que raconte Brian Krebs sur son blog le 18 mai 2026, sur la base d'une découverte de la société française GitGuardian. Et c'est probablement la fuite la plus emblématique de l'année, pas pour son volume, mais pour ce qu'elle dit de l'état réel de la cybersécurité publique en 2026.

Le contenu de l'archive

Le dépôt s'appelait Private-CISA. Le contractant qui l'a créé travaillait pour Nightwing, une entreprise basée à Dulles en Virginie. Le repo était hébergé sur GitHub.com en visibilité publique, accessible sans authentification, indexé par les moteurs de recherche. À l'intérieur, les chercheurs de GitGuardian ont trouvé exactement ce qu'on espère ne jamais voir.

Trois ensembles de credentials administratifs pour AWS GovCloud, l'environnement cloud d'Amazon réservé aux charges sensibles du gouvernement américain. Ces credentials donnaient un accès de haut privilège à des comptes contenant les services hébergés par CISA. Un fichier CSV nommé AWS-Workspace-Firefox-Passwords contenant en clair les identifiants Firefox de dizaines de systèmes internes. Des accès au dépôt Artifactory de l'agence, c'est-à-dire la bibliothèque de tous les paquets logiciels utilisés pour construire les outils internes. Des manifests Kubernetes, des fichiers ArgoCD, des logs CI/CD, et des certificats SAML pour Entra ID, soit l'identité fédérée de l'organisation.

Pour bien mesurer ce que ça représente, il faut comprendre que l'accès à un Artifactory n'est pas une simple fuite de credentials. C'est un point d'entrée idéal pour une attaque par chaîne d'approvisionnement. Un attaquant qui obtient ce niveau d'accès peut injecter du code malveillant dans les paquets utilisés en interne, attendre que les builds suivants intègrent automatiquement ce code, et voir son backdoor se propager dans tous les systèmes qui consomment ces paquets. C'est exactement la catégorie de menace que CISA est censée prévenir et combattre.

La désactivation volontaire des protections

GitHub propose depuis plusieurs années une fonctionnalité de scan automatique qui détecte les secrets posés dans les dépôts publics et bloque leur publication. C'est activé par défaut sur tous les comptes. Quand vous tentez de pousser un fichier contenant une clé AWS, un token JWT, ou un certificat privé, GitHub vous arrête et vous demande de confirmer.

Les logs de commit du dépôt Private-CISA montrent que le contractant a désactivé manuellement cette protection avant de pousser ses données. Ce n'est pas un oubli. C'est une action volontaire, documentée, traçable. Quelqu'un, à un moment précis, a cliqué pour contourner une mesure de sécurité qu'on impose par défaut à tous les utilisateurs de la plateforme.

Et ce détail change la nature de l'incident. On ne parle pas d'un développeur qui aurait commis une erreur en oubliant un fichier dans son dépôt. On parle d'une personne qui a délibérément désarmé un mécanisme de protection pour publier ses propres backups personnels. Plusieurs commentateurs sur le forum de Krebs y voient une utilisation détournée de GitHub comme système de synchronisation entre une machine professionnelle et une machine personnelle, dans un environnement où les ports USB et les clouds tiers seraient probablement bloqués par la politique de sécurité de Nightwing.

Si c'est le cas, et c'est plausible, on touche à quelque chose qui dépasse largement l'incident CISA. On touche au shadow IT structurel des sous-traitants de l'État, à la pratique du contournement quotidien des règles de sécurité parce qu'elles sont vécues comme des obstacles au travail. C'est exactement le sujet que je traitais il y a deux semaines à propos du scandale Europol Pressure Cooker. Le pattern se répète, sur tous les continents, dans toutes les agences.

Les 48 heures qui en disent long

Le 14 mai 2026, GitGuardian détecte le dépôt. Ses systèmes automatiques envoient neuf alertes au propriétaire du compte. Aucune réponse, à part les acknowledgments automatiques. Le 15 mai au matin, l'équipe contacte directement le centre d'incidents CERT/CC, et en parallèle Brian Krebs pour qu'il active ses contacts personnels à CISA. L'agence est jointe en début d'après-midi européen. Le dépôt est retiré à dix-huit heures, heure de l'est, ce qui correspond à environ vingt-six heures entre la première alerte à CISA et le takedown.

Sur ce point, l'agence a réagi vite, et le mérite doit être reconnu. La plupart des divulgations responsables prennent beaucoup plus de temps.

Mais voilà le détail qui devrait nous arrêter. Les credentials AWS exposés sont restés valides pendant quarante-huit heures après le retrait du dépôt. Soit deux jours entiers pendant lesquels un attaquant qui aurait copié les secrets pendant les six mois d'exposition pouvait continuer à les utiliser pour accéder aux comptes GovCloud. La rotation des clés, qui devrait être une action automatique et immédiate dans tout incident de ce type, n'a été déclenchée que tardivement.

Pourquoi c'est important. Parce que dans une enquête forensique, les actions d'un attaquant pendant la fenêtre où les credentials sont encore valides ressemblent à l'identique aux actions légitimes des administrateurs. Les logs ne font pas la différence entre un usage autorisé et un usage frauduleux tant que la clé n'a pas été marquée comme compromise. Donc auditer ces quarante-huit heures pour exclure une exploitation est extraordinairement difficile, et pour l'instant CISA n'a publié aucun bilan forensique complet.

La déclaration que personne ne peut prouver

Face à la pression médiatique, CISA a fait une déclaration officielle qui mérite d'être lue attentivement. Je cite. Actuellement, il n'y a aucune indication que des données sensibles aient été compromises à la suite de cet incident.

Cette phrase est techniquement juste, mais elle est aussi techniquement vide. Comment peut-on affirmer qu'il n'y a pas eu de compromission sur cent quatre-vingt-trois jours d'exposition publique, avec accès administratif à trois comptes GovCloud, et avec des credentials qui sont restés valides quarante-huit heures après la découverte ? On ne peut pas. À moins de produire un audit forensique complet de tous les accès sur cette période, ce que CISA n'a pas publié, et ce que CISA aurait probablement beaucoup de mal à produire compte tenu de ses effectifs actuels.

Parce qu'il faut le rappeler, l'agence fonctionne aujourd'hui à environ soixante-dix pour cent de ses effectifs pré-2025. Coupes budgétaires, démissions, retraites anticipées, départs sous l'administration Trump. La capacité d'enquête forensique sur un incident de cette ampleur, à effectifs réduits, devient un défi structurel.

Sept couches de protection, sept échecs

Ce qui rend cet incident pédagogique, c'est qu'il révèle un empilement de défaillances qui auraient dû individuellement empêcher la fuite ou la limiter dramatiquement.

GitHub bloque par défaut la publication des secrets. Le contractant a désactivé cette protection. Première défense tombée.

AWS GovCloud supporte les identifiants temporaires via IAM avec des tokens STS qui expirent en quelques heures. Les credentials exposés étaient des credentials statiques de long terme. Deuxième défense absente.

AWS Secrets Manager permet la rotation automatique des clés à intervalle régulier. La rotation n'était pas activée. Troisième défense absente.

Les comptes administratifs GovCloud peuvent être protégés par des clés de sécurité matérielles, type YubiKey. Apparemment, ce n'était pas le cas. Quatrième défense absente.

CISA devrait disposer d'un système interne de monitoring des fuites de credentials qui détecterait l'apparition de ses propres clés dans des dépôts publics. C'est GitGuardian, une société française privée, qui a fait la découverte, pas l'agence elle-même. Cinquième défense absente.

La politique de mots de passe interne devrait interdire les conventions triviales du type nom_de_la_plateforme + année. Plusieurs identifiants exposés suivaient exactement ce schéma. Sixième défense absente.

Et le contractant aurait dû être contraint à utiliser des outils d'entreprise pour ses sauvegardes, et non son compte GitHub personnel. Septième défense absente.

Quand sept couches de contrôle indépendantes échouent au même endroit, on n'est plus dans l'incident. On est dans le système.

Ce que cela nous apprend, à nous, sur nous

Et là, vous allez peut-être me dire, oui, mais c'est aux États-Unis, c'est CISA, c'est compliqué, c'est un cas particulier. Sauf que non. Et c'est précisément le sens de cet article.

Les organisations qui ont les frameworks les plus matures, les certifications les plus solides, les budgets les plus confortables, peuvent se faire grillées de la même façon que la plus modeste des PME. Parce que la sécurité, dans la réalité opérationnelle, ne dépend pas du nombre de pages dans le manuel ISO 27001. Elle dépend de ce que font les humains quand ils sont seuls devant leur écran, à six heures du soir, avec un fichier à transférer sur leur machine personnelle pour finir tranquillement à la maison.

Vous pouvez avoir tous les audits annuels du monde, tous les certificats de conformité, toutes les politiques en triple exemplaire signées par votre RSSI, votre DPO, et votre direction générale. Si la culture opérationnelle ne suit pas, si les contrôles automatiques peuvent être désactivés par un clic, si la rotation des credentials n'est pas automatique, si vos contractants utilisent GitHub comme cloud personnel sans que vous le sachiez, vous êtes dans la situation de CISA.

C'est ça la vraie cybersécurité. Pas la documentation. Pas les frameworks. Pas les annonces. La culture opérationnelle quotidienne, c'est-à-dire ce qui se passe quand personne ne regarde.

Et maintenant

À l'heure où j'écris ces lignes, le 19 mai 2026, la sénatrice Maggie Hassan vient de demander un briefing classifié urgent au directeur intérimaire de CISA. La Maison Blanche, le département de la Sécurité intérieure, et l'administration américaine vont devoir répondre à des questions précises sur leurs pratiques internes. Et l'incident va probablement nourrir le débat budgétaire qui s'ouvre sur le financement de l'agence pour 2027.

Pendant ce temps, en France, on continue de discuter de la transposition de NIS2 avec dix-huit mois de retard. On continue de débattre des backdoors dans les messageries chiffrées. Et on continue de publier des feuilles de route Matignon qui demandent aux ministères de mettre en place en 2026, à horizon 2027, les contrôles élémentaires qu'on attendrait d'une PME française moyenne.

À quel moment cessons-nous de réagir à chaque incident comme s'il était une exception, et commençons-nous à les traiter comme les symptômes systémiques qu'ils sont ?

---

Source principale : Brian Krebs, KrebsOnSecurity, 18 mai 2026. Investigation complémentaire par GitGuardian (Guillaume Valadon) et Seralys (Philippe Caturegli). Confirmation officielle par CISA et reportage Axios sur la demande de briefing classifié du Sénat.