Un sous-domaine oublié. Du JavaScript public. Un token GitHub en clair. Résultat : 1,3 To de données exfiltrées chez Novo Nordisk, 4 748 dépôts de code source dans les mains d'un groupe de cyber-extorsion, et la formule d'un médicament à plusieurs milliards d'euros quelque part sur un serveur inconnu. Ce n'est pas une attaque sophistiquée. C'est une erreur de développement vieille de vingt ans, reproduite en 2026 dans l'une des plus grandes entreprises pharmaceutiques mondiales. Et ce n'est pas une anomalie — c'est le scénario qui attend des centaines d'organisations qui font exactement la même chose aujourd'hui.

L'erreur que tout le monde fait et que personne ne surveille vraiment

Commençons par la réalité terrain, sans euphémisme : hardcoder des credentials dans du code n'est pas une pratique réservée aux développeurs juniors ou aux petites boîtes sans département sécurité. C'est une erreur systémique que l'on retrouve dans des multinationales du CAC 40, dans des agences gouvernementales, dans des fintech régulées par l'ACPR. La raison n'est pas la stupidité des développeurs — c'est la pression et la culture qui entourent les environnements de développement.

Voilà comment ça se passe concrètement. Un développeur travaille sur un proof of concept ou un environnement de sandbox. Il a besoin d'accéder à un service Azure, à un dépôt GitHub privé, à une API interne. Plutôt que de passer par le processus souvent long de gestion des secrets via HashiCorp Vault ou AWS Secrets Manager, il met la clé directement dans le code — temporairement, bien sûr. Le PoC est transformé en prototype, puis en produit. Le code migre. Le secret reste. Quelqu'un déploie le frontend. Le bundle JavaScript est minifié, mais pas obfusqué. La clé est là, lisible en 30 secondes par n'importe quel navigateur, n'importe où dans le monde.

La suite, c'est un sous-domaine oublié dans le DNS de l'entreprise qui continue de servir ce JavaScript pendant des mois ou des années après que l'équipe projet l'a "fermé". Personne n'a pensé à désactiver le DNS. L'environnement est considéré comme mort, mais il est toujours accessible. Et il parle encore avec les systèmes de production via un token qui n'a jamais été révoqué. C'est exactement ce qui s'est passé avec dev.nnedl.pub.aws.novonordisk.com et datahub-sand.novonordisk.com chez Novo Nordisk.

GitGuardian, dans son rapport State of Secrets Sprawl 2026, documente 12,7 millions de secrets exposés dans des dépôts GitHub publics sur une seule année. Ce chiffre a augmenté de 22 % par rapport à 2025. La progression est mécanique : plus de code produit, plus de développeurs, plus de services cloud intégrés, plus de surface d'exposition. L'industrialisation du développement logiciel génère de la dette secrète (secret debt) à une vitesse que les équipes de sécurité ne peuvent pas absorber avec des processus manuels de revue et de correction.

Ce que peu d'organisations mesurent : les secrets supprimés d'un commit git récent sont toujours présents dans l'historique du dépôt. Supprimer un token du code dans un commit de correction n'efface pas sa présence dans les commits précédents — il suffit à un attaquant de parcourir l'historique avec git log -p pour retrouver des secrets "supprimés" il y a des mois ou des années. C'est une réalité que beaucoup de développeurs ignorent encore en 2026, et que les scanners modernes comme TruffleHog explorent systématiquement.

Ce que les attaquants trouvent — et la méthode industrielle derrière

Ne vous imaginez pas un attaquant qui tombe par hasard sur votre token en naviguant sur votre site. Les groupes comme FulcrumSec ont des pipelines industriels de collecte de secrets, construits et affinés sur plusieurs années. Ils utilisent des forks personnalisés de TruffleHog et Gitleaks, combinés à des scrapers qui indexent en continu les nouveaux commits sur GitHub public, les bundles JavaScript accessibles sur les sous-domaines d'entreprises identifiées comme cibles à fort potentiel (via Shodan, Censys, ou des bases de données sectorielles payantes), et les fuites de code source qui circulent sur des forums privés.

La méthodologie de FulcrumSec, décrite par Sysdig après l'incident Novo Nordisk, est représentative de l'état de l'art en cyber-extorsion d'entreprise. Ils maintiennent une liste de sous-domaines d'entreprises cibles, collectée via Certificate Transparency Logs (disponible publiquement via crt.sh) et des crawlers DNS passifs. Pour chaque sous-domaine actif, ils téléchargent automatiquement les ressources JavaScript et les passent dans des scanners de secrets. Le processus est entièrement automatisé. Un token trouvé est immédiatement testé contre les APIs correspondantes pour valider son périmètre d'accès réel et ses droits. Si le token donne accès à un dépôt GitHub Enterprise avec des centaines de projets privés, le groupe passe en phase d'exploitation manuelle — reconnaissance lente, cartographie des actifs les plus sensibles, exfiltration progressive pour rester sous les seuils d'alerte.

Le point le plus important à comprendre : le groupe n'a pas besoin de faille de sécurité au sens technique traditionnel du terme. Pas de 0-day, pas d'injection SQL, pas de buffer overflow à développer et maintenir. Juste un token valide trouvé dans du code public. L'ensemble de la chaîne d'attaque repose sur des APIs légitimes utilisées avec des credentials légitimes. C'est pourquoi la détection est si difficile : les logs montrent des accès normaux à l'API GitHub, des clonages de dépôts normaux, des requêtes Azure normales. Rien n'est anormal dans la forme — seul le contexte (qui fait la requête, depuis quelle adresse IP, en quelle quantité) peut trahir l'intrusion, et encore, seulement si vous avez des alertes baselines configurées.

D'autres acteurs utilisent des approches similaires. Watchtowr Labs a documenté en 2026 que plusieurs groupes APT d'Asie de l'Est intègrent désormais des phases de reconnaissance de secrets dans leurs chaînes d'attaque initiales, avant de passer à des techniques plus sophistiquées si les secrets trouvés ne suffisent pas à atteindre leurs objectifs. La frontière entre cybercriminalité opportuniste et espionnage étatique se floute quand les deux utilisent les mêmes techniques d'entrée, les mêmes outils open-source, et les mêmes vecteurs d'attaque basés sur des erreurs de configuration plutôt que des vulnérabilités techniques.

Les chiffres réels derrière le problème

L'incident Novo Nordisk est spectaculaire par son échelle, mais loin d'être isolé. SpectralOps a publié en juillet 2026 une étude sur 50 000 applications web appartenant à des entreprises du Fortune 500 : 23 % contenaient au moins un secret exposé dans leurs ressources JavaScript publiques. Parmi ces secrets, 41 % étaient des tokens de services cloud (AWS, Azure, GCP), 28 % des clés API de services tiers (Stripe, Twilio, SendGrid, Mailgun), et 18 % des tokens d'accès à des systèmes de versioning (GitHub, GitLab, Bitbucket). Les 13 % restants incluaient des credentials de bases de données, des certificats privés et d'autres types de secrets critiques.

Ce qui est remarquable dans ces statistiques : les secrets dans du JavaScript frontend ne sont pas protégés par l'obscurité, même si le code est minifié. Les outils modernes de dé-minification comme prettier ou js-beautify restituent un code lisible en quelques secondes. Et les gros tokens structurés (tokens AWS de 40 caractères alphanumériques, PAT GitHub de 40 caractères hexadécimaux, clés Stripe commençant par "sk_live_") ne sont pas affectés par la minification — ils restent intacts et parfaitement identifiables dans le bundle. La minification n'est pas de l'obfuscation et n'apporte aucune protection contre ce type d'attaque.

L'impact financier dépasse systématiquement la rançon demandée. L'incident Novo Nordisk : coût de l'enquête forensique, des notifications légales obligatoires (RGPD pour 163 000 employés européens concernés par l'exfiltration), des potentielles amendes réglementaires, des actions en justice des employés dont les données ont été volées, et la valeur de propriété intellectuelle compromise — notamment ce médicament expérimental contre l'obésité dont la formule représente des années de R&D et des centaines de millions d'investissement. Dans le secteur pharmaceutique, la valeur d'une formule de médicament en phase avancée de développement est pratiquement incalculable : un avantage concurrentiel absolu, potentiellement des milliards de revenus futurs.

Selon le rapport Ponemon Institute Cost of a Data Breach 2026, le coût moyen d'une violation de données a atteint 5,1 millions de dollars pour les entreprises industrielles, et 8,3 millions pour le secteur santé/pharma. Ces chiffres incluent la détection, l'endiguement, la notification, les pertes d'affaires et les frais juridiques — mais pas la valeur de la propriété intellectuelle volée ni le manque à gagner concurrentiel à long terme, qui sont les véritables coûts cachés d'incidents comme celui de Novo Nordisk.

Pourquoi les processus existants n'empêchent pas le problème

Les organisations qui prennent ce problème au sérieux ont généralement mis en place une combinaison de mesures : politiques de sécurité documentées interdisant les secrets en dur, formations développeurs sur les bonnes pratiques DevSecOps, revues de code intégrant des checks de sécurité. Et pourtant, les incidents continuent. Pourquoi ?

Première raison : la prolifération des environnements. En 2026, une organisation de taille moyenne maintient des dizaines d'environnements de développement, de staging, de test, de démo et de PoC. Ces environnements sont créés rapidement, utilisés brièvement, puis théoriquement arrêtés. En pratique, ils continuent d'exister dans l'infrastructure DNS, dans les registres de conteneurs, dans les comptes cloud — souvent pendant des années. Aucun processus d'inventaire ne couvre réellement ces environnements éphémères qui ne l'ont finalement pas été. Le DNS est particulièrement problématique : les entrées DNS ne coûtent rien à maintenir, donc personne ne les nettoie.

Deuxième raison : la rotation insuffisante des secrets. Même quand un développeur ne hardcode pas de credentials, les tokens utilisés dans les environnements de développement ont souvent des durées de vie très longues. Les Personal Access Tokens GitHub sans expiration, les clés API créées "pour tester" et jamais révoquées, les credentials de service account Azure avec une validité de 12 mois renouvelée quasi automatiquement — tous ces secrets peuvent rester valides des années après avoir été exposés dans un environnement oublié. Un token exposé il y a deux ans et jamais révoqué est aussi dangereux qu'un token exposé hier.

Troisième raison : le shadow IT cloud. Des développeurs créent des comptes cloud personnels pour tester des services, y déposent du code de l'entreprise pour faciliter le travail à distance, créent des tokens d'accès, puis quittent l'organisation sans processus d'offboarding rigoureux. Les tokens restent valides. Le code source partiel de l'entreprise reste dans un dépôt personnel potentiellement public. Aucun processus standard n'adresse systématiquement cette réalité.

Quatrième raison : les pipelines CI/CD comme vecteur d'exposition involontaire. Les fichiers de configuration des pipelines (GitHub Actions workflows, fichiers .gitlab-ci.yml, Jenkinsfiles) contiennent fréquemment des références à des secrets injectés comme variables d'environnement — ce qui est correct. Mais quand ces fichiers sont dans des dépôts publics et que les logs de build sont accessibles publiquement, les valeurs des secrets peuvent être exposées accidentellement dans les sorties de build : un echo de debug laissé par inadvertance, un outil de logging trop verbeux qui trace les variables d'environnement, ou une exception qui dump le contexte d'exécution.

Ce que vous devez faire — maintenant, pas dans six mois

Je vais être direct : si vous n'avez pas de programme actif de détection de secrets dans votre code et vos environnements, vous avez probablement des credentials exposés quelque part dans votre organisation. La question n'est pas de savoir si c'est le cas, mais où exactement. Voici l'ordre de priorité qui correspond à ce que je recommande lors de mes missions d'audit.

Étape 1 — Scan immédiat de vos dépôts publics. Exécutez TruffleHog sur l'intégralité de vos organisations GitHub et GitLab publiques, en mode historique complet. Les secrets supprimés dans un commit récent restent dans l'historique git et sont accessibles à quiconque clone le dépôt. TruffleHog3 avec le flag --only-verified valide les secrets trouvés contre les APIs correspondantes (GitHub, AWS, Azure, Slack, Stripe, etc.) pour confirmer qu'ils sont valides et actifs. Résultat : zéro faux positif sur les secrets confirmés. Attendez-vous à des surprises, même dans des organisations qui se croient propres.

Étape 2 — Inventaire DNS et audit des sous-domaines actifs. Utilisez Certificate Transparency Logs (crt.sh) pour récupérer la liste exhaustive de tous les certificats émis pour vos domaines — ils révèlent des sous-domaines que vous avez oublié d'avoir créés. Pour chaque sous-domaine actif qui répond, vérifiez quel service il expose et si les ressources JavaScript servies contiennent des secrets. Un script Python avec requests et TruffleHog peut automatiser ce scan en quelques heures pour des centaines de sous-domaines.

Étape 3 — Révocation et rotation immédiate. Tout secret trouvé doit être révoqué dans l'heure, pas dans les prochains jours. Un token révoqué qui était exposé depuis des mois est peut-être déjà dans les mains d'un attaquant — la révocation interrompt l'accès existant. Après révocation, analysez impérativement les logs d'utilisation de ce token sur les 90 derniers jours pour détecter des usages anormaux qui auraient pu indiquer une exploitation préexistante.

Étape 4 — Intégration dans le pipeline CI/CD. Le scan de secrets doit devenir un check automatique bloquant dans votre pipeline de CI — bloquant, pas juste avertissant. GitHub Advanced Security propose ce feature nativement avec ses "secret scanning alerts" et "push protection" pour les dépôts GitHub. GitLab Ultimate inclut une fonctionnalité similaire. Pour les pipelines indépendants, des pre-commit hooks avec Gitleaks sont une option légère et immédiatement déployable.

Étape 5 — Politique de durées de vie courtes pour tous les secrets. Imposez une durée de vie maximale de 7 jours pour les Personal Access Tokens GitHub (configuré dans les paramètres de l'organisation GitHub Enterprise), 1 heure pour les credentials AWS temporaires via IAM Roles (utiliser AssumeRole plutôt que des clés statiques), et 30 jours pour les Service Principals Azure avec rotation automatique via Managed Identities. Cette politique réduit drastiquement la fenêtre d'exploitation d'un secret exposé : même si quelqu'un trouve votre token dans un bundle JavaScript publié la semaine passée, il est déjà expiré.

L'outillage qui fait le travail — ce que j'utilise en mission

Il existe aujourd'hui un écosystème mature d'outils de détection de secrets. Voici mon retour terrain sans langue de bois.

TruffleHog 3.x est le meilleur outil open-source pour le scan de secrets avec vérification active. Son mode --only-verified teste les tokens trouvés contre les APIs correspondantes pour confirmer leur validité — zéro faux positif sur les secrets confirmés, une vraie différence par rapport à la version 2.x qui produisait énormément de bruit. Inconvénient : le scan complet d'un historique git volumineux (plusieurs années, milliers de commits) peut prendre des heures. Je l'utilise pour les audits ponctuels approfondis.

Gitleaks 8.x est plus rapide que TruffleHog pour les scans d'historique et l'intégration CI/CD comme pre-commit hook ou step de pipeline. Sa configuration via fichier TOML permet d'ajouter des patterns personnalisés pour vos secrets internes (identifiants propriétaires, formats de tokens custom spécifiques à votre infrastructure). Il ne fait pas de vérification active des tokens trouvés — il produit plus de faux positifs — mais sa vitesse le rend indispensable pour une intégration continue dans les pipelines de build.

GitGuardian (SaaS) est la solution commerciale la plus mature du marché. Elle monitore en continu GitHub, GitLab et Bitbucket publics, avec des alertes en temps réel si un secret de votre organisation y apparaît (sur la base de votre signature d'organisation configurée). Leur base de détection couvre plus de 350 types de secrets avec une très faible proportion de faux positifs. Le tier gratuit couvre les dépôts publics, suffisant pour une couverture de base. Je le recommande systématiquement comme filet de sécurité complémentaire aux outils embarqués dans les pipelines.

Pour l'IaC, Checkov est spécifique aux fichiers d'Infrastructure as Code (Terraform, CloudFormation, Helm charts, Kubernetes manifests). Il détecte les secrets dans les fichiers de configuration cloud — une surface souvent oubliée par les scanners orientés code source applicatif. À déployer dans tous les pipelines qui touchent à l'infrastructure.

Mon avis d'expert

L'incident Novo Nordisk va faire les manchettes pendant quelques semaines, puis sera oublié. Dans six mois, un autre géant sera compromis de la même façon. Ce n'est pas de la fatalité — c'est le résultat d'une industrie qui continue de traiter la gestion des secrets comme un problème de niveau deux, résolvable avec une formation annuelle et une politique dans un PDF que personne ne lit. La réalité : sans automatisation, sans contrainte technique non contournable, sans indicateurs mesurables sur la dette secrète de votre organisation, vous êtes Novo Nordisk. Pas si. Quand. Et la question est juste de savoir si FulcrumSec vous trouvera avant que vous ne trouviez vos propres problèmes.

Conclusion

Les credentials hardcodés dans le frontend ne sont pas un problème nouveau. Ils sont documentés depuis les premières années du web. En 2026, avec des outils de détection matures disponibles en open-source, des plateformes cloud qui permettent nativement la gestion fine des permissions et des durées de vie des secrets, et des incidents médiatiques qui auraient dû suffire à convaincre les plus réticents — il n'y a plus d'excuse acceptable pour ne pas avoir résolu ce problème dans son organisation.

La bonne nouvelle : c'est un problème soluble, et relativement rapidement. Un premier scan TruffleHog sur vos dépôts publics peut se faire en quelques heures. L'inventaire DNS de vos sous-domaines actifs, en une journée. La mise en place d'un pre-commit hook Gitleaks, en quelques minutes. Ce n'est pas le problème le plus complexe à traiter — c'est juste celui qu'on reporte systématiquement au profit de features qui génèrent de la valeur business directement visible dans les tableaux de bord produit.

Sauf que la valeur détruite par un FulcrumSec qui trouve votre token GitHub en clair dans un bundle JavaScript est d'un ordre de grandeur supérieur à la valeur de n'importe quelle feature livrée pendant le temps passé à ne pas scanner vos secrets. La prochaine fois que votre RSSI demande du temps d'ingénierie pour ce type de chantier et qu'on lui répond qu'on est occupé sur la roadmap produit, montrez-leur le montant des 25 millions de rançon demandée à Novo Nordisk. Et précisez que Novo Nordisk a quand même refusé de payer — et que les données se retrouvent sur Internet malgré tout.

Besoin d'un regard expert sur votre sécurité ?

Ayi NEDJIMI audite la gestion des secrets et la sécurité de vos pipelines de développement. Scan de dépôts, audit de sous-domaines, revue de vos processus CI/CD — un regard externe qui trouve ce que vos équipes internes ne voient plus.

Prendre contact