Segurança de pacotes ainda tem lacunas em permissões e dependências

O problema: lacunas entre controles

Andrew Nesbitt argumenta que a segurança de gerenciadores de pacotes melhorou - padrões mais rígidos, cooldowns de publicação, restrições a scripts de instalação - mas o trabalho restante continua recaindo sobre cada consumidor, nas lacunas entre controles que funcionam isoladamente. É preciso verificar se uma política configurada realmente vale em todas as ferramentas usadas e encontrar quem possa publicar uma correção quando um scanner aponta vulnerabilidade.

O caso que abre o texto ilustra a falha: em maio de 2026, um contribuidor do Nx instalou uma dependência maliciosa publicada 77 minutos antes. O repositório tinha cooldown de sete dias configurado, mas a versão do pnpm fixada era anterior ao suporte à configuração; o cliente pulou a verificação. As credenciais roubadas alimentaram um lançamento malicioso do Nx Console uma semana depois.

Permissões e promoção de versões

Em permissões de instalação, o autor nota que o Nx já tinha sofrido outro comprometimento em agosto de 2025, quando um script pós-instalação do npm roubou credenciais com as permissões do desenvolvedor, sem aprovação separada para acesso à rede ou a credenciais não relacionadas. No pip, o backend de build roda com as permissões de sistema operacional do usuário que invoca. O Composer bloqueia plugins por padrão, mas cada etapa da instalação precisaria de controle sobre o que o código permitido pode fazer.

Na promoção de versões, o ataque ao Ledger Connect Kit (dezembro de 2023) alcançou aplicativos por um loader que buscava a biblioteca mais recente de um CDN em tempo de execução, sem rebuild ou aprovação. Os cooldowns dependem de timestamps de publicação e de um cliente que os aplique; o autor prefere que a revisão de correções urgentes seja financiada como serviço compartilhado, em vez de cada projeto criar exceções próprias ao temporizador.

Dependências de build e artefatos

O comprometimento do tj-actions/changed-files (março de 2025) veio de uma cadeia de comprometimentos anteriores ligados por credenciais e dependências de ações - relações fora do lockfile da aplicação. No primeiro ataque ao Ultralytics (dezembro de 2024), envenenamento de cache do GitHub Actions forneceu material malicioso ao fluxo legítimo de publicação; remover tokens de registro não fecharia essa rota, pois o próprio build comprometido podia publicar.

No caso xz, a lógica maliciosa de build existia nos tarballs de release, mas não no Git: revisar o código marcado teria perdido a parte exclusiva do tarball. As atestações dos releases maliciosos do Ultralytics ajudaram investigadores a localizar a origem do comprometimento. Go verifica binários publicados contra rebuilds independentes, mas revisão de código-fonte e aprovação dos insumos continuam separadas.

Nomes, sucessão e triagem

Nos incidentes event-stream (2018) e do ctx (2022), mudança de mantenedor e domínio de e-mail expirado abriram caminho para código malicioso; nos sequestros de contas do Packagist (2023), senhas reutilizadas redirecionaram catorze pacotes. O autor sugere exigir nova revisão quando muda o publicador ou o repositório-fonte.

Sobre sucessão: uma pesquisa de dependências classificou 713 de 5.874 repositórios como mortos, e 391 não estavam arquivados; 1.414 pacotes mortos ou dormentes tinham um único publicador. O caso do httpclient, sem release de 2016 a 2025 com certificados CA expirados em 2023, mostra que consumidores precisam de caminhos viáveis de patch e fork, e registros precisam de procedimentos de sucessão.

Na triagem, a ISC registrou 150 envios em cerca de três meses no início de 2026: oito válidos, oito em investigação e 134 falsos positivos. Ao testar scanners contra o curl em maio, um deles encontrou um bug que exigia argumentos ou configuração do atacante - fora do perímetro de segurança declarado pelo projeto. O autor propõe medir scanners pelo trabalho de correção verificado que chega aos usuários em relação ao tempo de investigação exigido dos mantenedores.

Medição, inventário e obrigações

Stenberg constatou que uma figura de 10.467 downloads anuais do curl contrasta com cerca de 250.000 downloads mensais de tarball no site oficial - wrappers, distribuições e cópias embutidas medem objetos diferentes. A decisão de financiamento precisa considerar dependências mal medidas. No trabalho de integração de vulnerabilidades do Homebrew, foram identificados 1.191 patches em 809 formulae; consultas por repositório-fonte no OSV retornaram apenas 1 de 10 CVEs resolvidos pelo conjunto de patches do glibc.

Por fim, o autor critica a extensão das obrigações: a orientação da ENISA exclui gerenciadores de pacotes do sistema operacional, publicação segura e o próprio canal de distribuição do gerenciador. O campo de fornecedor do SPDX permite NOASSERTION e não estabelece contrato de suporte; tratar isso como obrigação de resposta a incidentes de um mantenedor voluntário acrescenta um compromisso que o inventário não criou. Segundo proposta da Æva Black no FOSDEM, o custo de atestações e de manutenção deve ficar com quem usa o software commercialmente, sem transferir responsabilidade aos mantenedores.