ISGroup Conseil en Cybersécurité

Clés API et jetons dans le code généré par l’IA : risques et contrôles avant le déploiement

Clés API, jetons et secrets dans le code généré par l’IA : le risque le plus sous-estimé

Un assistant IA peut écrire en quelques minutes du code qui se connecte à des bases de données, des API de paiement, des buckets cloud, des dépôts, des systèmes SaaS, des services d’email et des environnements de déploiement. Cependant, pour que tout fonctionne immédiatement, le chemin le plus court passe souvent par une clé collée dans un fichier, une variable imprimée dans les logs, un .env créé à la volée ou un jeton copié dans une discussion lors du débogage.

Le risque des secrets dans le code généré par l’IA ne se limite pas au codage en dur classique. Les clés API, jetons, chaînes de connexion et identifiants peuvent finir dans des prompts, l’historique des discussions, des tickets (issues), des logs de build, des artefacts, des source maps, des images de conteneurs, des tests, des fichiers README, des fichiers temporaires, des configurations locales et des espaces de travail distants utilisés par les agents. Le dépôt peut sembler propre alors qu’une clé reste exposée ailleurs.

Pour les développeurs, les fondateurs techniques et les équipes DevOps, la question concrète avant le déploiement est : quels secrets l’IA a-t-elle vus, où ont-ils été enregistrés, lesquels sont arrivés dans le dépôt, lesquels ont fini dans les pipelines et lesquels doivent être renouvelés (rotation) avant que l’application ne touche à des données réelles ou à des services de production.

[Callforaction-WAPT]

Pourquoi les agents IA augmentent le risque lié aux secrets

Les outils de codage par IA travaillent dans un contexte plus large que le simple fichier : ils peuvent lire des portions de dépôts, générer des fichiers de configuration, proposer des scripts, modifier des tests, lancer des commandes, expliquer des erreurs et aider à connecter des services externes. Dans de nombreux flux de travail, surtout avec le mode agent, le terminal ou les environnements distants, l’assistant ne se limite pas à suggérer du code, mais participe activement au processus opérationnel.

Cela crée une nouvelle surface d’exposition pour les secrets. Lors d’une session de débogage, un développeur peut coller une chaîne de connexion pour demander pourquoi la base de données ne répond pas ; l’agent peut créer un .env.local pour faire passer un test ; une commande peut imprimer des variables d’environnement dans les logs ; une build peut inclure une clé dans le bundle frontend. La vitesse rend le problème moins visible : lorsque le code fonctionne enfin, l’équipe a tendance à se concentrer sur la fonctionnalité, mais une clé exposée peut donner accès à des paiements, au cloud, à des bases de données, à des dépôts, à des services SaaS, à des systèmes de production ou à des données clients.

Qu’est-ce qui compte comme un secret

Un secret n’est pas seulement un mot de passe. Dans un projet moderne, le périmètre inclut les clés API, les jetons OAuth, les jetons d’accès personnels (PAT), les secrets JWT, les secrets de webhook, les clés privées, les certificats, les fichiers .pem, les comptes de service, les URL de base de données, les chaînes de connexion, les cookies de session, les jetons de rafraîchissement, les jetons de déploiement, les clés de signature, les jetons GitHub ou GitLab, les identifiants cloud, les mots de passe SMTP, les jetons Slack, les clés Stripe et les clés de fournisseurs LLM.

Certaines clés semblent “publiques” car elles sont utilisées dans le frontend ou dans la documentation du fournisseur, mais même dans ces cas-là, il faut comprendre les restrictions, les portées (scopes) et les possibilités d’abus. Une clé anonyme Supabase n’est pas la même chose qu’une clé de rôle de service, et un jeton de test peut tout de même lire des données de staging, envoyer des emails, consommer du crédit ou ouvrir une voie vers des systèmes internes.

Avant de publier, chaque secret devrait avoir au moins quatre informations : à quoi il sert, dans quel environnement il est valide, quels privilèges il accorde et où il est conservé. Si une clé n’a pas de propriétaire, de date d’expiration ou de portée claire, il devient difficile de décider quoi faire lorsqu’elle apparaît dans un diff généré par l’IA.

Où finissent les secrets pendant le “vibe coding”

Le premier endroit à contrôler est le code lui-même : sources, configurations, tests, scripts, exemples et fichiers générés. Les agents peuvent insérer des valeurs réelles dans config.ts, settings.py, docker-compose.yml, les workflows CI/CD, les migrations, les seeds, les fixtures, les scripts de déploiement ou les fichiers de test, transformant un exemple temporaire en une configuration qui arrive jusqu’au commit.

Le deuxième endroit est le dépôt autour du code : fichiers .env sous diverses variantes, sauvegardes, fichiers .pem, clés téléchargées depuis des fournisseurs cloud, identifiants CLI, dossiers cachés de l’outil, sorties de débogage et fichiers temporaires. Un .gitignore incomplet suffit pour transformer un raccourci local en une fuite permanente dans l’historique Git.

Le troisième endroit, souvent le plus sous-estimé, est en dehors du dépôt : prompts, discussions, tickets, issues, commentaires de PR, logs CI/CD, artefacts, images de conteneurs, source maps, rapports de test, captures d’écran, rapports de crash et systèmes d’observabilité. Supprimer une clé du fichier ne supprime pas la clé de la discussion où elle a été collée ou du log où elle a été imprimée.

Codage en dur : quand le code fonctionne tout de suite mais expose trop

Le modèle le plus simple est aussi le plus fréquent : pour connecter un service, l’IA suggère une clé directement dans le code ou dans un exemple copiable. Dans une démo locale, cela semble inoffensif, mais dans une PR, dans un dépôt partagé ou dans un déploiement automatique, cela devient un accès réel. Les cas les plus courants incluent des URL de base de données dans des fichiers côté serveur, des jetons API dans des fonctions d’intégration, des clés de paiement dans les tests, des mots de passe SMTP dans les configurations, des secrets JWT codés en dur, des secrets de webhook copiés dans des gestionnaires et des clés de service utilisées pour contourner un problème d’autorisation.

La correction ne consiste pas seulement à “déplacer vers une variable d’environnement”. La variable doit être gérée dans un gestionnaire de secrets ou dans le système de déploiement avec les permissions appropriées, séparée par environnement, non imprimée dans les logs et non accessible au frontend. Si la clé a été committée ou partagée, elle doit être renouvelée.

Fichiers .env, fichiers d’exclusion et configurations locales

Les fichiers .env sont utiles pour le développement, mais deviennent risqués lorsque l’IA les crée ou les modifie sans convention claire. Un agent peut générer un .env.example avec des valeurs réelles, suggérer un .env.production pour simplifier le déploiement ou insérer un fichier d’identifiants dans le projet parce qu’un SDK l’exige.

Il est important de contrôler .gitignore, .dockerignore, les fichiers d’exclusion de l’outil IA et ceux utilisés par l’IDE ou l’agent, car dans certains flux de travail, il est nécessaire d’empêcher les dossiers locaux, les fichiers .env, les clés privées, les sorties de build ou les répertoires de configuration d’entrer dans le contexte de l’assistant. L’objectif n’est pas seulement d’éviter le commit : c’est de réduire ce que l’agent peut lire et réutiliser.

Un bon modèle consiste à maintenir un .env.example avec des noms de variables et des valeurs fictives, à documenter où obtenir les clés réelles et à utiliser des gestionnaires de secrets ou des paramètres protégés de la plateforme pour le staging et la production. Chaque fichier contenant des valeurs réelles devrait rester en dehors du dépôt et en dehors des prompts.

Prompts, discussions et historique de l’agent

De nombreuses fuites ne naissent pas du code, mais de la conversation. Lors du débogage, il est facile de coller une erreur complète avec des en-têtes, des jetons, des URL signées, des payloads, des chaînes de connexion ou des captures d’écran de tableaux de bord : l’assistant répond, la discussion reste enregistrée et l’équipe oublie que ce secret est sorti du périmètre du projet.

La règle opérationnelle est simple : ne collez pas de secrets dans les prompts. Lorsque vous demandez de l’aide sur une erreur, il suffit de remplacer les jetons et les clés par des espaces réservés (placeholders), d’utiliser des données synthétiques et de réduire les payloads au minimum. Si une clé réelle a déjà été partagée dans une discussion, elle doit être traitée comme exposée : il faut vérifier le fournisseur, la renouveler et contrôler les accès anormaux.

Le mode privé, les plans entreprise ou les paramètres de rétention peuvent réduire certains risques, mais ils ne transforment pas un secret collé dans une discussion en une bonne pratique. Même lorsque la donnée n’est pas utilisée pour l’entraînement, elle peut rester dans l’historique, les logs, les exportations, les systèmes de support ou le contexte opérationnel de l’outil selon les paramètres du service.

Logs de build, de test et de déploiement

Les scripts générés par l’IA peuvent en dire trop. Un console.log(config), un printenv, une erreur d’initialisation, un test échoué ou une commande de débogage peuvent exposer des variables d’environnement dans les logs CI/CD, qui sont souvent visibles par plus de personnes que le dépôt, conservés pendant des semaines ou copiés dans des artefacts.

Il vaut la peine de contrôler les workflows GitHub Actions, GitLab CI, Vercel, Netlify, Replit, les builds Docker, les scripts npm, les test runners et les systèmes de déploiement, en cherchant des sorties qui montrent des configurations, des en-têtes, des jetons, des URL complètes, des chaînes de connexion ou des payloads. Il est important de vérifier également le masquage des secrets, car tous les jetons personnalisés ne sont pas masqués automatiquement et certaines transformations peuvent contourner les protections. Chaque modification apportée aux builds, aux tests et aux déploiements devrait être révisée dans le cadre de la sécurité des secrets, même lorsque l’IA n’intervient que pour “aider au débogage”.

Artefacts, bundle frontend et source maps

Un secret peut sortir même après la build. Si une variable privée est utilisée dans le code côté client, elle peut finir dans le bundle JavaScript ; si les source maps sont publiques, elles peuvent révéler des détails que l’équipe pensait internes ; si une image de conteneur inclut des fichiers .env ou des identifiants dans des couches précédentes, les supprimer lors d’une étape ultérieure peut ne pas suffire.

Cette étape est particulièrement importante pour les applications générées avec v0, Lovable, Bolt.new, Replit Agent ou d’autres outils qui connectent rapidement le frontend, les API et le déploiement. Dans le frontend, il faut distinguer avec précision les variables publiques et privées : des préfixes comme NEXT_PUBLIC_ ou équivalents rendent une variable disponible au navigateur, donc si l’IA déplace une clé privée dans une variable publique pour résoudre une erreur, le déploiement peut l’exposer à quiconque ouvre les outils de développement (DevTools).

Agents avec terminal, système de fichiers et MCP

Lorsqu’un agent peut lire des fichiers, exécuter des commandes ou utiliser des outils externes, le risque change de nature. Le problème n’est pas que l’agent “veuille” voler des secrets, mais que le contexte opérationnel peut inclure des fichiers et des sorties sensibles : une commande peut lire un .env, un outil MCP peut accéder à des dépôts ou à des tickets, une session distante peut contenir des identifiants d’environnement.

Avant de donner à un agent un accès opérationnel, il est utile de séparer les secrets d’exécution (runtime) de l’espace de travail de développement, en utilisant des environnements dédiés, des identifiants à portée minimale, des fichiers d’exclusion, une approbation pour les commandes sensibles et des comptes de service non réutilisés en production. Pour MCP et les outils externes, il faut cartographier quels systèmes peuvent être lus ou modifiés — dépôts, gestionnaires de tickets, bases de données, cloud, stockage de fichiers, CI/CD, gestionnaires de secrets — car si un outil peut accéder à un secret, ce secret doit être gouverné comme faisant partie du périmètre de l’agent.

Dépôt privé ne signifie pas secret protégé

Un dépôt privé réduit l’exposition, mais ce n’est pas un gestionnaire de secrets. Les identifiants dans le code peuvent être lus par des collaborateurs, des forks internes, des CI/CD, des outils d’analyse, des applications installées, des sauvegardes, des miroirs, des agents et des comptes compromis. Si le dépôt devient public par erreur ou est partagé avec un fournisseur, les secrets dans l’historique deviennent immédiatement critiques.

Le problème de l’historique Git est particulièrement pertinent : même si vous supprimez la clé du dernier commit, elle peut rester dans les commits précédents, les branches, les tags, les pull requests, le cache ou les forks. Réécrire l’historique peut réduire la visibilité, mais ne garantit pas que personne n’a déjà lu le secret, donc la rotation reste nécessaire. Avant d’ouvrir un dépôt à de nouveaux collaborateurs, de publier un modèle, de partager une démo ou de connecter des agents externes, il est indispensable d’effectuer une analyse sur l’historique, les branches et les tags, et pas seulement sur l’arborescence de travail (working tree).

Analyse des secrets : nécessaire, mais pas suffisante

L’analyse des secrets (secret scanning) et la protection contre le push (push protection) sont des contrôles fondamentaux qui bloquent de nombreuses erreurs avant qu’elles n’arrivent dans le dépôt distant et aident à détecter des clés connues déjà présentes dans la base de code. GitHub, les fournisseurs cloud et divers outils de sécurité offrent des contrôles utiles sur des modèles reconnus.

La limite est que chaque secret n’a pas une signature connue : les jetons internes, les chaînes personnalisées, les identifiants fragmentés, les secrets composés, les valeurs codées, les fichiers propriétaires ou les clés générées par des systèmes d’entreprise peuvent échapper aux scanners standard. Même un jeton réel mais expiré peut signaler un problème de processus, car s’il est arrivé là une fois, cela peut se reproduire. Pour les projets générés par IA, la stratégie la plus solide combine des scanners automatiques, des modèles personnalisés, une revue manuelle et des contrôles sur les sorties : un scanner propre est un bon signe, pas une preuve définitive.

Rotation : quand supprimer ne suffit pas

Si une clé a été exposée, la question n’est pas “l’avons-nous supprimée ?” mais “est-elle encore valide ?”. Un secret committé, imprimé dans un log, collé dans une discussion, inclus dans un artefact ou partagé dans un ticket doit être considéré comme compromis tant qu’il n’est pas renouvelé ou révoqué.

La rotation doit suivre une séquence ordonnée : identifier le service, comprendre les privilèges et les consommateurs, créer une nouvelle clé, mettre à jour les environnements et les pipelines, vérifier que l’application fonctionne, révoquer l’ancienne clé et contrôler les logs d’accès pour détecter une utilisation anormale. Dans les systèmes critiques, il faut également vérifier si le secret donnait accès à des données clients, des paiements, au cloud ou à des dépôts.

Pour réduire l’impact futur, il est utile d’utiliser des portées minimales et des clés séparées par environnement : une clé de développement ne devrait pas pouvoir lire la production, un jeton utilisé par une pipeline ne devrait pas avoir de privilèges administratifs globaux et un secret de webhook ne devrait pas être réutilisé entre différents services.

Que faire lorsque vous trouvez un secret exposé

Lorsqu’une clé émerge dans une PR générée par l’IA, dans un log ou dans une discussion, la première question n’est pas comment nettoyer le fichier, mais quelle capacité cet identifiant accorde-t-il : peut-il lire une base de données, modifier le cloud et IAM, envoyer des paiements ou des emails, effectuer des déploiements, accéder à des dépôts ou à des données clients ?

L’étape suivante consiste à délimiter l’exposition en cherchant la même valeur dans l’arborescence de travail, l’historique Git, les branches, les tags, les PR, les logs CI/CD, les artefacts, les images de conteneurs, les source maps, les issues, les tickets, les prompts et les discussions. S’il apparaît à plusieurs endroits, la rotation doit couvrir tous les consommateurs et le nettoyage doit inclure les systèmes qui conservent des copies.

La séquence correcte est : créer une nouvelle clé avec une portée minimale, mettre à jour l’application et la pipeline, vérifier que le service fonctionne, révoquer l’ancienne clé et contrôler les logs d’accès du fournisseur. Si l’identifiant concernait la production, des données clients, des paiements, des dépôts ou le cloud, la découverte devrait bloquer la mise en ligne jusqu’à ce que la rotation soit terminée.

Même une clé “de test” doit être vérifiée, car de nombreux environnements de staging partagent des données, des webhooks, des buckets ou des comptes de service plus larges que prévu. Avant de classer l’incident comme mineur, il faut contrôler l’environnement, les privilèges, les limites de dépenses, les données accessibles et les intégrations connectées.

Checklist de nettoyage avant le déploiement

Avant de publier du code généré ou modifié avec l’IA, effectuez au moins ces contrôles :

  • Analysez le dépôt, l’historique Git, les branches, les tags et les pull requests.
  • Cherchez les fichiers .env, .pem, .key, .p12, les fichiers d’identifiants, les sauvegardes et les configurations CLI.
  • Contrôlez les scripts de build, de test, de déploiement et les workflows CI/CD.
  • Vérifiez les logs récents, les artefacts, les images de conteneurs, les bundles frontend et les source maps.
  • Revoyez les prompts, les discussions, les tickets et les issues utilisés pour le débogage.
  • Séparez les clés de développement, de staging et de production.
  • Déplacez les secrets vers un gestionnaire de secrets, un coffre-fort (vault) ou des variables protégées de la plateforme.
  • Activez l’analyse des secrets et la protection contre le push là où c’est disponible.
  • Ajoutez des modèles personnalisés pour les jetons internes ou les formats propriétaires.
  • Renouvelez chaque clé exposée, suspecte ou passée dans un système non prévu.

Cette checklist doit être exécutée même si le dépôt est privé et même si l’application n’est pas encore publique, car un secret peut être exploité avant la mise en ligne (go-live) s’il donne accès au cloud, à des bases de données, à des paiements, à des emails ou à des dépôts.

Comment ISGroup peut vérifier les secrets et les configurations

ISGroup peut soutenir une vérification ciblée sur le code généré ou modifié avec l’IA, en se concentrant sur le codage en dur, les fichiers sensibles, les configurations, les pipelines, les logs, les artefacts, les dépendances et les modalités avec lesquelles les agents ont interagi avec le projet. L’objectif est de comprendre s’il existe des identifiants exposés, s’ils doivent être renouvelés et quels contrôles insérer avant le prochain déploiement.

Si dans le projet généré par IA vous trouvez… Risque principal Contrôle recommandé
Clés API, jetons, fichiers .env, chaînes de connexion ou fichiers sensibles dans le dépôt Exposition directe d’identifiants Code Review
Services, hôtes, panneaux ou API accessibles via des identifiants suspects Surfaces exploitables ou configurations exposées Vulnerability Assessment
Mode agent, CI/CD, artefacts de build, analyse de secrets et processus de fusion non gouvernés Risque répétable sur les versions ultérieures Software Assurance Lifecycle
Cloud, buckets, bases de données, IAM ou comptes de service liés à des clés exposées Privilèges excessifs ou mauvaise configuration cloud Cloud Security Assessment
App ou API déjà en ligne avec une clé potentiellement compromise Abus réel depuis l’extérieur Web Application Penetration Testing

Le choix du contrôle dépend de ce que le secret permet de faire : lire des données, modifier le cloud, envoyer des paiements, accéder à des dépôts, utiliser des API externes ou publier des déploiements. Éliminer les secrets du code avant la mise en ligne et réduire les dommages possibles en cas de nouvelle exposition sont les deux objectifs concrets à atteindre avant le go-live.

Évidences à préparer pour une revue

Pour une revue efficace, il est utile de préparer le dépôt, les branches concernées, les PR générées par l’IA, la liste des outils utilisés, les workflows CI/CD, les systèmes de déploiement, les environnements, les fichiers d’exclusion, le gestionnaire de secrets, la liste des variables critiques et les alertes d’analyse de secrets déjà reçues.

Il est tout aussi important de recueillir des indices en dehors du code : discussions où des erreurs ont été collées, tickets de débogage, logs de build, artefacts, images de conteneurs, source maps, captures d’écran, prompts partagés, fichiers README et scripts temporaires. Si une clé a été renouvelée, il est utile de conserver quand, par qui, où elle était utilisée et quels logs d’accès ont été contrôlés, car ces informations permettent de distinguer entre un secret réellement exposé, un faux positif, une clé de test sans privilèges, un identifiant de production à révoquer immédiatement et un problème de processus à corriger dans le cycle de développement.

Décision avant la publication

Bloquez le déploiement si vous trouvez des clés de production dans le dépôt, des clés de rôle de service dans le frontend, des URL de base de données avec des privilèges réels, des jetons cloud avec une portée large, des secrets dans les logs publics, des artefacts téléchargeables avec des identifiants ou des jetons collés dans des discussions sans rotation.

Vous pouvez planifier après la mise en ligne uniquement les améliorations avec un risque résiduel clair : renforcer le nommage des variables, ajouter des modèles personnalisés aux scanners, compléter la documentation, réduire la portée des clés non critiques ou améliorer l’onboarding de l’équipe. La rotation d’une clé exposée ne devrait jamais être reportée.

La décision finale doit être vérifiable : quels secrets ont été trouvés, lesquels ont été renouvelés, quels scanners sont actifs, quels fichiers sont exclus, quels logs ont été contrôlés et quel processus empêche la même erreur de revenir dans la version suivante.

Questions fréquentes

  • Si le dépôt est privé, dois-je quand même supprimer les clés API ?
  • Oui. Un dépôt privé n’est pas un gestionnaire de secrets. Les collaborateurs, les CI/CD, les agents, les applications installées, les sauvegardes et les comptes compromis peuvent quand même accéder aux identifiants.
  • Si j’ai supprimé la clé du code, dois-je la renouveler ?
  • Oui, si la clé a été committée, imprimée dans des logs, incluse dans des artefacts ou collée dans des prompts. La suppression du fichier n’invalide pas le secret.
  • L’analyse des secrets suffit-elle pour être tranquille ?
  • Non. C’est un contrôle nécessaire, mais il peut ne pas reconnaître les jetons personnalisés, les secrets partiels, les formats internes ou les identifiants présents en dehors du dépôt, comme dans les logs et les discussions.
  • Puis-je mettre des clés dans le frontend si le framework le permet ?
  • Seulement si ce sont des clés conçues pour être publiques et limitées. Les clés de service, les URL de base de données privées, les jetons administratifs, les secrets JWT et les identifiants cloud ne doivent pas finir dans le bundle.
  • Que faire si j’ai collé une clé dans une discussion IA ?
  • Traitez-la comme exposée : renouvelez-la, vérifiez les logs d’accès du fournisseur, contrôlez où elle était utilisée et informez l’équipe sur la manière de partager des erreurs sans identifiants réels.
  • Quels secrets sont les plus urgents à renouveler ?
  • Clés cloud, jetons GitHub/GitLab, clés de rôle de service, URL de base de données de production, clés API de paiement, secrets de webhook, secrets JWT, clés privées et jetons avec accès aux données clients.

[Callforaction-WAPT-Footer]

Approfondissements utiles

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *