Une nouvelle analyse a révélé que plus de 10 000 images de conteneurs Docker Hub divulguaient des identifiants sensibles — notamment des clés API actives, des jetons d’accès au cloud et des secrets CI/CD.
Cette exposition met les organisations en danger de compromission directe, sans que les attaquants aient besoin d’exploiter la moindre vulnérabilité.
« L’exposition de secrets sur Docker Hub n’est pas nouvelle. De nombreux acteurs malveillants analysent activement Docker Hub ainsi que d’autres registres et dépôts de code ; les secrets exposés sont donc probablement déjà compromis », a déclaré Assaf Morag, chercheur en cybersécurité chez Flare.
Il a ajouté : « Ce qui nous a surpris, c’est l’ampleur de l’exposition en 2025, malgré une sensibilisation accrue. C’est pourquoi nous pensons que l’approche la plus efficace consiste à continuer de sensibiliser l’ensemble du secteur, et pas seulement au sujet de Docker Hub. »
- Une exposition généralisée des secrets dans tous les secteurs
- Comment les secrets se retrouvent dans les images de conteneurs
- Des incidents réels illustrent le coût des secrets exposés
- Mesures pour réduire le risque d’exposition des secrets
- Le risque croissant des secrets dans la chaîne d’approvisionnement
Une exposition généralisée des secrets dans tous les secteurs
L’exposition concerne plus de 100 organisations de secteurs variés, notamment la technologie, la finance, l’industrie manufacturière et le conseil, ainsi qu’une entreprise du Fortune 500.
Dans de nombreux cas, les identifiants exposés accordaient un accès administrateur à des environnements cloud de production, à des dépôts GitHub privés ou à des systèmes CI/CD critiques — pourtant, les entreprises concernées ignoraient que ces secrets étaient accessibles publiquement sur Docker Hub.
Parmi les images analysées, 42 % contenaient au moins cinq secrets chacune : un seul conteneur compromis pouvait donc permettre de déverrouiller l’intégralité d’un pipeline de développement ou d’une infrastructure cloud.
La recherche met également en évidence une forte hausse des fuites de clés API de modèles d’IA : près de 4 000 ont été exposées, preuve que l’adoption de l’IA progresse plus vite que la capacité des organisations à la sécuriser.
Comment les secrets se retrouvent dans les images de conteneurs
À l’origine du problème se trouve la forte dépendance du développement logiciel moderne, des outils d’automatisation et des pratiques de conteneurisation aux secrets.
Il peut s’agir de clés API, d’identifiants cloud, de jetons, de clés SSH, de mots de passe de bases de données ou encore de jetons d’accès aux modèles.
Les chercheurs ont constaté que les secrets se retrouvaient souvent dans les conteneurs parce que les développeurs les stockaient fréquemment dans des .env fichiers ou des répertoires de configuration, les inscrivaient en dur dans des fichiers Python ou Node.js, ou les intégraient directement dans des Dockerfiles.
Dans de nombreux cas, ces images étaient ensuite poussées vers des registres publics ou personnels — notamment des comptes appartenant à des prestataires — plaçant les identifiants sensibles hors du contrôle de l’organisation et augmentant le risque d’exposition accidentelle.
Lors des processus de build Docker, des répertoires de projet entiers — y compris les fichiers contenant des secrets — étaient copiés dans les images de conteneurs.
Lorsque ces images étaient poussées vers des dépôts Docker Hub publics, les secrets devenaient ouvertement accessibles et immédiatement récupérables par des robots d’analyse automatisée et des acteurs malveillants.
Plus inquiétant encore : bien que certains développeurs aient supprimé les secrets exposés après leur découverte, 75 % n’ont pas révoqué ni renouvelé les clés sous-jacentes, ce qui signifie que les attaquants pouvaient encore les utiliser longtemps après le nettoyage de la fuite visible.
Des incidents réels illustrent le coût des secrets exposés
La recherche met en évidence plusieurs cas particulièrement graves :
- Une importante entreprise de services d’IA a divulgué un jeton GitHub disposant de tous les privilèges d’administration dans une image de conteneur, permettant à des attaquants de supprimer des dépôts, de manipuler des workflows CI/CD et d’accéder aux environnements clients en aval.
- L’architecte principal d’une banque nationale gérait un compte Docker Hub personnel contenant des centaines d’images publiques, dont plusieurs exposaient des jetons d’API d’IA et des composants d’infrastructure internes.
- Le shadow IT s’est imposé comme un thème majeur : des prestataires et des employés ont téléversé à leur insu des conteneurs contenant des secrets d’entreprise vers des espaces de noms personnels, contournant toute surveillance organisationnelle.
Ces incidents montrent pourquoi les attaquants se concentrent de plus en plus sur la collecte de secrets : l’authentification permet de contourner l’authentification multifacteur, les défenses périmétriques et les protections de l’identité.
Avec une clé valide, les attaquants n’ont pas besoin d’un zero-day — il leur suffit de se connecter.
Mesures pour réduire le risque d’exposition des secrets
La protection des identifiants sensibles exige une approche systématique qui réduit les endroits où les secrets peuvent apparaître, limite leur durée de vie et renforce leur gestion et leur surveillance tout au long du cycle de développement.
- Ne stockez jamais de secrets dans des conteneurs et veillez à les supprimer des fichiers tels que .env, des répertoires de configuration, du code applicatif et des Dockerfiles.
- Utilisez des méthodes d’accès à durée de vie courte ou fondées sur l’identité telles que AWS STS, les identités managées Azure, la fédération des identités de charge de travail ou des comptes de service associés à des rôles IAM cloud.
- Centralisez tous les identifiants dans un coffre-fort de secrets géré et imposez des périmètres de moindre privilège pour chaque clé ou jeton.
- Intégrez l’analyse automatisée des secrets aux workflows des développeurs, notamment aux contrôles avant commit, aux pull requests, aux pipelines CI et à l’analyse des images de conteneurs.
- Révoquez et renouvelez immédiatement tout identifiant exposé et effectuez régulièrement des opérations planifiées de renouvellement et des audits d’hygiène.
- Surveillez l’informatique fantôme en suivant les registres des prestataires et les registres personnels, et activez la journalisation et les alertes pour tout accès aux secrets ou comportement d’utilisation inhabituel.
- Formez les développeurs à la gestion sécurisée des secrets et imposez des politiques sous forme de code ainsi que des mesures de contrôle des applications afin d’empêcher la présence de secrets non fiables ou mal gérés dans le SDLC.
Ensemble, ces mesures aident les organisations à mettre en place une approche plus fiable et plus résiliente de la gestion des secrets dans leurs environnements.
Le risque croissant des secrets dans la chaîne d’approvisionnement
Les résultats soulignent un défi plus vaste dans l’ensemble de la chaîne d’approvisionnement logicielle : les organisations gèrent un volume croissant de secrets et, en l’absence de mesures de protection cohérentes, certains de ces identifiants finissent inévitablement par être exposés.
À mesure que les architectures cloud natives se développent et que les services pilotés par l’IA deviennent plus interconnectés, le nombre d’identifiants en circulation — ainsi que la nécessité d’une gestion rigoureuse — continue d’augmenter.
Cette tendance concorde avec des incidents récents, comme la compromission de workflows GitHub Actions et le ver Shai-Hulud pour NPM, qui a exploité des jetons de développeurs exposés pour se propager dans de vastes écosystèmes.
Dans les environnements hautement automatisés, les secrets restent essentiels au fonctionnement des systèmes, mais ils nécessitent également une gouvernance rigoureuse pour prévenir tout accès ou usage abusif involontaire.
Ces tendances montrent pourquoi la sécurité de la chaîne d’approvisionnement logicielle est devenue une priorité essentielle pour les équipes de développement modernes.