Technologies

Développement : IA partout, secrets nulle part

Selon une étude, plus de 1,27 million de secrets liés à l'IA ont été exposés en 2025, soit une augmentation de 81% par rapport à l'année précédente. (Photo : Kristina Flour/Unsplash)

La généralisation en cours de l'IA dans les processus de développement confronte les RSSI à l'explosion des identités de machines et à la propension de cette technologie à laisser fuiter des secrets dans le code qu'elle génère.

PublicitéLorsque Matt Schlicht a créé Moltbook, un réseau social où des agents IA communiquent entre eux, il n'a pas écrit le code lui-même. Il avait simplement une vision de cette application et l'a développée par vibe-coding. Le réseau social a été lancé le 28 janvier 2026 et, quelques jours plus tard, des chercheurs en sécurité y ont détecté de graves failles de sécurité.

Les experts de la société de sécurité Wiz et, indépendamment, le chercheur Jameson O'Reilly, ont découvert que la base de données back-end de Moltbook, hébergée sur Supabase, avait été mal configurée. De ce fait, elle offrait un accès étendu 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 indiqué les chercheurs de Wiz dans un billet de blog.

Dans le développement logiciel traditionnel, la fuite d'un secret résulte généralement d'une erreur. Le plus souvent, un développeur intègre une clé en dur dans le code, copie le mauvais fichier de configuration ou publie du code interne sur un dépôt public. Avec la programmation assistée par l'IA, ces erreurs peuvent survenir rapidement et passer inaperçues, car la vitesse et la fonctionnalité sont souvent privilégiées au détriment de la sécurité.

Explosion du volume de code

Face à la popularité croissante du vibe-coding, le problème s'aggrave. « Le rythme auquel nous développons et la quantité colossale de code produit auraient été inimaginables il y a encore quelques années », signale Dwayne McDaniel, responsable de la communication auprès des développeurs chez GitGuardian, un spécialiste de la protection des secrets et de la gestion des identités.

En 2025, le nombre de commits publics de code a bondi de plus de 40% par rapport à l'année précédente, et les secrets ainsi disséminés augmentent tout aussi rapidement. GitGuardian estime la hausse à 34% sur GitHub l'année dernière - un record -, portant le total à près de 29 millions d'identifiants exposés. « Douze des quinze types de fuites de secrets dont la croissance est la plus rapide sont liés à des services d'IA », note Dwayne McDaniel. Plus de 1,27 million de secrets liés à l'IA ont été exposés en 2025, soit une augmentation de 81% par rapport à l'année précédente, la plus forte croissance jamais enregistrée dans une seule catégorie. Dwayne McDaniel regroupe ces fuites d'identifiants en plusieurs grandes catégories : les plateformes LLM elles-mêmes, l'écosystème de support et d'orchestration, le plan de contrôle de l'IA, les serveurs MCP (Model Context Protocol) et les assistants de programmation.

Publicité« Je suis de plus en plus préoccupée par le volume de code généré par l'IA et la rapidité avec laquelle les développeurs le vérifient, dit de son côté Christine Bejerasco, RSSI de WithSecure (le nouveau nom de l'éditeur finlandais d'outils de sécurité F-Secure). Cela peut engendrer davantage de code vulnérable, et c'est d'autant plus préoccupant que les modèles d'IA de pointe sont désormais capables d'identifier les vulnérabilités à grande échelle. »

Réagir à la fuite d'un secret

De nombreuses organisations savent bien qu'elles ont un problème avec le code généré par l'IA. Cependant, certaines n'ont pas totalement conscience de la gravité de la situation ni du nombre considérable de secrets exposés dans leurs systèmes. Or, lorsqu'une fuite de secret est détectée, l'incident doit être traité comme une crise de sécurité. « Nous activons alors immédiatement notre processus de réponse aux incidents », explique Christine Bejerasco de WithSecure.

Le secret est révoqué ou désactivé, et un nouveau est généré. « L'équipe de réponse aux incidents collabore ensuite avec la R&D pour analyser l'impact sur les systèmes et les données. S'ensuivent le nettoyage, puis le renforcement de la sécurité, précise-t-elle. Bien que la gestion des incidents soit généralement assurée par le RSSI, la révocation et le nettoyage proprement dits relèvent de la responsabilité de l'équipe de R&D. » L'organisation réalise ensuite des analyses post-mortem et met en oeuvre les mises à jour nécessaires de ses systèmes et politiques en fonction des enseignements issus de la crise.

Si la remédiation est essentielle, le processus est loin d'être simple. Selon GitGuardian, 64% des secrets valides dont la fuite avait été identifiée en 2022 restent actifs en 2026, principalement parce que de nombreuses organisations ne disposent pas de la gouvernance et des processus nécessaires pour les supprimer à grande échelle. « Nous pensons qu'il s'agit moins d'un problème de visibilité que d'une combinaison de priorités, d'outils et de responsabilité », dit Dwayne McDaniel de GitGuardian. La détection est la partie facile, ajoute Rohan Gupta, vice-président cloud, sécurité et DevOps chez R Systems (éditeur d'outils d'ingénierie), mais « c'est la correction qui met la rigueur [de l'organisation] à l'épreuve. »

S'attaquer au problème dans son ensemble

Avec l'essor du développement assisté par l'IA, les RSSI doivent repenser leur gestion des risques. Cela implique d'aller au-delà des dépôts de code et de sécuriser l'intégralité du cycle de vie du développement logiciel (SDLC), y compris les outils collaboratifs où les identifiants sont souvent présents. « Nous nous concentrons sur les deux aspects, mais le profil de risque est très différent : ce qui est identifié dans Jira ou Slack est bien différent de ce que l'on trouve dans un dépôt de code, explique David MacKinnon, directeur de la sécurité chez N-able, autre éditeur de la cyber. Un SDLC éprouvé, qui inclut des éléments tels que la gestion efficace des identifiants, la séparation des tâches, l'analyse du code source, la séparation des environnements de développement, de préproduction et de production, etc., contribue à minimiser les risques pour l'entreprise. »

Chez WithSecure, Christine Bejerasco explique que les secrets et les accès des agents IA sont gérés de manière « aussi éphémère que possible » afin de réduire les risques. Une politique de sécurité du cycle de vie logiciel, qui impose des revues de code, est également en place. « Cette politique est en quelque sorte la bible de la sécurité pour les développeurs, affirme-t-elle. « Elle couvre les analyses d'impact sur la vie privée, la modélisation des menaces, les tests de sécurité et les revues de code. »

Rohan Gupta, de R Systems, conseille aux organisations de faire tourner les identifiants, de révoquer les versions exposées, de réaliser des audits des accès non autorisés pendant toutes les fenêtres d'exposition et de supprimer les données de l'historique lorsque cela est possible. « La gestion des comptes de services anciens, les intégrations de tiers et la rotation des identifiants des fournisseurs intégrés à nos offres reste un processus manuel faisant l'objet de coordinations, que nous automatisons progressivement », précise-t-il.

S'intégrer aux workflows de conception

Une étape essentielle pour résoudre le problème de la fuite des secrets est... d'en prendre conscience. « Si une organisation ignore le nombre de secrets qu'elle expose dans son code source, ou le niveau d'accès que ces secrets confèrent, elle court un risque business considérable sans le savoir », résume David MacKinnon, directeur de la sécurité de N-able.

Et de conseiller aux RSSI de sensibiliser leurs équipes à l'ampleur du problème. Il suggère également de renforcer la formation des développeurs, d'améliorer l'outillage de détection et de gestion des risques et de mettre en place des solutions permettant un développement sécurisé, tant humain qu'avec l'IA. Selon lui, il est tout aussi important d'intégrer ces pratiques aux workflows quotidiens, afin que la sécurité fasse partie intégrante de la conception du code, et ne soit pas vécue comme un ajout a posteriori.

N-able analyse ainsi le code à la recherche de secrets lors de chaque validation afin de bloquer toute modification susceptible d'introduire des risques dans les produits. « Le créateur de ce code, qu'il soit humain ou qu'il s'agisse d'une IA, est soumis aux mêmes exigences de maturité en matière de sécurité », ajoute David MacKinnon. « Nous devons définir clairement la responsabilité en amont, la valider en permanence, et sévir contre toute faille de sécurité », abonde Christine Bejerasco. Sinon, ces identités et secrets non gérés s'accumuleront plus vite que nous ne pourrons les contrôler. »

Là où les RSSI peuvent faire fausse route

S'il y a une leçon essentielle à tirer de l'essor du développement piloté par l'IA, c'est celle-ci : la plus grande erreur que puissent commettre les RSSI est de considérer la prolifération des secrets comme un simple problème de détection. « Il s'agit en réalité d'un problème de propriété et de gouvernance des identités de machines à grande échelle », tranche Dwayne McDaniel.

Rohan Gupta va plus loin : « une fuite de secret est le symptôme d'un problème d'identité non humaine (NHI pour Non-human identity) non gouvernée, affirme-t-il. Si vous vous contentez de détecter et de réagir, vous passerez votre temps à traquer les fuites. En revanche, si vous adoptez une approche de gouvernance des identités - inventorier chaque NHI, en attribuer la propriété, imposer des identifiants à durée de vie limitée, privilégier l'identité liée à l'application aux clés statiques, effectuer une rotation automatique et une mise hors service rapide -, le problème commencera à s'atténuer au lieu de s'aggraver.»

Fuite privée = sécurité ?

Et si les fuites de secrets publiques attirent l'attention, la plupart des expositions se produisent en privé - dans les référentiels internes, les systèmes de compilation et les flux de travail des développeurs - où la propriété est floue et la correction souvent différée. « On confond souvent privé et sûr, alors qu'en réalité, cela signifie simplement qu'il y a moins de surveillance, explique Rohan Gupta. Dans les dépôts privés, la vigilance est moindre. Le sentiment de confinement engendre un relâchement de la vigilance. Il suffit d'un problème dans la chaîne d'approvisionnement ou d'une personne qui récupère avec un accès non autorisé. »

Le véritable risque réside dans le volume considérable d'identités de machines, créées bien plus rapidement que les organisations ne peuvent les contrôler. « Les RSSI les plus avisés incitent actuellement leurs équipes DevOps et de développement à adopter de meilleures méthodes de gestion des autorisations que des clés API à longue durée de vie et associé à des privilèges excessifs », ajoute Rohan Gupta.

L'IA pour gouverner l'IA ?

Pour Christine Bejerasco de WithSecure, les problèmes de sécurité liés au code généré par l'IA sont urgents. « L'appétit des dirigeants pour l'adoption de l'IA est actuellement très fort, et nous devons gérer ce risque même si les capacités et les contrôles ne sont pas encore totalement matures, souligne-t-elle. Je ne pense pas que quiconque détienne encore les réponses définitives ; nous construisons tous notre gouvernance au fur et à mesure ». À mesure que les agents d'IA se généralisent, les approches traditionnelles risquent de ne plus suffire, et les organisations pourraient devoir recourir... à l'IA pour mieux gouverner l'IA, ajoute-t-elle.

David MacKinnon (N-able) estime que les RSSI ne devraient pas rester seuls face à ce problème. Mais devraient impliquer directions générales et DSI dans le processus et leur expliquer que la réalité et l'omniprésence du risque associé. « Il n'y a jamais de moment idéal pour s'y attaquer, mais investir dans la réduction proactive de ce risque est bien plus simple et économique que de le découvrir après qu'il a été exploité pour compromettre l'entreprise », souligne l'expert.