Trouver des identifiants fuités est un problème résolu. Truffle Security s'y emploie depuis quatre ans et affiche 431 875 découvertes AWS. La moitié non résolue est l'étape d'après, celle où quelqu'un doit se connecter et supprimer la clé. Cela arrive une fois sur sept.

Truffle Security a publié un recensement cette semaine, et BleepingComputer l'a repris jeudi. Depuis août 2022, l'entreprise collecte des clés d'accès AWS là où elles apparaissent en public : historique git, datasets Hugging Face, images Docker, registres de paquets, logs CI. Puis elle vérifie si elles fonctionnent encore.

Le rapport recense 431 875 découvertes AWS vérifiées, dédupliquées en 64 024 clés d'accès uniques réparties sur 50 654 comptes distincts. Parmi elles, 10 616 paires portaient assez de matériel pour être retestées. Quatre-vingt-huit pour cent s'authentifient toujours. Cela fait 9 308 clés, actives aujourd'hui, que n'importe qui aurait pu ramasser sur une surface publique à un moment des quatre dernières années.

La vérification est restée étroite, avec des appels de métadonnées en lecture seule : sts:GetCallerIdentity, iam:ListAccessKeys, énumération des noms de politiques, une lecture de budget, un appel Cost Explorer par compte. Ils n'ont lu aucune donnée et n'ont rien modifié, et ils ont prévenu 10 260 des 10 616 propriétaires avant de publier.

Regardez ensuite l'âge des clés.

Cinq ans, et ça continue

La clé médiane qui fonctionne encore a 1 831 jours. La plus ancienne a 17,4 ans. Seules 25 clés du lot, neuf dixièmes de pour cent, datent des trente derniers jours.

Cette distribution décrit un sédiment plutôt qu'un flux d'accidents frais attrapés et nettoyés. Une clé fuite et reste fuitée, parce qu'une clé d'accès statique AWS n'a pas d'expiration : pas d'horloge, pas de renouvellement, pas de certificat qui périme au bout de dix-huit mois. Elle fonctionne jusqu'à ce que quelqu'un ouvre la console et la supprime. Truffle a mesuré la fréquence à laquelle ce quelqu'un se présente. Parmi les utilisateurs dont les chercheurs ont pu énumérer les clés, 398 sur 2 903 ont une clé plus récente à côté de la clé fuitée, soit 13,7%. Les 2 505 restants ne l'ont jamais fait tourner.

On ne peut pas non plus mettre cela sur le dos de la détection, parce qu'Amazon avait déjà fait la découverte. Quand AWS repère l'une de ses propres clés en public, il attache à l'utilisateur une politique appelée AWSCompromisedKeyQuarantine, restreint ce que la clé peut faire, et envoie un e-mail au compte. Personne n'a besoin de le lui demander. Truffle a trouvé 929 utilisateurs IAM, 12% des 7 590 actifs, portant cette politique en ce moment même. Cent douze d'entre eux portent la version originale, donc AWS les a signalés il y a au moins trois ans et ils répondent toujours.

La détection a fonctionné, l'e-mail est parti, et trois ans plus tard la clé est encore bonne.

Une clé d'accès statique AWS n'a pas d'expiration, donc une fuite n'a pas de date de fin. La seule chose qui la referme est une personne qui supprime la clé, et sur 2 903 utilisateurs énumérables cela s'est produit 13,7% du temps, y compris pour les 929 utilisateurs qu'AWS avait lui-même signalés et mis en quarantaine.

La surface de fuite s'est déplacée là où il n'y a pas de bouton supprimer

La plus grande source unique de tout le recensement est Hugging Face : 8 482 clés actives uniques réparties sur 3 394 datasets, et un taux de clés root de 17,9%, bien au-dessus du reste de la population.

Truffle avait déjà mesuré l'autre bout de ce tuyau. En juin, l'équipe a cloné tous les datasets publics de Hugging Face : 186,9 millions de fichiers uniques, 7,6 pétaoctets, environ 815 000 dépôts de datasets. Elle a aplati Parquet, Arrow, JSONL et archives en texte analysable et vérifié tout ce qu'elle trouvait. Résultat : 221 303 identifiants actifs et uniques dans 6 003 datasets : 11 496 clés de fournisseurs d'IA, 8 557 clés de comptes de service Google Cloud sur 3 811 projets, 8 594 accès de base de données fonctionnels, 3 343 clés AWS qui passent un contrôle d'identité STS, 349 jetons d'accès personnels GitHub dont 223 peuvent pousser du code et 130 réécrire des workflows CI.

Deux de leurs exemples montrent jusqu'où va une seule erreur. Quelqu'un a collé la clé AWS d'une fintech brésilienne dans un chatbot, et elle réapparaît aujourd'hui recopiée environ dix-huit fois dans différents corpus. Une clé Infura captée de la même manière a fini dans 1 131 datasets et 10 162 emplacements de fichiers distincts. Quarante-quatre pour cent des secrets actifs uniques trouvés par Truffle apparaissent dans plus d'un dataset.

Ensuite, les gens entraînent des modèles sur ces datasets. Les données d'entraînement documentées de StarCoder contiennent 25 217 de ces clés ; Swallow, 22 484 ; OLMo 3, 21 278. Les grands modèles propriétaires gardent leurs corpus privés, donc personne à l'extérieur n'en sait rien.

Truffle en tire la conclusion brutale : la rotation reste le seul remède, parce que personne ne peut revenir en arrière nettoyer des données d'entraînement. Considérez comme brûlée toute clé ayant un jour atterri dans un dépôt public, une page web ou un chatbot.

Un identifiant qui atteint un dataset public ne peut pas être retiré. Truffle a trouvé 44% des secrets actifs dupliqués entre corpus, une clé Infura dans 1 131 datasets, et des dizaines de milliers de clés fonctionnelles dans les données d'entraînement documentées de modèles ouverts. Supprimer le fichier d'origine ne change rien en aval.

Chaque source de cette liste est quelque chose qu'un agent écrit

Regardez de nouveau où Truffle est allé faire ses courses : historique git, images Docker, registres de paquets, logs CI, dépôts de datasets. Ce sont des sorties de build, et ce sont les artefacts qu'un agent de code produit désormais sans surveillance, la nuit, à un rythme qu'aucune équipe ne pourrait relire.

Un agent qui traite un backlog pendant que vous dormez écrit des commits, réécrit des lockfiles, construit des images, pousse des branches et remplit des logs. Chacune de ces choses est une surface de publication, et l'agent a votre ~/.aws/credentials à portée tout du long, parce que c'est ainsi que le SDK est conçu pour le trouver.

Les agents de code écrivent ces artefacts plus vite que n'importe quel outil avant eux, et les 13,7% n'ont pas bougé.

La moitié qui signe reste sur votre Mac

Bromure Agentic Coding exécute l'agent dans une VM Ubuntu jetable sur le framework Virtualization d'Apple, avec un proxy côté hôte pour seule sortie. AWS demande un traitement propre dans cette conception. SigV4 ne met jamais le secret sur le fil, puisque le SDK le consomme en interne pour calculer un HMAC, donc un proxy n'a rien à substituer en transit. Bromure déplace donc la signature.

Dans la VM, ~/.aws/config nomme un assistant credential_process. Quand le SDK demande des identifiants, l'assistant renvoie le véritable identifiant de clé d'accès associé à un faux secret de quarante caractères, frappé à neuf à chaque session. L'identifiant de clé d'accès est un identifiant, pas un secret, et c'est la moitié qui indique quel utilisateur IAM appelle. La clé d'accès secrète est la moitié qui signe, et elle n'entre jamais dans l'espace d'adressage de la VM. Bromure n'exporte même pas AWS_ACCESS_KEY_ID ni AWS_SECRET_ACCESS_KEY dans l'environnement de l'invité, au motif que les variables d'environnement fuient par /proc, ps -E et l'historique du shell. La VM reçoit une chaîne de région et rien d'autre.

Le SDK signe une requête dont la signature ne peut pas être correcte. À la sortie, l'hôte retire cette signature et recalcule SigV4 avec le vrai matériel. aws, boto3 et terraform fonctionnent comme d'habitude. Tout ce qui contourne le proxy reçoit un InvalidSignatureException d'Amazon, ce qui est l'échec que vous voulez.

Passez maintenant un espace de travail Bromure à la méthodologie de Truffle. Leur critère pour compter une clé est un sts:GetCallerIdentity signé qui revient valide. Supposez qu'une dépendance compromise récupère le fichier d'identifiants dans cet invité, ou que l'agent se laisse convaincre de le cat, ou qu'un build l'inline dans un bundle public. Ce qui sort est un identifiant et quarante caractères qui n'ont jamais été le secret. Cela échoue le jour de la fuite, donc cela ne rejoint jamais la couche de sédiment et il n'y a pas de traîne de cinq ans derrière.

Cela supprime aussi l'étape de rotation qui attend un humain. Le vrai secret vit à un seul endroit, sur votre Mac, dans le panneau Identifiants du profil. Changez-le là et la session suivante le reprend. Personne n'a à déterminer laquelle des quatre-vingt-dix exécutions nocturnes a écrit quel artefact.

Les identifiants AWS dans un espace de travail Bromure : l'identifiant de clé d'accès désigne l'appelant et entre dans la VM, la clé d'accès secrète signe et n'y entre pas. L'invité signe une requête vouée à l'échec, l'hôte la resigne avec le vrai matériel, et tout ce qui est récupéré dans la VM échoue au même contrôle STS que celui qu'utilisait le recensement pour compter les clés actives.

Une requête signée plus étroite que la clé qui la signe

L'autre gros titre du recensement, c'est la portée. Sur 817 clés rattachées à une entreprise, 768 donnaient le contrôle total du compte : 526 clés root et 242 utilisateurs IAM détenant AdministratorAccess. Cent trente de ces clés root se trouvent sur des comptes de gestion d'organisation, le compte qui gouverne tous les comptes membres de l'organisation. Sur l'ensemble des utilisateurs que les chercheurs ont pu énumérer, 976 détenaient AdministratorAccess, soit 84%.

Ce sont des clés frappées par commodité, il y a des années, pour une tâche qui avait besoin de trois permissions.

Le réglage Garde-fous de Bromure resserre l'identifiant au point d'usage, pour que vous n'ayez jamais à penser à le resserrer à la source. C'est un moteur de politique côté hôte, dans le proxy. Pour AWS, il lit le nom de l'action dans l'en-tête X-Amz-Target pour les services au protocole JSON comme DynamoDB et Lambda, ou dans le paramètre Action= pour les services au protocole query comme EC2, IAM et SQS, et se rabat sur la méthode HTTP pour S3. Delete*, Terminate*, Remove*, Purge* et Destroy* sont classés destructeurs ; Get*, List* et Describe* sont classés lectures. Réglez le profil sur Lecture seule et une mutation revient en 403 sec que l'agent lit comme un échec d'API ordinaire. Réglez-le sur Bloquer les opérations destructrices et les créations et mises à jour passent, mais pas les suppressions.

C'est votre Mac qui applique cela, pas la VM, donc un agent que l'on a convaincu de quelque chose ne peut pas argumenter pour passer outre. L'identifiant avec lequel votre hôte signe finit plus étroit que l'identifiant lui-même, ce qui a de la valeur dans une population où 84% des utilisateurs énumérables portaient les droits admin.

La trace arrive avant la facture

Encore un chiffre du rapport. Sur les 2 754 comptes dont les chercheurs ont pu lire le budget, 262 ont une alerte de budget configurée, soit 9,5%, à un plafond médian de huit dollars. Ce même ensemble a dépensé 420 631 dollars en juillet, avec cinquante comptes au-dessus de 1 000 dollars et neuf au-dessus de 10 000. La plupart de ces propriétaires rencontreront leur intrus sur une facture.

Bromure écrit la trace pendant que le travail se fait. Chaque requête que l'hôte signe émet une ligne credential.aws_sign dans Fenêtre → Chronologie de sécurité, portant le service, la méthode, l'hôte, la région et l'identifiant de clé d'accès masqué, aux côtés des récupérations de paquets, des verdicts du pare-feu et des substitutions d'identifiants. Bromure garde ce journal sur le Mac, où rien à l'intérieur de la VM ne peut le modifier. Pour la version plus stricte, AWS → Exiger une approbation à l'usage transforme chaque appel de signature en une demande de consentement avec une autorisation limitée dans le temps, de sorte qu'un après-midi de vrai travail ne demande qu'une fois.

Bromure applique la même idée une étape plus tôt, quand vous montez un profil pour la première fois. Il passe la configuration d'agent que vous importez dans une passe de rédaction : JSON, TOML et YAML structurés filtrés par nom de clé, avec correspondance sur token, secret, password, apikey, credential, authorization, private_key et access_key, et texte libre filtré par forme de jeton, avec correspondance sur AKIA, ASIA, sk-ant-, ghp_, glpat-, AIza et npm_. Quels que soient les vrais secrets présents dans les dotfiles de votre Mac, ils ne montent pas dans la VM avec le reste de la configuration.

Ce que prouve le recensement

Truffle Security a bien mené l'affaire : appels en lecture seule, aucune donnée touchée, 10 260 des 10 616 propriétaires prévenus avant publication. AWS s'en sort mieux que le titre ne le laisse croire, puisque la politique de quarantaine, c'est Amazon qui trouve ses propres clés fuitées et prévient le propriétaire sans qu'on le lui demande. Les deux moitiés de la chaîne de détection ont fait leur travail.

Le résultat reste 9 308 clés actives d'un âge médian de cinq ans, et un taux de rotation de 13,7%.

Le contrôle défaillant demande à une personne d'accomplir une corvée des mois ou des années après l'erreur, sur un système qui n'est peut-être plus le sien, pour une clé qui ne donne aucun signe de poser problème. Les contrôles de cette forme échouent à l'échelle, et ils échouaient déjà avant que quoi que ce soit ne se mette à écrire des commits la nuit.

Alors cessez de demander à la corvée de porter tout le poids. Mettez dans l'espace de travail un identifiant qui n'a jamais été l'identifiant, et le recensement n'a plus rien à compter, le corpus n'a plus rien à recopier, et la traîne de cinq ans appartient à quelqu'un d'autre.

Sources : Truffle Security, « Leaked Corporate AWS Keys Held Full Admin Rights » (19 août 2026) · Truffle Security, « Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets » (1er juin 2026) · Truffle Security, « Introducing TruffleHog AWS Analyze » (20 août 2026) · BleepingComputer, « Hundreds of leaked AWS keys give full control over corporate accounts » (21 août 2026) · Cybernews, « Massive exposure: researchers test leaked AWS keys, 9 out of 10 still authenticate » (21 août 2026)