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.

Que contenait le dépôt Private-CISA ?

Le dépôt s'appelait Private-CISA. Le contractant qui l'a créé travaillait pour Nightwing, une entreprise basée à Dulles en Virginie. Il avait été mis en ligne le 13 novembre 2025, 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, regroupés dans un fichier sobrement nommé importantAWStokens. 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. Une clé RSA privée ouvrant les dépôts de code de CISA-IT. 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 Terraform, des fichiers ArgoCD, des logs CI/CD, l'accès à l'environnement LZ-DSO (Landing Zone DevSecOps) et des certificats SAML pour Entra ID, soit l'identité fédérée de l'organisation.

Guillaume Valadon, le chercheur de GitGuardian qui a fait la découverte, ne mâche pas ses mots. Je cite. Des mots de passe stockés en clair dans un fichier CSV, des sauvegardes dans Git, des commandes explicites pour désactiver la détection de secrets de GitHub. J'ai honnêtement cru que tout cela était faux avant d'analyser le contenu en profondeur. C'est bien la pire fuite dont j'aie été témoin dans ma carrière.

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.

Erreur humaine ou contournement 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é au moment où j'écris, 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. Elle comptait près de trois mille quatre cents personnes au début de l'exercice 2025 ; en décembre, elles n'étaient plus que deux mille quatre cents, une chute de près d'un tiers. 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. Sa lettre joint douze questions précises sur les politiques et les procédures qui ont rendu l'incident possible, et exige une réponse au plus tard le 5 juin. Les démocrates de la commission Sécurité intérieure de la Chambre des représentants réclament de leur côté leur propre briefing. 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 tombe en plein débat budgétaire. L'agence a déjà perdu près d'un tiers de ses effectifs depuis janvier 2025, et la proposition de budget suivante prévoit d'en supprimer environ mille de plus, tout en amputant l'agence d'environ quatre cent quatre-vingt-quinze millions de dollars et en fermant des programmes entiers, du programme de sécurité électorale au financement du MS-ISAC, le centre de partage d'informations des États et des collectivités. Une note de recherche de la Cloud Security Alliance fait le lien noir sur blanc avec la fuite : les contrôles qui auraient dû repérer cette exposition plus tôt, scan actif des secrets, supervision des sous-traitants, gestion du cycle de vie des identifiants, avaient été soit désactivés, soit déprioritisés, soit jamais appliqués. On demande à l'organisation chargée de défendre le pays de le faire avec un tiers de personnel en moins, puis on s'étonne qu'un contractant sous pression prenne un raccourci.

Que dit le rapport post-mortem de CISA ?

Il aura fallu attendre le 13 juillet 2026, presque deux mois après la découverte, pour que CISA publie son rapport post-mortem, signé du directeur des systèmes d'information par intérim Preston Werntz et du responsable de la sécurité par intérim Brad Libbey.

Le document confirme, presque mot pour mot, l'hypothèse posée plus haut. Je cite. L'intéressé avait téléversé des copies d'un dépôt de build et de déploiement de CISA sur son compte GitHub personnel afin de créer de l'infrastructure cloud de manière autonome. Autrement dit, exactement le shadow IT que je décrivais : un contractant qui contourne l'outillage officiel pour aller plus vite, et qui embarque au passage les clés du royaume. Et ce que révèle l'incident dépasse le geste d'un individu : pour plusieurs analystes du secteur, la défense cyber fédérale américaine repose désormais sur une base de sous-traitants trop vaste pour être gouvernée au niveau de sensibilité qu'elle exige, ce qui fait de la gestion des identités et des accès de ces prestataires le vrai point de rupture.

Sur la fenêtre des quarante-huit heures, l'agence reconnaît à demi-mot ce que les logs laissaient deviner. La rotation des clés a pris plus de temps que prévu, admet-elle, en raison de la complexité de ses systèmes et de ses interconnexions avec ses partenaires fédéraux et industriels. Traduction : personne ne savait précisément où toutes ces clés étaient utilisées, donc personne ne pouvait les révoquer d'un seul geste.

Sur la compromission, CISA maintient sa ligne, mais avec un argument plus solide qu'en mai. Aucune donnée client ou de mission n'aurait été exposée, aucun usage non autorisé des credentials n'aurait été détecté, et l'agence affirme cette fois qu'une journalisation complète a permis d'enquêter rapidement. C'est plus étayé que la déclaration initiale, mais cela demande encore de croire sur parole une agence qui n'avait pas vu ses propres clés traîner en public pendant cent quatre-vingt-trois jours.

Le plus honnête, dans ce rapport, tient en une phrase de contrition. Aucun dépôt ne devrait contenir de secrets, écrit CISA, or des secrets se sont retrouvés dans ses dépôts. En allant vérifier, l'agence a d'ailleurs découvert des secrets jusque dans ses propres dépôts privés, qu'il a fallu supprimer puis renouveler, avant de lancer un plan de surveillance étendu à l'ensemble de ses dépôts. Le problème n'était donc pas confiné au compte d'un seul contractant. L'agence admet aussi qu'elle ne disposait d'aucun playbook pour un incident de sécurité cloud parti de GitHub. Il y a plus embarrassant encore : le chercheur de GitGuardian n'avait pas trouvé de canal évident pour alerter l'agence et avait dû passer par les contacts personnels de Brian Krebs. L'organisation qui coordonne la divulgation des vulnérabilités du pays reconnaît, noir sur blanc, qu'on ne savait pas facilement lui remonter les siennes. Les mesures annoncées suivent : blocage des envois de personnel vers des dépôts publics, nouveaux contrôles d'accès aux dépôts de code, journalisation renforcée, clarification et publication des canaux de signalement pour les chercheurs, accès du contractant révoqué, mots de passe changés dans tous les environnements de développement.

Ce sont, ligne pour ligne, les contrôles élémentaires qui manquaient. On les met en place après. On les met toujours en place après.

En France, pendant ce temps, 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 ?

---

Sources

• KrebsOnSecurity, « CISA Admin Leaked AWS GovCloud Keys on Github », 18 mai 2026
• KrebsOnSecurity, « Lessons Learned from CISA's Recent GitHub Leak », juillet 2026
• Cybersecurity Dive, « CISA details security lapses that led to GitHub leak », 14 juillet 2026
• SC Media, « CISA shares postmortem of GitHub credential leak », juillet 2026
• GitGuardian, « How We Got a CISA GitHub Leak Taken Down in Under a Day », mai 2026
• Sénatrice Maggie Hassan, communiqué et lettre à CISA, 19 mai 2026
• Axios, « Senator requests classified briefing on CISA credentials leak », 19 mai 2026
• Nextgov/FCW, « House Homeland Dems request CISA briefing amid report of leaked agency credentials », mai 2026
• Cloud Security Alliance, note de recherche « Private-CISA: GovCloud Leak and the Hollowing of U.S. Cyber Defense », 2026
• Biometric Update, « GitHub exposure points to broader contractor identity security gaps at CISA », juin 2026
• Cybersecurity Dive, « CISA workforce cut by nearly one-third so far », 2025
• Federal News Network, « DHS budget request would cut CISA staff by 1,000 positions », mai 2025