Gerenciadores de pacotes têm um problema de integridade
Aprofundamento CEVIU
Aprofundamento
O autor do estudo testou 25 dos gerenciadores de pacotes mais populares para saber se eles detectam um repositório comprometido injetando código malicioso em pacotes legítimos. Menos da metade usa lockfiles que verificam adulteração por padrão, e só dois verificam a integridade de todo pacote baixado. Na prática, o teste usou Docker e mitmproxy para simular um servidor invadido. Chaves privadas de assinatura ficaram fora do alcance do atacante simulado.
Hashes nem sempre significam integridade. Bun, npm, pnpm, Yarn, uv, Poetry, Bundler, Cargo e SwiftPM validam hashes do lockfile. Pub (Dart e Flutter) detecta o desvio de hash, mas instala o pacote mesmo assim, a menos que se use a opção --enforce-lockfile. O pnpm tinha comportamento parecido até a versão 11.4, de maio de 2026. Conan e CocoaPods guardam identificadores (MD5 e SHA-1) que não servem como garantia criptográfica, e o Composer grava hashes de commit, mas o ZIP baixado não permite verificá-los. Em assinaturas, só o Go verifica por padrão. O cpanminus, do Perl, usa HTTP sem criptografia por padrão, e o autor diz que a mudança seria quebra de compatibilidade. O estudo ressalva que testou uma versão, um pacote e uma plataforma por gerenciador.
O que mudou
A cobertura anterior mostra o avanço do problema em outros elos da cadeia, não uma evolução deste estudo. Em 29 de abril de 2026, o CEVIU noticiou "GitHub Actions é o Elo Mais Fraco da Cadeia de Suprimentos Open Source", e em 3 de setembro de 2026, "Ataque 'Shai-Hulud' expõe falhas na segurança de supply chain e sequestra pipelines de desenvolvimento", sobre worms em npm. O novo texto desloca o foco para os registries, que seriam o próximo alvo se o comprometimento de desenvolvedores ficar mais difícil.
Por que isso importa
Para quem opera pipelines e define políticas de dependências, a leitura é que ter lockfile não basta. Vale checar se o gerenciador em uso realmente barra um hash divergente por padrão, ou só com flag. Também vale perguntar se o time espera do lockfile integridade criptográfica ou apenas reprodutibilidade.
Linha do tempo
CEVIU noticia que o GitHub Actions é o elo mais fraco da cadeia de suprimentos open source.
CEVIU noticia o ataque 'Shai-Hulud' e a fragilidade de proveniência na supply chain de software.
Estudo mostra que menos da metade de 25 gerenciadores verifica integridade por padrão.
Perguntas frequentes
Quais gerenciadores de pacotes verificam hashes do lockfile por padrão?
Segundo o estudo, Bun, npm, pnpm, Yarn, uv, Poetry, Bundler, Cargo e SwiftPM seguem o fluxo padrão com hashes no lockfile. No pnpm, a proteção ao sobrescrever o lockfile após divergência só veio na versão 11.4, de maio de 2026. Outros exigem configuração extra, como NuGet e Pip.
O Pub (Dart e Flutter) protege contra pacote adulterado?
Só com configuração. O Pub detecta o hash divergente, mas instala o pacote mesmo assim. Para bloquear a instalação é preciso usar a opção --enforce-lockfile, que não é padrão.
Assinaturas de pacotes resolvem o problema?
Ainda não na prática. Nos testes, só o Go verificou assinaturas por padrão. Os demais exigiam configuração, não tinham código de verificação ou não suportavam assinaturas.
Por que o cpanminus é um caso à parte?
Ele usa HTTP sem criptografia por padrão para falar com o repositório do Perl. Isso permite que um atacante ativo na rede injete código nos pacotes. O desenvolvedor não migrou para HTTPS porque seria uma quebra de comportamento padrão.
Fontes
- blog.trailofbits.comfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 22 de outubro de 2026
- Editoria
- CEVIU Segurança da Informação

