Strix découvre un token GitHub admin exposé dans les images Docker publiques de Baseten
- Une startup de sécurité (Strix) a découvert un token GitHub personnel avec droits admin exécuté sur les dépôts principaux de Baseten, activé 3+ ans après son création, en scannant leurs domaines publics sans authentification.
- Le token était stocké dans l'historique de build d'une image Docker publiquement téléchargeable, un pattern classique d'exposition de secrets via les métadonnées de construction.
- Baseten a réagi en ~20 heures : rendus privé le registre Harbor concerné, révoqué le token, et traité les autres failles signalées en quelques jours.
- La chaîne d'exploitation était pure reconnaissance : domaine oublié → registre Harbor public → images téléchargeables → inspection de l'historique Docker → token GitHub valide → vérification des permissions.
Ce que dit la source
Strix (outil d'audit autonome de sécurité) a scanné les domaines Baseten sans credentials et découvert un registre Harbor public contenant des images de production. En inspectant l'historique de build de l'image baseten/baseten-app, l'outil a trouvé un token GitHub personnel d'une valeur de 13 milliards de dollars d'une startup qui gère l'inférence pour des clients sérieux. Le token disposait de droits admin et push sur le dépôt produit principal, le dépôt GitOps contrôlant l'infrastructure, le tap Homebrew, et accès read/write à des dépôts clients. L'image datait de mars 2023 ; le token fonctionnait toujours juillet 2026.
- Le token a été découvert dans le champ build history de la configuration Docker (history[].created_by), lequel conserve les commandes RUN avec variables d'environnement expandues, un endroit où les équipes oublient souvent que les secrets persisteront après suppression du Dockerfile
- Harbor, le gestionnaire de registre, était configuré de manière à autoriser les requêtes anonymes sur au moins un projet public, permettant d'énumérer les dépôts et de télécharger les manifestes d'images sans token
- Le credentials scanning (TruffleHog) couplé à l'inspection manuelle du contenu des couches a établi chaîne complète de preuve : AWS key morte → GitHub token valide → vérification des scopes (repo) et permissions par dépôt
- L'exposition ne s'arrêtait pas à un seul token : accès read/write sur plusieurs dépôts clients nommés individuellement, symétriquement accès admin sur basetenlabs/baseten (produit principal) et basetenlabs/flux-cd (infrastructure GitOps)
- Strix n'a jamais eu besoin d'authentification ; la surface d'attaque découverte était un sous-domaine oublié (gcp-us-east4-zlw.registry.baseten.co), trouvé par énumération de certificats, ce qui illustre le risque classique du black-box testing sans accès au code
Dans les commentaires
Débat limité mais consensuel : respect envers la réactivité de Baseten, mais interrogation justifiée sur l'asymétrie entre une startup qui audit ses prestataires et des clients déjà confiants (ce que signale un commentateur). Scepticisme mesuré sur le timing : découverte de 3+ ans après création du secret, ce qui pose question sur les rotations.
- Un commentateur relève l'asymétrie perverse : une jeune startup (Strix) fait du due diligence de sécurité avant de signer un service, alors que des clients importants ont déjà confié leurs données à Baseten sans audit préalable, suggérant que le due diligence était absent chez les autres clients.
- La pratique Docker critiquée (token dans RUN history plutôt que build secrets) est qualifiée de classique mais facilement évitable avec --provenance=false ou des secrets Docker scoped au build.
- Un ancien utilisateur de Strix note que l'outil a progressé depuis 5 mois, signalant un bémol de contexte polluant les résultats à l'époque, mais pas de détails sur l'impact concret.
- La nature du story : il s'agit simultanément d'un audit de sécurité légitime et d'une vitrine marketing pour Strix, ce qu'un commentateur reconnaît (
- ce n'est pas une objection au contenu mais une observation sur le positionnement stratégique).
Notre lecture
L'incident illustre un pattern classique : token de build CI/CD oublié dans les métadonnées Docker, combiné à une surface d'attaque non fermée (registre public sur sous-domaine). La réaction de Baseten a été exemplaire, ce qui limite le dommage réputationnel. Pour les équipes DevOps : l'article confirme que les image configs Docker stockent tout (y compris les secrets en clair dans history si exposés lors du build), et qu'une image téléchargeable est autant une base de reconnaissance qu'une livrable. Pour les DSI : ce n'est pas un bug Baseten-spécifique mais une classe entière de risques (secrets en build history). La vraie leçon est que l'audit de sécurité d'un prestataire avant d'envoyer code/données n'est pas paranoïa, c'est un différentiel de maturité entre Strix et les autres clients de Baseten. À intégrer dans les processus de vendor risk.