A revogação dos tokens clássicos no npm foi um passo importante, mas está longe de ser a solução definitiva para ataques à cadeia de suprimentos de software. A mudança reduziu alguns vetores óbvios de comprometimento, porém ainda deixa brechas que podem ser exploradas por invasores determinados, especialmente em cenários de phishing e má configuração de autenticação.
Depois do incidente conhecido como Sha1-Hulud, em dezembro de 2025, o npm promoveu uma reformulação profunda em seu modelo de autenticação. A ideia central era diminuir a chance de que credenciais expostas fossem usadas para publicar versões maliciosas de pacotes populares. Até então, muitos mantenedores utilizavam os chamados “tokens clássicos”: chaves de longa duração, com escopo amplo, que permitiam realizar publicações sem uma validação adicional do código-fonte. Se um atacante obtivesse um token desse tipo, tinha liberdade praticamente total para injetar código malicioso em novas versões.
Com a atualização, a plataforma passou a priorizar tokens de sessão de curta duração, geralmente válidos por cerca de duas horas, obtidos via comando npm login. A autenticação multifator (MFA) foi colocada como requisito padrão para o processo de publicação, elevando o nível básico de segurança. Na prática, isso significa que, além de usuário e senha, o desenvolvedor precisa confirmar a ação por um segundo fator, como aplicativo autenticador ou chave física.
Outro pilar da mudança foi o incentivo ao uso de OIDC Trusted Publishing. Nesse modelo, sistemas de integração contínua (CI) não armazenam segredos de forma permanente: em vez disso, recebem credenciais temporárias por execução, vinculadas a um contexto específico de build. Assim, se um invasor comprometer o servidor de CI ou o repositório de código, ainda assim não terá acesso a um token estático capaz de ser reutilizado indefinidamente para publicações maliciosas.
Mesmo com esses avanços, especialistas chamam atenção para duas fragilidades centrais que permanecem em aberto. A primeira é o phishing direcionado ao console do npm. O caso do pacote ChalkJS se tornou emblemático: o mantenedor foi enganado por um ataque cuidadosamente elaborado, que capturou não apenas a senha, mas também o código MFA em tempo real. Em situações assim, a curta duração do token não impede o dano; o atacante dispõe de alguns minutos preciosos – mais do que suficientes – para publicar uma versão adulterada do pacote.
A segunda fragilidade está relacionada à forma como o MFA é aplicado. Apesar de ser fortemente recomendado e, em muitos fluxos, exigido, ainda existem cenários em que o uso de MFA obrigatório para publicação é opcional. Desenvolvedores podem configurar tokens com validade de até 90 dias que permitem o bypass do MFA. Na prática, isso recria um contexto muito próximo ao antigo modelo de tokens permanentes, enfraquecendo o objetivo original da reforma de autenticação.
Se um invasor consegue comprometer a conta de um mantenedor que utiliza esse tipo de token prolongado com bypass habilitado, ele passa a ter permissão para publicar pacotes em nome do autor sem precisar passar por novas verificações de identidade. É exatamente o tipo de risco que o npm tentou mitigar com a extinção dos tokens clássicos. A diferença é que, agora, essa vulnerabilidade surge como consequência de configurações permissivas, e não de um padrão formal da plataforma.
Diante desse cenário, surgem recomendações claras para fortalecer a segurança do ecossistema Node.js e reduzir a exposição a ataques de supply chain. Uma das principais propostas é tornar o uso de OIDC Trusted Publishing o padrão obrigatório a longo prazo. Ao remover gradualmente a dependência de tokens estáticos, o npm poderia minimizar a chance de que uma credencial vazada se transforme em um desastre de grandes proporções.
Outra sugestão importante é exigir autenticação multifator também para uploads locais de pacotes, eliminando completamente a possibilidade de tokens com bypass de MFA. Isso força um alinhamento entre todos os fluxos de publicação, sejam eles feitos via CI ou a partir da máquina do desenvolvedor. Se cada tentativa de publicar uma nova versão precisar, inevitavelmente, de um segundo fator, o espaço para uso indevido de tokens de longa duração diminui consideravelmente.
A inclusão de metadados públicos nas releases também é vista como um avanço estratégico. A ideia é que cada versão publicada traga informações claras sobre as práticas de segurança adotadas pelo mantenedor, como uso de OIDC, MFA obrigatório, assinaturas digitais e processos de revisão. Consumidores de pacotes, equipes de segurança e ferramentas automatizadas poderiam, então, priorizar dependências com perfil de segurança mais robusto e identificar rapidamente projetos que ainda operam com controles frágeis.
Especialistas defendem que credenciais de curta duração, atreladas diretamente à identidade do desenvolvedor ou do pipeline de CI, são fundamentais para reduzir a superfície de ataque. Em vez de um único token poderoso e estável, passa a existir um conjunto de credenciais efêmeras, cada uma válida apenas para um contexto e por um intervalo de tempo bem definido. Isso dificulta a vida do atacante, que precisa agir em janelas muito menores e, em geral, sob maior monitoramento.
Uma abordagem adicional, considerada por muitos como o próximo passo natural, é mudar o foco da confiança: em vez de acreditar cegamente no artefato publicado no registro npm, reconstruir o pacote a partir de código-fonte verificável. Isso envolve, por exemplo, reproduzir o build usando o repositório upstream e comparar o resultado com o artefato distribuído. Se houver divergência, o pacote pode ser sinalizado como suspeito antes de chegar aos usuários finais.
Essa estratégia é especialmente relevante quando se observa que, em análises de incidentes já registrados, cerca de 98,5% dos casos de malware foram encontrados apenas no artefato publicado, e não no repositório de código original. Ou seja, o desenvolvedor legítimo nem sempre é o responsável pela inserção do código malicioso; muitas vezes, o ataque ocorre no momento da publicação. Ao reconstruir a partir do código upstream, a possibilidade de detectar manipulações posteriores aumenta e o impacto de versões comprometidas tende a cair de forma acentuada.
Essas medidas se encaixam no chamado “modelo do queijo suíço” de segurança: nenhuma proteção individual é perfeita, mas a sobreposição de várias camadas de defesa reduz significativamente a probabilidade de um ataque bem-sucedido. Tokens curtos, MFA rigoroso, OIDC como padrão, reconstrução de artefatos e transparência nas práticas de segurança formam, juntos, uma barreira muito mais resistente do que qualquer solução isolada.
Para desenvolvedores e equipes que dependem intensamente do ecossistema npm, algumas práticas podem ser adotadas imediatamente, mesmo antes que mudanças estruturais se tornem obrigatórias. Entre elas, desativar o uso de tokens com validade extensa, habilitar MFA para todas as ações sensíveis, revisar periodicamente quem tem permissão de publicação e segmentar privilégios em contas de organização. Monitorar logs de acesso e configurar alertas para atividades anômalas no console do npm também ajuda a detectar tentativas de invasão em estágios iniciais.
Outro ponto crucial é o fortalecimento da cultura de segurança entre mantenedores. Muitos ataques bem-sucedidos começam com e-mails de phishing, páginas falsas de login ou engenharia social direcionada. Investir em capacitação básica – reconhecer sinais de golpe, validar domínios, usar gerenciadores de senhas e chaves de segurança físicas – costuma ter um impacto direto na redução de incidentes. Por mais sofisticadas que sejam as mudanças técnicas na plataforma, o elo humano continua sendo alvo preferencial de atacantes.
Equipes de empresas que consomem grande volume de pacotes de terceiros também precisam rever suas políticas internas. Implementar listas de permissões (allowlists) de dependências confiáveis, utilizar ferramentas de análise de composição de software (SCA) e manter inventários atualizados das bibliotecas utilizadas são medidas essenciais. Assim, caso um pacote seja comprometido, é possível identificar rapidamente onde ele está sendo usado e aplicar correções ou substituições com agilidade.
Por fim, fica claro que a revogação dos tokens clássicos foi apenas o começo de um esforço mais amplo para reforçar a segurança da cadeia de suprimentos em Node.js. A superfície de ataque hoje é complexa: envolve contas de usuários, pipelines de CI, processos de build, artefatos publicados e até o modo como consumidores avaliam a confiabilidade de um pacote. Tratar esse problema exige uma combinação de políticas mais rígidas na plataforma, boas práticas adotadas por desenvolvedores e monitoramento contínuo de ameaças emergentes.
Enquanto o ecossistema avança rumo a padrões mais maduros – como OIDC obrigatório, reconstrução reprodutível e transparência total nas cadeias de build – permanece a necessidade de vigilância constante. A segurança não é um estado fixo alcançado com uma única atualização, mas um processo contínuo de adaptação. Nesse contexto, entender as limitações da revogação de tokens clássicos e agir proativamente para cobrir as brechas restantes é essencial para quem publica, mantém ou consome pacotes no npm.