Sur Docker Hub, des milliers de secrets compromis font courir des risques aux entreprises

La place des secrets dans le SDLC moderne

Dans le cycle de vie du développement logiciel (SDLC) des organisations modernes, les secrets constituent le tissu conjonctif de la chaîne d'approvisionnement numérique. Ils permettent l'authentification, l'automatisation, la communication inter-services et la confiance machine-à-machine à travers les fournisseurs de cloud, les pipelines CI/CD, les plateformes de messagerie et les outils de développement. 

De la mise en place de l'infrastructure à la publication des artefacts, tout repose sur des clés, des jetons et des certificats. Avec l'adoption par les entreprises des microservices, des infrastructures éphémères, des architectures sans serveur et des modèles de développement fédérés, le nombre de secrets en circulation a explosé. 

Une seule application peut nécessiter des dizaines de clés API provenant de fournisseurs tels qu'AWS, GitHub, Slack, Stripe, GCP, et de services internes, etc. Souvent, ces identifiants restent valides longtemps après qu'un développeur a quitté le projet ou l'organisation.

Mais si les secrets sont essentiels à l'automatisation, ils sont aussi dangereusement fragiles. Leur pouvoir dépasse souvent leur visibilité. De nombreuses organisations possèdent des milliers de secrets actifs qui ne sont jamais audités, analysés, renouvelés ni gérés de manière centralisée. En pratique, les secrets se retrouvent dispersés à travers :

• code source
• fichiers de configuration
• ordinateurs portables de développeur
• construire des pipelines
• image de conteneur
• comptes cloud personnels

Certains de ces secrets peuvent permettre de contrôler en profondeur les environnements de production, les comptes cloud, voire le cœur même d'une entreprise. Il en résulte une faille de sécurité permettant, grâce à un simple jeton exposé, de contourner l'authentification multifacteur, les défenses périmétriques et d'obtenir un accès privilégié direct aux systèmes de production. En résumé, les secrets sont à la fois le lubrifiant de l'ingénierie moderne et le talon d'Achille de la sécurité organisationnelle : faciles à utiliser, faciles à oublier et dévastateurs en cas de divulgation.

Scénarios d'attaque et impact potentiel

Ces incidents, largement médiatisés, présentent une constante : les attaquants n'ont pas besoin d'exploiter des failles zero-day ni de contourner des systèmes de chiffrement sophistiqués. Ils attendent simplement que les organisations divulguent leurs propres secrets, puis utilisent ces identifiants pour s'introduire directement dans les dépôts de code, les flux d'intégration continue, voire les comptes cloud de production. 

Qu’il s’agisse de Shai-Hulud récoltant des jetons de développeur à partir de packages compromis, d’une action GitHub avec porte dérobée récupérant des secrets CI/CD, ou d’entreprises comme Microsoft et Toyota publiant accidentellement des identifiants cloud dans des dépôts publics, le problème sous-jacent est le même : les secrets sont traités comme statiques et immortels plutôt que dynamiques et éphémères, et la détection automatisée des fuites d’identifiants au moment de leur exposition est insuffisante. 

Ce modèle illustre que les violations actuelles des chaînes d'approvisionnement et du cloud ne sont pas aléatoires ; elles sont structurellement prévisibles, évitables et se propagent par le maillon le plus faible : l'hygiène des identifiants.

Diagramme d'exploitation de la vulnérabilité de Docker Hub

Le ver NPM Shai-Hulud 2.0

Shai-Hulud 1.0 a commencé comme un ver malveillant de la chaîne d'approvisionnement NPM qui infectait les packages légitimes avec des scripts post-installation pour voler des secrets de développeur et se propager en utilisant des identifiants NPM/GitHub compromis, poussant du code malveillant dans les écosystèmes en aval et rendant publics les dépôts privés. 

Les défenseurs ont initialement atténué les dégâts en vidant les caches, en faisant tourner les identifiants et en inspectant l'activité GitHub – mais Shai-Hulud 2.0, lancé en novembre 2025, a introduit des capacités beaucoup plus avancées : déplacement de l'exécution vers des scripts de préinstallation, utilisation de charges utiles basées sur Bun pour échapper à la détection, passage à l'échelle pour des centaines de paquets compromis et des dizaines de milliers de dépôts, amélioration de l'exfiltration secrète via la création de dépôts GitHub publics et réalisation d'une propagation latérale entre victimes. 

Cette évolution a transformé Shai-Hulud, d'un astucieux collecteur de certificats, en un ver informatique mondial des chaînes d'approvisionnement extrêmement adaptable. En savoir plus.

Actions GitHub tj-actions/changed-files Rupture de la chaîne d'approvisionnement

À la mi-mars 2025, une faille de sécurité massive dans la chaîne d'approvisionnement a touché GitHub lorsqu'une action GitHub populaire, tj-actions/changed-files, a été modifiée et introduite par une porte dérobée pour imprimer des secrets CI/CD (PAT, clés, jetons de registre, identifiants cloud, etc.) directement dans les journaux de flux de travail, les exfiltrant silencieusement à travers des milliers de pipelines. 

Les enquêteurs ont par la suite établi que la faille provenait d'un jeton d'accès personnel SpotBugs divulgué. Les attaquants ont exploité cette vulnérabilité via un flux de travail vulnérable pour obtenir un accès en écriture, élever leurs privilèges et se déplacer à travers les dépôts et actions dépendants. Le fait que la campagne se soit initialement concentrée sur l'agentkit open source de Coinbase illustre la stratégie des attaquants : compromettre un maillon CI/CD critique, collecter des secrets à grande échelle et exploiter l'infrastructure SDLC exposée pour permettre des intrusions plus profondes en aval.

Ceci illustre comment une simple clé peut être exploitée par des attaquants pour avoir un impact considérable sur l'ensemble de l'écosystème de développement. Plus d'informations En savoir plus.

Fuite de clés SAS Microsoft Azure – Accès non autorisé à des données d'IA internes

En 2023-2024, Microsoft a été confronté à une importante faille de sécurité dans son cloud lorsqu'un dépôt GitHub contenait par inadvertance un jeton Azure SAS (Shared Access Signature) largement permissif accordant un accès complet aux comptes de stockage internes utilisés pour les données d'entraînement de l'IA. 

Ce jeton permettait à quiconque le trouvait de consulter des ensembles de données privés, de télécharger des documents confidentiels, et même de modifier des conteneurs de stockage et des objets blob au sein de l'environnement Azure de Microsoft. Cette faille a contraint Microsoft à renouveler rapidement les identifiants d'accès compromis et à mettre en œuvre des contrôles internes plus stricts concernant l'analyse des référentiels, la gestion des secrets et la gouvernance des clés afin de prévenir toute fuite future.

Exposition des identifiants AWS de Toyota – Des années d'accès silencieux au cloud

Au cours de la même période, Toyota a connu sa propre faille de sécurité dommageable dans le cloud lorsque des identifiants AWS ont été accidentellement envoyés vers un dépôt GitHub public, accordant involontairement l'accès à son système télématique embarqué dans le cloud. 

Des pirates ont utilisé ces clés pour accéder aux données de plus de 2 millions de propriétaires de véhicules Toyota, notamment des données de télémétrie de géolocalisation, des informations GPS et des enregistrements relatifs à la sécurité. La clé serait restée valide pendant des années, ce qui signifie que cette faille a probablement permis un accès non autorisé persistant et a mis en lumière des défaillances systémiques en matière de gestion des identifiants au sein du cycle de vie du développement logiciel (SDLC) et de la sécurité du cloud de Toyota.

Méthodologie de la recherche

Nous avons défini 15 types de secrets distincts couvrant le cycle de vie du développement logiciel (SDLC), les identifiants d'infrastructure cloud et les jetons d'accès aux modèles d'IA. Ces types clés ont été initialement choisis comme échantillons représentatifs (non exhaustifs), et nos recherches nous ont rapidement permis d'élargir cette liste à des centaines, voire des milliers, d'autres types d'identifiants exposés et en circulation. 

En fait, nos découvertes ont directement enrichi nos modèles de détection et amélioré notre capacité à découvrir et à contextualiser d'autres secrets révélés.

Voici la liste précise des principaux types sur lesquels nous nous sommes concentrés :

1. Certifications SDLC et contrôle de version :
   GITHUB_TOKEN, BITBUCKET_APP_PASSWORD, ECR_SECRET_ACCESS_KEY, NPM_TOKEN, PYPI_API_TOKEN
2. Identifiants du fournisseur de services cloud :
   AWS_SECRET_ACCESS_KEY, GOOGLE_OAUTH_ACCESS_TOKEN, AZURE_CLIENT_SECRET

Jetons d'accès à l'IA et aux modèles :
OPENAI_API_KEY, OPENAI_TOKEN, HF_TOKEN, HUGGINGFACE_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, GROQ_API_KEY

Toutes les analyses ont été effectuées sur des images de conteneurs Docker Hub téléchargées au cours du mois précédent (du 1er au 30 novembre 2025). Au total, nous avons identifié 10 456 images de conteneurs contenant une ou plusieurs clés exposées. Après avoir filtré les résultats de gravité inférieure à Élevée et Critique, il nous restait : 205 espaces de noms distincts sur Docker Hub.

Nous avons choisi Docker Hub car nous utilisons une approche de double indexation :

1. Nous indexons les manifestes Docker Hub, à l'instar d'autres organisations.
2. Nous extrayons et décompressons également les images de conteneurs, extrayons les fichiers et les analysons à la recherche de données sensibles, puis indexons ces résultats. À notre connaissance, aucun autre fournisseur n'effectue une extraction approfondie au niveau des fichiers et une analyse des secrets à cette échelle.

Au cours de notre enquête, nous avons analysé les 205 espaces de noms et avons réussi à associer 101 d'entre eux à des entreprises identifiables de tailles diverses, principalement des petites et moyennes entreprises, bien que quelques grandes entreprises et même une organisation Fortune 500 soient apparues dans l'ensemble de données. 

L'identification a été réalisée en corrélant la propriété des espaces de noms avec les entités connues de l'entreprise ; les espaces de noms restants ont été classés comme comptes personnels. Fait intéressant, nous avons constaté plusieurs cas où des fondateurs, des prestataires, des indépendants ou des employés diffusaient des images de conteneurs depuis leurs comptes Docker Hub personnels, exposant ainsi involontairement des informations confidentielles de l'entreprise.

Vous trouverez ci-dessous une ventilation des secteurs d'activité représentés par les 101 entreprises identifiées :

Principaux secteurs d'activité des 101 entreprises exposées

Un constat particulièrement alarmant est apparu lors de l'examen des secrets révélés : Environ 42 % des images de conteneurs divulguées contenaient cinq valeurs sensibles ou plus. Ces expositions à de multiples secrets représentent des risques critiques, car elles donnent souvent un accès complet aux environnements cloud, aux dépôts Git, aux systèmes CI/CD, aux intégrations de paiement et à d'autres composants d'infrastructure essentiels.

Répartition de la taille de l'exposition en fonction du nombre de clés exposées

Vous trouverez ci-dessous une analyse plus détaillée des secrets découverts :

Catégories	Comptes Docker Hub	Sens
AI	191	Grok/Gemini/Anthropic de l'API IA, etc.
CLOUD	127	secrets AWS/Azure/GCP/Cosmos/RDS
BASE DE DONNÉES	89	Identifiants Mongo / Postgres / Neon / ODBC / SQL
ACCÈS	103	JWT / CLÉ_SECRET / CLÉ_APP / chiffrement
JETON_API	157	Clés API génériques tierces
SCM_CI	44	GitHub / Bitbucket / NPM / Docker
COMMUNICATION	31	SMTP / Sendgrid / Brevo / Slack / Telegram
PAIEMENTS	21	Stripe / Razorpay / Cashfree / SEPAY

Une recherche complémentaire comparant les secrets de l'IA a montré qu'en filtrant uniquement sur l'analyse des images Docker Hub du dernier mois (du 1er au 30 novembre 2025) et en ne retenant que les niveaux de gravité élevés et critiques, il y avait près de 4 000 clés d'IA exposé.

De plus, nous avons identifié 10 clés d'accès NPM, dont trois étaient liées à des entreprises de taille moyenne ayant un volume important de téléchargements de packages NPM. 

Identifier une entreprise

• Associer un compte Docker Hub à une entreprise peut être très simple ou impossible, selon les données disponibles et cachées dans le registre. Le plus simple est de consulter les informations sur Docker Hub : il s’agit parfois d’une entreprise, et dans ce cas, on trouve son adresse e-mail, son site web et d’autres informations. 
• Le nom peut être révélateur : il ne s’agit pas d’une entreprise, mais si le nom est « Company X Ltd », cela peut vous orienter vers cette entreprise.
• En approfondissant l'analyse : le processus de validation était beaucoup plus long et rigoureux, s'appuyant sur plusieurs indicateurs clés tels que les noms de domaine, les adresses IP, les espaces de noms et d'autres identifiants intégrés au code. Si notre niveau de confiance était inférieur à 80 % (selon différents facteurs que nous avions définis), l'identité était validée ; sinon, elle était considérée comme inconnue.

Réflexions sur nos conclusions

Nous pouvons classer les résultats concernant l'identité des propriétaires des comptes en trois grandes catégories :

1. Des organisations et des entreprises qui divulguent des secrets
2. Des comptes personnels divulguent des secrets personnels
3. Des comptes personnels divulguent des secrets d'entreprises

Exposition des entreprises

Les flux de travail modernes du cycle de vie du développement logiciel (SDLC) reposent sur un grand nombre de secrets pour prendre en charge des pipelines de développement hautement automatisés et distribués. Les développeurs utilisent couramment des clés cloud, des jetons d'API, des identifiants d'accès aux modèles, des chaînes de connexion aux bases de données et des jetons CI/CD pour permettre une intégration transparente entre les outils et les environnements. Les conteneurs sont devenus la pierre angulaire de cet écosystème, en encapsulant les dépendances, les environnements d'exécution et les microservices dans des unités portables qui circulent entre les phases de développement, de compilation, de test et de production.

Prenons l'exemple concret d'une entreprise spécialisée dans la personnalisation de modèles d'IA pour répondre aux besoins techniques et commerciaux spécifiques de ses clients. Dans ce cas précis, l'entreprise a involontairement divulgué un jeton GitHub en l'intégrant directement dans le manifeste d'un conteneur Docker Hub.

Le jeton GitHub exposé n'était pas restreint, il avait privilèges d'administrateur complets L'attaque concernait l'ensemble des dépôts, organisations et registres de paquets de l'entreprise. Son périmètre d'accès comprenait des permissions à haut risque telles que write:packages, delete:packages, repo, delete_repo, admin:org et même admin:enterprise. Avec un tel niveau d'accès, un attaquant pouvait ajouter ou supprimer des paquets, modifier les pipelines GitHub Actions, supprimer des dépôts et altérer des configurations organisationnelles critiques. En pratique, le jeton conférait un contrôle total et absolu sur le code source, les flux de travail CI/CD, les secrets et les éléments de la chaîne d'approvisionnement.

Les implications vont bien au-delà de l'organisation exposée. Une compromission de cette ampleur pourrait permettre à un attaquant d'accéder initialement aux environnements des clients en aval, notamment ceux qui utilisent des modèles, des packages ou des flux de travail d'automatisation distribués via les dépôts affectés. Autrement dit, un seul jeton divulgué devient un point d'entrée potentiel. multiplicateur de compromis de la chaîne d'approvisionnement avec un impact en cascade sur l'ensemble de l'écosystème client de l'organisation.

Révélation de secrets personnels

Il existe de nombreux exemples de comptes personnels comportant des projets parallèles et des environnements privés. Ces comptes sont généralement caractérisés par la divulgation d'un secret parmi d'autres, exposant ainsi la personne et son infrastructure technologique à des risques importants.

Exposition des liens personnels avec les entreprises

Alors que les registres d'entreprise sont souvent étroitement surveillés à l'aide de scanners de sécurité, d'analyseurs SAST et SCA, et d'autres outils, les comptes externes contenant des informations confidentielles, ou plus précisément les comptes Shadow IT, sont rarement contrôlés. Cela peut entraîner une exposition prolongée des données, sans que l'entreprise ait les connaissances ou la capacité de détecter et de corriger la situation. Voici quelques exemples de cas concrets mis en lumière lors de nos recherches :

Dans un cas précis, nous avons établi une corrélation entre un compte public Docker Hub et le site web d'un développeur indépendant. Ce dernier propose des services de développement web et applicatif aux petites entreprises, selon des projets spécifiques. Le compte Docker Hub contient 70 dépôts ; environ 45 % des images de conteneurs sont mises à jour régulièrement (y compris au cours des 30 derniers jours), environ 35 % ont été mises à jour au cours de l'année écoulée, et le reste est plus ancien.

La structure du conteneur reste la même ; un fichier spécifique du système de fichiers du conteneur contient des dizaines de clés et de secrets de l'environnement.

Normalement, il s'agit d'un accès à un compte cloud (principalement AWS), d'un secret de compartiment S3 donnant accès à l'intégralité des journaux d'activité et des artefacts du projet, d'une base de données (généralement PostgreSQL), des clés et secrets d'API des applications, des clés Google Analytics et des clés OpenAI.

Ce sont toutes des clés de l'organisation ; elles n'appartiennent pas au prestataire indépendant, mais elles sont hors de portée des contrôles et capteurs de sécurité de l'organisation.

Dans un autre cas frappant, nous avons identifié une entreprise du Fortune 500 dont les secrets ont été exposés via un compte Docker Hub public et personnel, appartenant probablement à un employé ou un prestataire. Aucun identifiant visible ne reliait le dépôt à la personne ou à l'organisation, pourtant les manifestes des conteneurs contenaient des identifiants hautement sensibles donnant accès à de multiples environnements internes. Ce cas met en lumière une réalité critique : les organisations sont de plus en plus vulnérables non pas à cause de leur infrastructure officielle et surveillée, mais à cause de dépôts personnels et parallèles qui échappent totalement à la visibilité, à la gouvernance et aux contrôles de sécurité de l'entreprise.

J'ai interviewé un ingénieur DevOps senior qui, depuis plus de dix ans, propose des solutions d'infrastructure et de cycle de vie de développement logiciel (SDLC) sur mesure en tant que freelance. Il a décrit son processus de travail : « Je travaille généralement par l'intermédiaire d'un important prestataire qui fournit des ingénieurs freelance qualifiés à différentes organisations, allant des grandes entreprises technologiques aux jeunes startups. »

Lorsque je lui ai montré un extrait censuré des secrets révélés par nos recherches, il a immédiatement réagi : « Oh, c’est grave. Cela n’arriverait jamais dans les entreprises pour lesquelles je travaille. Elles vous attribuent une identité professionnelle complète et ne fournissent des clés d’accès qu’au sein de leurs environnements sécurisés. Nombre d’entre elles vous livrent même un ordinateur portable professionnel sécurisé avec un VPN obligatoire, une surveillance des terminaux et des contrôles de sécurité stricts. »

Un autre cas mis au jour lors de nos investigations s'est avéré particulièrement préoccupant : un registre de conteneurs appartenant à l'architecte logiciel en chef d'une grande banque nationale. Ce registre contenait des centaines d'images de conteneurs, dont plusieurs incluaient des jetons d'API d'IA exposés. Si la présence de clés liées à l'IA pouvait à elle seule être dommageable, le problème le plus alarmant résidait dans le fait que plus de 430 images de conteneurs associées à la banque étaient accessibles publiquement, sans aucun contrôle d'accès, audit ou validation efficace. Concrètement, cela signifiait que non seulement les projets expérimentaux ou personnels de l'architecte (mais potentiellement des composants d'infrastructure essentiels) étaient exposés sur Internet, créant ainsi une faille de sécurité majeure au sein de l'une des institutions financières les plus critiques du pays.

Explication de ces résultats du point de vue des développeurs/DevOps

Tous les secrets divulgués et décrits ici ont été découverts dans des dépôts publics de Docker Hub. L'exemple suivant illustre un flux de travail de développement typique pour la création et le déploiement d'images de conteneurs Docker, et surtout, les erreurs courantes qui exposent involontairement des informations sensibles.

L'une des erreurs les plus fréquentes que nous avons constatées est l'utilisation d'un fichier « .env » pour stocker les variables d'environnement et les secrets lors du développement local. Les développeurs créent souvent un fichier « .env » contenant les identifiants de base de données, les clés d'accès au cloud, les jetons et autres éléments d'authentification nécessaires à l'exécution du projet. Pour les applications plus importantes, ce fichier peut contenir des dizaines de secrets provenant de multiples intégrations externes. Un répertoire de projet typique pourrait ressembler à ceci :

Voici à quoi peut ressembler le contenu d'un fichier '.env' :

Vous allez ensuite créer une image de conteneur Docker à partir de cela, en utilisant un Dockerfile.

Lors de la copie de l'intégralité du répertoire du projet pendant le processus de construction Docker, le fichier '.env' est souvent inclus involontairement, intégrant ainsi tous ses secrets directement dans le système de fichiers du conteneur. 

Même si l'image résultante est stockée dans un registre privé, cela représente toujours une pratique à haut risque ; une compromission de ce registre exposerait immédiatement ces secrets et permettrait une circulation latérale au sein de l'organisation. 

Un scénario encore plus dangereux se produit lorsqu'une telle image est diffusée, intentionnellement ou non, vers un dépôt public. C'est pourquoi il est essentiel d'analyser et de nettoyer les images de conteneurs afin d'y détecter les données sensibles avant leur publication, qu'elles soient destinées à un usage privé ou public.

Nous avons observé à plusieurs reprises des fuites similaires via d'autres types de fichiers. Par exemple, des fichiers d'application Python contenant des jetons d'API d'IA codés en dur et en clair. Ces identifiants n'étaient ni chiffrés, ni obscurcis, ni protégés d'aucune manière efficace.

Un autre vecteur d'exposition courant que nous avons identifié est la présence de secrets directement dans le Dockerfile. Dans ce cas, les secrets ne sont pas nécessairement contenus dans le conteneur, mais ils restent exposés via le manifeste de l'image et visibles sur Docker Hub, les rendant ainsi accessibles à toute personne consultant les métadonnées de l'image.

Lorsque des secrets sont intégrés dans le Dockerfile ou le contexte du conteneur, ils deviennent souvent visibles directement sur la page Docker Hub, exposés de fait à l'ensemble d'Internet et régulièrement collectés par des scanners automatisés, des bots et des acteurs malveillants cherchant à accéder initialement aux environnements des victimes.

Mais que se passe-t-il lorsque cette divulgation est accidentelle ? Nos recherches montrent qu’environ 25 % des développeurs ont supprimé le secret exposé de leur conteneur ou manifeste dans un délai de 1 à 2 jours. Bien que cette réaction soit encourageante, elle reste insuffisante, car dans la plupart des cas, l’identifiant associé n’a pas été révoqué. Autrement dit, la clé est restée pleinement valide et exploitable même après la « correction » de la fuite visible. Les développeurs pensent souvent que l’incident est résolu simplement parce qu’ils ont supprimé la référence, alors qu’en réalité, le secret lui-même continue de fonctionner et reste en possession des attaquants.

Il est nettement préférable d'éviter complètement d'intégrer des secrets lors de la compilation. Il est conseillé de les injecter uniquement à l'exécution via des variables d'environnement, par exemple :

Cette approche élimine le stockage statique des informations d'identification à l'intérieur du conteneur ou du manifeste, réduisant considérablement le risque d'exposition accidentelle, car les secrets n'existent jamais à l'intérieur du registre ou de l'artefact.

Cartographie de la campagne selon le cadre MITRE ATT&CK

Nos recherches ont démontré comment, par le passé, des attaquants ont exploité des secrets pour s'en prendre aux organisations. Suite à la divulgation de ces secrets, des techniques communes, réelles ou potentielles, ont été mises en œuvre par les attaquants. Nous avons ici associé chaque élément mentionné dans l'article de blog aux techniques correspondantes. Cadre MITRE ATT & CK:

Accès initial	Internationaux	Accès aux informations d'identification	Découverte	Impact
Comptes valides (T1078)	Interpréteur de commandes et de scripts : Windows (T1059.003)	Identifiants non sécurisés (T1552)	Découverte des informations système (T1082)	Destruction de données (T1485)
Compromission de la chaîne d'approvisionnement (T1195)	Interpréteur de commandes et de scripts : Shell Unix (T1059.004)	Identifiants provenant de gestionnaires de mots de passe (T1555)	Découverte de fichiers et de répertoires (T1083)	Chiffrement des données (T1486)
Services externes à distance (T1133)	Interpréteur de commandes et de scripts : Python (T1059.006)	Créer ou modifier un processus système (T1543.002)	Découverte des services cloud (T1082)	Arrêt de service (T1489)
N/D	N/D	N/D	N/D	Détournement de ressources (T1496)

Une solution sur mesure avec une touche d'originalité

Flare indexe de multiples flux de données provenant de domaines open source, du web profond et du dark web, notamment GitHub, Docker Hub et Pastebin. De plus, Flare analyse divers fichiers, compartiments S3 et fichiers Docker Hub au sein des différentes couches de l'image conteneurisée, créant ainsi un ensemble de sources idéal pour identifier d'éventuelles failles de sécurité, qu'elles proviennent du dépôt de l'organisation, d'un prestataire, d'un freelance ou d'un employé.

Le Monitoring

Vous pouvez vous connecter à la plateforme et commencer à configurer les alertes. Si votre organisation est petite et ne possède que quelques clés et jetons, vous pouvez suivre cette procédure simplifiée pour définir vos alertes.

1. Sélectionnez les identifiants. Dans le volet principal, vous devez choisir « Identifiants ».

2. Vous pouvez créer des identifiants. Vous pouvez choisir une option de locataire Azure prête à l'emploi et définir votre ID de locataire.

Comme indiqué dans la capture d'écran ci-dessous, définissez un mot-clé : un jeton GitHub, une clé AWS ou tout autre élément de votre choix. Nous sommes conscients que certaines organisations préfèrent ne pas copier les clés API sensibles. L'utilisation d'un jeton Canary dans l'alerte partagée avec l'équipe DevOps, afin de l'intégrer aux packages sources internes, est une approche plus sûre que nous recommandons. Imaginez-le comme un piège dans les projets logiciels de vos équipes.

 Enfin, vous obtiendrez une liste d'identifiants comme dans la capture d'écran ci-dessous.

3. Créez un canal. Accédez à la section « Alertes » et créez une alerte. Si vous n'avez pas encore défini de canal de réception des alertes, vous devrez en créer un. Nous avons choisi d'envoyer l'alerte à l'adresse e-mail de notre équipe de sécurité.

4. Créez une alerte. À cette étape, vous pouvez définir l'alerte et choisir le niveau de gravité approprié. Nous recommandons d'utiliser Haute or Critical lorsque l'alerte ne cible pas une clé, un secret ou un domaine spécifique. Toutefois, si vous configurez une alerte pour une valeur spécifique propre à votre organisation (telle qu'une clé, un secret ou un domaine interne particulier), vous pouvez l'attribuer. tout niveau de gravité qui correspond à vos besoins opérationnels.

Cela dit, un scénario plus réaliste concerne une organisation gérant des centaines, voire des milliers, de clés API, de jetons et d'identifiants uniques. Grâce à l'API de Flare, vous pouvez enregistrer une clé API et automatiser la recherche à grande échelle des données sensibles de votre organisation. Par exemple, vous pouvez créer un script qui collecte les clés de vos coffres-forts de données AWS, Azure, GCP et autres, puis interroge l'API de Flare pour vérifier si certaines de ces clés ont été divulguées. Cette approche assure une surveillance continue et automatisée des identifiants compromis, permettant ainsi de détecter les fuites d'informations d'identification dans l'environnement des menaces externes.

Chasse à l'aide de la recherche globale

Lorsque la surface d'attaque est étendue ou qu'il est difficile de consacrer suffisamment de temps à la surveillance de tous les événements, une approche par chasse aux vulnérabilités peut s'avérer plus efficace. La barre de recherche globale permet de se concentrer sur des catégories telles que « Buckets » et « Code source ». Dans ce cas, nous recommandons l'utilisation du modificateur de requête `contains_secrets:true`. Son effet sur les requêtes est le suivant : décrit dans notre documentation.

Recommandations d'atténuation pour les équipes de sécurité

La principale conclusion de nos recherches est que la divulgation d'informations confidentielles n'est pas un accident rare ; elle est prévisible et structurellement systémique. Les mesures d'atténuation doivent donc elles aussi être systémiques et englober les pratiques culturelles, les contrôles techniques et la refonte architecturale.

Ne jamais ranger des secrets dans des contenants.

Aucun secret ne devrait jamais se trouver à l'intérieur d'une image conteneur. Point final. 

Voici quelques secrets :

• fichiers .env
• Fichiers Python
• Configuration.json
• Configurations YAML
• Fichiers Docker
• Répertoires d'espaces de travail
• Manifestes des composants sur Docker Hub

Si une image de conteneur contient un secret, elle est déjà compromise. Un conteneur doit uniquement Référencer les secrets de manière externe lors de l'exécution.

Cessez d'utiliser des identifiants statiques à longue durée de vie 

Transcender l'authentification par session éphémère. Les jetons à longue durée de vie sont la cause première du risque persistant. Le modèle défensif moderne repose sur une identité éphémère. Les organisations devraient remplacer :

• AWS_SECRET_ACCESS_KEY
• jeton GitHub à longue durée de vie
• AZURE_CLIENT_SECRET
• service_account_key.json

Avec des modèles d'accès basés sur les sessions tels que :

• AWS SSO avec IAM Identity Center
• AWS STS AssumeRole avec MFA
• Fédération d'identités des effectifs GCP
• Identités gérées Azure AD
• Keycloak OpenID Connect
• Jetons d'accès éphémères Okta / Auth0

Ces méthodes permettent accès juste à temps, des clés à durée de vie limitée et empêcher la persistance des informations d'identification.

Centraliser la gestion des secrets 

Les développeurs stockent souvent les secrets là où cela leur convient. Les organisations doivent donc adopter un système de stockage centralisé, tel que :

• AWS Secrets Manager
• Gestionnaire de secrets GCP
• Azure Key Vault
• Caveau HashiCorp
• 1Password Connect
• CyberArk Conjur

Mettre en œuvre une analyse continue 

Des secrets sont divulgués lors des compilations, du débogage, des pipelines CI/CD, des tests locaux, de la conteneurisation, etc.

Les organisations doivent analyser de multiples environnements, couvrant divers fournisseurs, plateformes et technologies. Il arrive que les personnes ayant commis l'erreur suppriment la fuite, mais celle-ci persiste souvent dans les dépôts miroirs, les bases de données des scrapers, etc. Il est donc nécessaire de couvrir les dépôts de code source, les images de conteneurs, les registres de paquets, l'historique des commits, les journaux de compilation et les environnements éphémères.

Ainsi, les outils qui permettent une large visibilité et un historique des modifications, comme la détection de secrets basée sur l'API de Flare, constituent une meilleure solution pour de tels cas.

Une fois découverts, les secrets doivent être détectés et révoqués. avant que les agresseurs ne les trouvent, pas après.

Appliquer les procédures de révocation et de rotation immédiates 

Lorsqu'un secret est divulgué, le compte à rebours commence et les attaquants effectuent des analyses continues – en quelques minutes, et non en quelques jours. La meilleure pratique consiste donc à :

• Révocation automatique de la clé divulguée
• Rotation automatique des identifiants régénérés
• Invalider les anciennes sessions
• Journaux d'audit pour les accès non autorisés

Notre étude a révélé un schéma de défaillance critique : environ 25 % des développeurs ont supprimé une clé divulguée de Docker Hub. mais n'a pas révoqué l'identifiant sous-jacent. Ils se croyaient en sécurité – ils ne l'étaient pas.

Gagnez en visibilité sur l'informatique parallèle.

Surveiller les registres personnels et les comptes des entrepreneurs. Nos recherches ont mis en évidence un angle mort majeur.

Les secrets d'entreprise sont fréquemment révélés par :

• Comptes personnels Docker Hub des employés
• Entrepreneurs reprennent
• Ressources pour développeurs indépendants
• Espaces de noms externes non gérés

Les organisations ont besoin de :

• Surveillance de l'espace de noms externe
• heuristiques d'association d'identité
• Surveillance inter-registres
• Corrélation des domaines divulgués, des API et des chemins internes
• Découverte en temps réel des flux d'artefacts « non officiels »

Flare permet précisément cela en analysant les conteneurs externes et en associant les clés exposées aux identités de l'entreprise, même lorsqu'elles proviennent de l'extérieur de l'infrastructure officielle.

Former les développeurs

Le glissement vers la gauche se poursuit, les organisations devant constamment s'adapter à l'évolution des mentalités et des modes de propriété. Le fait de placer des clés dans des conteneurs n'est pas simplement une erreur technique, c'est une erreur de mentalité.

Les développeurs doivent être formés :

• Ne jamais intégrer de secrets dans le code
• Ne jamais les stocker sur disque
• Ne jamais les coller dans des fichiers par commodité
• Partir du principe que tout environnement est compromis par défaut

Surveillance des fuites de secrets grâce à Flare

Pour approfondir ces conclusions et comprendre comment protéger votre organisation contre les fuites d'identifiants à grande échelle, participez à notre prochain événement. praticien vérifié session:

Révélations massives de secrets sur Docker Hub : Principales conclusions et informations essentielles
18 décembre, 9h00-9h30 (heure de l'Est) | Serveur Discord de Flare Academy

Pas encore vérifié ? Devenez membre vérifié de la communauté via Flare Academy pour accéder à des synthèses de recherche exclusives, des formations pour praticiens et des ressources pratiques. 

Déjà vérifié ? L’événement est répertorié dans la liste Discord Flare AcademyDes mises à jour régulières seront publiées sur le canal officiel. Nous espérons vous y retrouver.