Le 20 mai 2026, GitHub a confirmé que des attaquants avaient volé des données d'environ 3 800 de ses dépôts de code internes. Le point d'entrée n'était pas une vulnérabilité « zero-day » dans les serveurs de GitHub. Il s'agissait d'une extension VS Code empoisonnée installée sur l'ordinateur portable d'un seul employé. Une fois que cette extension s'est exécutée avec les mêmes permissions de système de fichiers que le développeur, elle a pu lire tout ce qui était à sa portée : code source, fichiers de configuration et toutes les informations d'identification (credentials) se trouvant dans l'espace de travail. Si vous voulez protéger les clés API de la même catégorie d'attaque, la leçon est inconfortable mais simple. Le maillon faible est rarement le cloud. C'est la machine du développeur et les outils qui s'y exécutent.
TL;DR
Pour protéger les clés API contre une extension IDE compromise ou un dépôt divulgué, cessez de stocker les informations d'identification (credentials) actives là où les outils de développement peuvent les lire. Gardez les secrets hors du code source et des fichiers .env committés. Considérez .gitignore comme une commodité, et non comme un contrôle de sécurité. Limitez la portée de chaque clé à un seul environnement, utilisez des informations d'identification (credentials) de courte durée et à privilège minimum, et faites-les pivoter (rotate) selon un calendrier. Des outils comme Apidog aident en stockant les informations d'identification (credentials) API dans des variables d'environnement avec des valeurs uniquement locales, au lieu de les laisser en clair éparpillées dans votre dépôt et votre espace de travail.
Pourquoi la violation de GitHub est un signal d'alarme pour chaque développeur
L'incident de GitHub s'apparente à une attaque de la chaîne d'approvisionnement typique. Le groupe de menaces, suivi sous le nom de TeamPCP, a l'habitude de « trojaniser » des packages dans les écosystèmes npm, PyPI et PHP. Cette fois, la charge utile malveillante est arrivée via une extension VS Code. Selon les rapports de TechCrunch, les attaquants ont exfiltré des données d'environ 3 800 dépôts internes et vendent maintenant l'ensemble de données pour plus de 50 000 $ sur des forums clandestins. GitHub affirme n'avoir aucune preuve que les données clients stockées en dehors de ces dépôts internes aient été affectées, et l'enquête est en cours.
Voici la partie qui devrait vous faire réfléchir. Une extension VS Code n'est que du code. Lorsque vous en installez une, elle s'exécute dans le processus de l'éditeur avec vos permissions d'utilisateur. Elle peut lister les fichiers, les ouvrir et en lire le contenu. Elle peut surveiller les modifications de fichiers. Elle peut effectuer des requêtes réseau sortantes. Rien de tout cela n'est une vulnérabilité ; c'est le modèle d'extension qui fonctionne comme prévu. La plupart des extensions ont besoin d'un accès aux fichiers pour fonctionner. Le problème est qu'une extension malveillante ou compromise utilise exactement le même accès pour collecter tout ce qu'elle trouve.
Que trouve-t-elle ? Dans un projet typique, elle trouve beaucoup de choses. Un fichier .env à la racine du dépôt. Un config/secrets.yml. Un jeton (token) codé en dur dans un script de test rapide que vous vouliez supprimer. Les informations d'identification AWS dans ~/.aws/credentials. Un .npmrc avec un jeton d'authentification. Des clés SSH. Le groupe TeamPCP est le même acteur derrière la campagne du ver npm « Mini Shai-Hulud », qui a collecté des informations d'identification (credentials) de développeurs, de CI/CD, de cloud et d'outils d'IA à partir de machines infectées. Le schéma est cohérent : faire exécuter du code sur la machine d'un développeur, puis rechercher tout ce qui ressemble à une information d'identification (credential).
Ceci n'est pas nouveau dans sa nature, seulement dans son profil. Nous avons écrit sur un schéma d'exposition similaire dans notre analyse des leçons de sécurité API tirées de la violation de Vercel, et la mécanique de la chaîne d'approvisionnement correspond étroitement à ce que nous avons abordé dans le guide de sécurité de la chaîne d'approvisionnement npm. L'incident de GitHub est la même histoire avec un nom plus important qui y est associé. Alors la question qui mérite d'être posée aujourd'hui est directe : si une extension malveillante s'exécutait dans votre éditeur en ce moment, avec quoi repartirait-elle ?
Les clés codées en dur et les fichiers .env committés constituent une vulnérabilité permanente
La plupart des fuites d'informations d'identification (credentials) ne sont pas sophistiquées. Il s'agit d'un développeur qui colle une clé dans le code « pour l'instant » et l'oublie, ou d'un fichier .env qui se glisse dans un commit. Les deux créent une vulnérabilité qui réside indéfiniment dans votre dépôt.
Les clés codées en dur sont le péché évident. Vous avez vu du code comme celui-ci :
import requests
# Test rapide du point de terminaison de paiement
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"
response = requests.post(
"https://api.stripe.com/v1/charges",
auth=(STRIPE_KEY, ""),
data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())
Cette clé sk_live_ fait maintenant partie du fichier. Elle se trouve dans votre répertoire de travail où toute extension peut la lire. Si le fichier est committé, la clé reste dans votre historique Git pour toujours, même après que vous ayez supprimé la ligne dans un commit ultérieur. Quiconque clone le dépôt, ou tout outil qui le scanne, obtient la clé.
Le fichier .env est censé être la solution. L'idée est bonne : garder les secrets hors du code, les charger à l'exécution. Un vrai fichier .env ressemble à ceci :
# .env (chargé à l'exécution, jamais destiné à être livré)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
C'est mieux que le codage en dur. Mais remarquez ce que cela n'a pas changé. Ce fichier se trouve toujours dans votre espace de travail, en texte clair, lisible par chaque processus exécuté par l'éditeur. Une extension malveillante ne se soucie pas de savoir si vos secrets se trouvent dans app.py ou dans .env. Ce sont tous deux des fichiers. Les deux sont à un fs.readFileSync de distance. Le modèle .env ne résout le problème des « secrets dans l'historique Git » que si le fichier n'est jamais committé, et il ne fait absolument rien pour le problème de l'« outil local compromis ».
Le fichier .env committé est le pire scénario. C'est une situation alarmante et courante. Un développeur ajoute .env au projet, y écrit de vraies clés et oublie de l'ignorer avant le premier commit. Ou un coéquipier clone le dépôt, voit .env.example, le copie en .env, remplit les clés de production, et un git add . ultérieur l'inclut. Maintenant, les informations d'identification (credentials) de production se trouvent dans l'historique partagé d'un dépôt qui pourrait être public, être mis en miroir, ou se retrouver dans une violation comme celle de GitHub. Nous approfondissons l'aspect des fuites de dépôts dans notre article complémentaire sur la documentation API et la sécurité des dépôts Git.
.gitignore n'est pas un contrôle de sécurité
Ceci mérite sa propre section car le malentendu est si répandu. Ajouter .env à .gitignore donne l'impression de verrouiller la porte. Ce n'est pas le cas. C'est une note autocollante qui dit « s'il vous plaît, ne prenez pas cela ».
Voici ce que .gitignore fait réellement. Il indique à Git d'ignorer les fichiers non suivis correspondant à un modèle lorsque vous exécutez git add. C'est toute sa portée. Il présente trois modes de défaillance importants pour la sécurité :
- Il ne fait rien pour les fichiers déjà suivis. Si
.enva été committé une fois, avant que vous n'ajoutiez la règle d'ignorance, Git continue de le suivre. La règle d'ignorance est silencieusement annulée. Vous devez exécutergit rm --cached .envet committer cette suppression, et le secret reste dans chaque commit historique. - Il ne fait rien pour le fichier sur le disque.
.gitignoreest une instruction Git. Le fichier.envse trouve toujours dans votre répertoire de travail en texte clair. Une extension VS Code malveillante lit le système de fichiers, pas l'index Git. Votre règle d'ignorance lui est invisible. C'est le mode de défaillance le plus important pour une attaque de type GitHub. - Il est à une erreur d'être contourné.
git add -f .envignore la règle d'ignorance. Il en va de même pour l'ajout du fichier via l'interface utilisateur de contrôle de source d'un éditeur. Il en va de même pour un autre fichier.gitignoredans un sous-répertoire qui ne répète pas le modèle.
Vous pouvez vérifier le premier point vous-même. Si vous suspectez qu'un secret a été committé, cette commande vous le montrera :
# Liste chaque commit qui a touché le fichier, même s'il est maintenant "ignoré"
git log --all --full-history --oneline -- .env
# Voir les valeurs secrètes réelles qui sont toujours dans l'historique
git log -p --all -- .env | grep -iE "key|secret|token|password"
Si cela renvoie quelque chose, l'information d'identification (credential) est compromise dès que le dépôt est exposé. La solution n'est pas une meilleure règle d'ignorance. La solution est de faire pivoter la clé et de supprimer le fichier de l'historique avec un outil comme git filter-repo. La solution plus profonde est de s'assurer que l'information d'identification (credential) active n'a jamais été dans un fichier en premier lieu.
.gitignore vaut toujours la peine d'être utilisé. Il permet de détecter les erreurs honnêtes et de garder vos diffs propres. Ne le confondez simplement pas avec une limite que l'attaquant respecte. C'est de l'hygiène, pas de la défense.
Limiter la portée, séparer, raccourcir, faire pivoter : les quatre habitudes qui réduisent le rayon d'impact
Vous ne pouvez pas garantir qu'une information d'identification (credential) ne fuira jamais. Vous pouvez garantir qu'une information d'identification (credential) divulguée est quasiment sans valeur. Quatre habitudes font l'essentiel du travail.
Limiter la portée des secrets aux environnements
Une clé divulguée ne devrait déverrouiller qu'une seule chose, pas l'ensemble de votre domaine. L'erreur de portée la plus courante est d'utiliser la même clé API en développement, staging et production parce que c'était plus facile. Lorsque cette clé fuit, chaque environnement tombe en même temps.
Donnez à chaque environnement ses propres informations d'identification (credentials). Votre machine locale utilise une clé de développement avec accès à un projet bac à sable (sandbox) et à des données de test. Le staging utilise une clé de staging. La production utilise une clé de production qui existe en un seul endroit et n'est jamais copiée sur un ordinateur portable. Si la clé de développement fuit via une extension compromise, l'attaquant atteint un bac à sable (sandbox) avec de faux clients. C'est une nuisance, pas un incident.
Séparer correctement les environnements
La séparation des environnements est plus que trois valeurs de clés différentes. Cela signifie que les environnements ne peuvent pas se joindre les uns les autres. La base de données de développement est une base de données différente, et non une réplique en lecture de la production. Le fournisseur de paiement de staging est en mode test du fournisseur, donc une clé de staging divulguée ne facture rien de réel. Les outils et les humains ne devraient pas pouvoir pointer une configuration « dev » vers des données de production en changeant une seule variable.
Lorsque la séparation est réelle, la question « de quel environnement provient cette clé ? » a une réponse claire, et cette réponse vous indique exactement la gravité d'une fuite.
Utiliser des clés à privilège minimum et de courte durée
Deux propriétés déterminent l'étendue des dégâts causés par une clé volée.
Privilège. Une clé devrait avoir l'ensemble de permissions le plus restreint requis par sa fonction. Une build frontend qui lit un catalogue de produits public a besoin d'une clé en lecture seule limitée à cette seule ressource. Elle n'a pas besoin d'un accès en écriture, elle n'a pas besoin d'un accès à la facturation, et elle n'a certainement pas besoin d'être administrateur. La plupart des fournisseurs d'API prennent en charge les clés à portée limitée ou les jetons à grain fin ; les jetons d'accès personnels à grain fin de GitHub sont un bon modèle. Si vous évaluez les styles de jetons, notre comparaison des clés API versus OAuth explique quand les jetons OAuth de courte durée l'emportent clairement sur les clés statiques.
Durée de vie. Une clé qui expire en une heure est une maigre récompense. Au moment où un attaquant achète un ensemble de données volé et s'intéresse à votre clé, celle-ci est morte. Les clés statiques qui vivent éternellement sont le contraire : elles fonctionnent jusqu'à ce que quelqu'un s'en aperçoive, ce qui prend souvent des mois. Préférez les jetons de courte durée émis à la demande. Là où une clé à longue durée de vie est inévitable, définissez la plus courte expiration que le flux de travail tolère.
Faire pivoter selon un calendrier, pas dans la panique
La rotation consiste à modifier la valeur d'une information d'identification (credential) pour que l'ancienne cesse de fonctionner. La plupart des équipes ne font pivoter les clés qu'après une violation, dans la précipitation, sous le stress. C'est le pire moment pour apprendre que votre processus de rotation n'est pas documenté.
Faites pivoter selon un calendrier plutôt. Choisissez un intervalle par classe d'informations d'identification (credentials) ; les clés de production à privilège élevé mensuellement, les clés à risque plus faible trimestriellement. La rotation régulière fait deux choses. Elle plafonne la durée de vie utile de toute fuite que vous n'avez pas encore détectée, car une clé volée aujourd'hui cesse de fonctionner au prochain cycle. Et elle maintient les mécanismes, la mise à jour de la valeur dans chaque environnement consommateur, bien rodés et routiniers. Lorsqu'un incident réel survient, la rotation est un bouton que vous avez pressé cinquante fois, pas un exercice d'incendie. Pour un traitement plus complet, consultez notre récapitulatif des outils de gestion des clés API.
Gardez les informations d'identification (credentials) dans les variables d'environnement Apidog, et non en vrac dans votre espace de travail
Voici le cadrage honnête. Apidog propose une extension VS Code et son propre serveur MCP. L'argument n'est pas « notre outil est immunisé contre la classe d'attaque qui a frappé GitHub ». Aucun outil côté client ne l'est. L'argument porte sur l'endroit où résident vos secrets et sur leur degré d'exposition lorsque quelque chose sur votre machine se comporte mal.
Pensez au scénario réaliste. Vous développez et testez des API toute la journée. Vous avez besoin d'un jeton porteur, d'une clé API, d'une chaîne de connexion de base de données. Le comportement par défaut est de les insérer dans un fichier .env ou un script afin que votre client puisse les utiliser. Cela place les informations d'identification (credentials) actives dans des fichiers en texte clair dans l'espace de travail, ce qui est exactement la surface qu'une extension malveillante parcourt. Le système d'environnement d'Apidog modifie l'emplacement de ces valeurs.
Variables d'environnement au lieu de fichiers en texte clair
Dans Apidog, vous stockez les informations d'identification (credentials) sous forme de variables d'environnement plutôt que sous forme de texte en vrac dans votre dépôt. Une requête référence la variable par son nom, comme {{access_token}} dans un en-tête Authorization, et Apidog la résout au moment de l'envoi. L'en-tête de votre définition de requête lit Bearer {{access_token}}, et non Bearer sk-proj-aB3dEf.... Le secret littéral ne se trouve pas dans un fichier .env à la racine du projet, attendant d'être lu.
Ceci est important pour la même raison que .env est préférable au codage en dur, mais un cran plus loin. L'information d'identification (credential) n'est plus une ligne en texte clair dans un fichier qui se trouve à côté de votre source. C'est une valeur gérée à l'intérieur du client API, référencée indirectement.
Les valeurs locales gardent les secrets sur votre machine
Apidog établit une distinction délibérée entre deux types de valeurs pour chaque variable. Il y a une valeur partagée, ou initiale, qui se synchronise avec les serveurs d'Apidog et est visible par votre équipe. Et il y a une valeur locale, ou actuelle, qui reste sur votre machine et n'est jamais téléchargée. Les directives officielles sont explicites : placez les données sensibles telles que les jetons et les mots de passe dans la valeur locale afin qu'elles ne quittent jamais votre client.
L'effet pratique est qu'un coéquipier qui clone la structure du projet obtient le nom et la forme de la variable, access_token, db_password, et le reste, mais pas votre secret réel. Chaque développeur renseigne sa propre valeur locale. Aucun jeton de production actif ne circule dans les données de projet synchronisées, et il n'y a pas de fichier partagé de clés réelles à divulguer.
Gestion des environnements et isolation des environnements
La gestion des environnements d'Apidog est construite autour de l'habitude de limitation de portée de la section précédente. Vous définissez des environnements distincts, Développement, Staging, Production, et chacun a sa propre URL de base et son propre ensemble de valeurs de variables. Les variables sont limitées à l'environnement : seules les valeurs de l'environnement actif sont en vigueur, et le changement d'environnement change l'ensemble complet des informations d'identification (credentials) en une seule fois.
Cela vous offre une isolation d'environnement par construction. Votre variable payment_api_key contient une clé sandbox en Développement et une clé de production en Production. Vous ne modifiez jamais une requête pour passer de l'un à l'autre ; vous changez d'environnement. Parce que les valeurs sont liées à l'environnement, une information d'identification (credential) de développement ne peut pas accidentellement se retrouver dans un appel de production, et un secret de production n'a jamais à exister dans votre environnement de développement local. Un environnement de développement divulgué expose les valeurs de développement. La production reste intacte.
Pour les équipes qui ont besoin d'une limite stricte : les secrets de coffre-fort
Si votre équipe a besoin que les secrets de production ne touchent jamais le client API, le plan Enterprise d'Apidog ajoute une fonctionnalité Vault Secret qui récupère les secrets directement de HashiCorp Vault, Azure Key Vault ou AWS Secrets Manager. Apidog stocke uniquement le chemin du coffre-fort et les métadonnées. Les valeurs secrètes réelles sont extraites à la demande, chiffrées dans le client local et jamais partagées avec les coéquipiers via le projet. Le lieu de résidence de l'information d'identification (credential) reste le gestionnaire de secrets dédié, ce qui est exactement là où une information d'identification (credential) de production devrait se trouver.
Pour essayer le flux de travail des variables d'environnement, Téléchargez Apidog, créez un projet, ouvrez la Gestion des environnements, et ajoutez vos informations d'identification (credentials) comme variables d'environnement avec des valeurs uniquement locales. Cela prend quelques minutes et cela retire les secrets actifs des fichiers en texte clair qu'une extension peut lire.
Une mise en garde honnête. Déplacer les secrets vers Apidog réduit le nombre d'informations d'identification (credentials) en texte clair qui se trouvent dans votre dépôt et votre espace de travail. Cela ne rend pas votre machine immunisée contre un outil compromis. La défense en profondeur s'applique toujours : auditez les extensions que vous installez, maintenez les clés de production avec le minimum de privilèges et une courte durée de vie, et faites-les pivoter (rotate) selon un calendrier. Apidog gère la partie « où résident les informations d'identification (credentials) ». Le reste dépend toujours de vous.
Conclusion
La violation de GitHub est un signal clair. Les attaquants ont compris que la machine du développeur, avec ses outils fiables et ses fichiers de configuration en texte clair, est une cible plus facile que n'importe quel serveur de production. Vous ne pouvez pas rendre cette machine parfaitement sûre. Vous pouvez vous assurer qu'une extension IDE compromise ou un dépôt divulgué ne donne que très peu à un attaquant.
Commencez par un audit. Ouvrez le dépôt sur lequel vous travaillez le plus et recherchez key, secret, token et password. Vérifiez si .env se trouve dans votre historique Git. Quoi que vous trouviez, considérez-le comme exposé : faites-le pivoter (rotate), puis déplacez la valeur active là où un outil égaré ne peut pas la lire. Téléchargez Apidog et placez votre prochaine série d'informations d'identification (credentials) API dans des variables d'environnement au lieu d'un fichier en texte clair. Pour un contexte plus large, nos articles complémentaires sur les outils API auto-hébergés après la violation de GitHub et les outils de gestion des clés API sont de bonnes lectures à suivre.
FAQ
Une extension VS Code peut-elle vraiment lire mon fichier .env et mes clés API ?
Oui. Une extension VS Code s'exécute dans le processus de l'éditeur avec les permissions de fichier de votre compte utilisateur. Elle peut lister les répertoires, ouvrir les fichiers et en lire le contenu, y compris les fichiers .env, les fichiers de configuration et les fichiers d'informations d'identification (credentials) comme ~/.aws/credentials. C'est un comportement normal pour une extension, car de nombreuses extensions ont légitimement besoin d'accéder aux fichiers. Le risque est qu'une extension malveillante ou compromise utilise le même accès pour collecter des secrets. C'est le mécanisme derrière la violation de GitHub de mai 2026.
L'ajout de .env à .gitignore est-il suffisant pour protéger les clés API ?
Non. .gitignore indique seulement à Git d'ignorer les fichiers non suivis lors d'un git add. Il ne fait rien pour les fichiers déjà committés avant l'existence de la règle, et le secret reste dans l'historique Git quoi qu'il arrive. Il ne fait rien non plus pour le fichier sur le disque : le fichier .env se trouve toujours dans votre espace de travail en texte clair, entièrement lisible par n'importe quel outil local ou extension. Considérez .gitignore comme un moyen de prévenir les erreurs honnêtes, et non comme une limite de sécurité.
Que dois-je faire si je trouve une clé API dans mon historique Git ?
Considérez-le comme compromis immédiatement, même si le dépôt est privé. Faites pivoter (rotate) la clé d'abord afin que la valeur exposée cesse de fonctionner. Ensuite, supprimez le fichier de l'historique à l'aide d'un outil comme git filter-repo, et faites un push forcé de l'historique nettoyé après coordination avec votre équipe. Enfin, déplacez l'information d'identification (credential) active hors de tout fichier en texte clair afin que la même fuite ne se reproduise plus. Consultez notre guide sur les outils de gestion des clés API pour les pratiques continues.
Comment le stockage des clés API dans Apidog réduit-il mon exposition ?
Apidog vous permet de stocker les informations d'identification (credentials) sous forme de variables d'environnement et de les référencer par leur nom dans les requêtes, de sorte que le secret littéral ne se trouve pas dans un fichier .env en texte clair dans votre dépôt. Chaque variable prend en charge une valeur uniquement locale qui reste sur votre machine et ne se synchronise jamais avec les serveurs ou les coéquipiers, ce qui est l'endroit où la documentation recommande de conserver les jetons et les mots de passe. Les variables à portée environnementale maintiennent également les informations d'identification (credentials) de développement et de production séparées. Cela réduit le nombre de secrets actifs qui se trouvent dans des fichiers qu'un outil peut collecter ; cela ne rend pas votre machine immunisée contre un outil compromis.
Apidog a-t-il aussi une extension VS Code, et est-ce un risque ?
Oui, Apidog propose une extension VS Code et un serveur MCP. Le but de cet article n'est pas de dire qu'un outil est immunisé contre les attaques de la chaîne d'approvisionnement ; aucun outil côté client ne l'est. Le point est de savoir où résident vos secrets. Conserver les informations d'identification (credentials) dans des variables d'environnement avec des valeurs uniquement locales, ou dans une intégration de coffre-fort, signifie que moins de clés en texte clair sont exposées si un outil sur votre machine, y compris l'extension propre à Apidog, est compromis. La défense en profondeur, l'audit des extensions, le privilège minimum et la rotation s'appliquent toujours.
Quelle est la différence entre la limitation de portée et la rotation des clés API ?
La limitation de portée restreint ce qu'une clé peut faire et où elle s'applique : une clé de développement n'atteint qu'un bac à sable (sandbox), et une clé en lecture seule ne peut pas écrire. La rotation modifie la valeur d'une clé selon un calendrier afin que l'ancienne valeur cesse de fonctionner. La limitation de portée réduit les dommages qu'une clé divulguée peut causer ; la rotation réduit la fenêtre de temps pendant laquelle une clé divulguée reste utile. Vous voulez les deux. Utilisées ensemble, une clé volée déverrouille peu et expire rapidement.
À quelle fréquence dois-je faire pivoter (rotate) les clés API ?
Faites pivoter (rotate) selon un calendrier fixe plutôt qu'uniquement après un incident. Une base de référence raisonnable est mensuelle pour les informations d'identification (credentials) de production à privilège élevé et trimestrielle pour les clés à risque plus faible, ajustée à votre tolérance au risque et à toutes les règles de conformité. La rotation planifiée limite la durée de vie utile des fuites que vous n'avez pas détectées et maintient le processus de rotation bien rodé, de sorte qu'un incident réel est une routine plutôt qu'une course effrénée.
Les clés API de production devraient-elles un jour se trouver sur l'ordinateur portable d'un développeur ?
Idéalement, non. Une information d'identification (credential) de production devrait exister dans le moins d'endroits possible, normalement un gestionnaire de secrets dédié et l'environnement d'exécution de production, jamais copiée sur la machine d'un développeur. Les développeurs devraient travailler avec des informations d'identification (credentials) de développement ou de staging limitées aux données non-production. Si un ordinateur portable est compromis, l'attaquant atteint un bac à sable (sandbox), et non des systèmes clients en direct. L'isolation d'environnement et l'intégration de coffre-fort d'Apidog soutiennent cela en gardant les valeurs de production hors des environnements de développement locaux.