Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Les hachages des modules Go couvrent les noms et le contenu des fichiers, et non l'encodage zip, de sorte qu'une archive reconstruite indépendamment peut correspondre exactement.
- De ce fait, le fait de configurer GOPROXY pour qu'il pointe vers un registre filtré n'invalide pas les entrées go.sum que vous possédez déjà.
- La reconstitution exacte prouve qu'une archive correspond à sa source, et non que la source est sûre.
- Le changement en lui-même n'est qu'une variable d'environnement, et le véritable risque réside dans la dérive de la configuration.
En juillet 2026, des chercheurs ont établi un lien entre une vague de comptes de maintenance compromis sur npm, Packagist et les modules Go et une campagne liée à la Corée du Nord, baptisée PolinRider . Cette campagne a également publié de nouveaux paquets malveillants, mais le plus préoccupant concerne le sort réservé aux paquets existants. Les attaquants ont accédé à des comptes ayant des années d'historique vierge et ont diffusé de nouvelles versions à partir de ces comptes.
Une nouvelle version de module publiée depuis un compte de maintenance compromis peut passer les contrôles d'intégrité de Go lors de sa première utilisation. Go.sum et la base de données de sommes de contrôle confirment que vous avez bien reçu la version publiée. Cependant, aucun des deux ne se prononce sur la sécurité de cette version.
L'ajout d'une couche de vérification à une compilation peut engendrer des frictions. Il faut gérer de nouvelles identités de paquets, suivre les versions, et modifier les fichiers de verrouillage sans s'en soucier. Go s'en sort relativement bien, et il est important de comprendre pourquoi, car cela explique aussi ce que la vérification en Go peut et ne peut pas prouver.
Pourquoi les archives des modules Go peuvent être vérifiées avec exactitude
Un module Go au format zip contient le code source. Aucune compilation n'est effectuée lors de l'importation, et la structure de l'archive suit un algorithme documenté plutôt que celui utilisé par le script d'empaquetage de l'éditeur.
Cela a une conséquence souvent négligée. Go calcule le hachage du module à partir des noms et du contenu des fichiers de l'archive. L'encodage ZIP, la méthode de compression, les dates de modification de chaque fichier et autres métadonnées sont ignorés. Ainsi, toute personne ayant accès à l'historique du système de contrôle de version peut reconstruire le module et obtenir la même somme de contrôle h1, même si les deux fichiers ZIP diffèrent octet par octet.
D'autres écosystèmes comportent davantage d'intermédiaires entre un dépôt et un artefact publié. Maven distribue des fichiers JAR compilés. Les roues Python sont le résultat de la compilation. Une archive tar npm peut contenir le code source brut, ou les résidus d'un script de pré-compilation. La reproductibilité des compilations a fait de réels progrès dans plusieurs de ces écosystèmes ; la frontière entre l'impossible et la précision absolue est donc floue. En réalité, la somme de contrôle de Go a été conçue dès le départ pour ignorer les erreurs de packaging, ce qui rend la vérification d'une reconstruction indépendante particulièrement simple.
Ce qui différencie les fournisseurs, c'est si une comparaison est systématiquement effectuée à l'échelle du registre, pour chaque module et à chaque fois. Un registre de vérification peut extraire l'historique du système de contrôle de version pour un chemin de module donné, créer l'archive conformément aux spécifications et la comparer à celle servie par le proxy public. Une non-concordance signifie que l'archive ne correspond pas à la source annoncée.
Cette distinction est plus importante qu'il n'y paraît. Une reconstruction exacte confirme qu'une archive correspond à sa source déclarée. Elle ne dit rien sur la sécurité de la source elle-même. PolinRider en est un exemple frappant : les attaquants ont modifié directement les dépôts légitimes, allant jusqu'à écraser des commits existants. Une reconstruction fidèle à partir de cette source reproduit le contenu malveillant avec la même précision. La reconstruction permet de détecter les altérations entre le dépôt et l'archive. La détection de code malveillant au sein du dépôt est une tâche distincte.
Remarque : Pour les artefacts nécessitant une compilation, des scripts d’empaquetage ou des fichiers générés, « reconstruit à partir des sources » signifie également reproduire ces conditions de compilation. La somme de contrôle de Go provient directement de l’arborescence source empaquetée, ce qui rend la comparaison particulièrement simple à vérifier. Demandez à un fournisseur de vous montrer une anomalie, plutôt que de vous la décrire.
Pourquoi go.sum continue-t-il de fonctionner ?
Si un registre reconstruit les archives de modules, les hachages changent-ils et est-ce que tous les go.sum de l'organisation sont corrompus ?
Non. Le hachage couvrant l'arborescence des fichiers et ignorant les détails d'empaquetage, une archive correctement reconstruite produit le même hachage que celui généré par le proxy public. Vos entrées go.sum existantes sont validées par rapport à cette valeur, et la base de données de sommes de contrôle sur sum.golang.org confirme ces valeurs.
C’est pourquoi ce changement ne nécessite aucune modification des fichiers go.mod ou go.sum. Il ne s’agit pas d’une migration qui se trouve être courte. Il n’y a rien à migrer. La correspondance des hachages est le résultat attendu, et une divergence est un signal plutôt qu’un inconvénient.
Un cas particulier rompt cette symétrie et mérite une réponse claire plutôt qu'une simple note de bas de page. Go considère le chemin et la version d'un module comme immuables. Par conséquent, si un registre propose des contenus patchés pour une version déjà existante en amont, ces contenus ne peuvent pas réutiliser la somme de contrôle d'origine. Une entrée existante dans `go.sum` rejetterait d'emblée les octets modifiés, et la base de données publique des sommes de contrôle continuerait de contenir le hachage d'origine. Les modules patchés nécessitent donc leur propre mécanisme de distribution documenté, qu'il s'agisse d'une version distincte, d'un chemin de module distinct ou d'une autre configuration de confiance contrôlée. Si l'application de correctifs post-EOL est l'une des raisons de votre migration, confirmez ce mécanisme avec TuxCare avant de planifier le déploiement. C'est le seul domaine où l'adage « rien ne change » n'est plus vrai.
La ligne unique
GOPROXY accepte toute URL qui implémente le protocole proxy du module ; le fait de le faire pointer vers un registre filtré constitue donc une modification de variable d’environnement.
go env -w GOPROXY=<your SecureChain Go proxy URL>,direct
Utilisez une virgule avant `direct` plutôt qu'une barre verticale (|) et comprenez bien le fonctionnement de chaque option. Avec une virgule, Go utilise l'entrée suivante uniquement après une erreur 404 ou 410. Avec une barre verticale, il utilise l'entrée suivante après toute erreur, y compris un délai d'attente dépassé. Ainsi, une panne du registre détourne discrètement votre compilation du système pour lequel vous avez installé le registre. Dans tous les cas, `direct` signifie récupérer directement les données depuis le système de contrôle de version, et une virgule permet toujours de traiter une erreur 404. Si le registre est conçu comme un filtre plutôt que comme une simple suggestion, les modules bloqués devraient renvoyer une autre valeur que « introuvable ». Go fait référence à l'erreur 403 précisément à cet effet.
Cela fonctionne que GOPROXY pointe directement vers SecureChain ou vers un gestionnaire de dépôts comme Artifactory ou Nexus qui pointe lui-même vers SecureChain. Les modules et le flux de travail restent les mêmes dans les deux cas.
Pour l'intégration continue, configurez-le dans l'environnement plutôt que de l'intégrer à une image.
export GOPROXY=<your SecureChain Go proxy URL>,direct
export GOSUMDB=sum.golang.org
Le fait de laisser GOSUMDB activé explicitement est intentionnel. La vérification des sommes de contrôle et l'analyse du registre répondent à des questions différentes, et le changement de proxy n'est pas une raison pour désactiver l'une ou l'autre.
Conseil de pro : configurez GOPROXY avec la commande `go env -w` sur les machines de développement et via les variables d'environnement CI sur les agents de build. Ensuite, exécutez `go env GOPROXY` sur un runner en production pour vérifier la configuration réelle. Les images de base intègrent parfois leur propre valeur, ce qui est généralement à l'origine des problèmes lors des déploiements.
Ce qui reste inchangé et ce qui change
| Article | Changements |
| aller.mod | Non |
| go.sum pour les modules en amont servis tels quels | Non |
| allez construire, allez tester, allez récupérer | Non |
| Annuaires de fournisseurs | Non |
| Comportement de sélection de version | Non |
| D'où proviennent les archives | Oui |
| Les archives sont-elles examinées avant la résolution ? | Oui |
Vos commandes de compilation restent inchangées, tout comme le dépôt. Seuls l'emplacement de l'archive et son traitement avant la compilation sont modifiés. Attention cependant concernant les dépendances externes : une compilation utilisant ces dépendances lit le répertoire `vendor/` et n'interroge jamais le proxy. Par conséquent, cette modification est inutile tant que le répertoire n'est pas actualisé.
Qu'apporte le dépistage avant la résolution ?
Go ne dispose pas d'un mécanisme d'installation équivalent aux scripts de cycle de vie de npm, ce qui constitue généralement un avantage. Cela ne rend pas pour autant le contenu d'un module inoffensif. Un code malveillant peut être compilé dans votre binaire, et les outils associés à un dépôt peuvent ouvrir leurs propres chemins d'exécution. PolinRider illustre bien ce dernier cas. Les charges utiles étaient des chargeurs JavaScript obfusqués, dissimulés dans les ressources du projet, incluant de faux fichiers de police .woff2, et non des programmes exécutés par une fonction d'initialisation Go.
Cela fait du filtrage préalable à la résolution l'une des premières opportunités automatisées de bloquer les contenus malveillants avant qu'ils n'atteignent l'environnement de compilation.
Le problème se manifeste sous trois formes différentes, et chacune requiert une réponse différente.
Un chemin de module compromis par un dépôt Go peut servir une nouvelle version malveillante via le chemin légitime sans enfreindre les sommes de contrôle existantes de Go, car ces contrôles authentifient le contenu du module plutôt que la propriété ou l'intention du dépôt. Recompiler à partir de cette source VCS compromise est également inutile, puisque le dépôt appartient désormais à l'attaquant. En revanche, analyser le contenu à la recherche de logiciels malveillants avant de résoudre le problème est la solution.
Le cas de PolinRider illustre une version publiée en amont après la compromission d'un compte. go.sum et la base de données de sommes de contrôle peuvent l'authentifier avec succès, car ils vérifient si les octets sont identiques plutôt que leur sécurité. Le filtrage permet de combler cette lacune.
Un module abandonné porteur d'une vulnérabilité CVE pose un tout autre problème. Aucun élément malveillant n'y a été introduit. Le responsable de la maintenance a simplement cessé de corriger les problèmes existants. Les avis de sécurité vous en informeront, mais fermer le module implique de le maintenir à jour après le départ de son auteur ; il s'agit donc d'une maintenance et non d'un contrôle. C'est précisément le rôle du support du cycle de vie continu (ELS).
L'ampleur de cette prise de contrôle de compte mérite d'être examinée. Les chercheurs ont découvert des traces de compromission dans 80 modules Go parmi 108 paquets uniques touchés lors de la campagne, avec un total de 162 artefacts de publication malveillants. Ils ont retracé cette activité dans le cadre de Contagious Interview, également connu sous le nom de Famous Chollima. Ces modules ont été compromis via des comptes ayant des années d'historique légitime, et non via des noms similaires récemment enregistrés. Or, la simple vérification d'intégrité ne permet pas de détecter ce type de problème. Une nouvelle version de ce type passe la première vérification car le hachage authentifie fidèlement tout contenu associé à cette version, et une publication provenant d'un mainteneur de confiance de longue date ne paraît pas suspecte au premier abord.
Il existe une difficulté particulière liée à Go. Les modules Go étant généralement extraits directement des tags ou des commits du système de contrôle de version (VCS), plutôt que d'être téléchargés séparément sur un registre, une compromission du dépôt peut se propager à l'écosystème des modules sans que l'attaquant ait besoin d'une seconde paire d'identifiants. Des chercheurs ont constaté que le compte d'un mainteneur compromis ne présentait aucune publication malveillante dans un écosystème exigeant une étape de téléchargement distincte, ce qui pourrait signifier que les attaquants n'ont jamais atteint ce stade.
L'abandon est la version plus discrète de cette même exposition. Une analyse récente portant sur 13,1 millions de paquets open source situe la part de Go hors bande, pondérée par les dépôts dépendants plutôt que par le nombre de paquets, entre 33,2 % et 57,9 %. Cet écart s'explique par la définition : le chiffre le plus élevé inclut tout paquet n'ayant pas fait l'objet d'une nouvelle publication depuis 730 jours. Le chiffre le plus bas exige également l'absence de modifications de dépôt pendant cette période. Quoi qu'il en soit, les exemples Go cités sont pertinents : gopkg.in/yaml.v2, jwt-go, AWS SDK pour Go v1. Aucune architecture de registre, qu'elle soit vérifiée ou non, ne résout ce problème à elle seule. Un système de correctifs continus est nécessaire, comme dans le troisième cas mentionné précédemment.
Déploiement sans rupture de build
Quatre phases, et l'ordre importe plus que la vitesse.
| Phase | Action | Ce que vous apprenez |
| 1 | Configurez GOPROXY sur un service non critique | Si un chemin de module ne parvient pas à résoudre |
| 2 | Téléchargez et vérifiez les dépendances à partir d'un cache de modules vide. | Les modules servis par le nouveau registre s'authentifient-ils auprès de votre fichier go.sum existant ? |
| 3 | Déploiement vers l'intégration continue sur tous les dépôts | Quelles pipelines avaient GOPROXY codé en dur dans une image |
| 4 | Limiter la sortie de l'agent de compilation vers le registre et la base de données de sommes de contrôle | Ce qui contournait discrètement la configuration |
La deuxième phase produit les preuves qu'un examinateur sceptique demandera réellement.
nettoyer -modcache
télécharger le mod go
vérifier le modérateur
Il est important de préciser ce que chaque commande prouve. Avec un cache vide, `go mod download` force le téléchargement des modules requis via le nouveau registre et les authentifie par rapport aux entrées de votre fichier `go.sum` validées, ou par rapport à la base de données de sommes de contrôle configurée si aucun hachage n'est déjà enregistré. `go mod verify` vérifie ensuite que le contenu du cache n'a pas changé depuis son téléchargement. Après ces deux commandes, effectuez votre compilation ou vos tests habituels ; la compatibilité est ainsi validée par rapport aux dépendances actuelles de votre projet dans votre propre environnement, et non par rapport à une documentation fournisseur.
La quatrième phase marque le passage de la politique à son application. Tant que l'accès sortant n'est pas bloqué, GOPROXY est une suggestion que chacun peut contourner pour débloquer un déploiement du vendredi. Bloquer proxy.golang.org seul ne suffira pas, car cette redirection directe génère des erreurs 404 vers GitHub et ses partenaires. Autorisez le registre et bloquez le reste. Avant de modifier la règle, une vérification s'impose : la vérification des sommes de contrôle nécessite toujours un accès à la base de données des sommes de contrôle, soit directement, soit via un proxy qui la duplique. Assurez-vous donc que ces recherches aboutissent régulièrement afin d'éviter toute interruption de service dès la première panne.
Conseil de pro : Exécutez la phase quatre en préproduction suffisamment longtemps pour tester vos flux de travail de compilation habituels avant la mise en production. Vous découvrirez ainsi l’inventaire réel des pipelines qui se résolvaient directement sans que personne ne le sache, et il est bien plus utile de disposer d’une liste maintenant que d’un incident plus tard.
Sécurisez votre chaîne d'approvisionnement Go
Si les phases un et deux ont déjà été validées dans vos dépôts, avec votre propre fichier go.sum, vous disposez des preuves de compatibilité requises pour un audit de sécurité, et vous les avez vous-même produites. SecureChain for Go ajoute un contrôle continu à chaque récupération (au lieu d'une vérification ponctuelle), ainsi que des correctifs qui se poursuivent même après le départ du mainteneur d'un module, via un registre utilisant le même protocole de proxy de module que votre chaîne d'outils. Avant de vous appuyer sur les correctifs post-EOL, vérifiez le mécanisme de versionnage et de somme de contrôle documenté pour les modules Go corrigés afin qu'il puisse être intégré au déploiement.
Demandez un devis pour SecureChain ou découvrez comment SecureChain se compare à Chainguard .
FAQ
Comment puis-je modifier le proxy de mon module Go ?
Définissez la variable d'environnement GOPROXY sur l'URL du registre, en utilisant une virgule avant « direct » plutôt qu'une barre verticale. La commande `go env -w GOPROXY=…` enregistre cette configuration sur la machine de développement. En intégration continue, définissez-la dans la variable d'environnement plutôt que dans une image de base.
Le changement de proxy des modules Go perturbe-t-il go.sum ?
Non, à condition que le registre propose le même contenu de module. Le hachage des modules Go est calculé à partir des noms et du contenu des fichiers, et non des détails d'encodage ZIP. Par conséquent, des archives générées indépendamment, avec la même arborescence de fichiers, produisent le même hachage. Les modules patchés constituent l'exception : un contenu différent implique par définition un hachage différent, et la manière dont ce contenu est versionné et authentifié dépend du mécanisme de distribution des modules patchés du registre.
Puis-je laisser la base de données de sommes de contrôle activée ?
Oui, et vous devriez. La vérification GOSUMDB et le contrôle du registre répondent à des questions différentes, et pour les modules amont servis tels quels, les hachages concordent par construction. Laissez GOSUMDB=sum.golang.org activé pour ces modules et gérez les modules modifiés via le mécanisme de versionnage et de somme de contrôle documenté par votre registre.
Dois-je modifier go.mod pour utiliser un proxy différent ?
Non. go.mod enregistre les chemins et versions des modules, et hormis les directives de remplacement que vous avez définies, il n'a aucune influence sur la provenance des archives. Le choix du proxy se fait dans la configuration de l'environnement.
Comment puis-je vérifier moi-même l'affirmation de compatibilité ?
Videz le cache des modules avec la commande `go clean -modcache`, puis exécutez `go mod download` via le nouveau registre afin que Go télécharge et authentifie à nouveau tous les modules par rapport à vos sommes de contrôle existantes. Ensuite, exécutez `go mod verify` suivi de votre procédure de compilation ou de test habituelle. Une compilation réussie signifie que les modules reçus correspondent aux hachages déjà approuvés par votre projet.
