Mercedes-Benz et la fuite de token GitHub : leçons pour vos secrets

Septembre 2023 : RedHunt Labs découvre qu'un développeur de Mercedes-Benz a laissé un token GitHub en accès libre dans un repo public. Conséquence : accès potentiel à des plans de conception internes, des clés de bases de données, des mots de passe SSO, des clés API critiques. Mercedes a réagi rapidement (révocation, suppression du repo) et a annoncé qu'aucune donnée client n'avait été exfiltrée. Le cas est exemplaire — ni unique, ni le pire qu'on ait vu — pour comprendre comment un secret oublié devient une crise et comment l'éviter.

Anatomie d'une fuite type

Le scénario derrière le cas Mercedes ressemble fort à ceux qu'on voit en audit :

1. Un dev a besoin de tester localement un script qui appelle une API interne. Il met le token directement dans un fichier de config, "juste pour tester".
2. Quelques jours plus tard, il push son repo sur GitHub. Soit le repo est public dès le départ (oubli), soit il devient public plus tard, soit le repo est privé mais ses commits historiques contiennent encore le token et le repo est forké/cloné par d'autres.
3. Des scanners automatisés (RedHunt, mais aussi des bots malveillants) trouvent le token en quelques heures.
4. La fenêtre d'exposition entre commit et révocation est tout ce qui sépare l'incident anodin de la crise.

GitHub fournit aujourd'hui un Secret Scanning natif qui alerte automatiquement les fournisseurs (AWS, Stripe, Google, GitHub lui-même) qui révoquent souvent en quelques minutes. C'est un filet de sécurité utile mais imparfait : il ne couvre pas les tokens internes maison.

Le bon design pour des secrets en entreprise

1. Aucun secret en clair n'importe où

C'est l'invariant n°1. Un secret n'a sa place que dans :

• Un secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Doppler, 1Password Secrets Automation).
• Une variable d'environnement injectée au runtime (jamais commitée).
• Un fichier .env local en .gitignore strict.

Tous les autres emplacements (code, config commitée, wiki interne, Slack DM, ticket Jira) sont des fuites différées.

2. Détection en pre-commit + CI

• Pre-commit : gitleaks ou detect-secrets en hook. Refuse le commit local si un secret est détecté.
• CI : re-vérifie systématiquement (un dev peut désactiver son hook local).
• GitHub Secret Scanning activé sur l'org (gratuit pour repos publics, payant via GitHub Advanced Security pour repos privés).
• Bloquant, pas warning. Un secret commité = un secret à révoquer immédiatement.

3. Scope minimal et rotation

Le pire avec le token Mercedes n'était pas qu'il existait — c'était son scope. Un token qui donne accès à plusieurs systèmes, ou qui peut écrire ce qu'il devrait juste pouvoir lire, transforme un oubli en catastrophe.

• Un token = une fonction. Pas de "super token" qui peut tout faire.
• Read-only par défaut. Write seulement si la fonction le requiert.
• Expirent court : 30-90 jours max. Rotation automatique quand possible.
• Audit log : qui a accédé à quoi, quand. Détection d'anomalies sur volumes inhabituels.

4. Histoire Git nettoyée si un secret y entre

Un secret commité reste dans l'historique Git, même si on le supprime du fichier dans un commit suivant. Solutions :

• git filter-repo (mieux que git filter-branch) pour réécrire l'historique.
• Force-push, prévenir tous les forks/clones, demander aux contributeurs de ré-cloner.
• En pratique, dans 90% des cas, considérer le secret comme compromis et le révoquer. Réécrire l'historique est faisable mais risqué — si quelqu'un a déjà cloné, le secret reste circulant.

5. Inventaire et audit

Vous ne pouvez pas protéger ce que vous ne connaissez pas. Un audit secrets minimum :

• Scan rétroactif de tous les repos avec trufflehog (qui va plus profond dans l'historique que gitleaks).
• Inventaire vivant des secrets actifs : où vit chacun, qui l'utilise, quand expire-t-il, qui peut le faire tourner.
• Revue trimestrielle : qui a vu quoi, qui a accédé à quoi.

Les pièges classiques

"Les repos privés sont sûrs"

Faux. Les repos privés sont moins exposés au scan automatisé externe, mais :

• Un repo privé peut devenir public par erreur de configuration.
• Un employé qui part peut conserver des copies locales avant offboarding.
• Une fuite via un fork malveillant (si vos contributeurs sont nombreux) est possible.
• Un compromis du compte GitHub d'un dev expose ses repos privés.

Posture : traitez les secrets dans un repo privé comme s'il était public.

"On a un secret manager, on est ok"

Vrai si :

• 100% des services lisent leurs secrets depuis le manager au runtime.
• Aucun fallback hardcodé n'existe dans le code.
• L'accès au manager est strictement contrôlé (RBAC, MFA, audit log).

Souvent faux en pratique : les équipes mettent en place un secret manager mais gardent des .env.example avec des placeholders qui finissent par contenir de vrais secrets, ou des configs Terraform qui hardcodent.

"Les secrets de dev sont moins critiques"

Faux dans la moitié des cas. Beaucoup d'équipes utilisent des credentials AWS/GCP de dev qui ont accès à des données réelles (souvent un sample de prod), des tokens de webhook qui peuvent déclencher des actions, des keys OAuth qui partagent l'identité applicative avec la prod.

Le bon défaut : traitez tous les secrets comme s'ils étaient prod. Le surcoût opérationnel est faible, le gain de risque est important.

Que faire quand ça arrive ?

Découverte d'un secret leaké, dans l'ordre :

1. Révoquer immédiatement le secret côté fournisseur.
2. Rotation : générer un nouveau secret, déployer, vérifier que les services fonctionnent.
3. Audit log : qui a utilisé le secret entre la fuite et la révocation ? Y a-t-il des accès suspects ?
4. Communication : selon l'impact, notification équipe sécurité, RSSI, voire CNIL/clients si données personnelles. Voir Gérer un incident cyber en 7 étapes.
5. Post-mortem : comment le secret a été commité ? Quel contrôle a manqué ? Mise à jour des hooks et de la formation.

Le cas Mercedes est, dans le palmarès des incidents 2023-2024, plutôt bien géré. La leçon n'est pas "ne faites pas comme eux" — c'est "comme eux, ayez la capacité de réagir vite quand ça arrive". Parce que ça arrive.