Les RSSI devraient considérer la prolifération des secrets comme un défi de gouvernance. Cela signifie imposer une propriété claire, adopter des informations d’identification de courte durée et étendre les contrôles de sécurité tout au long du cycle de vie du développement logiciel.
Lorsque Matt Schlicht a créé Moltbook, le réseau social où les agents d’IA communiquent entre eux, il n’a pas écrit le code lui-même. Il « a juste eu une vision » et l’a codée en ambiance. Le réseau social a été lancé le 28 janvier 2026 et, quelques jours plus tard, les chercheurs en sécurité ont commencé à détecter de graves failles de sécurité.
Les experts de la société de sécurité cloud Wiz et, de manière indépendante, le chercheur Jameson O’Reilly, ont découvert que la base de données principale de Moltbook, hébergée sur Supabase, avait été mal configurée. En conséquence, il a accordé un large accès en lecture et en écriture aux données de la plateforme.
« L’exposition comprenait 1,5 million de jetons d’authentification API, 35 000 adresses e-mail et des messages privés entre agents », ont noté les chercheurs de Wiz dans un article de blog.
Dans le développement de logiciels traditionnels, la divulgation d’un secret résulte généralement d’une erreur. Habituellement, un développeur code en dur une clé, copie le mauvais fichier de configuration ou envoie le code interne vers un référentiel public. Avec le codage assisté par IA, ces erreurs peuvent se produire rapidement et passer souvent inaperçues, car la vitesse et la fonctionnalité sont prioritaires sur la sécurité.
Compte tenu de la popularité croissante du vibe coding, le problème s’accélère. « Le rythme auquel nous construisons et la quantité de code auraient été inimaginables il y a seulement quelques années », déclare Dwayne McDaniel, principal défenseur des développeurs chez GitGuardian.
En 2025, les engagements de code public ont augmenté de plus de 40 % par rapport à l’année précédente, et les secrets augmentent tout aussi rapidement. La société de sécurité GitGuardian a signalé une augmentation de 34 % des fuites de secrets sur GitHub l’année dernière – la plus forte hausse jamais enregistrée – portant le total à près de 29 millions d’identifiants exposés.
« 12 des 15 types de secrets divulgués qui connaissent la croissance la plus rapide étaient des services d’IA », explique McDaniel. Plus de 1,27 million de secrets liés à l’IA ont été dévoilés en 2025, ce qui représente une augmentation de 81 % d’une année sur l’autre, la croissance la plus rapide enregistrée dans une seule catégorie.
McDaniel regroupe ces informations d’identification dans plusieurs grands domaines : les plates-formes LLM elles-mêmes, l’écosystème de support et d’orchestration, le plan de contrôle de l’IA, les serveurs Model Context Protocol (MCP) et les assistants de codage agent.
« Je suis de plus en plus préoccupée par le volume de code généré par l’IA et par la vitesse à laquelle les développeurs l’examinent », déclare Christine Bejerasco, RSSI de WithSecure. « Cela peut conduire à un code plus vulnérable, d’autant plus que les modèles d’IA de pointe sont désormais capables d’identifier les vulnérabilités à grande échelle. »
Les fuites de secrets nécessitent une réponse immédiate
De nombreuses organisations savent au fond qu’elles ont un problème avec le code généré par l’IA. Cependant, certains ne réalisent pas la gravité de la situation, ni le nombre de secrets dévoilés dans leurs systèmes.
Lorsqu’une fuite de secret est détectée, le problème doit être traité comme un incident de sécurité. «Nous activons immédiatement notre processus de réponse aux incidents», déclare Bejerasco de WithSecure.
Le secret est révoqué ou désactivé et un nouveau est généré. « À partir de là, l’équipe de réponse aux incidents travaille avec le R&D pour étudier l’impact sur les systèmes et les données. Cela est suivi d’un nettoyage, puis d’un renforcement », explique-t-elle. « Bien que les incidents soient généralement coordonnés par le bureau du RSSI, l’équipe R&D est responsable de la révocation et du nettoyage. »
L’organisation effectue des autopsies et met en œuvre toutes les mises à jour nécessaires des systèmes ou des politiques en fonction de ce qui a été appris.
Même si la remédiation est essentielle, le processus est loin d’être simple. Selon GitGuardian, 64 % des secrets valides identifiés en 2022 restent non révoqués en 2026, en grande partie parce que de nombreuses organisations ne disposent pas de la gouvernance et des processus reproductibles nécessaires pour les nettoyer à grande échelle.
« Nous pensons qu’il s’agit moins d’un problème de visibilité que d’une combinaison de priorité, d’outils et de propriété », déclare McDaniel de GitGuardian.
La détection est la partie la plus facile, déclare Rohan Gupta, vice-président du cloud, de la sécurité et du DevOps chez R Systems. « La réhabilitation est l’endroit où la discipline est mise à l’épreuve. »
Aborder le problème plus large
À mesure que le codage assisté par l’IA se développe, les responsables de la sécurité doivent repenser la manière dont ils gèrent les risques. Cela signifie regarder au-delà des référentiels et sécuriser l’intégralité du cycle de vie du développement logiciel (SDLC), y compris les outils de collaboration où les informations d’identification apparaissent souvent.
« Nous nous concentrons sur les deux, mais le profil de risque est très différent : ce qui est identifié dans Jira ou Slack est très différent de ce que vous trouverez dans votre référentiel de code », explique David MacKinnon, responsable de la sécurité chez N-able. « Un SDLC mature, qui inclut des éléments tels qu’un stockage efficace des informations d’identification, la séparation des tâches, l’analyse du code source, des environnements de développement, de scène et de production séparés, etc., contribue à minimiser les risques commerciaux. »
Chez WithSecure, Bejerasco affirme que les secrets et l’accès des agents sont conservés « aussi transitoires que possible » pour réduire les risques. Et il existe également une politique de sécurité du cycle de vie qui impose la révision du code. « Cette politique est en fait la « bible » de la sécurité pour les développeurs », dit-elle. « Il couvre les évaluations de l’impact sur la vie privée, la modélisation des menaces, les tests de sécurité et la révision du code. »
Gupta de R Systems est d’accord, conseillant aux organisations de alterner les informations d’identification, de révoquer les versions exposées, de vérifier les utilisations non autorisées pendant n’importe quelle fenêtre d’exposition et de purger l’historique dans la mesure du possible. « Pour les comptes de services existants à longue traîne, les intégrations tierces, la rotation des informations d’identification des fournisseurs intégrés reste un exercice manuel coordonné, et nous évoluons progressivement vers l’automatisation », dit-il.
Il conseille aux RSSI de sensibiliser à l’ampleur du problème. Il suggère également une formation plus solide des développeurs, de meilleurs outils pour détecter et gérer les risques, ainsi que des solutions permettant au développement humain et piloté par l’IA de fonctionner en toute sécurité. Selon lui, il est tout aussi important d’intégrer ces pratiques dans les flux de travail quotidiens afin que la sécurité fasse partie de la manière dont le code est écrit, et non quelque chose d’ajouté ultérieurement.
Son organisation recherche les secrets lorsque le code est validé afin de bloquer toute validation susceptible d’introduire un risque dans les produits. « Le créateur de ce code, qu’il soit humain ou IA, est tenu au même niveau de maturité en matière de sécurité », ajoute MacKinnon.
Bejerasco est d’accord. « Nous devons délibérément attribuer la propriété dès le départ et la valider en permanence, et réprimer tout ce qui passe entre les mailles du filet », dit-elle. « Sinon, ces identités et secrets non gérés s’accumuleront plus rapidement que nous ne pourrons les contrôler. »
Conseils aux RSSI
S’il y a une leçon claire à tirer de l’essor du développement basé sur l’IA, c’est bien la suivante : la plus grande erreur que les RSSI peuvent commettre est de traiter la prolifération des secrets comme un problème d’analyse. « Il s’agit en réalité d’un problème de propriété et de gouvernance pour les identités de machines à grande échelle », explique McDaniel.
Gupta va encore plus loin. « Une fuite de secret est le symptôme d’un problème d’identité non humaine (NHI) non gouverné », dit-il. « Traitez-le comme une détection et une réponse, et vous chasserez les fuites pour toujours. Traitez-le comme une gouvernance des identités – inventoriez chaque NHI, attribuez la propriété, appliquez des informations d’identification de courte durée, préférez l’identité de la charge de travail aux clés statiques, faites une rotation automatique, mettez hors service de manière agressive – et le problème commence à diminuer au lieu de croître. «
Et même si les fuites publiques attirent l’attention, la plupart des révélations de secrets s’accumulent en privé – dans les référentiels internes, les systèmes de construction et les flux de travail des développeurs – où la propriété n’est pas claire et où la remédiation est souvent différée.
« Le secteur privé a tendance à être confondu avec la sécurité, alors que cela signifie simplement qu’il y a moins de regards sur lui », explique Gupta. « Dans les pensions privées, les gens se détendent. Parce qu’ils se sentent confinés, la garde peut être lâchée. Il suffit d’un problème de chaîne d’approvisionnement ou que quelqu’un franchisse la porte avec un accès non autorisé. »
Le véritable risque réside dans le grand nombre de NHI créés plus rapidement que les organisations ne peuvent les suivre. « Les RSSI les plus intelligents poussent actuellement leurs équipes DevOps et de développement à adopter de meilleures façons de gérer les autorisations que les clés API de longue durée et surprivilégiées », dit-il.
Pour Bejerasco de WithSecure, les problèmes de sécurité associés au code généré par l’IA sont urgents. « L’appétit des dirigeants organisationnels pour l’adoption de l’IA est élevé à l’heure actuelle, et nous devons gérer ce risque même si les capacités et les contrôles ne sont pas encore complètement matures », dit-elle.
Pourtant, malgré l’urgence, l’industrie cherche encore comment réagir. « Je pense que personne n’a encore les bonnes réponses ; nous construisons tous la gouvernance au fur et à mesure », déclare Bejerasco. À mesure que les agents d’IA se généralisent, les approches traditionnelles pourraient ne pas suivre le rythme et les organisations pourraient avoir besoin d’utiliser l’IA pour les aider à gouverner l’IA, ajoute-t-elle.
MacKinnon estime que les RSSI ne devraient pas être seuls dans cette situation. Ils devraient impliquer les PDG et les CTO dans le processus et leur expliquer que « le risque est réel et endémique ».
« Il n’y a jamais de moment idéal pour y remédier, mais investir dans une réduction proactive de ce risque est bien plus facile et moins coûteux que d’en prendre connaissance après qu’il a été utilisé pour compromettre votre entreprise », déclare MacKinnon.
