CISA et la fuite de credentials sur GitHub : six mois d’exposition et un système de signalement défaillant

Introduction

La Cybersecurity and Infrastructure Security Agency (CISA), l’agence fédérale américaine chargée de protéger les infrastructures critiques du pays, a été le théâtre d’un grave incident de sécurité interne. Un prestataire externe (contractor) a publié sur un dépôt GitHub public environ 844 Mo de données sensibles, dont des clés d’administrateur pour des serveurs cloud gouvernementaux et des mots de passe en clair. L’exposition est restée active pendant plus de six mois, malgré neuf alertes automatiques envoyées par le système de scan GitGuardian, et n’a cessé qu’après l’intervention directe du journaliste d’investigation Brian Krebs. L’épisode, bien que sans compromission effective, illustre de manière emblématique comment même l’organisation symbole de la cybersécurité peut trébucher sur des processus internes inadaptés.

Analyse technique

Le dépôt incriminé, significativement baptisé « Private CISA », contenait des fichiers internes non protégés totalisant 844 Mo. Dans le détail, on y trouvait :

• des credentials avec des privilèges administratifs pour trois serveurs AWS GovCloud, la plateforme cloud dédiée aux charges de travail du gouvernement américain ;
• un fichier CSV avec des dizaines de noms d’utilisateur et de mots de passe en clair pour des systèmes internes de la CISA.

GitGuardian, le service de scan automatique des secrets utilisé par l’agence, avait détecté la fuite et envoyé neuf notifications au cours du semestre. Malheureusement, celles-ci étaient arrivées dans un canal de signalement inadapté, probablement lié aux processus de traitement des vulnérabilités produit, et n’avaient reçu aucune réponse. La situation s’est débloquée en mai 2026, lorsque Brian Krebs (KrebsOnSecurity) – après avoir analysé le dépôt – a contacté personnellement les dirigeants de la CISA.

La phase de confinement a exigé plus de 48 heures à compter de la notification : un délai inhabituellement long, dû à la nécessité de renouveler de manière sécurisée toutes les clés compromises et de gérer les nombreuses interconnexions avec des partenaires fédéraux et industriels qui utilisaient les mêmes credentials. L’enquête qui a suivi, étayée par des logs étendus et une architecture zero‑trust déjà opérationnelle, a permis d’exclure tout accès externe non autorisé, confirmant qu’aucune donnée de mission ou de client n’avait été compromise.

Impact

Bien qu’il n’y ait pas eu de dommage matériel immédiat, le risque potentiel a été jugé « élevé » : des clés administratives d’environnements gouvernementaux auraient pu être exploitées pour se déplacer latéralement au sein de l’infrastructure fédérale ou pour exfiltrer des données sensibles.

L’impact le plus immédiat a été de nature réputationnelle. L’agence qui rédige les directives de cybersécurité pour la nation a montré des vulnérabilités élémentaires – des mots de passe en clair sur un dépôt public – et, plus grave encore, a révélé l’absence d’un canal efficace pour les signalements concernant sa propre sécurité interne. La rotation exceptionnelle des credentials a en outre entraîné un ralentissement opérationnel significatif, avec la consommation de ressources et d’heures de travail pour rétablir le plein fonctionnement.

Atténuation

La CISA a publié une analyse post‑mortem transparente et a formulé plusieurs recommandations, applicables bien au‑delà du périmètre gouvernemental :

• Scan continu et intégré : les systèmes de détection des secrets (comme GitGuardian) doivent générer des alertes acheminées directement dans les flux de réponse aux incidents, avec des métriques de prise en charge et de réponse immédiate.
• Canaux de signalement séparés et visibles : il faut distinguer clairement les points de contact pour les vulnérabilités de produit de ceux pour les incidents internes. Les instructions doivent être publiées sur le fichier security.txt, sur les portails d’entreprise et sur chaque interface publique, avec des processus empêchant un aiguillage erroné.
• Rotation des clés rapide et automatisée : les plans de révocation et de renouvellement des credentials doivent être testés régulièrement et inclure les scénarios impliquant des partenaires externes, afin de réduire les temps de réaction.
• Playbooks dédiés : définir des procédures spécifiques pour les fuites de credentials sur des plateformes comme GitHub, en les intégrant au système de gestion des incidents.
• Zero‑trust et journalisation étendue : l’architecture de confiance zéro a démontré son efficacité pour contenir l’incident. Étendre l’enregistrement des activités et appliquer les principes de moindre privilège reste une défense cruciale.
• Formation obligatoire pour les prestataires : les collaborateurs externes doivent être liés contractuellement à la protection des secrets et formés aux politiques de publication de code, avec des vérifications automatiques avant chaque commit public.

FAQ

1. Comment l’incident a‑t‑il été découvert, étant donné que GitGuardian avait déjà envoyé plusieurs alertes ?
Bien que GitGuardian ait généré neuf notifications en l’espace de six mois, ces signalements n’ont pas été pris en compte car ils étaient dirigés vers un canal conçu pour les vulnérabilités de produit, et non pour les incidents internes. La prise de conscience réelle n’a eu lieu que lorsque le journaliste Brian Krebs a signalé manuellement le dépôt aux dirigeants de la CISA.

2. Y a‑t‑il eu des accès non autorisés aux serveurs AWS GovCloud ou à d’autres systèmes de la CISA ?
D’après les investigations menées à l’aide des logs et des contrôles zero‑trust, aucun accès externe abusif n’a été détecté. Les données de mission et les informations des clients sont restées intègres. Cependant, la fenêtre de six mois aurait pu permettre à un attaquant de se déplacer sans être découvert si les mesures de confinement n’avaient pas été en place.

3. Qu’est‑ce qui va changer à la CISA après cet incident ?
L’agence a complètement revu son système de réception des signalements externes, en séparant les flux dédiés aux vulnérabilités des produits de ceux pour les urgences internes. Elle a également renforcé les politiques de scan automatique, introduit des playbooks spécifiques à GitHub et rendu obligatoire une formation plus rigoureuse pour les prestataires, afin de prévenir la publication accidentelle de données sensibles.