Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- Os hashes do módulo Go abrangem os nomes e o conteúdo dos arquivos, e não a codificação ZIP; portanto, um arquivo compactado reconstruído de forma independente pode apresentar uma correspondência exata.
- Por isso, configurar o GOPROXY para um registro filtrado não invalida as entradas do go.sum que você já possui.
- A reconstrução exata comprova que um arquivo corresponde à sua fonte, e não que a fonte esteja segura.
- A alteração em si é uma variável de ambiente, e o risco real está no desvio de configuração.
Em julho de 2026, pesquisadores associaram uma onda de contas de mantenedores comprometidas no npm, no Packagist e nos módulos Go a uma campanha ligada à Coreia do Norte chamada PolinRider. A campanha também publicou pacotes maliciosos totalmente novos, mas o que merece atenção é o que aconteceu com os pacotes já estabelecidos. Os invasores obtiveram acesso a contas com anos de histórico limpo e, a partir delas, lançaram novas versões.
Uma nova versão de módulo enviada a partir de uma conta de mantenedor comprometida pode passar pelas verificações de integridade do Go na primeira utilização. Tanto o go.sum quanto o banco de dados de checksums confirmam que você recebeu exatamente o que foi publicado. Nenhum dos dois se pronuncia sobre se o que foi publicado é seguro.
Adicionar uma camada de verificação a uma compilação pode causar atritos em algum ponto. Novas identidades de pacotes para conciliar, versões para acompanhar, alterações no arquivo de bloqueio que ninguém havia previsto. O Go se sai relativamente bem, e vale a pena entender o motivo, pois isso também explica o que a verificação no Go pode e não pode comprovar.
Por que os arquivos do módulo Go podem ser verificados com exatidão
Um arquivo ZIP do módulo Go contém o código-fonte. Nada é compilado durante o processo de inclusão, e a estrutura do arquivo segue um algoritmo documentado, em vez de depender do que o script de empacotamento do editor estiver fazendo naquele dia.
Isso tem uma consequência que a maioria das pessoas ignora. O comando `go` calcula o hash do módulo com base nos nomes dos arquivos e no conteúdo dos arquivos dentro do arquivo compactado. A codificação ZIP, o método de compactação, as datas de modificação de cada arquivo e outros metadados são todos ignorados. Portanto, qualquer pessoa com acesso ao histórico do controle de versão pode recompilar o módulo e obter a mesma soma de verificação h1:, mesmo que os dois arquivos ZIP sejam diferentes byte a byte.
Outros ecossistemas apresentam mais variáveis entre um repositório e um artefato publicado. O Maven distribui JARs compilados. Os wheels do Python são o resultado da compilação. Um tarball do npm pode conter apenas o código-fonte, ou pode ser o que quer que um script de pré-empacotamento tenha gerado. O trabalho de compilação reproduzível tem avançado bastante em vários desses casos, portanto, não há uma linha clara entre o impossível e o exato. O fato é que a soma de verificação do Go foi projetada desde o início para ignorar ruídos de empacotamento, o que torna a verificação da reconstrução independente excepcionalmente simples.
O que diferencia os fornecedores é se alguém realmente realiza essa comparação em escala de registro, em todos os módulos, todas as vezes. Um registro de triagem pode extrair o histórico do VCS de um caminho de módulo, compilar o arquivo de acordo com as especificações e comparar com o que o proxy público disponibilizou. Uma incompatibilidade significa que o arquivo não corresponde à fonte da qual alega ter vindo.
Essa distinção tem mais importância do que parece à primeira vista. A reconstrução exata indica que um arquivo corresponde à fonte declarada. Ela não diz nada sobre se a própria fonte é segura. O PolinRider é um exemplo típico disso, pois os invasores modificaram diretamente os repositórios legítimos, em alguns casos substituindo à força os commits existentes. Uma reconstrução fiel a partir dessa fonte reproduz o conteúdo malicioso com a mesma fidelidade. A reconstrução detecta adulterações entre o repositório e o arquivo. Detectar código malicioso dentro do repositório é uma tarefa à parte.
Observação: Para artefatos que exigem compilação, scripts de empacotamento ou arquivos gerados, “recompilado a partir do código-fonte” também significa reproduzir essas condições de compilação. A soma de verificação do Go vem diretamente da árvore de código-fonte empacotada, o que torna a comparação excepcionalmente simples de auditar. Peça ao fornecedor para mostrar uma discrepância — não para descrevê-la.
Por que o go.sum continua funcionando
Se um registro reconstruir os arquivos dos módulos, os hashes mudam e todos os comandos `go.sum` da organização deixam de funcionar?
Não. Como o hash abrange a árvore de arquivos e ignora os detalhes da empacotamento, um arquivo compactado reconstruído corretamente gera o mesmo valor de hash que o proxy público teria produzido. Suas entradas existentes no go.sum são validadas em relação a esse valor, e o banco de dados de checksums em sum.golang.org continua a confirmar a validade.
É por isso que a mudança não requer alterações nos arquivos `go.mod` ou `go.sum`. Não se trata de um caminho de migração que por acaso seja curto. Não há nada a ser migrado. Hashes correspondentes são o resultado esperado, e uma divergência é um sinal, e não um inconveniente.
Há um caso que rompe essa simetria e que merece uma resposta direta, em vez de uma nota de rodapé. O Go trata o caminho do módulo e a versão como um todo imutável. Portanto, se um registro fornecer conteúdo corrigido para uma versão que já existe no upstream, esse conteúdo não poderá reutilizar a soma de verificação do upstream. Uma entrada existente no go.sum rejeitaria imediatamente os bytes alterados, e o banco de dados público de somas de verificação continuaria mantendo o hash do upstream. Módulos corrigidos, portanto, precisam de um mecanismo de entrega próprio e documentado, seja uma versão distinta, um caminho de módulo distinto ou outra configuração de confiança controlada. Se a aplicação de correções após o fim do ciclo de vida (EOL) for parte do motivo pelo qual você está mudando, confirme esse mecanismo com a TuxCare antes de planejar a implantação. É o único ponto em que a afirmação “nada muda” deixa de ser verdadeira.
A Única Linha
O GOPROXY aceita qualquer URL que implemente o protocolo de proxy do módulo; portanto, direcioná-lo para um registro filtrado é apenas uma alteração na variável de ambiente.
go env -w GOPROXY=<your SecureChain Go proxy URL>,direct
Use uma vírgula antes de “direct” em vez de uma barra vertical, e entenda o que cada uma delas realmente oferece. Com uma vírgula, o Go recorre à próxima entrada somente após um erro 404 ou 410. Com uma barra vertical, ele recorre após qualquer erro, incluindo um tempo limite, de modo que uma interrupção no registro redireciona discretamente sua compilação contornando exatamente o que você instalou o registro para resolver. De qualquer forma, “direct” significa buscar diretamente da fonte de controle de versão, e a vírgula ainda permite que um erro 404 chegue até ela. Se o registro tiver como objetivo atuar como um filtro, e não apenas como uma sugestão, os módulos bloqueados devem retornar um código de erro diferente de “não encontrado”. A própria documentação do Go aponta para o código 403 exatamente para esse propósito.
Isso funciona independentemente de o GOPROXY estar apontando para SecureChain diretamente ou para um gerenciador de repositórios como o Artifactory ou o Nexus, que por sua vez esteja apontado para o SecureChain. Os módulos e o fluxo de trabalho são os mesmos em ambos os casos.
Para a CI, configure isso no ambiente, em vez de incorporá-lo a uma imagem.
export GOPROXY=<your SecureChain Go proxy URL>,direct
export GOSUMDB=sum.golang.org
A decisão de manter o GOSUMDB explicitamente ativado é deliberada. A verificação da soma de verificação e a análise do registro respondem a questões diferentes, e a troca de proxies não é motivo para desativar nenhum dos dois.
Dica profissional: Defina GOPROXY com o comando `go env -w` nas máquinas dos desenvolvedores e por meio de variáveis de ambiente de CI nos agentes de compilação. Em seguida, execute `go env GOPROXY` em um executor real para verificar o que está realmente definido. Às vezes, as imagens base já vêm com um valor predefinido, e geralmente é isso que causa problemas nessas implantações.
O que permanece igual e o que muda
| Item | Alterações |
| go.mod | Não |
| O `go.sum` para módulos upstream é fornecido tal como está | Não |
| vá compilar, vá testar, vá buscar | Não |
| Diretórios de fornecedores | Não |
| Comportamento da seleção de versão | Não |
| De onde os arquivos são obtidos | Sim |
| Se os arquivos são filtrados antes da resolução | Sim |
Nada muda nos seus comandos de compilação, e nada muda no repositório. O que muda é a origem do arquivo e se ele é verificado antes mesmo de a compilação ter acesso a ele. Há, porém, uma ressalva em relação à linha “vendored”. Uma compilação “vendored” lê os arquivos da pasta `vendor/` e nunca consulta o proxy; portanto, ela não ganha nada com a mudança até que você atualize o diretório.
O que a triagem acrescenta antes da resolução
O Go não possui um gancho na hora da instalação equivalente aos scripts de ciclo de vida do npm, o que normalmente é um ponto a seu favor. Isso não significa, porém, que o conteúdo de um módulo seja inofensivo. Código-fonte malicioso ainda acaba sendo compilado em seu binário, e as ferramentas relacionadas a um repositório podem abrir seus próprios caminhos de execução. O PolinRider é um bom exemplo desse segundo tipo. As cargas úteis eram carregadores de JavaScript ofuscados, ocultos nos recursos do projeto, incluindo arquivos de fonte .woff2 falsos, em vez de qualquer coisa executada a partir de uma função init do Go.
Isso faz com que a verificação pré-resolução seja uma das primeiras oportunidades automatizadas de bloquear conteúdos maliciosos antes que eles cheguem ao ambiente de compilação.
O problema se apresenta em três variantes, e cada uma delas requer uma solução diferente.
Um caminho de módulo comprometido por “repojack” pode disponibilizar uma nova versão maliciosa por meio do caminho legítimo sem violar nenhuma verificação de soma de verificação que o Go já possui, pois essas verificações autenticam o conteúdo do módulo, e não a propriedade ou a intenção do repositório. Recompilar a partir dessa fonte VCS comprometida também não adianta, já que o repositório agora pertence ao invasor. O que ajuda é verificar se há malware no conteúdo antes da resolução.
Um exemplo de versão publicada no repositório principal após o comprometimento de uma conta é o caso do PolinRider. O go.sum e o banco de dados de checksums conseguem autenticá-la com sucesso, pois verificam se os bytes são os mesmos, e não se esses bytes são seguros. É a triagem que preenche essa lacuna.
Um módulo abandonado que contém uma vulnerabilidade CVE é um problema totalmente diferente. Nada malicioso conseguiu invadir o sistema. O mantenedor simplesmente parou de corrigir o que já existia. Os alertas informam sobre isso, mas resolver o problema significa manter o módulo atualizado mesmo depois que seu autor já não está mais envolvido, o que é uma questão de manutenção, e não de detecção. É isso que o Suporte de Ciclo de Vida Ilimitado (ELS) abrange.
Vale a pena dar uma olhada na magnitude desse caso de invasão de contas. Os pesquisadores encontraram vestígios de invasão em 80 módulos Go entre 108 pacotes únicos identificados ao longo da campanha, com 162 artefatos de lançamento maliciosos no total, e rastrearam a atividade como parte do Contagious Interview, também conhecido como Famous Chollima. Esses módulos foram comprometidos por meio de contas com anos de histórico legítimo, e não por nomes semelhantes recém-registrados — exatamente o tipo de situação que a verificação de integridade por si só não consegue detectar. Uma nova versão como essa passa na primeira verificação porque o hash autentica fielmente qualquer conteúdo associado a essa versão, e uma atualização enviada por um mantenedor de longa data não parece suspeita à primeira vista.
Há aqui um problema incômodo específico para o Go. Como os módulos do Go costumam ser obtidos diretamente de tags ou commits do VCS, em vez de serem enviados separadamente para um registro, uma violação no repositório pode se propagar para o ecossistema de módulos sem que o invasor precise de um segundo conjunto de credenciais. Os pesquisadores observaram que a conta de um mantenedor comprometido não apresentou versões maliciosas em um ecossistema que exige uma etapa separada de envio, o que pode significar que os invasores nunca chegaram a esse ponto.
O abandono é a versão mais discreta dessa mesma exposição. Uma análise recente de 13,1 milhões de pacotes de código aberto colocou a parcela “fora da banda” do Go — ponderada por repositórios dependentes, em vez de pelo número de pacotes — em algum ponto entre 33,2% e 57,9%. A variação se resume à definição: o valor mais alto inclui tudo o que não teve uma versão lançada nos últimos 730 dias. O valor mais baixo também exige que não haja commits no repositório nesse período. De qualquer forma, os exemplos citados do Go são bem conhecidos: gopkg.in/yaml.v2, jwt-go, AWS SDK for Go v1. Nenhuma arquitetura de registro, seja ela filtrada ou não, resolve isso por si só. É preciso aplicar correções contínuas, e é para isso que serve o terceiro caso acima.
Implementação sem interromper as compilações
São quatro fases, e a ordem é mais importante do que a velocidade.
| Fase | Ação | O que você aprende |
| 1 | Configure o GOPROXY em um serviço não essencial | Se algum caminho de módulo não for resolvido |
| 2 | Baixar e verificar dependências a partir de um cache de módulos vazio | Se os módulos disponibilizados por meio do novo registro realizam autenticação no seu go.sum existente |
| 3 | Implementar o CI em todos os repositórios | Quais pipelines tinham o GOPROXY codificado diretamente em uma imagem |
| 4 | Restringir o tráfego de saída do agente de compilação ao registro e ao banco de dados de checksum | O que estava sendo discretamente ignorado na configuração |
A segunda fase apresenta as evidências que um revisor cético realmente solicitará.
execute `go clean -modcache`
baixar o Go Mod
go mod verify
Vale a pena ser preciso sobre o que cada comando verifica. Com o cache vazio, o comando `go mod download` força a instalação dos módulos necessários por meio do novo registro e os autentica em relação às entradas confirmadas no `go.sum`, ou em relação ao banco de dados de checksums configurado, caso o hash ainda não esteja registrado. Em seguida, o comando `go mod verify` confirma se o conteúdo armazenado em cache não sofreu alterações desde que foi baixado. Execute ambos os comandos antes de sua compilação ou execução de teste normal, e a verificação de compatibilidade será validada em relação às dependências atuais do seu projeto no seu próprio ambiente, e não em um ambiente de teste do fornecedor.
A fase quatro é quando a política se transforma em aplicação. Até que a saída seja fechada, o GOPROXY é uma sugestão que qualquer pessoa pode ignorar para desbloquear uma implantação na sexta-feira. Bloquear apenas o proxy.golang.org não será suficiente, pois esse redirecionamento direto envia erros 404 para o GitHub e outros sites. Coloque o registro na lista de permissões e bloqueie o restante. Uma verificação antes de ativar a regra: a verificação da soma de verificação ainda precisa de acesso ao banco de dados de somas de verificação, seja diretamente ou por meio de um proxy que o espelhe; portanto, confirme se essas consultas continuam sendo resolvidas, em vez de descobrir isso durante a primeira falha no pipeline.
Dica profissional: Execute a fase quatro no ambiente de teste por tempo suficiente para testar seus fluxos de trabalho normais de compilação antes de passar para a produção. O que vem à tona é o inventário real dos pipelines que estavam sendo resolvidos diretamente sem que ninguém soubesse, e é muito melhor ter esse inventário agora, na forma de uma lista, do que enfrentá-lo mais tarde como um incidente.
Proteja sua cadeia de suprimentos Go
Se as fases um e dois já foram concluídas em seus próprios repositórios, em relação ao seu próprio go.sum, essa é a prova de compatibilidade necessária para uma revisão de segurança, e você mesmo a produziu. O que o SecureChain para Go acrescenta a partir daí é uma triagem contínua a cada busca, em vez de uma verificação única, além de correções que continuam mesmo depois que o mantenedor de um módulo se afastou, fornecidas por meio de um registro que utiliza o mesmo protocolo de proxy de módulos que sua cadeia de ferramentas já espera. Antes de contar com as correções pós-EOL, confirme o mecanismo documentado de controle de versão e checksum para módulos Go corrigidos, para que isso possa ser incorporado à implantação.
Solicite um orçamento para o SecureChain ou veja como o SecureChain se compara ao Chainguard.
Perguntas frequentes
Como faço para alterar o proxy do meu módulo Go?
Defina a variável de ambiente GOPROXY com a URL do registro, usando uma vírgula antes de “direct” em vez de um pipe. Executar o comando `go env -w GOPROXY=…` faz com que ela seja mantida na máquina do desenvolvedor. Na CI, defina-a no ambiente, em vez de na imagem base.
A alteração dos proxies do módulo Go prejudica o funcionamento do go.sum?
Não, desde que o registro forneça o mesmo conteúdo do módulo. O hash do módulo no Go é calculado a partir dos nomes e do conteúdo dos arquivos, e não dos detalhes da codificação ZIP; portanto, arquivos compactados gerados independentemente, mas com a mesma estrutura de arquivos, produzem o mesmo hash. Os módulos corrigidos são a exceção, já que um conteúdo diferente significa, por definição, um hash diferente, e a forma como esse conteúdo é versionado e autenticado depende do mecanismo de entrega de módulos corrigidos do registro.
Posso manter o banco de dados de checksum ativado?
Sim, e você deve fazer isso. A verificação do GOSUMDB e a análise do registro respondem a questões diferentes e, para módulos upstream fornecidos “no estado em que se encontram”, os hashes coincidem por definição. Deixe GOSUMDB=sum.golang.org ativado para esses módulos e lide com os módulos corrigidos por meio do mecanismo de controle de versão e de checksum que o seu registro documentar para eles.
Preciso alterar o arquivo go.mod para usar um proxy diferente?
Não. O go.mod registra os caminhos e as versões dos módulos e, exceto pelas diretivas de substituição que você tiver definido, ele não influencia de onde os arquivos são baixados. A seleção do proxy é definida na configuração do ambiente.
Como posso verificar por conta própria a alegação de compatibilidade?
Limpe o cache de módulos com o comando `go clean -modcache`, execute o `go mod download` por meio do novo registro para que o Go baixe novamente e autentique tudo em relação às suas somas de verificação existentes e, em seguida, execute o `go mod verify`, seguido da sua compilação normal ou suíte de testes. Se o processo for concluído com sucesso, isso significa que os módulos recebidos correspondem aos hashes nos quais seu projeto já confiava.
