CISA tente de contenir une fuite de données

• Un prestataire de CISA a publié sur un profil GitHub public, « Private-CISA », des identifiants en clair pour des dizaines de systèmes internes, avec des traces montrant aussi la désactivation des protections GitHub
• CISA a reconnu la fuite, mais n’a pas répondu sur la durée d’exposition ; le dépôt, créé en novembre 2025, présentait un usage proche d’un scratchpad personnel
• Des élus comme Maggie Hassan et Bennie Thompson ont mis en doute les politiques de sécurité interne de CISA, la gestion des prestataires et la culture de sécurité à un moment de montée des menaces contre les infrastructures critiques
• Une semaine après l’alerte de GitGuardian, certaines clés étaient encore en cours de rotation, et Dylan Ayrey de TruffleHog a indiqué qu’au 20 mai une clé privée RSA était toujours active
• Le flux public des événements GitHub peut être surveillé à la fois par les défenseurs et les attaquants, ce qui laisse subsister le risque que des secrets sensibles ajoutés fin avril 2026 aient déjà été exploités

---

La fuite chez CISA et les questions du Congrès

• Un prestataire de CISA, disposant de privilèges d’administrateur sur la plateforme de développement de code de l’agence, a créé un profil GitHub public nommé « Private-CISA », contenant des identifiants en clair pour des dizaines de systèmes internes de CISA
• Les journaux de commit montraient des traces de désactivation des protections intégrées de GitHub censées empêcher la publication d’identifiants sensibles dans des dépôts publics
• CISA a reconnu la fuite, mais n’a pas répondu à la question de savoir combien de temps les données sont restées exposées
• Des experts ayant examiné une archive du profil Private-CISA aujourd’hui disparu ont estimé que le dépôt avait été créé pour la première fois en novembre 2025 et qu’il ressemblait davantage à un scratchpad personnel ou à un moyen de synchronisation qu’à un dépôt de projet structuré
• Dans une déclaration écrite, CISA a affirmé qu’« il n’existe aucun signe indiquant que des données sensibles ont été compromises à la suite de cet incident »

Des élus s’inquiètent de la culture de sécurité

• La sénatrice Maggie Hassan a déclaré dans une lettre du 19 mai adressée au directeur par intérim de la CISA, Nick Andersen qu’un tel échec de sécurité au sein d’une agence chargée d’aider à prévenir les compromissions cyber soulevait de graves questions
• Hassan a souligné que cet incident renforçait les inquiétudes concernant les politiques et procédures internes de CISA, alors que les cybermenaces majeures visant les infrastructures critiques américaines se poursuivent
• L’incident s’est produit dans un contexte de forte désorganisation interne à CISA, après que l’administration Trump a imposé des départs anticipés, des rachats de contrats et des démissions dans plusieurs services, ce qui a fait perdre à l’agence plus d’un tiers de ses effectifs et presque tous ses hauts responsables
• Le représentant Bennie Thompson a écrit dans une lettre du 19 mai que l’incident pouvait refléter une culture de sécurité affaiblie ou une capacité insuffisante de CISA à gérer son soutien contractuel
• Thompson et la co-signataire la représentante Delia Ramirez estiment que, dans un contexte où des puissances adverses comme la Chine, la Russie et l’Iran cherchent à obtenir et maintenir un accès aux réseaux fédéraux, les fichiers du dépôt Private-CISA pouvaient fournir des renseignements, des accès et une feuille de route

Une révocation des identifiants toujours inachevée

• Plus d’une semaine après que l’entreprise de sécurité GitGuardian a signalé pour la première fois la fuite à CISA, l’agence poursuivait encore la révocation et la rotation d’un grand nombre de clés et secrets exposés
• Dylan Ayrey, créateur de TruffleHog, a indiqué qu’au 20 mai la clé privée RSA exposée dans le dépôt Private-CISA n’avait toujours pas été révoquée
• Cette clé privée RSA donnait accès à une application GitHub appartenant à un compte d’entreprise CISA et installée sur l’organisation GitHub CISA-IT, avec un accès complet à tous les dépôts de code
• Selon Ayrey, un attaquant pouvait, avec cette clé, lire le code source de tous les dépôts de l’organisation CISA-IT, y compris les dépôts privés, enregistrer un runner auto-hébergé malveillant pour compromettre les pipelines CI/CD et accéder aux secrets des dépôts
• Un attaquant pouvait également modifier les paramètres d’administration des dépôts, notamment les règles de protection de branche, les webhooks et les clés de déploiement
• Après que KrebsOnSecurity a signalé à CISA le 20 mai la découverte d’Ayrey, l’agence semble avoir révoqué cette clé privée RSA
• Ayrey a ajouté que CISA n’avait pas encore remplacé d’autres identifiants compromis liés à des technologies de sécurité essentielles déployées dans l’ensemble du portefeuille technique de l’agence
• CISA a répondu qu’elle « collaborait et se coordonnait activement avec les parties concernées et les fournisseurs afin de s’assurer que les identifiants compromis identifiés soient remplacés et révoqués, et qu’elle continuerait à prendre les mesures appropriées pour protéger la sécurité des systèmes »

La double face du flux public d’événements GitHub

• Truffle Security surveille les clés exposées sur GitHub et sur plusieurs autres plateformes de code, et cherche à notifier les comptes concernés lorsqu’une donnée sensible est exposée
• GitHub fournit un flux en temps réel contenant tous les commits et modifications des dépôts publics, ce qui rend possible la détection des expositions
• Ayrey a expliqué que les cybercriminels surveillent eux aussi ce flux public et ciblent rapidement les clés API ou clés SSH publiées accidentellement dans des commits
• Le dépôt GitHub Private-CISA exposait des dizaines d’identifiants en clair donnant accès à d’importantes ressources GovCloud de CISA
• Ayrey a indiqué qu’il était très probable que des groupes cybercriminels ou des puissances étrangères hostiles aient également vu la publication des secrets de CISA, et que les expositions les plus graves semblaient remonter à fin avril 2026
• Le risque central demeure dans le fait que « toute personne surveillant les événements GitHub peut disposer de ces informations »

Les limites des contrôles techniques

• James Wilson, du podcast de sécurité Risky Business, estime que les organisations qui gèrent leurs projets de code sur GitHub peuvent définir des politiques globales empêchant les employés de désactiver les mécanismes qui bloquent la publication de clés secrètes et d’identifiants
• Son coanimateur Adam Boileau estime qu’il n’est pas clair quelle technologie pourrait empêcher un employé d’ouvrir un compte GitHub personnel pour y stocker des informations sensibles et propriétaires
• Boileau qualifie cet incident de problème humain difficile à résoudre par les seuls contrôles techniques
• Si le prestataire utilisait GitHub pour synchroniser du contenu entre un appareil professionnel et un appareil personnel, l’incident met en lumière la difficulté d’empêcher des actions qui échappent au périmètre que CISA peut gérer ou surveiller
• La mise à jour de l’article ajoute la déclaration de CISA et corrige une erreur de date : Truffle Security a indiqué que certaines des secrets les plus sensibles du dépôt avaient été ajoutés non pas en 2025, mais fin avril 2026

[GN⁺]

Commentaires Hacker News

• C’est une erreur complètement absurde. Dire que « cela correspond davantage à un usage du dépôt comme bloc-notes de travail personnel ou moyen de synchronisation que comme dépôt de projet géré », alors que la règle la plus élémentaire de Git est justement de ne pas y mettre d’identifiants ? Je ne vois pas du tout à quel “usage” cela correspond

  • Cette formule ne défend pas ça comme une méthode de travail établie ou une bonne pratique
    Dire que « cela présente un schéma cohérent avec ~ » revient simplement à décrire à quoi ressemble l’usage du dépôt. Autrement dit, ce n’était ni un ensemble de code source gouvernemental pour un projet interne, ni un signal montrant une volonté de provoquer une fuite massive de données
  • Le type d’usage auquel cela correspond est déjà clairement indiqué : c’était utilisé comme une sorte de bloc-notes de travail personnel
    Tu prêtes à cette phrase plus de sens qu’elle n’en a. Elle décrit simplement ce qui a été observé
  • Ce n’est pas du tout une erreur. Le gouvernement américain est totalement infiltré par des services de renseignement étrangers, et cette “intrusion” était entièrement intentionnelle
  • Si on m’avait donné 1 dollar par secret commité dans un dépôt public, j’aurais probablement pu prendre ma retraite. Ça n’excuse rien, évidemment. Mais faire comme si le gouvernement américain n’était pas, au fond, composé de gens comme nous, c’est assez drôle

• Des contrôles techniques plus compétents auraient dû empêcher qu’un sous-traitant quelconque puisse copier chez lui un mot de passe de mi-2025 et que ce mot de passe fonctionne encore non seulement 30 jours plus tard, mais même 5 jours plus tard

  • Oui. En fait, je pensais que l’État utilisait depuis longtemps de façon assez sérieuse des cartes à puce et des HSM pour tout. Je ne comprends pas pourquoi on distribue à qui que ce soit des identifiants qu’on peut extraire, alors qu’il suffirait de fournir du matériel d’où les identifiants ne peuvent pas sortir
    Dans certaines organisations, le coût supplémentaire poserait problème, mais ici ce n’est clairement pas le cas. Ou alors c’est un autre symptôme de la dégradation provoquée l’an dernier quand les républicains ont cassé ce qui relevait justement du rôle de CISA dans ce genre de projets et de standards. Quoi qu’il en soit, la technologie peut clairement réduire ce genre d’incident, ce n’est pas une catastrophe naturelle inévitable
  • Je ne traite pas de secrets d’État, mais j’ai accès à des données sensibles ou précieuses pour des clients. L’idée même de télécharger directement quelque chose sur mon appareil me dépasse
    Même récupérer un fichier de logs avec un truc comme "aws s3 cp s3://client/file - | less" ne m’emballe pas. Je préfère largement lancer une petite instance bon marché et consulter les données à l’intérieur du VPC du client

• Quand on réduit une organisation d’experts, il semble évident qu’on réduit aussi beaucoup de capacités, y compris la sécurité opérationnelle
  En 2020, Chris Krebs a réfuté les accusations d’élection volée. En 2025, Trump a licencié Krebs et annulé son habilitation de sécurité, laissant CISA sans directeur. https://en.wikipedia.org/wiki/Chris_Krebs
  En mars 2025, les réductions ont commencé. https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
  En 2026, l’agence était toujours sans directeur et fonctionnait presque à l’os. https://techcrunch.com/2026/02/25/us-cybersecurity-agency-ci...
  Cette trajectoire ressemble à un affaiblissement délibéré de la défense d’un pays de l’intérieur et à une diffusion intentionnelle du chaos

  • Si c’était une puissance étrangère hostile qui dirigeait tout ça, est-ce qu’on verrait la différence ?
  • Honnêtement, ça correspond plus directement à une incompétence agressive et à des embauches/licenciements fondés sur la loyauté. J’admets que la question de savoir comment ces imbéciles ont obtenu le pouvoir d’embaucher et de licencier est plus complexe
  • Krebs a été licencié en 2020, pas en 2025

• CISA a perdu plus d’un tiers de ses effectifs ainsi que la plupart de ses dirigeants seniors après que l’administration Trump a poussé aux retraites anticipées, rachats de départ et démissions dans plusieurs services

• Des sénateurs semblent demander pourquoi CISA réduit ses efforts sur la sécurité électorale[1]. Le timing de la démission de Tulsi aujourd’hui paraît aussi étrangement coïncider avec la révélation de cette affaire
  [1]https://www.padilla.senate.gov/newsroom/press-releases/padil...

  • Je ne comprends pas pourquoi les sénateurs américains font tout ce bruit. Trump a été parfaitement clair en présentant son budget : il voulait réduire massivement le budget de la CISA, et il a aussi directement ordonné à CISA de fermer son bureau de sécurité électorale
    C’est le mème « qui a tué Hannibal ? ». Si Padilla et Warner ne le savaient pas, alors eux aussi sont incompétents. D’autant plus qu’ils avaient déjà traité le sujet dans un communiqué l’an dernier :
    https://www.padilla.senate.gov/newsroom/news-coverage/cnn-tr...
    Padilla, pourquoi as-tu oublié que tout cela s’était produit ?

• Ça me fait penser à l’en-shittification des transports publics. On coupe les budgets, la qualité du service baisse, puis l’opinion devient négative
  Au final, ce genre de trajectoire peut mener à davantage de privatisation via des prestataires de sécurité

  • C’est justement un prestataire de sécurité qui a divulgué les identifiants. Donc on est déjà, en quelque sorte, au stade final de cette privatisation croissante

• Je me souviens de la fuite d’un million de formulaires SF-86. Ces formulaires où l’on renseigne une quantité énorme d’informations très personnelles pour permettre de juger si l’on est digne de confiance pour manipuler des données sensibles

  • Ce n’était pas une fuite mais une compromission. C’était l’œuvre des services de sécurité d’État chinois
  • Ce n’était pas la CISA mais l’OPM, non ?

• Les élus veulent des réponses, mais eux-mêmes n’en donnent pas. Qui surveille les soi-disant surveillants ? La corruption des élus est massive, mais si une clé est rendue publique, on coupe des têtes ? Même des gens très intelligents publient souvent des clés par erreur
  Vous n’avez jamais lancé rm -rf * ? Jamais supprimé une base de données de production ? Jamais éteint le mauvais serveur ? Ça arrive à tout le monde

  • Leur surveillance ne vise pas le soin, mais le contrôle. Elle est discrètement hostile, et la “protection” n’est qu’un prétexte, pas la réalité

• Si ces gens, censés être des experts, n’arrivent même pas à être correctement en sécurité sur Internet, je ne vois pas comment qui que ce soit d’autre pourrait l’être

  • C’est après Doge. Doge a bien fait son travail. Tristement, beaucoup d’autres gens ont simplement répété les mensonges de Doge

• Le vrai point important n’est pas seulement la fuite des clés AWS GovCloud, mais le fait que le sous-traitant ait désactivé manuellement la protection de scan des secrets de GitHub