En 2026, une société de sécurité a évalué Baseten, une plateforme d’IA valorisée à 13 milliards de dollars. En seulement 25 minutes, ils ont obtenu un accès administrateur à ses principaux dépôts de code internes. Ce processus d’intrusion, presque sans obstacle, n’a utilisé aucune faille logicielle du début à la fin.
Fouiller l’historique des images publiques pour dérober les droits suprêmes du système
Strix est une entreprise de sécurité développant des agents de pénétration autonomes. Avant de décider de transférer des données, ils ont effectué un scan de routine sans identifiants sur Baseten. Le point de départ de la reconnaissance était un registre d’images de conteneurs, l’équivalent d’un conteneur de fret pour les paquets logiciels. L’un des projets du registre était entièrement public. N’importe qui pouvait lister les fichiers sans mot de passe et même demander un jeton anonyme pour télécharger des données.
La faille fatale était imprimée sur un journal appelé « historique de build ». Lorsque Docker empaquette un logiciel, il grave chaque commande de build dans l’historique, comme un reçu horodaté. L’une des commandes de configuration affichait directement une variable nommée GITHUB_TOKEN en texte clair.
Les développeurs ont utilisé ce jeton comme substitut de mot de passe, dans le but de fluidifier le processus de récupération du code pour le système. La documentation officielle avertit explicitement que les paramètres de build seront enregistrés. Cependant, par souci de commodité, les ingénieurs ont écrit la variable directement dans la commande. Les normes de sécurité ont cédé le pas à la vitesse de développement, franchissant allègrement les lignes rouges connues de l’industrie.
Image : Le jeton dans l’historique de build de Docker et les informations du compte renvoyées par GitHub. Source : Strix Post-mortem
Un jeton inchangé depuis trois ans cède le contrôle du dépôt central
En suivant cette piste exposée, Strix a acquis un jeton actif appartenant à une organisation interne de Baseten. Ce jeton leur a accordé l’accès à sept dépôts internes. Trois de ces zones à haut risque comprenaient des privilèges d’administrateur et l’autorité suprême pour pousser du code. Ces trois nœuds formaient la chaîne d’approvisionnement complète, du développement du code jusqu’au déploiement chez le client.
Une fois le dépôt du produit principal compromis, les intrus peuvent discrètement injecter une logique malveillante dans le code exécutant les modèles d’IA. Le dépôt GitOps est l’autoroute directe vers l’environnement de production ; il contenait même des sous-répertoires classés par noms de clients. Prendre le contrôle de la chaîne d’outils de distribution équivaut à ouvrir une porte dérobée sur les ordinateurs de tous les développeurs utilisant cet outil.
L’horodatage enregistré s’était arrêté au 3 mars 2023. Jusqu’à sa découverte en juillet 2026, ce jeton est resté pleinement fonctionnel. Le pouvoir destructeur d’un identifiant dont la validité est dépassée depuis trois ans dépasse de loin celui d’un cheval de Troie soigneusement programmé. Les entreprises dépensent des fortunes en pare-feu pour bloquer les attaques externes, tout en fermant les yeux sur des autorisations internes non mises à jour depuis des années.
Image : Le périmètre du jeton et l’organisation d’appartenance renvoyés par GitHub. Source : Strix Post-mortem
Une leçon à 13 milliards de dollars évitable par une vérification locale
Dès réception du rapport, l’équipe de sécurité de Baseten a réagi rapidement, renouvelant le jeton et verrouillant le projet public dès le lendemain après-midi. L’entreprise valorisée à 13 milliards de dollars a fait preuve de la détermination nécessaire pour empêcher la propagation de la catastrophe. Les identifiants avaient déjà fuité dans l’historique de build. Modifier le fichier de build à ce stade ne pouvait pas rappeler les images téléchargées. Le seul remède était de révoquer le jeton à la source.
La cause directe de l’incident était l’utilisation par les ingénieurs de la commande git config pour écrire une URL contenant le jeton dans la configuration globale. La pratique standard consiste à utiliser des identifiants chiffrés montés temporairement pour l’authentification. Les jetons doivent être considérés comme « lire et détruire » ; ils ne doivent jamais être laissés sur les disques durs ni dans les journaux d’historique.
Prévenir ce niveau de fuite d’identifiants nécessite seulement d’exécuter un simple filtre de correspondance de mots-clés localement avant le déploiement du code. Lorsque les étapes d’examen obligatoire font défaut dans le processus de développement, les erreurs élémentaires voyagent sans encombre jusqu’à l’environnement de production.
L’effondrement de la défense du système prend racine dans les habitudes des ingénieurs
Les zones où les défenseurs baissent facilement la garde sont souvent des recoins historiques oubliés. Les équipes se concentrent sur les applications principales et les dépôts de code les plus récents, oubliant souvent une image de conteneur dont la période de maintenance est dépassée depuis longtemps. Même si vous analysez les fichiers de contenu de l’image, le fait d’ignorer son historique de build permet à ce jeton mortel de rester en liberté.
L’intrusion a exploité trois vulnérabilités entièrement configurées par des humains : un dépôt lisible publiquement, des paramètres mal enregistrés et un jeton non renouvelé depuis trois ans. Il n’y a eu aucune technologie inconnue dévastatrice, seulement des portes laissées grandes ouvertes par les gardiens eux-mêmes.
Les faiblesses de sécurité de la chaîne d’approvisionnement en IA se cachent souvent dans les habitudes de configuration et d’hygiène les plus élémentaires des ingénieurs. La preuve empirique qu’il est possible de s’emparer des atouts majeurs d’une entreprise de 13 milliards de dollars en 25 minutes établit la ligne de base de sécurité la plus évidente : même la protection système la plus coûteuse ne peut remplacer une commande d’inspection ignorée.
Liens de référence :
- Strix Post-mortem
