Des clés API utilisées pour accéder à des modèles d’IA payants, notamment ceux d’OpenAI et d’Anthropic, pourraient avoir été exposées lors d’une faille de sécurité impliquant OpenCode. Des identifiants compromis pourraient permettre des activités non autorisées sur des comptes extérieurs à la plateforme de codage elle-même.
Le 17 octobre, OpenCode a identifié 1,4 % de ses utilisateurs de Console hébergée comme étant concernés. Les comptes de ce groupe avaient connecté des fournisseurs d’IA externes, et l’entreprise a averti les clients concernés par e-mail.
Pour les développeurs et les équipes de sécurité, cette distinction est importante. Une clé API compromise pourrait servir à envoyer des requêtes non autorisées directement à un fournisseur d’IA, ce qui pourrait générer des frais ou exposer des accès au-delà de la plateforme de codage.
Un ancien système détenait les identifiants des fournisseurs
Unenotification de violation a identifié un accès non autorisé à un ancien système qu’OpenCode était en train de désactiver. Des clés API tierces stockées dans les espaces de travail des clients pourraient avoir été exposées.
La documentation de Console sur les fournisseurs explique comment les administrateurs enregistrent les identifiants dans des espaces de travail partagés afin que leurs collègues puissent accéder aux modèles d’IA connectés sans manipuler eux-mêmes les clés. Les requêtes transitent par une passerelle hébergée qui prend également en charge les outils externes.
Le cofondateur Dax Raad a précisé que les clés configurées dans l’application installée localement n’atteignent jamais les serveurs de l’entreprise, distinguant ainsi le service concerné de l’ensemble plus vaste de la chaîne d’outils de développement de l’IA.
Une notification de suivi a identifié les identifiants stockés par espace de travail, fournisseur et leurs quatre derniers caractères. Elle a fixé au 17 octobre, à 00:30 UTC, la date et l’heure les plus anciennes auxquelles les clés listées pouvaient avoir été exposées, et a indiqué qu’aucune autre donnée ne semblait avoir été compromise à ce stade.
OpenCode a relié l’incident à ce qu’il a décrit comme une attaque de distillation de modèles d’IA à grande échelle, une technique consistant à recueillir les sorties d’un modèle pour entraîner un autre système.
Le cofondateur Dax Raad a également signalé des tentatives persistantes contre les systèmes de l’entreprise au cours des 48 heures précédentes. Toutefois, OpenCode n’a pas expliqué publiquement comment les attaquants avaient accédé à l’environnement obsolète ni établi si l’activité ultérieure était liée à l’intrusion initiale.
Des frais API non autorisés entraînent des révocations de clés et des remboursements
Des signalements de factures d’IA inattendues sont apparus sur X après la faille, ainsi que des mises à jour des fournisseurs concernant la révocation des clés et les remboursements.
Le développeur Colin Parsons a décrit 281 dollars US d’utilisation d’OpenAI et 168 dollars US de frais Anthropic sur des identifiants qu’il disait utiliser uniquement avec le service de codage. Une clé API copiée peut autoriser des requêtes en dehors de la plateforme où elle était stockée.
Pour empêcher toute utilisation abusive supplémentaire, Anthropic a révoqué les clés API Claude considérées comme concernées, selon Lydia Hallie. Google a également bloqué les identifiants Gemini exposés, et Evan Otero a conseillé aux utilisateurs de générer des remplaçants via AI Studio et d’examiner l’activité de leur compte.
Les remboursements ont constitué un autre volet de la réponse. Raad a déclaré que les remboursements étaient en cours. Le 19 octobre, Thibault Sottiaux, d’OpenAI, a annoncé que les clients concernés par les API recevraient le remboursement des crédits consommés pendant l’attaque.
Les équipes doivent examiner les identifiants d’IA tiers
Les équipes de sécurité chargées de superviser les accès des développeurs doivent tenir compte des clés de fournisseurs d’IA stockées dans des services de codage externes, y compris des connexions établies par des employés en dehors des systèmes gérés de manière centralisée. Ladétection des secrets existante peut repérer les identifiants accidentellement intégrés au code source, mais risque de ne pas détecter ceux qui ont été enregistrés délibérément dans des tableaux de bord hébergés.
Les organisations qui utilisent OpenCode Console doivent prendre les mesures suivantes pour évaluer une éventuelle exposition et protéger leurs comptes fournisseurs.
- Recensez les connexions concernées et examinez l’utilisation. Déterminez quels employés ont relié des comptes d’IA payés par l’entreprise à Console et consignez les identifiants concernés. Examinez l’activité des fournisseurs et les relevés de facturation à la recherche de requêtes inexpliquées, en conservant les éléments nécessaires pour contester les frais.
- Révoquez et remplacez les identifiants exposés. Renouvelez toute clé identifiée comme potentiellement compromise, même si aucun frais suspect n’est apparu. Invalidez-la directement auprès du fournisseur d’IA, car sa suppression d’OpenCode ne révoquera pas nécessairement l’identifiant. Coordonnez le remplacement avec les responsables des tâches de compilation et des services internes afin d’éviter de perturber le travail légitime.
- Renforcez les contrôles sur les intégrations externes. Attribuez des identifiants distincts aux applications individuelles lorsque cela est possible, utilisez la surveillance des API pour détecter les requêtes suspectes et configurez les limites de dépenses disponibles au niveau du fournisseur. La séparation des identifiants permet également aux équipes de déconnecter une intégration concernée sans interrompre les services sans rapport.
Les équipes chargées de la sécurité et des achats doivent également demander aux fournisseurs comment sont traités les identifiants stockés lorsque d’anciens systèmes sont mis hors service et comment les clients sont avertis lorsque ces systèmes sont compromis.
La leçon générale est que cesser d’utiliser un service n’invalide pas nécessairement les identifiants laissés derrière soi. Une clé API peut rester active longtemps après que les développeurs sont passés à autre chose.
Autres actualités de cybersécurité : la faille de sécurité de ConnectWise met les autorisations d’applications tierces sous surveillance après que des attaquants ont utilisé des intégrations cloud approuvées pour accéder aux environnements des clients.