Parce que… c’est l’épisode 0x6xx!

Shameless plug

• 25 et 26 février 2026 - SéQCure 2026
  
  
  
  • CfP
  
  
  
  


• 14 au 17 avril 2026 - Botconf 2026


• 28 et 29 avril 2026 - Cybereco Cyberconférence 2026


• 9 au 17 mai 2026 - NorthSec 2026


• 3 au 5 juin 2025 - SSTIC 2026

Description

Ce podcast accueille Garance de la Brosse, chercheuse en cybersécurité chez Boost Security, qui présente ses travaux sur les vulnérabilités dans la chaîne d’approvisionnement logiciel de l’écosystème Go. Après un an de travail avec Boost Security, notamment sur la détection de malwares en Java et l’écriture de règles de détection statique, Garance a mené une recherche approfondie sur les vecteurs d’attaque possibles lors de la phase de distribution des packages open source dans Go.

Contexte et méthodologie de la recherche

La recherche s’inscrit dans le cadre plus large du cycle de vie complet d’un package, tel que défini par le schéma Salsa, qui couvre quatre phases principales : la source (développement), le build (construction), la distribution (hébergement et téléchargement) et la consommation (utilisation finale). Boost Security possédait déjà une expertise sur les vulnérabilités des pipelines CI/CD, mais cette nouvelle recherche visait spécifiquement la phase de distribution, un domaine moins exploré.

L’équipe a commencé par un état de l’art exhaustif des attaques sur la chaîne d’approvisionnement logiciel depuis fin 2024, analysant les techniques utilisées et les points d’entrée exploités. Cette analyse a révélé un manque d’études spécifiques sur Go, un écosystème conçu en 2007 avec la sécurité comme priorité, mais qui n’est pas exempt de vulnérabilités. Pour approfondir leur analyse, les chercheurs ont développé un outil permettant de télécharger l’intégralité de l’index du GoProxy, créant une base de données SQLite de 10 Go contenant les métadonnées de tous les packages publiés depuis 2019.

Particularités de l’écosystème Go

L’écosystème Go se distingue fondamentalement des autres systèmes comme npm ou PyPI par son architecture décentralisée. N’importe quel serveur web peut héberger un package Go, sans nécessiter de compte centralisé. Cependant, Go introduit un cache central appelé GoProxy qui garantit l’immutabilité des packages : une fois qu’une version est mise en cache, elle ne peut plus être modifiée, assurant ainsi une stabilité et une cohérence importantes.

Cette immutabilité est renforcée par une check database qui stocke les hash cryptographiques de tous les packages, permettant de vérifier l’intégrité lors du téléchargement. Ce système suit un principe de « trust on first use » : dès qu’un package est téléchargé une première fois, tous les utilisateurs suivants obtiennent exactement la même version. Toutefois, cette architecture présente une faiblesse majeure : l’immutabilité ne garantit pas la confiance. Un package malveillant peut être mis en cache et devenir immutable, restant disponible indéfiniment.

Vulnérabilités découvertes : le Repo Jacking

La recherche révèle que l’écosystème Go est vulnérable aux mêmes attaques de social engineering que les autres écosystèmes, notamment le typosquatting. Plus préoccupant encore, la nature décentralisée de Go introduit des risques spécifiques liés à la gestion des identités. Les packages Go étant identifiés par leur chemin d’accès (par exemple, github.com/utilisateur/package), la sécurité dépend entièrement du registre source utilisé.

L’analyse a révélé une vulnérabilité majeure appelée Repo Jacking : lorsqu’un développeur change son nom d’utilisateur GitHub ou supprime son compte, son nom devient disponible pour n’importe qui. Un attaquant peut alors créer un compte avec ce nom, publier un package identique avec une version supérieure, et le faire cacher dans le GoProxy. Les utilisateurs mettant à jour leurs dépendances téléchargeront alors du code potentiellement malveillant sans s’en rendre compte.

Les statistiques sont alarmantes : sur 80% des packages Go hébergés sur GitHub, près de 35 000 packages stockés dans le GoProxy ont des comptes GitHub supprimés ou renommés, les rendant vulnérables au Repo Jacking. Parmi ceux-ci, 54 packages ont un score de criticité supérieur à 0,2 (indiquant une utilisation importante), et 9 500 packages sont importés dans au moins un autre projet open source, avec certains packages importés jusqu’à 600 fois. Cette vulnérabilité a même affecté des projets populaires listés dans la collection « Awesome Go Package ».

Autres vecteurs d’attaque identifiés

Au-delà du Repo Jacking, la recherche a identifié plusieurs autres vulnérabilités. Les noms de domaine expirés constituent un risque majeur : le domaine gopkg.in, utilisé par des projets critiques comme Kubernetes, est détenu par un individu privé travaillant pour Canonical. Si ce domaine expire et est racheté par un attaquant, les conséquences pourraient être catastrophiques.

Les pseudo-versions représentent également un vecteur d’attaque sophistiqué. Go permet d’importer du code non officiellement releasé via un hash de commit. Un attaquant peut publier un commit malveillant, le mettre en cache dans le GoProxy, puis le supprimer du registre source. Le code malveillant reste accessible via le GoProxy sans que personne ne puisse inspecter le code source d’origine. Cette technique a été utilisée dans l’attaque BoltDB, où l’attaquant a publié une version malveillante dans le GoProxy tout en maintenant un code légitime visible sur GitHub.

La directive « go replace » dans les fichiers go.mod peut également être exploitée pour camoufler des attaques. Cette directive, légitime pour appliquer des patches locaux, peut être modifiée subtilement dans une contribution open source pour remplacer une dépendance par une version malveillante avec une différence d’un seul caractère (par exemple, Nicolas vs Nicolo). Une fois dans une dépendance transitive, cette modification devient pratiquement indétectable.

L’attaque la plus sophistiquée combine plusieurs techniques : en exploitant un écart temporel entre la validation d’une pull request et son exécution par un bot CI/CD, un attaquant peut modifier le code après validation. Le bot copie alors du code malveillant dans une branche du repository légitime, et ce commit malveillant peut être caché dans le GoProxy avec une pseudo-version portant le nom du package légitime.

Solutions et outils développés

Pour permettre aux développeurs de vérifier leurs dépendances, l’équipe a créé Goblin, un outil open source qui construit le SBOM (Software Bill of Materials) d’un projet Go et vérifie si les comptes GitHub associés aux dépendances sont encore enregistrés. L’outil indique quelles dépendances directes et transitives sont vulnérables au Repo Jacking. Bien qu’utile pour la défense, cet outil peut également être utilisé par des attaquants pour identifier des cibles.

Conclusion

Cette recherche démontre que malgré son design sécurisé, l’écosystème Go n’est pas exempt de vulnérabilités. L’immutabilité du GoProxy, présentée comme un avantage pour la stabilité, devient paradoxalement une faiblesse lorsque du code malveillant est caché, car il reste accessible indéfiniment. Les développeurs doivent rester vigilants, particulièrement lors des mises à jour de dépendances. Garance conclut en précisant que Go reste néanmoins mieux conçu que npm ou PyPI en termes de sécurité, et elle cherche actuellement un emploi à temps plein en France ou en Europe dans le domaine de la cybersécurité.

Notes

• Don’t Go with the flaw

Collaborateurs

• Nicolas-Loïc Fortin


• Garance de la Brosse


• François Proulx

Crédits

• Montage par Intrasecure inc


• Locaux virtuels par Riverside.fm