Fuite de clés AWS GovCloud CISA sur GitHub : ce que révèle l'incident de sécurité le plus grave pour une agence fédérale

La négligence qui a compromis les systèmes les plus sensibles du gouvernement américain

Le 15 mai 2026, Guillaume Valadon, chercheur chez GitGuardian, découvre un dépôt GitHub public qui change la donne. Nommé « Private-CISA », ce repository contenait les identifiants administrateurs de plusieurs comptes AWS GovCloud de la Cybersecurity & Infrastructure Security Agency (CISA), ainsi que des dizaines de mots de passe en clair pour des systèmes internes critiques. Sécurité interne, secrets de déploiement, jetons d’authentification - tout était accessible au premier internaute venu. Pendant ce temps, l’agence censée protéger l’infrastructure critique des États-Unis avait ses clés numériques exposées sur Internet comme s’il s’agissait d’un code de démonstration.

Cet incident constitue, selon les mots mêmes des experts interrogés, l’une des fuites de données gouvernementales les plus graves jamais documentées. Bien plus qu’une erreur individuelle, elle révèle des failles structurelles dans les pratiques de sécurité des prestataires et sous-traitants qui accèdent aux systèmes les plus sensibles de l’État fédéral.

Anatomie d’une fuite historique : ce qui a été exposé

Des clés AWS GovCloud à portée de main

Le dépôt « Private-CISA » contenait un fichier intitulé « importantAWStokens » qui exposait les identifiants administrateurs de trois serveurs AWS GovCloud. AWS GovCloud est le cloud sécurisé d’Amazon conçu spécifiquement pour les agences gouvernementales américaines et les contractants manipulant des données classifiées ou hautement sensibles. L’accès administrateur à ces environnements donne potentiellement la capacité de modifier des configurations critiques, d’accéder à des environnements de production et même de créer de nouveaux accès persistants.

Philippe Caturegli, fondateur du cabinet de conseil Seralys, a testé la validité de ces clés. Sa conclusion est sans appel : les identifiants étaient non seulement authentiques, mais ils permettait un accès à un niveau de privilège élevé sur les trois comptes AWS GovCloud concernés. Les clés sont restées valides pendant encore 48 heures après la suppression du repository, alors même que CISA avait été alertée.

Des mots de passe en clair pour des dizaines de systèmes internes

Au-delà des credentials cloud, le repository exposait un fichier « AWS-Workspace-Firefox-Passwords.csv » listant des dizaines de noms d’utilisateur et mots de passe en texte clair pour des systèmes internes CISA. Parmi eux, un système appelé « LZ-DSO » (Landing Zone DevSecOps), l’environnement sécurisé de développement de code de l’agence, était directement accessible avec ses identifiants en clair.

Le repository contenait également les identifiants de l’« artifactory » interne de CISA - le dépôt centralisé de tous les paquets logiciels utilisés pour construire les applications de l’agence. Comme l’explique Philippe Caturegli : « Ce serait un endroit de choix pour se déplacer latéralement. Un backdoor injecté dans certains paquets logiciels, et à chaque fois qu’ils construisent quelque chose de nouveau, votre porte dérobée se déploie à tour de bras. »

Des mois de commits à découvert

L’analyse des métadonnées Git révèle que le repository « Private-CISA » a été créé le 13 novembre 2025, mais le compte GitHub associé existait depuis septembre 2018. Les commits réguliers jusqu’en mai 2026 indiquent que le contractor utilisait ce dépôt public comme un espace de synchronisation entre son ordinateur portable professionnel et son poste personnel. Cette pratique, aussi banale qu’elle puisse paraître, transformait un repository GitHub censé être privé en un serveur de fichiers accessible au monde entier - avec tous les secrets qu’il contenait.

Les défaillances de sécurité identifiées par les experts

La désactivation volontaire de la détection de secrets

Guillaume Valadon, de GitGuardian, a analysé les logs de commits du compte GitHub incriminé. Son constat est édifiant : « L’administrateur CISA a désactivé le paramètre par défaut de GitHub qui bloque la publication de clés SSH ou d’autres secrets dans les repositories publics. Des mots de passe stockés en clair dans des fichiers CSV, des sauvegardes dans Git, et des commandes explicites pour désactiver la fonction de détection de secrets de GitHub. » En d’autres termes, les mécanismes de protection étaient consciemment contournés.

Des mots de passe d’une faiblesse consternante

L’analyse du repository révèle que de nombreux credentials utilisaient des mots de passe d’une simplicité alarmante. Beaucoup suivaient un motif prévisible : le nom de la plateforme suivi de l’année en cours. Un expert en sécurité expliquant que ce type de pratique constitue une menace sérieuse pour toute organisation, même sans exposition externe. Les attaquants exploitant des credentials fuitée sur un réseau interne disposent déjà souvent d’un premier point d’accès - des mots de passe devinables accélèrent considérablement leur mouvement latéral.

L’utilisation d’adresses email personnelles et professionnelles

Les métadonnées Git montrent que le contractor a utilisé à la fois une adresse email associée à CISA et une adresse email personnelle dans ses commits. Cette configuration laisse supposer que le repository servait à synchroniser des fichiers entre des environnements différemment configurés - un workstation professionnel et un ordinateur domestique. Philippe Caturegli commente : « L’utilisation conjointe d’une adresse email associée à CISA et d’une adresse personnelle suggère que le repository a été utilisé dans des environnements différemment configurés. Les métadonnées Git disponibles ne prouveraient pas quel terminal ou appareil a été utilisé. »

Qui est derrière cette fuite ? Nightwing, un contractor sous les projecteurs

L’analyse du compte GitHub et des credentials exposés indique que le repository « Private-CISA » était maintenu par un employé de Nightwing, une entreprise de sous-traitance gouvernementale basée à Dulles, en Virginie. Nightwing fournit des services de sécurité informatique et de cybersécurité principalement pour des agences fédérales américaines. L’entreprise a décliné tout commentaire, préférant orienter les demandes de presse vers CISA.

La firme Nightwing opère dans un secteur où les exigences de sécurité sont parmi les plus élevées du marché. Ses employés accèdent régulièrement à des environnements sensibles, souvent avec des privilèges étendus. Le fait qu’un de ses collaborateurs ait pu exposer des credentials GovCloud de manière aussi négligente pose des questions fondamentales sur les processus de contrôle et de formation en sécurité au sein des contractors du secteur federal.

Réponse de CISA : entre minimisation et enquête

Face aux questions de KrebsOnSecurity, un porte-parole de CISA a déclaré que l’agence était consciente de l’exposition rapportée et qu’une enquête était en cours. La réponse officielle reste mesurée : « Actuellement, il n’existe aucune indication que des données sensibles aient été compromises à la suite de cet incident. Bien que nous exigions de nos équipes le plus haut niveau d’intégrité et de conscience opérationnelle, nous travaillons à la mise en place de garanties supplémentaires pour prévenir de futurs incidents. »

Cette déclaration appelle plusieurs remarques. D’une part, l’absence avérée de compromission n’est pas prouvée - les clés AWS sont restées valides 48 heures après la suppression du repository, laissant une fenêtre d’exploitation considérable. D’autre part, la formulation « nous travaillons à mettre en place des garanties supplémentaires » suggère que les contrôles en place n’étaient pas suffisants, ce qui soulève des interrogations sur la gouvernance de sécurité des contractors au sein de l’agence.

Ce que cet incident révèle sur la sécurité des contractors fédéraux

Un problème systémique, pas un cas isolé

La fuite de Nightwing n’est pas un accident isolée. Elle s’inscrit dans un pattern récurrent de problèmes de sécurité liés aux contractors gouvernementaux. Les fuites massives de données éducatives, comme celle d’Instructure par le groupe ShinyHunters, illustrent la vulnérabilité des systèmes tiers face aux cybermenaces. En 2024, un rapport du Senate Armed Services Committee estimait que plus de 40 % des violations de données fédérales impliquaient des acteurs tiers ou des contractors avec accès aux systèmes critiques. La surface d’attaque extension due aux prestataires esterni est considérable, et les mécanismes de contrôle restent insuffisants face à l’ampleur du problème.

Les experts s’accordent à dire que le cadre FedRAMP (Federal Risk and Authorization Management Program), qui encadre l’évaluation et l’autorisation des services cloud pour le gouvernement fédéral, ne couvre pas entièrement les pratiques de développement et de gestion des credentials des contractors. Un système peut être autorisé FedRAMP tout en laissant ses développeurs stocker des secrets en clair dans des repositories GitHub publics.

La question de la détection et du temps de réponse

Un aspect particulièrement préoccupant de cet incident concerne la durée de l’exposition. Le repository « Private-CISA » a été créé le 13 novembre 2025 et est resté public pendant environ six mois avant d’être découvert. GitGuardian pratique la détection automatique de secrets dans les repositories publics depuis des années, mais la découverte reste-conditionnée à la capacité de scanner l’intégralité de la plateforme GitHub. Ce délai de détection pose une question essentielle : combien d’autres repositories similaires existent dans l’ombre, avec des credentials toujours valides ?

Leçons et recommandations pour les organisations gérant des credentials sensibles

1. Implémenter une politique stricte de gestion des secrets

Toute organisation manipulant des credentials sensibles - qu’il s’agisse d’une agence gouvernementale ou d’une entreprise privée - doit-imposer des politiques de secret management centralisées. Des solutions comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault permettent de stocker et de distribuer des credentials de manière sécurisée, avec rotation automatique et journalisation des accès. L’utilisation de fichiers CSV avec des mots de passe en clair pour stocker des identifiants devrait constituer une violation disciplinaire.

2. Activer et enforce les protections GitHub

GitHub propose nativement des fonctionnalités de secret scanning et de push protection qui bloquent automatiquement le poussage de credentials dans les repositories publics. Ces fonctionnalités, activées par défaut, peuvent être désactivées par les administrateurs de repository - ce qui est exactement ce que le contractor CISA a fait. Les organisations doivent s’assurer que ces protections ne peuvent pas être désactivées au niveau de l’organisation, ou du moins faire l’objet d’un audit approfondi lorsqu’elles le sont.

3. Appliquer le principe du moindre privilège

Les credentials exposés dans l’incident CISA donnaient un accès administrateur complet à plusieurs comptes AWS GovCloud. Une application rigoureuse du principe du moindre privilège (least privilege) aurait limité les permissions au strict nécessaire pour chaque tâche, réduisant considérablement l’impact d’une éventuelle fuite. Les rôles IAM (Identity and Access Management) doivent être définis avec granularité, et les credentials à privilège élevé doivent être régulièrement tournés.

4. Surveiller les Patterns de synchronisation à risque

L’utilisation d’un repository GitHub public comme mécanisme de synchronisation entre environnements professionnel et personnel est un signal d’alerte majeur. Les organisations doivent mettre en place des systèmes de détection capable d’identifier des patterns atypiques - comme des commits massifs depuis des appareils non gérer ou des repositories personnels synchronisant des données sensible. L’EDR (Endpoint Detection and Response) et la surveillance des flux réseau peuvent aider à détecter ces comportements.

5. Former et sensibiliser avec des cas réels

La formation traditionnelle en cybersécurité tend à être théorique. Utiliser des cas réels comme celui de CISA-Nightwing dans les programmes de sensibilisation permet de concretiser les risques. Les développeurs doivent comprendre concrètement ce qui se passe lorsqu’un credential est exposé - le délai entre l’exposition et l’exploitation peut être de quelques minutes, pas de quelques mois. Des simulations d’exercices de détection de secrets dans les environnements de test peuvent ancrer les bonnes pratiques.

Impacts potentiels et perspectives

Risque de mouvement latéral

Le scenario le plus inquiétant lié à cette fuite concerne le mouvement latéral potentiel. Les credentials de l’artifactory CISA donnent accès à l’ensemble des paquets logiciels utilisés pour construire les applications de l’agence. Un attaquant ayant validé ces identifiants pourrait, en théorie, introduire du code malveillant dans des dépendances logicielles, compromettant potentiellement chaque nouveau déploiement de l’agence. Cette technique, connue sous le nom de « dependency confusion » ou « supply chain attack », a été documentée dans de nombreux incidents ces dernières années. Les chercheurs ont également documenté comment les ransomgiciels désactivent activement les outils de sécurité pour maximiser leur impact.

Implications pour les audits de sécurité fédéraux

Cet incident est susceptible de provoquer un réexamen des protocoles d’audit des contractors gouvernementaux. Les audits de conformité actuels se concentrent souvent sur les aspects techniques de la configuration cloud (chiffrement au repos, contrôle d’accès réseau, journalisation) mais accordent moins d’attention aux pratiques de développement quotidiennes des équipes techniques. L’intégration de vérifications de sécurité des pratiques Git et de gestion des secrets dans les cycles d’audit pourrait devenir une exigence.

Vers une responsabilisation accrue des contractors

Le cadre contractuel des agencies fédérales américaines inclut déjà des clauses de sécurité, mais la enforceabilité de ces clauses reste inégale. Des voix s’élèvent pour demander l’inclusion de pénalités contractuelles plus strictes en cas de négligence avérée dans la gestion des credentials, ainsi que des mécanismes de détection automatique des violations contractuelles liés à la sécurité.

Conclusion : quand celui qui surveille la maison laisse sa clé sous le paillasson

L’incident CISA-Nightwing est un rappel brutal que la sécurité d’un système se mesure à son maillon le plus faible - et que ce maillon est souvent humain. Un contractor, probablement animé par des intentions pratiques (synchroniser ses fichiers entre son poste professionnel et son ordinateur personnel), a exposé les clés d’accès aux environnements les plus sensibles du gouvernement américain pendant plusieurs mois. Les mécanismes de détection ont failli, les politiques de sécurité ont été contournées, et les credentials exposés sont restés valides bien après l’alerte.

Ce qui rend cet incident particulièrement significatif, c’est son contexte : l’agence concernée est la CISA, celle-là même qui publie des recommandations de sécurité et coordonne la réponse aux cyberattaques contre les infrastructures critiques des États-Unis. Si les pratiques de sécurité d’un contractor CISA peuvent être à ce point défaillantes, cela pose des questions sur l’état réel de la maturité cybersécurité à travers l’écosystème des contractors fédéraux.

Les organisations qui gèrent des credentials sensibles - cloud, systèmes internes, outils de développement - doivent tirer les leçons de cet incident. La détection proactive des secrets exposés, l’enforcement des protections au niveau organisationnel, et la formation continue des équipes techniques ne sont plus des options. Elles constituent le minimum indispensable pour éviter de figurer dans la prochaine liste des fuites historiques.

En définitive, la question n’est pas de savoir si un incident similaire se reproduira, mais de savoir si les mesures préventives seront mises en place à temps pour éviter qu’il ne se transforme en catastrophe. La sécurité cybernétique n’est pas un état, c’est un processus - et ce processus doit commencer par une gestion rigoureuse des clés qui ouvrent les portes les plus critiques.