Fuite GitHub de la CISA : 844 Mo de clés cloud gouvernementales exposées pendant six mois

Le dépôt qui n’aurait jamais dû exister

Le 14 mai 2026, Guillaume Valadon, chercheur chez GitGuardian, a signalé un dépôt GitHub public nommé « Private-CISA. » Le nom était trompeur : le dépôt était entièrement public et accessible depuis le 13 novembre 2025 — soit environ six mois.

Il contenait 844 Mo de données qui n’auraient jamais dû quitter un environnement fédéral sécurisé : des clés de compte AWS GovCloud de niveau administrateur stockées dans un fichier littéralement intitulé « importantAWStokens », des mots de passe en clair dans un fichier CSV nommé « AWS-Workspace-Firefox-Passwords.csv », un fichier de configuration de cluster Kubernetes (kube-config.txt), des clés SSH, des certificats SAML Entra ID, des journaux de build CI/CD, des workflows de déploiement et du code d’infrastructure Terraform.

Le dépôt appartenait à un employé de Nightwing, un sous-traitant gouvernemental basé à Dulles, en Virginie, selon Krebs on Security. Le sous-traitant utilisait apparemment un compte GitHub personnel comme « brouillon de travail », mêlant une adresse e-mail d’entreprise émise par la CISA avec une adresse Yahoo personnelle dans le même historique Git — créant ainsi un pont documenté entre un environnement fédéral classifié et un service cloud personnel non surveillé. Nightwing a refusé de commenter.

Le système de surveillance automatisé de GitGuardian avait déjà envoyé neuf e-mails d’alerte à l’auteur des commits avant l’escalade de Valadon. Aucune action n’a été prise. CyberScoop a rapporté que le dépôt a été mis hors ligne vers 18h00 EST le 15 mai 2026 — environ 26 heures après la notification directe de GitGuardian à la CISA.

Ce qui se trouvait réellement dedans — et pourquoi c’est grave

Le contenu du dépôt « Private-CISA » est plus qu’une simple imprudence d’un sous-traitant. Pris dans leur ensemble, ces éléments dressent une cartographie précise de l’architecture cloud interne de la CISA.

Les clés AWS GovCloud étaient de niveau administrateur — le détenteur pouvait provisionner, modifier ou supprimer des ressources cloud à volonté. Les manifestes Kubernetes donnaient à quiconque les consultait une image détaillée de la topologie d’orchestration des conteneurs de la CISA. Les journaux CI/CD et les workflows GitHub Actions révélaient comment la CISA construit et déploie ses logiciels en interne, y compris les dépendances de pipeline et les points d’intégration. Les identifiants Artifactory — un dépôt privé d’artefacts logiciels — auraient permis un mouvement latéral plus profond dans la chaîne d’approvisionnement logicielle de la CISA.

Le plus inquiétant était peut-être ce que révélaient les mots de passe eux-mêmes. Cybersecurity News a rapporté que de nombreux identifiants suivaient le schéma « nom de la plateforme + année en cours » — par exemple « AWS2026 ». C’est précisément la structure de credentials prévisible que les attaques automatisées de force brute et de credential stuffing sont conçues pour exploiter. Le sous-traitant avait également délibérément désactivé la protection native de GitHub contre les secrets, une fonctionnalité qui aurait signalé ou bloqué la publication des identifiants. Désactiver cette protection nécessite un choix actif — cela ne se produit pas accidentellement.

Le délai de 48 heures pour faire pivoter les clés AWS GovCloud exposées après la suppression du dépôt constitue une défaillance supplémentaire et aggravante. Akeyless a documenté que les clés sont restées valides deux jours complets après la suppression, ce qui signifie que quiconque avait copié les identifiants pendant les six mois d’exposition continuait à disposer d’un accès actif bien après la remédiation de l’exposition principale.

Ce que les RSSI et les équipes de sécurité doivent faire

L’incident de la CISA est un composite d’au moins cinq défaillances distinctes, chacune pouvant être prévenue indépendamment. Les comprendre séparément est ce qui transforme un article de presse en liste de contrôle opérationnelle.

1. Traiter les credentials statiques à longue durée de vie comme un défaut de conception, pas un problème de politique

La leçon la plus profonde est architecturale. Le sous-traitant avait un fichier nommé « importantAWStokens » parce que le système émettait des identifiants sous une forme qui pouvait être stockée et déposée. Les credentials cloud statiques à longue durée de vie — clés API qui n’expirent pas, clés SSH stockées dans des fichiers — sont la catégorie de secret la plus susceptible d’apparaître dans des dépôts GitHub, des messages Slack et des journaux d’incidents.

L’alternative n’est pas « une meilleure formation. » Ce sont des systèmes qui n’émettent pas du tout de secrets statiques. AWS IAM prend en charge les jetons de session à courte durée de vie via STS (Security Token Service) qui expirent entre 15 minutes et 12 heures et ne peuvent pas être réutilisés. Kubernetes prend en charge la fédération d’identité de charge de travail qui lie l’identité d’un pod à un rôle IAM cloud sans que des credentials ne soient jamais écrits sur disque. Les organisations gérant des charges de travail gouvernementales ou réglementées devraient auditer chaque endroit où une clé statique est requise et documenter un plan de migration vers des jetons à courte durée de vie ou l’authentification basée sur OIDC.

2. Déployer la détection des secrets au niveau du push, pas de l’audit

GitGuardian a envoyé neuf alertes automatisées avant qu’un humain n’escalade. Le sous-traitant les a toutes ignorées — et avait désactivé la protection native de GitHub pour s’assurer qu’elles pourraient l’être. C’est un schéma courant : la détection qui se produit après qu’un secret a été commis est réactive, pas préventive. La protection au niveau du push qui bloque un commit avant qu’il n’atteigne le dépôt distant est préventive.

Chaque organisation disposant d’un dépôt de code devrait activer la protection push de GitHub Advanced Security (ou l’équivalent pour GitLab, Bitbucket ou Azure DevOps) et la configurer de manière à ce que les développeurs ne puissent pas la désactiver sans une demande de dérogation explicite journalisée et examinée. La dérogation — et non le blocage — est ce qui devrait générer une alerte vers l’équipe de sécurité. Dans le cas de la CISA, la présence d’un paramètre de protection push désactivé aurait elle-même dû être une anomalie surveillée dans tout audit de gestion des secrets raisonnablement mature.

3. Définir, tester et limiter dans le temps la révocation des credentials comme étape formelle de réponse aux incidents

La fenêtre de 48 heures pendant laquelle les clés AWS GovCloud compromises sont restées valides après la suppression du dépôt est la partie de cet incident qui définira son exposition légale et réglementaire. Pour une agence fédérale, tout système dont les clés étaient accessibles pendant ces 48 heures doit désormais être traité comme potentiellement compromis, nécessitant une révision des journaux forensiques, une analyse des schémas d’accès et une re-certification conditionnelle de ces environnements.

La révocation des credentials doit être une étape nommée et testée dans votre guide de réponse aux incidents — pas un « quelqu’un va faire la rotation » informel. Le test devrait inclure un exercice de simulation où un credential est signalé compromis et l’équipe doit le révoquer et le remplacer dans un délai défini. La norme NIST 800-61r3 recommande que la rotation des credentials soit effectuée dans l’heure pour les systèmes à fort impact. La réponse de la CISA a pris 48 heures. Les équipes de sécurité devraient mesurer et publier leur propre délai moyen de révocation comme indicateur clé de performance.

4. Appliquer la séparation d’identité des sous-traitants au niveau du dépôt

Le « pont » qui a permis cet incident était structurel : un sous-traitant fédéral a mêlé une adresse e-mail gouvernementale avec une adresse Yahoo personnelle dans le même historique Git, et a utilisé un compte GitHub personnel pour stocker des travaux gouvernementaux. Ni le processus d’intégration de la CISA ni les procédures de gestion des sous-traitants de Nightwing ne semblent avoir imposé une séparation au niveau des dépôts.

GitHub Enterprise prend en charge des politiques de vérification d’identité qui exigent que les commits soient signés par une identité émise par l’organisation. Tout dépôt touchant à l’infrastructure gouvernementale devrait appliquer cette politique. Les contrats avec les sous-traitants devraient inclure des clauses explicites interdisant l’utilisation de comptes de dépôt personnels pour tout code ou configuration lié au travail, avec des dispositions d’audit. Dans un contexte gouvernemental, ces clauses ont un poids juridique en vertu des dispositions de sécurité du Federal Acquisition Regulation (FAR).

La vue d’ensemble : réductions d’effectifs et dette de sécurité

Le Congrès a réagi immédiatement. Le représentant Bennie Thompson et la représentante Delia Ramirez de la Commission de la sécurité intérieure de la Chambre ont envoyé une lettre le 26 mai 2026 demandant un briefing au niveau du personnel sur « comment cette grave défaillance de sécurité s’est produite, les conséquences potentielles pour la sécurité, les activités de remédiation, les mesures correctives concernant le personnel sous-traitant impliqué. » La sénatrice Maggie Hassan a envoyé une lettre séparée le même jour.

Les deux lettres faisaient référence à quelque chose que le rapport de Krebs on Security notait également : la CISA a perdu environ un tiers de ses effectifs depuis début 2025, à travers une combinaison de départs à la retraite, de rachats volontaires et de démissions dans le contexte des pressions budgétaires fédérales. Hassan a écrit : « Cet incident soulève de sérieuses questions sur la façon dont une telle défaillance de sécurité a pu se produire à l’agence même chargée d’aider à prévenir les cyberattaques. »

Ce cadrage pointe vers une dynamique structurelle qui dépasse largement un seul commit imprudent d’un sous-traitant. Lorsqu’une organisation perd un tiers de ses effectifs dans un délai compressé, trois choses se produisent simultanément : les connaissances institutionnelles des procédures d’exploitation sécurisées partent avec les employés expérimentés ; la supervision du personnel sous-traitant — qui doit combler les lacunes — devient plus mince et moins rigoureuse ; et le contrat psychologique qui empêche les ingénieurs de prendre des raccourcis sur leur hygiène de sécurité personnelle s’érode. Le sous-traitant qui a désactivé la protection push de GitHub n’opérait pas dans un environnement bien supervisé.

Questions Fréquemment Posées

Sources et lectures complémentaires

• CISA Admin Leaked AWS GovCloud Keys on GitHub — Krebs on Security
• How We Got a CISA GitHub Leak Taken Down in Under a Day — GitGuardian Blog
• CISA Credential Leak Raises Alarms, and Capitol Hill Demands Answers — CyberScoop
• CISA’s GitHub Leak Exposed a Static Secrets Problem — Akeyless
• CISA Admin Exposes AWS GovCloud Credentials on Public GitHub Repository — Cybersecurity News