« Ce type d’exposition se produit à une fréquence alarmante », a déclaré un expert ; voici ce que les OSC et les DSI devraient faire pour protéger les référentiels GitHub des employés et des sous-traitants.
Jusqu’à il y a quelques jours, un référentiel GitHub accessible au public exposait les informations d’identification des comptes AWS du gouvernement américain et des systèmes internes de la Cybersecurity and Infrastructure Security Agency (CISA).
C’est ce qu’affirme le journaliste en cybersécurité Brian Krebs, qui a annoncé la nouvelle pour la première fois ce week-end, agissant sur les conseils du chercheur Guillaume Valadon de GitGuardian.
Sur la base de l’historique des validations du référentiel et des notes de dépannage du créateur du compte, réintégrées dans le référentiel, Valadon pense que le référentiel a été géré par un sous-traitant de CISA qui l’a créé sur son compte GitHub personnel.
« Il s’agit d’une grave violation des contrôles de sécurité, car les secrets sont stockés en texte brut et transmis à Git au lieu d’être récupérés auprès d’un gestionnaire de secrets au moment de l’exécution », a-t-il écrit, « et parce que les documents internes destinés à rester privés ont été transférés vers un référentiel public au sein d’un compte de développeur personnel. »
GitGuardian est un service français dont les produits analysent les sources internes et externes, y compris GitHub, à la recherche de secrets révélés.
Le 14 mai, il a trouvé un référentiel GitHub public nommé « Private-CISA ». Le référentiel, opérationnel depuis le 13 novembre 2025, contenait 844 Mo de données, notamment des fichiers Kubernetes, des flux de travail GitHub Actions, des sauvegardes de documentation interne, des documents personnels et des scripts opérationnels, des mots de passe en texte brut, des jetons AWS et des jetons d’accès GitHub.
La bonne nouvelle : les données des événements GitHub indiquent que le référentiel n’a jamais été bifurqué, a déclaré Valadon, « ce qui a limité le rayon d’explosion ».
La mauvaise nouvelle : le propriétaire du compte n’a pas répondu immédiatement au message d’avertissement de Valadon, c’est pourquoi il s’est adressé à Krebs.
Valadon a également signalé la fuite au centre de coordination de l’équipe d’intervention en cas d’urgence informatique (CERT/CC), basé aux États-Unis, le 14 mai, et a contacté le lendemain la CISA. Le référentiel était hors ligne cette nuit-là. « Je dois leur attribuer le mérite (CISA) d’avoir supprimé ce référentiel rapidement », a déclaré Valadon. « La plupart de nos divulgations responsables prennent beaucoup plus de temps, et beaucoup ne sont jamais corrigées. Parvenir à mettre le référentiel hors ligne en une journée est un travail impressionnant. »
« J’ai travaillé neuf ans à l’ANSSI (l’équivalent français de la CISA) », a ajouté Valadon, « et maintenant, confronté quotidiennement à des fuites chez GitGuardian, c’est définitivement l’une des pires que j’ai jamais vues. »
Invité à commenter, un porte-parole de la CISA a déclaré dans un courrier électronique que l’agence était au courant de l’exposition signalée et qu’elle poursuivait son enquête sur la situation. « Actuellement, rien n’indique que des données sensibles aient été compromises à la suite de cet incident », ont-ils écrit. « Tout en exigeant que les membres de notre équipe respectent les normes d’intégrité et de conscience opérationnelle les plus élevées, nous nous efforçons de garantir que des mesures de protection supplémentaires soient mises en œuvre pour prévenir de futurs événements. »
Il existe de nombreux problèmes de sécurité graves avec les référentiels GitHub, allant des faux référentiels créés par des acteurs malveillants aux comptes légitimes créés à tort avec un accès public. Et le mois dernier, des chercheurs de Wiz ont découvert une vulnérabilité d’injection dans l’infrastructure interne de Git qui aurait pu permettre aux pirates d’exécuter des commandes arbitraires sur les serveurs backend de GitHub.
Dans le cas présent, le problème est humain ; Les référentiels GitHub peuvent contenir une gamme de secrets, tels que des jetons et des informations d’identification inclus par les créateurs de comptes, c’est pourquoi les utilisateurs doivent mettre en œuvre les protections étendues et les meilleures pratiques de sécurité de GitHub, notamment en limitant l’accès au référentiel.
Contenu connexe : Comptes GitHub ciblés par de fausses alertes de sécurité
Ce que les OSC et les DSI devraient faire
Révéler des secrets sur GitHub « est un problème grave et malheureusement courant », a commenté Johannes Ullrich, doyen de la recherche à l’Institut SANS.
Mais, a-t-il ajouté, le service informatique peut prendre plusieurs mesures pour éviter cela. Premièrement, les secrets tels que les mots de passe et les clés API doivent être gérés de manière centralisée. Un processus de gestion des secrets à l’échelle de l’entreprise n’est pas facile à mettre en œuvre, a-t-il reconnu, « mais c’est également votre meilleur pari pour éviter que les secrets ne soient traités de manière inappropriée ».
Deuxièmement, utilisez des outils qui analysent de manière proactive les systèmes des utilisateurs et les services publics tels que GitHub à la recherche de clés exposées. « Ces produits sont essentiels pour faire respecter toute politique régissant le traitement sécurisé des secrets », a déclaré Ullrich.
« Dans ce cas particulier, la faute semble être imputable à un entrepreneur, et non à CISA elle-même », a-t-il noté. « La gestion des relations avec les fournisseurs est importante et doit inclure des accords sur la manière de gérer les secrets utilisés pour accéder aux systèmes et données internes. »
Le consultant chevronné Robert Enderle du groupe Enderle a noté que ce type d’exposition se produit à une fréquence alarmante. « Les développeurs sont souvent soumis à une pression immense pour fournir du code rapidement », a-t-il déclaré, « et les frontières entre les référentiels personnels et professionnels peuvent facilement s’estomper. Cependant, pour un entrepreneur lié à la CISA – l’agence même chargée de défendre notre infrastructure nationale – les retombées potentielles sont catastrophiques. Laisser les informations d’identification exposées dans un référentiel GitHub public équivaut à laisser les clés principales des cyberdéfenses du pays sur un banc public. Si ces informations d’identification avaient été exploitées par un acteur étatique, cela aurait pu faciliter une attaque massive de la chaîne d’approvisionnement ou une infiltration profonde dans les systèmes gouvernementaux critiques.
