Em setembro de 2025, um pacote npm chamado @ctrl/tinycolor ganhou duas versões novas que ninguém tinha pedido. Horas depois, as credenciais roubadas desse pacote estavam a publicar versões maliciosas de outras centenas de bibliotecas, numa cadeia que se replicava sozinha como um verme de rede. Foi o início do Shai-Hulud, e marcou a viragem para uma fase mais agressiva dos ataques à cadeia de fornecimento de software. Um ano depois, o padrão repetiu-se em registos diferentes, com técnicas diferentes, mas com o mesmo objetivo: chegar ao computador do programador antes de chegar ao utilizador final.
Este artigo compara os quatro maiores repositórios de código aberto do mundo (npm, PyPI, Open VSX e crates.io) pelos incidentes reais que sofreram entre 2025 e 2026, pelas defesas técnicas que cada um construiu e pelo custo de se proteger contra eles. Não é um exercício teórico. Usamos números de relatórios da Sonatype, da StepSecurity, da Socket, da Phoenix Security e de outras equipas de investigação que seguiram estes casos ao minuto. O tema liga-se diretamente a outras áreas que já cobrimos no hub de segurança do shattered.io, da deteção de segredos expostos em código à assinatura de artefactos antes de chegarem a produção.
O que mudou desde 2025: a era dos worms auto-replicantes
Até 2024, a maioria dos ataques à cadeia de fornecimento seguia um guião simples: um atacante publicava um pacote com nome parecido com outro popular (o chamado typosquatting), ou comprometia a conta de um só maintainer e lançava uma versão maliciosa isolada. Era desagradável, mas continha-se. O que mudou em 2025 foi a chegada de campanhas que se propagam sem intervenção humana contínua, usando as próprias credenciais roubadas para publicar mais pacotes maliciosos, que por sua vez roubam mais credenciais.
A Sonatype descreveu esse padrão como o primeiro caso de uma campanha npm a espalhar-se de forma autónoma, à semelhança de um worm de rede tradicional. Isto muda a forma como as equipas de segurança devem reagir. Um pacote malicioso isolado resolve-se com uma remoção. Um worm que se propaga por si próprio exige conter toda a cadeia de confiança antes que se espalhe para outros projetos.
Em agosto de 2026, a StepSecurity publicou uma análise que seguiu 56 campanhas distintas de ataque à cadeia de fornecimento de código aberto nos 12 meses anteriores, espalhadas por npm, PyPI, RubyGems, Composer, crates.io, GitHub Actions e extensões de IDE. O número por si só diz muito: não se trata de um incidente isolado por registo, mas de um ritmo quase semanal de novas campanhas em todo o ecossistema open source.
O alvo também já não se limita a bibliotecas comuns. O caso do grupo TeamPCP, que conseguiu comprometer pacotes ligados a ferramentas como Bitwarden, Trivy e Checkmarx, mostrou que os próprios produtos de segurança se tornaram alvos apetecíveis. Atacar a ferramenta que devia detetar o ataque é, para quem está do outro lado, a forma mais eficiente de ganhar tempo antes de ser descoberto.
npm sob ataque: da primeira à segunda vinda do Shai-Hulud
O npm continua a ser o registo mais visado, em boa parte porque é também o maior: milhões de projetos JavaScript e Node.js dependem dele todos os dias. A primeira onda do Shai-Hulud, a 15 de setembro de 2025, afetou mais de 500 pacotes identificados por rastreadores de incidentes, com cerca de 180 confirmados como comprometidos. O mecanismo era simples e eficaz: cada pacote infetado tentava publicar versões maliciosas de outros pacotes do mesmo maintainer, usando tokens npm e GitHub roubados.
A segunda vaga, divulgada a 24 de novembro de 2025, foi maior. A Sonatype catalogou-a como sonatype-2025-007248 e contou mais de 2.100 pacotes maliciosos associados à campanha. Outro inventário independente de incidentes registou 796 pacotes, cerca de 25 mil repositórios afetados e aproximadamente 350 maintainers envolvidos. Os números variam entre relatórios porque cada equipa usou critérios diferentes para contar o que entra na lista, mas a ordem de grandeza mantém-se consistente entre fontes independentes: centenas a milhares de pacotes.
Esta segunda versão do worm também ficou mais sofisticada a nível técnico. Usava ficheiros chamados setup_bun.js e bun_environment.js durante o passo de pré-instalação, e chegava a criar um runner self-hosted do GitHub Actions com o nome SHA1HULUD para garantir persistência mesmo depois de o pacote original ser removido. Segundo um relatório citado pela comunidade de segurança, a campanha chegou a nove organizações distintas em cerca de 30 minutos, incluindo nomes como Ornikar, Deliveroo, ServiceTitan e Qlik. Outra estimativa apontou para mais de 700 pacotes npm ligados ao Shai-Hulud 2.0, representando um total combinado de aproximadamente 132 milhões de downloads mensais nos pacotes afetados.
O npm, gerido pelo GitHub (e portanto pela Microsoft), respondeu com medidas estruturais em vez de apenas remoções caso a caso. Desde novembro de 2025, os tokens de acesso legados deixaram de ser suportados, substituídos por tokens granulares que podem limitar permissões a pacotes específicos, organizações ou operações. A publicação de pacotes passou a exigir autenticação de dois fatores ativa na conta, ou um token granular com a opção explícita de bypass_2fa apenas para automação controlada. Pacotes novos passaram a ter 2FA ativada por omissão a partir de dezembro de 2025.
PyPI em 2026: menos barulho mediático, o mesmo risco técnico
O PyPI, gerido pela Python Software Foundation, não sofreu um único evento ao estilo worm com a escala do Shai-Hulud, mas isso não significa que esteja mais seguro. Em vez disso, teve uma série de incidentes rápidos e cirúrgicos ao longo de 2026, cada um a explorar o facto de que pacotes Python populares são frequentemente dependências transitivas de produtos de IA.
Em março de 2026, versões maliciosas do pacote LiteLLM (1.82.7 e 1.82.8) ficaram disponíveis durante um período estimado entre 40 minutos e pouco mais de duas horas e meia, dependendo da fonte consultada, e já tinham acumulado mais de 119 mil downloads antes de serem colocadas em quarentena. Em abril, foi a vez do PyTorch Lightning: as versões 2.6.2 e 2.6.3 foram removidas cerca de 42 minutos depois da publicação. Em maio, três versões maliciosas do pacote durabletask da Microsoft (1.4.1, 1.4.2 e 1.4.3) ficaram no ar durante uma janela de aproximadamente 35 minutos, num pacote com cerca de 417 mil downloads mensais em condições normais.
Há também casos que não dependem de comprometer infraestrutura, mas de enganar diretamente as pessoas. O pacote num2words teve versões comprometidas depois de os seus maintainers caírem num ataque de phishing direcionado, uma lembrança de que a parte mais fraca da cadeia continua a ser, muitas vezes, humana e não técnica.
O PyPI tem crescido a um ritmo que torna a vigilância manual impraticável. Segundo dados citados em relatórios de 2026, o registo adicionou cerca de 130 mil pacotes novos durante 2025, a um ritmo que se aproxima de 900 pacotes por dia. Com um volume de tráfego anual estimado em 1,92 exabytes, qualquer janela de poucos minutos entre publicação e deteção já é suficiente para gerar centenas de milhares de downloads maliciosos antes de uma remoção.
Open VSX e o problema das extensões “dormentes”: o caso GlassWorm
Se o npm e o PyPI lidam com bibliotecas de código, o Open VSX (gerido pela Eclipse Foundation e usado como marketplace de extensões por editores como o VS Code e o Cursor) lida com algo mais perigoso em certos aspetos: código que corre diretamente dentro do ambiente de desenvolvimento, com acesso ao sistema de ficheiros e aos tokens de autenticação armazenados localmente.
O GlassWorm tornou-se o exemplo de referência desta categoria de ataque em 2025 e 2026. A técnica central chama-se “extensão dormente”: o atacante publica uma extensão sob um nome que parece legítimo, deixa-a acumular confiança e downloads durante semanas ou meses, e só depois a arma com código malicioso através de uma atualização normal. A Socket, empresa de investigação que seguiu o caso de perto, atribuiu à campanha mais de 320 artefactos publicados desde 21 de dezembro de 2025, com uma vaga adicional de 73 extensões de imitação identificada a 25 de abril de 2026.
Outra análise, focada numa janela mais estreita entre 3 e 19 de março de 2026, atribuiu ao GlassWorm mais de 433 componentes comprometidos distribuídos entre GitHub, npm, o VS Code Marketplace e o próprio Open VSX, com cerca de 35.800 downloads estimados antes da contenção. O mecanismo de roubo de credenciais funcionava em cadeia: a extensão maliciosa recolhia tokens de GitHub, npm e Open VSX de quem a tinha instalado, e usava-os para publicar atualizações envenenadas noutras extensões e pacotes mantidos pela mesma pessoa. Uma análise da RapidFort sobre os incidentes de 2026 descreve este tipo de propagação cruzada entre registos como o traço mais preocupante do ano, porque obriga as equipas de segurança a vigiar vários ecossistemas em simultâneo em vez de apenas um.
A escala do problema de extensões maliciosas também está a crescer de forma mensurável. A ReversingLabs detetou 27 extensões maliciosas em 2024. Nos primeiros dez meses de 2025, esse número subiu para 105, quase quatro vezes mais. Um caso anterior, divulgado em julho de 2025 e investigado pela Kaspersky, envolvia uma extensão falsa chamada “Solidity Language” distribuída através do Open VSX e visando utilizadores do Cursor que trabalham com contratos inteligentes. A infraestrutura por trás dessa extensão incluía um instalador em PowerShell e ferramentas como ScreenConnect e Quasar RAT, e pelo menos uma vítima do setor de criptomoedas reportou perdas de aproximadamente 500 mil dólares.
Este tipo de ataque partilha semelhanças com outro caso que já analisámos em detalhe, o do GitSpawn, que explorou ficheiros de configuração git para atingir ferramentas de IA como o Claude Code e o Cursor. Em ambos os casos, o alvo final não é o utilizador comum, mas o próprio ambiente de desenvolvimento, onde uma única credencial comprometida pode abrir a porta a dezenas de projetos diferentes.
crates.io: o exemplo de contenção rápida
O registo de pacotes Rust, mantido junto da Rust Foundation, oferece o contraponto mais favorável nesta comparação, embora com uma ressalva importante sobre a escala dos dados disponíveis. A 20 de agosto de 2026, três pacotes maliciosos (arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9) foram publicados através de uma conta de maintainer comprometida, usando uma dependência com nome parecido a um pacote legítimo e um script de build para executar o payload. As três versões foram removidas entre 86 e 107 minutos depois da publicação.
Esse tempo de resposta é claramente melhor do que o observado nas maiores campanhas de npm, onde a escala chegou a milhares de pacotes antes da contenção completa. Mas há uma diferença de fundo que impede uma comparação direta: o incidente do crates.io envolveu três versões de pacotes, enquanto o Shai-Hulud envolveu centenas a milhares. Não há, nos dados disponíveis publicamente, prova de que o crates.io tenha uma taxa de ataque subjacente mais baixa. É possível, e provavelmente mais correto, dizer apenas que o ecossistema Rust é um alvo menos frequente até agora, não necessariamente mais seguro por desenho.
Tabela comparativa: npm vs PyPI vs Open VSX vs crates.io
A tabela seguinte resume as características técnicas e o histórico de incidentes dos quatro registos, com base nos dados reunidos ao longo deste artigo.
| Critério | npm | PyPI | Open VSX | crates.io |
|---|---|---|---|---|
| Entidade gestora | GitHub (Microsoft) | Python Software Foundation | Eclipse Foundation | Rust Foundation |
| Linguagem/ecossistema | JavaScript / Node.js | Python | Extensões de IDE (VS Code, Cursor, outros) | Rust |
| Maior incidente 2025-2026 | Shai-Hulud 2.0 (2.100+ pacotes) | Série de incidentes pontuais (LiteLLM, PyTorch Lightning, durabletask) | GlassWorm (320+ artefactos) | 3 crates maliciosos (ago. 2026) |
| Padrão de ataque dominante | Worm auto-replicante via credenciais roubadas | Comprometimento rápido de conta + typosquatting | Extensões “dormentes” com ativação tardia | Conta de maintainer comprometida |
| Tempo médio de contenção observado | Horas a dias (escala elevada) | 35 a 150 minutos nos casos documentados | Semanas (deteção tardia por desenho) | 86 a 107 minutos |
| 2FA obrigatória para publicar | Sim, desde 2025 (ou token granular com bypass controlado) | Parcial, reforçada progressivamente | Depende do publisher individual | Associada à conta GitHub/crates.io |
| Tokens de longa duração | Removidos em nov. 2025, substituídos por tokens granulares | Em transição para Trusted Publishing (OIDC) | Tokens pessoais, sem OIDC nativo generalizado | Tokens de API com escopo |
| Atestação de proveniência | Sim, via npm publish --provenance | Trusted Publishing (OIDC, sem tokens de longa duração) | Não generalizada | Não generalizada |
| Crescimento de pacotes novos | Milhares por dia (ecossistema maior do mundo) | Cerca de 900 pacotes novos por dia (2026) | Centenas por mês | Centenas por dia |
| Risco por execução | Código corre em build/runtime do projeto | Código corre em build/runtime do projeto | Código corre dentro do IDE, com acesso a ficheiros locais e tokens | Código corre em build/runtime do projeto |
| Ferramentas de deteção mais citadas | Socket, Snyk, GitGuardian, Sonatype | Socket, Phoenix Security, Trail of Bits (auditorias) | Socket, Koi Security, Aikido | cargo-audit, RustSec |
Benchmarks de ameaças: o que dizem Sonatype, StepSecurity e Phoenix Security
Como estes ataques não têm um benchmark de desempenho no sentido tradicional, a forma correta de comparar a gravidade da ameaça é olhar para três relatórios independentes que mediram o mesmo fenómeno com metodologias próprias.
A Sonatype mede o impacto por número de componentes e organizações afetadas, e o seu relatório sobre o Shai-Hulud 2.0 continua a ser a referência mais citada para a escala do maior incidente npm da década. A StepSecurity, numa análise publicada a 22 de agosto de 2026, optou por medir frequência de campanhas: 56 ataques distintos ao open source em 12 meses, uma métrica que mostra a persistência do problema mais do que o pico de um único caso. Já a Phoenix Security, no relatório “Supply Chain Attacks 2026: npm, PyPI, VS Code, AI Agents”, contou 59 campanhas e 657 indicadores de pacotes maliciosos entre junho de 2024 e junho de 2026, com uma observação relevante: a maioria destes casos nunca recebeu um número CVE formal, porque são tratados como remoções de registo e não como vulnerabilidades de software convencional.
Um quarto ponto de dados vem da Unit 42, da Palo Alto Networks, que descreve o npm como tendo uma superfície de ataque estruturalmente maior do que os outros registos, não por ser tecnicamente mais fraco, mas por ter mais pacotes, mais maintainers individuais e mais dependências transitivas por projeto médio. Quando quatro organizações de investigação independentes, com metodologias diferentes, chegam à mesma conclusão sobre onde o risco se concentra, a confiança nesse resultado sobe de forma clara.
Quem tem o pior histórico? A análise dos dados
Pela escala pura de pacotes maliciosos documentados, o npm tem o histórico mais preocupante: mais de 500 pacotes na primeira vaga do Shai-Hulud e mais de 2.100 associados à segunda, segundo a contagem da Sonatype. Nenhum outro registo chegou perto desse volume num único evento até à data deste artigo.
Pelo critério de velocidade de contenção, o crates.io sai melhor na comparação direta, com remoções em menos de duas horas no incidente de agosto de 2026. Ainda assim, vale repetir a ressalva: o volume de dados disponível sobre o crates.io é muito menor, o que torna qualquer conclusão sobre “o registo mais seguro” prematura com base apenas num incidente.
O Open VSX destaca-se por uma razão diferente: não é o maior em volume, mas é o que tem o padrão de ataque mais difícil de detetar com ferramentas tradicionais de scanning de dependências. Uma extensão dormente que só ativa o payload semanas depois de publicada escapa a muitas análises estáticas feitas no momento da instalação. A subida de 27 para 105 extensões maliciosas detetadas pela ReversingLabs entre 2024 e os primeiros dez meses de 2025 sugere que este vetor está a crescer mais rápido, em termos relativos, do que os ataques clássicos a pacotes de código.
O PyPI ocupa uma posição intermédia incómoda: não teve um evento ao estilo worm com a escala do Shai-Hulud, mas teve vários incidentes de alta precisão contra pacotes com centenas de milhares de downloads mensais, cada um contido em menos de três horas. Isso sugere maintainers e equipas de segurança atentos, mas também sugere atacantes a escolher alvos de forma mais seletiva e eficaz do que uma campanha de volume indiscriminado.
Linha do tempo: os maiores incidentes de 2025 e 2026
- 15 de setembro de 2025: Shai-Hulud 1.0 no npm: mais de 500 pacotes afetados, cerca de 180 confirmados como comprometidos, com o caso
@ctrl/tinycolorcomo ponto de entrada inicial. - 24 de novembro de 2025: Shai-Hulud 2.0 no npm: mais de 2.100 pacotes maliciosos catalogados pela Sonatype, com criação de runners self-hosted do GitHub Actions para persistência.
- 21 de dezembro de 2025 a abril de 2026: Campanha GlassWorm no Open VSX: mais de 320 artefactos publicados, incluindo uma vaga de 73 extensões de imitação identificada a 25 de abril de 2026.
- Março de 2026: Pacote LiteLLM no PyPI: versões maliciosas com mais de 119 mil downloads antes da quarentena.
- Entre 3 e 19 de março de 2026: Onda adicional do GlassWorm atribuída a mais de 433 componentes entre GitHub, npm, VS Code Marketplace e Open VSX.
- Abril de 2026: Pacote PyTorch Lightning no PyPI: remoção em cerca de 42 minutos depois da publicação.
- Maio de 2026: Pacote
durabletaskda Microsoft no PyPI: três versões maliciosas removidas numa janela de aproximadamente 35 minutos. - 20 de agosto de 2026: Três crates maliciosos no crates.io (
arrayref,internment,append-only-vec): removidos entre 86 e 107 minutos.
Preços: quanto custa proteger-se destes ataques
Nenhum dos quatro registos cobra para publicar ou instalar pacotes. O custo real aparece nas ferramentas de deteção e bloqueio que as equipas de engenharia precisam de adicionar por cima dos registos para se protegerem. A tabela seguinte reúne os preços publicados oficialmente pelos principais fornecedores em 2026.
| Ferramenta | Plano gratuito | Plano pago inicial |
|---|---|---|
| Socket | 1.000 scans/mês, 3 membros, 1 repositório | 25 $/mês por developer (Team, mínimo 5 developers) |
| Snyk | 5 projetos, 100 testes Snyk Code/mês | A partir de 25 $/mês (Team, até 100 projetos) |
| Sonatype Nexus Repository | Community Edition grátis | A partir de 1.950 $/ano (Nexus Repository Cloud Pro) + consumo |
| Sonatype Repository Firewall | Sem plano gratuito público | Preço personalizado, sob consulta |
| GitGuardian | Sem limites públicos confirmados para 2026 | Sob consulta (sem preço público verificado) |
| Aikido Security | Sem limites públicos confirmados para 2026 | Sob consulta (sem preço público verificado) |
Para equipas que já usam ferramentas de scanning de segredos ou SAST, vale comparar o investimento total. Já analisámos essa área noutro artigo sobre GitGuardian vs Gitleaks vs Semgrep, onde o volume de segredos expostos em repositórios públicos chega a 28,65 milhões de casos só em 2026. A escolha entre pagar por uma ferramenta comercial e montar uma pilha com ferramentas gratuitas como o cargo-audit ou o Dependabot depende do tamanho da equipa e do número de registos que precisam de cobertura simultânea. Para uma comparação mais detalhada entre estas três opções específicas, o artigo sobre Snyk vs Dependabot vs Socket entra nos preços por desenvolvedor e nas diferenças de cobertura entre os três produtos.
Casos de uso: qual proteção escolher para o seu projeto
Não existe uma resposta única, porque o perfil de risco muda consoante o tipo de equipa e o registo que mais se usa no dia a dia.
- Programador independente ou pequena startup em Node.js: ativar 2FA obrigatória na conta npm, usar tokens granulares com escopo limitado a um pacote, e confiar no plano gratuito do Socket para scanning básico antes de fazer merge.
- Equipas de dados ou machine learning em Python: fixar versões exatas no
requirements.txtoupoetry.lock, migrar para Trusted Publishing no PyPI em vez de tokens de API de longa duração, e monitorizar dependências como LiteLLM e PyTorch Lightning com particular atenção, dado o histórico recente. - Equipas de infraestrutura em Rust: usar
cargo-audite a base de dados RustSec como primeira linha de defesa, sem assumir que o volume baixo de incidentes do crates.io significa risco zero. - Equipas que usam muitas extensões de VS Code ou Cursor: auditar regularmente a lista de extensões instaladas, desativar extensões não usadas há mais de 60 dias, e dar prioridade a extensões com assinatura verificada e histórico de atualizações consistente, exatamente o perfil que faltava às vítimas do GlassWorm.
- SOC ou equipa de segurança empresarial com múltiplos registos em produção: considerar uma plataforma única de SCA que cubra npm, PyPI e Open VSX ao mesmo tempo, como o Socket ou o Snyk, para evitar lacunas de visibilidade entre ferramentas diferentes por linguagem.
- Equipas de CI/CD com pipelines GitHub Actions: revisar runners self-hosted periodicamente, já que o Shai-Hulud 2.0 demonstrou como um runner comprometido pode servir de ponto de persistência invisível durante semanas.
Guia de migração: de reativo a proativo em 7 passos
Passar de uma postura reativa, que remove o pacote depois do alerta, para uma postura proativa, que bloqueia antes de o pacote entrar no build, exige mudanças concretas, não apenas boas intenções.
- Passo 1: Auditar todas as dependências diretas e transitivas do projeto com uma ferramenta de SCA (Socket, Snyk ou equivalente) e identificar pacotes sem atualização há mais de 12 meses, seguindo recomendações como as publicadas pelo NCSC do Reino Unido.
- Passo 2: Ativar 2FA obrigatória em todas as contas de publicação de pacotes da equipa, sem exceções para contas de automação que não usem tokens com escopo limitado.
- Passo 3: Substituir tokens de API de longa duração por mecanismos de Trusted Publishing baseados em OIDC, disponíveis no PyPI e cada vez mais comuns noutros registos.
- Passo 4: Fixar versões exatas (pinning) em ficheiros de lockfile, e tratar qualquer atualização automática de dependências como um evento a revisar manualmente, não a aceitar às cegas.
- Passo 5: Reduzir o número de extensões de IDE instaladas ao mínimo necessário, e verificar o publisher de cada uma antes de instalar, em particular no Open VSX.
- Passo 6: Configurar alertas automáticos para publicações novas em dependências críticas, de forma a reduzir a janela entre publicação maliciosa e deteção interna.
- Passo 7: Fazer simulações trimestrais de resposta a incidentes de cadeia de fornecimento, incluindo o cenário de uma conta de maintainer comprometida, para que a equipa saiba exatamente que pacotes remover e que credenciais rotar em minutos, não em horas.
Equipas que já usam ferramentas de assinatura e verificação de artefactos podem complementar este guia com as práticas descritas no artigo sobre Trivy vs Syft vs Cosign, focado em SBOM e assinatura de software, outra camada de defesa que reduz a superfície de ataque antes mesmo de chegar à fase de instalação.
Vantagens e desvantagens de cada registo
npm
Vantagens: maior ecossistema do mundo, resposta estrutural rápida a incidentes (remoção de tokens legados, 2FA obrigatória, atestação de proveniência), forte cobertura por ferramentas comerciais de terceiros.
Desvantagens: superfície de ataque enorme pela quantidade de pacotes e maintainers individuais, histórico dos piores incidentes documentados em volume absoluto.
PyPI
Vantagens: tempos de contenção curtos nos incidentes documentados de 2026, adoção crescente de Trusted Publishing para eliminar tokens de longa duração.
Desvantagens: crescimento muito rápido, próximo de 900 pacotes novos por dia, que dificulta a vigilância manual, e pacotes de IA como alvos de alto valor por terem centenas de milhares de downloads mensais.
Open VSX
Vantagens: comunidade ativa de investigadores de segurança, como a Socket e a Koi Security, a seguir campanhas de perto.
Desvantagens: o padrão de ataque “dormente” é difícil de detetar com scanning estático, o código corre diretamente no ambiente de desenvolvimento com acesso a ficheiros e tokens locais, e as deteções maliciosas quase quadruplicaram entre 2024 e 2025.
crates.io
Vantagens: contenção mais rápida entre os quatro registos no único incidente documentado em detalhe, entre 86 e 107 minutos, e uma comunidade Rust historicamente rigorosa com segurança de memória e de build.
Desvantagens: o volume de dados públicos sobre incidentes ainda é limitado, o que torna qualquer conclusão sobre segurança estrutural prematura.
Veredito: qual ecossistema é mais seguro em 2026
Com os dados reunidos neste artigo, a resposta mais honesta é que nenhum dos quatro registos é “seguro” no sentido absoluto. A pergunta certa não é qual é o melhor, mas qual é o perfil de risco que a sua equipa já está a assumir sem saber.
O npm tem o pior histórico em volume absoluto de pacotes maliciosos, com mais de 2.100 casos catalogados pela Sonatype apenas na segunda vaga do Shai-Hulud. Isso não o torna o registo “pior” de forma automática, porque também é o maior em número de pacotes e de projetos dependentes, o que estatisticamente aumenta a probabilidade de incidentes isolados. O PyPI mostra o melhor equilíbrio entre volume de crescimento e velocidade de resposta, com remoções medidas em minutos nos casos mais recentes. O Open VSX é o que levanta mais preocupação a olhar para a tendência, não para o volume absoluto, porque o seu vetor de ataque, as extensões dormentes, é o mais difícil de apanhar antes de causar dano. O crates.io, com os dados disponíveis, parece o mais contido, mas a amostra ainda é pequena para fechar uma conclusão sólida sobre a sua postura de segurança a longo prazo.
Na prática, a decisão que mais protege qualquer equipa de engenharia em 2026 não depende de qual registo é mais seguro, mas de três hábitos concretos: 2FA obrigatória sem exceções, eliminação de tokens de longa duração a favor de Trusted Publishing ou equivalente, e scanning automático de dependências antes de cada build. Estes três hábitos, combinados, teriam reduzido o impacto de praticamente todos os incidentes descritos neste artigo.
Para empresas sediadas em Portugal e no resto da União Europeia, há ainda uma camada regulatória a considerar. A diretiva NIS2 já obriga milhares de empresas portuguesas a reportar incidentes de cibersegurança significativos, e um ataque à cadeia de fornecimento de software que comprometa dados de clientes conta como tal. Uma equipa que dependa de pacotes npm ou PyPI sem qualquer processo de auditoria de dependências corre o risco de, além do dano técnico direto, enfrentar uma obrigação de notificação que podia ter sido evitada com práticas básicas de higiene de segurança. O cálculo final é simples: o custo de implementar os sete passos de migração descritos acima é muito menor do que o custo de recuperar de um incidente depois de ele acontecer.
Por fim, vale lembrar que nenhum destes quatro registos vai deixar de ser indispensável. Não é realista imaginar equipas de engenharia a abandonar o npm ou o PyPI amanhã. A mudança que faz diferença mensurável é tratar cada dependência nova como uma decisão de risco, não como um comando de instalação automático que ninguém revê.
Perguntas frequentes
O que é o Shai-Hulud e porque é diferente de outros ataques a pacotes npm?
O Shai-Hulud é o nome dado a uma campanha de malware no npm que se replica usando credenciais roubadas dos próprios pacotes que infeta, em vez de depender apenas de um atacante a publicar manualmente cada versão maliciosa. A primeira vaga surgiu em setembro de 2025, e a segunda, maior, em novembro de 2025, com mais de 2.100 pacotes catalogados pela Sonatype.
O Open VSX é seguro para instalar extensões no Cursor ou no VS Code?
O Open VSX em si não é inseguro por desenho, mas o padrão de extensões dormentes usado pela campanha GlassWorm mostrou que uma extensão pode parecer legítima durante semanas antes de ser armada com código malicioso. Recomenda-se limitar o número de extensões instaladas e verificar o publisher antes de confiar numa atualização.
Qual destes quatro registos teve o maior incidente de 2025-2026?
Em volume absoluto de pacotes maliciosos, o npm teve o maior incidente, com mais de 2.100 pacotes associados ao Shai-Hulud 2.0. Em número de artefactos ligados a uma única campanha persistente, o GlassWorm no Open VSX também teve um impacto considerável, com mais de 320 artefactos publicados desde dezembro de 2025.
O que é o Trusted Publishing e porque está a substituir os tokens de API?
Trusted Publishing é um mecanismo baseado em OIDC que permite publicar pacotes sem depender de um token de longa duração guardado num ficheiro de configuração de CI/CD. Em vez disso, o registo confia diretamente no pipeline de build através de uma credencial temporária, o que reduz o risco de um token roubado continuar válido durante meses depois de uma fuga de dados.
Como é que uma equipa pequena, sem orçamento para ferramentas comerciais, se pode proteger?
O ponto de partida gratuito mais eficaz é ativar 2FA obrigatória em todas as contas de publicação, fixar versões exatas em ficheiros de lockfile, e usar ferramentas gratuitas como o Dependabot do GitHub ou o cargo-audit no caso do Rust. O plano gratuito do Socket, com 1.000 scans por mês, também cobre as necessidades básicas de projetos pequenos.
Os ataques à cadeia de fornecimento têm números CVE associados?
Na maioria dos casos, não. A Phoenix Security, no relatório “Supply Chain Attacks 2026”, descreveu explicitamente a maior parte das suas 59 campanhas analisadas como tendo zero CVEs atribuídos, porque os registos tratam pacotes maliciosos como remoções administrativas e não como vulnerabilidades de software num sentido técnico tradicional.
Vale a pena migrar de npm para outro gestor de pacotes JavaScript por razões de segurança?
Não necessariamente. Alternativas como o pnpm ou o Yarn usam o mesmo registo npm por baixo na maioria dos casos, apenas com mecanismos de resolução de dependências diferentes. A mudança que realmente reduz risco é adotar práticas de 2FA, tokens granulares e scanning automático, independentemente do gestor de pacotes escolhido.
Quanto tempo demora, em média, a detetar um pacote malicioso nestes registos?
Varia muito por caso e por registo. Os incidentes documentados do PyPI em 2026 foram contidos entre 35 minutos e cerca de duas horas e meia. O crates.io conteve o seu incidente de agosto de 2026 entre 86 e 107 minutos. Já as campanhas maiores de npm e a campanha GlassWorm no Open VSX levaram semanas a ser totalmente mapeadas, mesmo que remoções pontuais tenham começado mais cedo.
