L'auto-hébergement d'un proxy de modules Go ne permet aucune vérification, et les pirates le savent bien

Principaux enseignements

• Un proxy de module Go est conçu pour servir des fichiers, et non pour déterminer si ces fichiers peuvent être exécutés en toute sécurité.
• Un caractère de votre chaîne GOPROXY détermine si un proxy hors service envoie les builds sur l'Internet public de manière visible ou discrète.
• GOPRIVATE ignore la base de données publique des sommes de contrôle pour chaque chemin qu'il identifie ; ainsi, un motif trop général peut désactiver cette protection à une échelle bien plus large que prévu.

En mai 2026, des chercheurs ont signalé une vague de modules Go malveillants publiés sous un compte GitHub nommé BufferZoneCorp. Le vol d’identifiants faisait partie de la charge utile, mais le plus intéressant résidait dans la cible visée par plusieurs de ces modules Go : le système de compilation lui-même. Ils ont corrompu GOPROXY, affaibli la vérification des sommes de contrôle, modifié le fichier go.sum et injecté de faux wrappers Go dans les chemins d’exécution, de sorte que les étapes de CI suivantes exécutaient le binaire de l’attaquant au lieu de la véritable chaîne d’outils. L’équipe de sécurité de Go a bloqué les modules identifiés. Cette technique fonctionne toujours partout où l'infrastructure des modules est traitée comme une configuration plutôt que comme une frontière de sécurité.

La mise en cache confère à cette infrastructure une longue mémoire. Un module peut rester accessible bien après que son code source a été modifié ou a disparu, et une faille de sécurité antérieure dans Go a montré jusqu’où cela pouvait aller : le proxy public de modules Go a continué à servir une version malveillante pendant plus de trois ans après que la balise GitHub correspondante eut été discrètement réécrite (plus d’informations à ce sujet ci-dessous). Ce problème de persistance explique en grande partie pourquoi les équipes mettent en place un proxy de modules interne et configurent GOPROXY pour qu’il y pointe.

Cet instinct n'est pas faux. La reproductibilité des builds s'améliore, les dépendances mises en cache ne dépendent plus de l'accessibilité du proxy public, et il existe enfin un endroit unique où visualiser les dépendances de l'organisation.

Ce qui ne découle pas de cela, c'est la conclusion en matière de sécurité. Un proxy modulaire transmet des octets. Le protocole lui-même ne comporte aucune étape de vérification du contenu ni aucun mécanisme de contrôle, et il ne se prononce pas sur la nature des fichiers qu'il renvoie. Gérer son propre proxy revient à contrôler le cache – ce qui est utile, mais ne revient pas à contrôler ce qui y est stocké.

Le rôle réel d'un proxy Go Module

Le protocole proxy du module est volontairement simple. Un proxy est un serveur HTTP qui expose quelques points de terminaison par chemin de module :

C'est tout ce qu'il y a. Aucun élément de cette liste ne comporte de signature, de résultat d'analyse, de verdict de politique de sécurité, ni aucune affirmation vérifiable concernant l'origine du code.

Remarque : Comme le protocole repose sur des requêtes HTTP GET simples suivant une structure de chemins prévisible, un répertoire de fichiers mis à disposition par NGINX peut techniquement être considéré comme un proxy de module Go valide. C'est en partie pour cette raison que les proxys se sont répandus si rapidement dans l'univers Go, et c'est aussi pourquoi si peu d'entre eux effectuent des vérifications, à moins que vous ne les intégriez vous-même.

Dans Go, la vérification s'effectue côté client, et non au niveau du proxy. La commande `go` compare le contenu du module téléchargé à la somme de contrôle enregistrée dans `go.sum`. Lorsque cette somme de contrôle n'est pas encore enregistrée, elle est généralement récupérée dans la base de données des sommes de contrôle, un journal indépendant de type « append-only », avant d'être écrite dans `go.sum`. Une fois enregistrée, les compilations suivantes se contentent de comparer le module à cette somme de contrôle stockée.

Ainsi, les propriétés de sécurité que la plupart des équipes attribuent à leur proxy sont en réalité celles de `go.sum` et de `GOSUMDB`. Celles-ci fonctionnent exactement de la même manière, que vous utilisiez un proxy ou que vous accédiez directement à proxy.golang.org directement.

La virgule et la barre verticale déterminent votre comportement par défaut

GOPROXY prend en charge une liste de sources, et le caractère qui les sépare détermine la réaction à adopter en cas de défaillance de l'une d'entre elles.

# Ne passe à l'entrée suivante qu'en cas de code 404 ou 410

GOPROXY=https://goproxy.internal.example.com,direct

# Passe à l'entrée suivante en cas d'erreur, QUELLE QU'ELLE SOIT

GOPROXY=https://goproxy.internal.example.com|direct

Ce schéma part du principe que « direct » est la source suivante dans la liste, comme dans les exemples ci-dessus. En soi, un « pipe » signifie simplement que le traitement passe à l'élément suivant.

Une virgule indique à la commande `go` de passer à la source suivante uniquement lorsque la source actuelle signale clairement que le module est absent (code 404 ou 410). Un barre verticale lui indique de passer à la source suivante en cas de n'importe quelle erreur, y compris les délais d'attente, les échecs TLS et les codes 500.

Imaginez ce que cela signifie en plein incident. Votre proxy interne subit un problème de déploiement et commence à renvoyer des erreurs 502. Avec une configuration « pipe » suivie d’un « direct », toutes les versions de l’organisation se mettent discrètement à récupérer les modules à partir du système de contrôle de version public.

Conseil de pro : Vérifiez les paramètres réellement définis dans votre CI, et non ceux indiqués dans le runbook. Les paramètres GOFLAGS et GOPROXY ont tendance à être hérités des images de base, et un pipe ajouté il y a deux ans pour contourner un déploiement instable est exactement le genre de chose qui survit à toutes les revues ultérieures, car les builds continuent de réussir.

La chaîne « direct » qui figure à la fin de la plupart des chaînes GOPROXY mérite également qu’on s’y attarde. Elle indique à la chaîne d’outils de se rabattre sur le contrôle de version lorsque le proxy ne renvoie aucun résultat ; ainsi, un chemin de module que votre proxy n’a jamais rencontré est tout de même résolu directement à partir de son dépôt en amont, comme d’habitude. Si l’intérêt de mettre en place un proxy était justement d’en faire la seule source de vérité, la chaîne « direct » va discrètement à l’encontre de cet objectif.

L'option « GOPROXY=off » est la plus restrictive qui soit. La commande « go » ne téléchargera aucun module ; tout ce dont une compilation a besoin doit donc déjà se trouver dans le cache des modules. En supprimant le « direct » à la fin, vous obtenez une limite stricte au niveau des sources sans aller tout à fait aussi loin.

Pourquoi l'auto-hébergement ne vérifie rien par lui-même

Athens est un logiciel fiable. Il remplit exactement la fonction pour laquelle un module proxy est conçu.

Ce qu’il ne fournit pas, c’est une opinion sur ce que contient un module. Il n’y a pas de analyse anti-malware intégrée, aucune vérification de la correspondance entre l’archive et son dépôt source, ni aucun moyen prêt à l’emploi de dire « bloquez ce module, il a commencé à faire quelque chose de nouveau dans la version 1.4.2 ». Le filtrage standard s’applique aux chemins d’accès des modules plutôt qu’aux actions effectuées par le code. Athens expose toutefois un hook de validation qui est appelé à chaque téléchargement de module, ce qui permet aux opérateurs de l’étendre avec leur propre logique d’analyse ou de politique, mais cette vérification est quelque chose que vous concevez, exécutez et maintenez en fonctionnement.

Cette lacune est importante en raison de l'endroit où s'exécute le code Go malveillant. Go ne dispose pas d'un hook de script au moment de l'installation, contrairement à npm , ce qui constitue un véritable atout. Cependant, le code malveillant présent dans un module Go s'exécute tout de même ultérieurement, lors de l'exécution d'une application ou d'un outil qui importe ce paquet, généralement via une fonction init() déclenchée au démarrage du programme.

Un proxy qui met en cache et fournit ce module n'a rien fait de répréhensible au regard de la spécification. Il a fait exactement ce pour quoi il a été conçu.

La véritable question est de savoir si l’archive fournie par un proxy correspond bien au référentiel source vers lequel son chemin de module est censé pointer. Aucune disposition du protocole n’exige qu’un fichier ZIP de module corresponde à un commit particulier, ce qui en fait un artefact plutôt qu’une attestation. Reconstruire un module à partir du code source et comparer le résultat obtenu avec ce que le chemin a fourni constitue un contrôle distinct, qui doit être effectué avant que l’artefact ne soit admis dans un référentiel de confiance ou fourni à une compilation.

Comparaison de cinq architectures GOPROXY

Cinq schémas couvrent la quasi-totalité des actions que les équipes travaillent à l'entraînement. Ce qui les distingue, c'est le type de blocage prévu pour chacun d'entre eux et le joueur chargé de le mettre en œuvre.

Le proxy public avec basculement direct est la configuration par défaut avec laquelle la plupart des équipes commencent, et il est meilleur que ce que l'on dit de lui. proxy.golang.org gère un cache immuable : ainsi, une version qu’il a servie une fois reste disponible et inchangée, même si le dépôt en amont est supprimé. Il s’agit là d’une véritable propriété de sécurité, que l’auto-hébergement ne reproduit pas automatiquement.

De nombreuses équipes finissent par opter pour un proxy auto-hébergé comme Athens, et pour être honnête, cela leur apporte davantage de disponibilité et de visibilité que de vérification.

Un proxy de gestion de référentiel permet un contrôle d’accès centralisé et, selon le produit et les modules complémentaires de politique pour lesquels vous disposez d’une licence, il peut vérifier la conformité des composants par rapport à la politique et mettre en quarantaine ceux qui ne la respectent pas. Ce qu’un proxy classique ne permet toujours pas de garantir, c’est qu’un artefact a bien été recompilé à partir de la source indiquée par son chemin d’accès et qu’il correspond bien à celle-ci.

Un registre filtré et reconstruit constitue une catégorie à part, et non une variante des quatre premiers. Il reconstruit chaque module à partir du code source et le soumet à un filtrage anti-malware avant de le mettre à disposition ; c’est pourquoi c’est la seule ligne qui répond « oui » à la colonne « filtrage ». C’est le modèle SecureChain pour Go , dont la prise en charge de Go est prévue pour le quatrième trimestre 2026.

D'où vient l'utilisation abusive des caches proxy ?

Les incidents liés au cache qui touchent l'infrastructure des modules Go suivent généralement le même schéma, comme l'illustre bien un cas survenu début 2025. En février de cette année-là, des chercheurs ont découvert un module appelé github.com/boltdb-go/bolt usant de l'identité de BoltDB, un magasin de clés/valeurs embarqué largement utilisé qui comptait plus de 8 000 paquets dépendants au moment où l'incident a été signalé.

L’auteur de la menace avait publié la version malveillante dès novembre 2021, puis avait réécrit la balise GitHub pour qu’elle pointe vers un commit « propre », ce qui signifiait que toute personne vérifiant manuellement le dépôt ne voyait rien d’anormal. Le proxy du module Go avait déjà mis en cache la version malveillante d’origine, et comme ce cache est conçu pour être immuable, la copie contenant la porte dérobée est restée accessible pendant plus de trois ans à tout client recherchant cette version du module, jusqu’à ce que des chercheurs la signalent finalement comme un « typosquat ».

Il ne s’agissait pas d’une erreur de somme de contrôle. « boltdb-go/bolt » était un chemin d’accès distinct, utilisé à des fins d’usurpation d’identité ; il n’existait donc aucune somme de contrôle fiable pour le véritable BoltDB à laquelle la version falsifiée aurait dû correspondre. Les contrôles d’intégrité de Go ont sans problème authentifié les octets propres au « typosquat », car c’est précisément à cela qu’ils servent. La porte dérobée a réussi grâce au nom utilisé.

Cette distinction est importante, car cela ne revient pas à accorder une confiance aveugle dès la première utilisation. Pour les modules publics, le client consulte normalement la base de données des sommes de contrôle, un journal authentifié de manière indépendante, la première fois qu’il a besoin d’un hachage pour une version ; ainsi, un proxy ne peut pas modifier unilatéralement la valeur de confiance d’une version déjà enregistrée. Un proxy auto-hébergé décide toujours quel artefact le client voit en premier, mais avec GOSUMDB, c’est la base de données des sommes de contrôle, et non le proxy, qui décide si cet artefact est accepté.

Mais tout cela ne permet en rien de vérifier si un module est digne de confiance, ce qui est précisément la faille dont profitent les « typosquats ». De plus, la partie publique de ce mécanisme est contournée dès lors qu’il y a une correspondance avec GOPRIVATE, ou dans tout environnement où GOSUMDB est désactivé.

Ce que GOPRIVATE désactive discrètement

GOPRIVATE a été créé pour une bonne raison. Les modules privés ne devraient pas faire l'objet de requêtes via un proxy public, et leurs chemins d'accès ne devraient pas non plus être envoyés à une base de données publique de sommes de contrôle, car le chemin d'accès au module lui-même peut révéler des informations sur ce que vous développez.

Il s’agit également d’une variable de commodité, et c’est au niveau de cet effet secondaire que les choses dérapent. GOPRIVATE fournit la valeur par défaut à la fois pour GONOPROXY et GONOSUMDB, conformément à la documentation des modules de Go, ce qui signifie que chaque chemin qu’il correspond est exclu à la fois du proxy et de la base de données publique de sommes de contrôle, à moins que l’une de ces deux variables ne soit définie séparément.

Voici où cela pose problème dans la pratique.

GOPRIVATE=github.com/yourcompany/*

Si le critère est suffisamment précis, il correspondra à l'organisation que vous souhaitiez sélectionner.

GOPRIVATE=*.example.com,github.com/*

Ce deuxième modèle exclut tous les modules hébergés sur GitHub de la base de données publique de sommes de contrôle, ce qui représente une part considérable de ce que la plupart des builds Go récupèrent. Les modèles ont tendance à s’élargir facilement de cette manière : un échec de résolution doit être corrigé, et assouplir la condition de correspondance est la modification qui permet au build de passer immédiatement au vert.

Vérifiez les paramètres effectivement définis dans vos environnements :

go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS

Exécutez cela sur un serveur d'intégration continue (CI), et pas seulement sur votre ordinateur portable. Il peut y avoir des différences entre les deux, car le système d'intégration continue récupère les variables à partir des images de base et de la configuration du serveur.

Définissez-les de manière délibérée. Configurez directement GONOPROXY et GONOSUMDB lorsque votre routage et votre politique de somme de contrôle doivent diverger, ce qui arrive plus souvent que ne le pensent les équipes. Si un proxy interne de confiance dessert à la fois les modules publics et privés, GONOPROXY=none permet de faire passer tout le trafic par ce proxy, tandis que GONOSUMDB ne couvre que les chemins véritablement privés. Ce qu’il faut éviter, c’est l’inverse, à savoir laisser des chemins privés dans la base de données publique, ce qui peut soit interrompre la compilation, soit divulguer le chemin vers un service public.

Choisir une architecture

Tout dépend en fin de compte du problème que vous cherchez réellement à résoudre, et le fait d’être honnête à ce sujet permet de raccourcir considérablement la durée globale du projet.

Si votre priorité est la disponibilité et la reproductibilité de la mise en production, utilisez un proxy auto-hébergé ou un gestionnaire de référentiels, privilégiez la virgule plutôt que la barre verticale, et cessez de qualifier cela de « contrôle de sécurité ». Il s’agit simplement d’une infrastructure de qualité qui remplit parfaitement la fonction pour laquelle elle a été conçue. Si votre priorité est la visibilité sur les dépendances de l’organisation, pratiquement n’importe quel proxy vous permettra d’y parvenir, et les gestionnaires de référentiels offrent de meilleurs rapports pour une charge opérationnelle moindre.

Si le principe directeur consiste à appliquer une politique déterminant quels modules sont autorisés, un gestionnaire de référentiels doté de règles de chemin d'accès constitue la base, tandis que c'est au niveau de ses modules complémentaires de politique ou de pare-feu que s'effectue réellement l'application de cette politique. Athens peut être orienté dans cette direction grâce à son hook de validation, mais c'est vous qui gérez la logique, le réglage et le système d'alerte.

Si le pilote doit vérifier que le contenu d’un module est fiable, le protocole proxy ne permet pas à lui seul de répondre à cette question, car il n’a jamais été conçu pour inclure une étape de vérification. Ce contrôle doit être mis en place en amont du proxy, ou provenir d’un système qui valide les artefacts par rapport à leur source avant de les diffuser.

Et si Go côtoie npm, PyPI, Maven ou crates.io dans votre pile technologique, définissez une architecture unique pour l’ensemble de ces plateformes. C’est précisément lorsque cinq proxys distincts, gérés par cinq équipes différentes, sont utilisés pour chaque écosystème que des failles de couverture apparaissent. PolinRider illustre parfaitement ce phénomène : la campagne liée à la Corée du Nord, suivie sous ce nom, a consisté à publié des paquets malveillants sur npm, Packagist, Go Modules et les extensions Chrome, et elle était toujours active lorsque les chercheurs ont publié leur rapport en juillet 2026. Le cluster plus large « Contagious Interview » auquel elle appartient a été associé à plus de 1 700 paquets malveillants sur npm, PyPI, Go et Rust. Un problème au niveau de la pile nécessite une réponse au niveau de la pile, et non pas cinq caches déconnectés les uns des autres.

Un proxy est l’outil idéal pour résoudre les problèmes de disponibilité, de latence et de reproductibilité. En revanche, il ne convient pas pour résoudre les questions de confiance. En séparant ces deux objectifs, on préserve la simplicité de l’architecture et on parvient à déployer un proxy fonctionnel. Les mélanger transforme un simple projet de mise en cache en un effort bien plus vaste en matière de politiques et d’ingénierie de sécurité, avec un risque réel de se retrouver avec une couche de politiques complexe greffée sur ce qui est, fondamentalement, un composant de mise en cache.

Le rôle de TuxCare SecureChain

Il existe également un problème que nul proxy ne résout : les modules dont plus personne n’assure la maintenance. Un cache sert un module inactif avec exactement la même fidélité qu’un module activement maintenu, et un module non corrigé présentant une vulnérabilité CVE connue et dépourvu de correctif en amont n’est pas un problème que résout une architecture de cache. Le portage d’un correctif vers un code dont le responsable de maintenance s’est détourné constitue une discipline à part entière, articulée autour des tests de régression et de la compatibilité comportementale, ce qui explique généralement pourquoi cela sort du champ de compétence d’une équipe de plateforme.

Si la vérification est l'élément qui manque à votre architecture, c'est là que se trouve la lacune SecureChain a été conçu pour combler cette lacune dans les écosystèmes qui font généralement partie de la même pile. npm est disponible dès aujourd’hui, Maven et PyPI seront disponibles en août 2026, tandis que Go et Rust/crates.ioet Packagist/PHP suivront au quatrième trimestre 2026. Dans chaque cas, SecureChain recompile les paquets à partir du code source, les analyse au moment de leur récupération avant que quoi que ce soit n'atteigne la phase de compilation, et continue de corriger les vulnérabilités connues même lorsque le développeur en amont d'un paquet n'est plus actif. Vous vous demandez comment cela s'intègre à votre propre configuration GOPROXY ou au reste de votre pile ? Posez-nous une question et notre équipe vous guidera pas à pas.

FAQ

Qu'est-ce qu'un proxy de module Go ?

Serveur HTTP implémentant le protocole de proxy des modules Go. Il met à disposition les listes de versions, les métadonnées, les fichiers `go.mod` et les archives source correspondant aux chemins d'accès des modules. Il met en cache et achemine les requêtes, mais le protocole lui-même ne prévoit aucune vérification du contenu qu'il renvoie.

Le fait d'exploiter mon propre proxy de modules Go rend-il les compilations plus sûres ?

Cela améliore la disponibilité, la reproductibilité et la visibilité, autant d’aspects utiles. Le protocole proxy ne comporte pas d’étape de vérification propre. L’authentification du contenu s’effectue côté client : la commande `go` vérifie les téléchargements par rapport à `go.sum`, et pour les modules publics, par rapport à la base de données de sommes de contrôle lorsqu’aucun hachage n’a encore été enregistré. Cela fonctionne de la même manière, que vous utilisiez un proxy ou non, sauf si `GOSUMDB` est désactivé ou si le chemin est exclu de la base de données publique via `GOPRIVATE` ou `GONOSUMDB`.

Quelle est la différence entre une virgule et une barre verticale dans GOPROXY ?

Une virgule fait en sorte que la commande « go » passe à la source suivante uniquement en cas d’erreur 404 ou 410 ; toute autre erreur de proxy interrompt donc la résolution. Un barre verticale permet de passer à la source suivante en cas d’erreur, quelle qu’elle soit, ce qui signifie qu’une panne de proxy peut discrètement envoyer les builds vers l’Internet public au lieu de simplement échouer.

GOPRIVATE désactive-t-il la vérification de la somme de contrôle ?

Par défaut, il ignore la consultation de la base de données publique des sommes de contrôle pour les chemins correspondants, car GOPRIVATE alimente GONOSUMDB. Une entrée existante dans go.sum peut néanmoins détecter une modification ultérieure du contenu.

La ville d'Athènes suffit-elle pour héberger un proxy privé dédié au module Go ?

En ce qui concerne la disponibilité, la mise en cache et la distribution interne des modules, oui. Son filtrage standard s'applique aux chemins d'accès des modules plutôt qu'au contenu ; par défaut, il ne vous indiquera donc pas si un module est malveillant ou si l'archive qu'il met à disposition correspond bien à son dépôt source. Son hook de validation peut être étendu pour intégrer ce type de logique, mais c'est à vous de concevoir et de gérer cette partie.

Comment puis-je vérifier à quoi mes builds Go font réellement confiance ?

Exécutez la commande « go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS » sur un runner CI. La configuration héritée des images de base et des paramètres du runner diffère souvent des configurations de développement locales, ainsi que de ce que le runbook indique comme étant la configuration normale.

Résumé

Nom de l'article

Options de proxy du module Go et ce que GOPROXY vérifie réellement

Description

Un proxy de module Go met en cache et achemine les données, et le protocole ne vérifie en rien le contenu du module. Respectez les décisions de GOPROXY, GOPRIVATE et de la base de données de sommes de contrôle.

Auteur

Artem Karasev

Nom de l'éditeur

de TuxCare

Logo de l'éditeur