Vos secrets trainent quelque part en clair

Un développeur rejoint une nouvelle équipe. Première chose qu’il fait après avoir cloné le repo ? Il lance grep -r "password" . dans le terminal. 14 credentials hardcodés. Une clé AWS en clair dans un fichier de configuration. Un token Slack dans un commentaire de code oublié depuis 2021.

Ce scénario n’est pas une hypothèse. C’est la réalité du terrain, rencontrée dans la grande majorité de mes audits.

La gestion des secrets est l’un de ces sujets qu’on reporte toujours à plus tard. “On le fera quand on aura le temps.” “Le projet est en cours de démarrage, on verra ensuite.” “C’est pas grave, c’est juste un environnement de dev.” Et pendant ce temps-là, des clés d’API, des mots de passe de bases de données et des tokens d’accès dorment tranquillement dans des fichiers de configuration partagés sur Slack, dans l’historique Git, ou dans une page Confluence accessible à toute l’entreprise.

Le coût de ce laisser-aller est bien documenté. Une clé cloud exposée peut générer des dizaines de milliers d’euros de ressources non autorisées en quelques heures. Une violation de données impliquant des credentials peut déclencher des pénalités RGPD, une obligation de notification aux autorités sous 72 heures, et une atteinte à la réputation difficile à quantifier. Le rapport IBM Cost of a Data Breach 2025 chiffre le coût moyen d’une violation à 4,4 millions de dollars. Ces incidents arrivent à des organisations de toutes tailles, pas seulement aux startups qui manquent de ressources.

La situation s’est encore complexifiée ces 2 dernières années avec l’irruption des agents LLM dans nos environnements de développement. Copilot, Cursor, Claude Code : ces outils tournent sur les machines de vos développeurs, avec un accès large au système de fichiers. Un agent compromis, une injection de prompt malveillante ou un outil mal configuré peut accéder à des fichiers de configuration contenant des credentials et les transmettre à l’extérieur, en quelques secondes, sans que personne ne s’en aperçoive.

Un secret exposé, c’est une fenêtre grande ouverte sur un système de production. Et la fermer prend souvent beaucoup plus longtemps que de l’ouvrir.

3 couches pour reprendre le contrôle

La gestion des secrets ne se règle pas avec un seul outil. C’est une discipline qui s’articule en 3 couches : l’infrastructure, le pipeline CI/CD, et le poste de développement. Ignorer l’une des 3, c’est laisser une surface d’attaque entière sans réponse.

Couche 1 : le coffre centralisé (infrastructure)

HashiCorp Vault, Infisical, AWS Secrets Manager, Azure Key Vault, Google Secret Manager : les options ne manquent pas. Le principe est le même pour tous. Les secrets ne vivent plus dans des fichiers de configuration. Ils sont stockés, chiffrés, dans un système dédié, et les applications y accèdent via des appels authentifiés au moment de l’exécution.

Mais un coffre-fort mal configuré vaut à peine mieux qu’un fichier non sécurisé. Ce qui change tout, c’est la façon dont on s’en sert.

Un credential qui expire après une heure est infiniment moins dangereux qu’un mot de passe statique valable indéfiniment. Si un secret est compromis, la fenêtre d’exposition est limitée : impossible pour un attaquant de l’exploiter une fois expiré. Dans ce même esprit, plutôt que de distribuer un “super-mot de passe” permettant d’accéder au coffre, les applications prouvent leur identité via des tokens éphémères émis par la plateforme cloud. Pas de secret partagé, pas de credential statique à faire tourner.

La rotation automatique suit la même logique : l’application obtient un credential de base de données valable une heure, le système en génère un nouveau à l’expiration. Zéro downtime, zéro intervention humaine. La séparation des accès complète le tableau : dev, staging et prod ont chacun leurs secrets, chaque équipe n’accède qu’à ce dont elle a besoin. Et savoir qui a accédé à quoi et quand est aussi important que la restriction elle-même : c’est ce qui permet de réagir vite en cas d’incident.

Couche 2 : le pipeline CI/CD

C’est souvent la couche oubliée. On pense à protéger les secrets en production, on pense à protéger le poste du développeur, mais le pipeline reste une zone grise.

L’erreur classique : un token cloud avec des droits larges, stocké dans les variables de l’outil CI/CD, qui ne tourne jamais. Ce token peut être exfiltré via une contribution malveillante, une dépendance de build compromise, ou une action automatisée mal configurée. L’alternative, c’est l’authentification via token éphémère : GitHub Actions, GitLab CI et leurs équivalents peuvent s’authentifier directement auprès des plateformes cloud via un token généré pour chaque exécution, sans aucun credential statique à stocker. Plus rien à faire tourner manuellement.

L’autre angle mort, c’est l’absence de filet de sécurité. Des outils comme TruffleHog, git-secrets ou GitHub Advanced Security analysent les commits à la recherche de secrets avant même qu’ils n’atteignent la branche principale. GitGuardian envoie une alerte en temps réel si un credential apparaît dans un push. Ces outils ne remplacent pas une bonne hygiène, mais ils rattrapent les erreurs humaines avant qu’elles ne deviennent des incidents.

Couche 3 : le poste de développement

C’est la couche la plus difficile à maîtriser, parce qu’elle touche aux habitudes individuelles de chaque développeur. Le développeur a besoin de secrets pour faire tourner l’application localement, et ces secrets finissent invariablement quelque part : dans un fichier de configuration, dans l’historique de commandes, dans une note quelconque.

Des outils comme fnox ou Infisical proposent d’injecter des secrets directement dans le contexte d’exécution, sans jamais les écrire dans un fichier. Les valeurs sont disponibles pendant la durée de la commande, puis disparaissent. C’est l’équivalent du “clean desk policy” appliqué au poste de développement.

Mais le défi le plus récent, c’est la montée en puissance des agents LLM sur les machines de développement. Un agent avec accès au système de fichiers peut lire des fichiers de configuration contenant des credentials. Un outil mal configuré ou compromis peut transmettre ces informations à l’extérieur, sans laisser de trace visible. Une instruction malveillante glissée dans un fichier de code source peut amener un agent à lire et exfiltrer des informations sensibles, sans que le développeur ne s’en aperçoive.

La réponse tient à une règle simple : contrôler précisément ce que l’agent peut faire. Les outils de coding assisté comme Claude Code ou Cursor proposent des modes de permission granulaires. On peut autoriser la lecture de certains répertoires, les commandes de build et les tests, tout en bloquant l’accès aux fichiers de configuration sensibles et aux outils de gestion de secrets. C’est le principe du moindre privilège appliqué à un outil de développement. Donner un accès illimité à un agent en espérant que les secrets restent inaccessibles dans le même environnement, c’est contradictoire.

Le secret le plus dangereux est celui qu’on oublie

Dans les audits que je mène, le problème n’est presque jamais l’absence d’outils. Les équipes ont souvent des variables secrètes dans leurs pipelines, parfois même un coffre-fort cloud. Le problème, c’est le secret sprawl : des secrets dupliqués à travers une dizaine de systèmes différents, des anciens credentials jamais révoqués, des ex-collaborateurs qui ont encore accès à des ressources de production 6 mois après leur départ.

La dette secrète s’accumule comme la dette technique, mais elle est encore plus silencieuse. Un mot de passe jamais changé depuis 3 ans. Un token de service qui donne encore accès à un stockage cloud de production alors que la personne qui l’a créé a quitté l’entreprise il y a 18 mois. Ces oublis sont ceux qui causent les incidents les plus graves, parce qu’ils passent sous le radar de toutes les revues de sécurité.

L’Infrastructure as Code est un angle mort particulièrement répandu. Les fichiers d’état des outils d’infrastructure contiennent régulièrement des valeurs sensibles en texte clair. Les secrets Kubernetes sont encodés mais pas chiffrés au repos par défaut. Des équipes qui se croient à l’abri parce qu’elles utilisent un coffre-fort continuent d’exposer des secrets dans leurs configurations d’infrastructure, sans s’en rendre compte.

Ce que j’observe systématiquement, c’est que la sécurité des secrets est autant un problème humain qu’un problème technique. Les processus d’onboarding et d’offboarding, les pratiques de partage en interne, la culture de l’équipe vis-à-vis des secrets : voilà ce qui détermine le niveau de risque réel. Un coffre-fort sans politique de rotation et sans traçabilité des accès vaut moins qu’une hygiène rigoureuse sur les pratiques de base.

Et dans votre organisation ?

Quand avez-vous changé les credentials de votre base de données de production pour la dernière fois ? Si la réponse est “je ne sais plus” ou “au démarrage du projet”, c’est un signal.

Combien de personnes qui ont quitté votre organisation ont encore accès à des secrets de production ? Dans la grande majorité des entreprises, la réponse honnête est “je ne sais pas, et c’est exactement ce qui m’inquiète.”

Si un agent LLM tournant sur la machine d’un de vos développeurs était compromis demain, qu’est-ce qu’il pourrait atteindre ? Avec la prolifération des outils de coding assisté, cette question mérite une réponse sérieuse et documentée.

Vos pipelines CI/CD utilisent-ils des credentials cloud longue durée, ou des tokens éphémères ? Si c’est la première option, chaque exécution est une surface d’attaque potentielle que vous n’avez pas encore adressée.

Avez-vous un moyen de détecter un secret commité accidentellement avant qu’il n’arrive en production ? Si non, vous comptez uniquement sur la vigilance humaine, qui est par définition faillible, surtout à 17h30 un vendredi.

Un audit technique permet de répondre à toutes ces questions en quelques jours, et d’établir une feuille de route concrète pour réduire l’exposition de façon progressive.

Conclusion

La gestion des secrets reste mal traitée dans la plupart des organisations, en partie parce que c’est un sujet ingrat. Personne n’en parle dans les conférences tech, personne n’en fait la promotion sur LinkedIn. C’est de la plomberie, et la plomberie ne génère pas de likes.

L’approche en 3 couches donne un cadre d’action concret : un coffre centralisé avec des credentials éphémères pour l’infrastructure, des pipelines sans credentials statiques et avec du secret scanning pour la CI/CD, des permissions granulaires pour contenir la menace des agents LLM en développement local. Tout déployer le premier jour n’est pas nécessaire. Arrêter de committer des secrets, en revanche, c’est la règle minimale, non négociable.

Si la sécurité de votre software factory est un sujet qui vous préoccupe, contactez-moi pour qu’on en discute.