NPM reforça a segurança com tokens efêmeros e OIDC, mas a cadeia de fornecimento segue em risco

Em dezembro de 2025, o npm aplicou uma mudança profunda no seu sistema de autenticação para reduzir o risco de ataques à cadeia de fornecimento: ele revogou os chamados “classic tokens” e promoveu tokens de sessão e fluxos baseados em OIDC. É uma melhoria significativa nas defesas por defeito, mas não elimina completamente a possibilidade de um ator malicioso publicar código prejudicial.

Durante anos a base do problema foi simples: as credenciais antigas eram largamente válidas, com um amplo alcance, e se caíam em mãos erradas permitiam publicar novas versões de pacotes sem que fosse necessário demonstrar a proveniência do código. Esse modelo converteu o npm em um objetivo atrativo para aqueles que buscam inserir malware diretamente em bibliotecas muito usadas. Incidentes bem documentados no ecossistema têm mostrado como bastam credenciais comprometidas para causar dano grande e rápido.

A resposta de npm focou-se em três ideias: caducidade curta de credenciais interativas, melhor gestão de tokens e promover o uso de identidades ligadas a execuções de CI através de OIDC. Você pode ler a explicação oficial dessas mudanças no anúncio da equipe de npm aqui. Na prática isso significa que, para operações normais, os tokens interativos expiram rápido e as publicações podem requerer autenticação multifator.

No entanto, a segurança real depende tanto das melhorias técnicas como de como as usam as pessoas e as equipes. Dois pontos chave continuam a deixar a porta aberta para ataques. Primeiro, os ataques de phishing dirigidos à autenticação multifator continuam sendo efetivos: se um mantenedor for enganado e entrega sua senha e o código de um segundo fator, um atacante pode obter um token de sessão válido e publicar uma versão maliciosa em questão de minutos.

Segundo, a plataforma continua a permitir fluxos pensados para a automação que, se configurados com bypass de MFA ou com tokens de longa duração (por exemplo, tokens de 90 dias), recriam essencialmente o problema anterior. Ou seja, a existência de tokens permanentes ou com MFA omitido conserva um vetor de risco importante quando esses segredos são armazenados ou expostos em sistemas de CI/CD.

Isto leva-nos a uma conclusão prática: as melhorias de npm reduzem a janela de exposição e aumentam a dificuldade para o atacante, mas não a elimina. Enquanto houver vias para gerar credenciais persistentes ou para enganar um humano para entregar credenciais de um único uso, haverá sempre um risco de publicação não autorizada.

Em termos concretos de mitigação, é conveniente impulsionar três linhas de trabalho complementares. A primeira é a adoção ampla de OIDC nas integrações de CI; usar tokens ligados a uma execução específica e de vida muito curta reduz drasticamente a utilidade de qualquer segredo roubado. O GitHub oferece documentação sobre como configurar o OIDC para implantação que pode servir como referência prática: configurar o OIDC no GitHub Actions.

A segunda linha é endurecer as políticas de MFA e minimizar exceções: não permitir Tokens que eludam o fator adicional para operações de publicação e forçar MFA na consola reduz a possibilidade de um phishing ser suficiente para publicar código. Os guias de prevenção de phishing e boas práticas de autenticação publicadas por agências como CISA ajudam a entender por que mesmo usuários com MFA podem ser vítimas se não se combinarem controles adicionais: recomendações sobre phishing (CISA).

A terceira linha vai além da autenticação: reexaminar como chegam os artefatos aos nossos ambientes. Se em vez de baixar pacotes pré-compilados do registro nós reconstruímos cada dependência a partir de seu código fonte verificável, o risco de que uma versão publicada com malware chegue às nossas cadeias de fornecimento diminui muito. Uma pesquisa prática de Chainguard sustenta que, em sua base de dados pública de pacotes comprometidos, a maioria dos casos investigados mostravam malware presente apenas no pacote publicado, não no código fonte upstream. Você pode encontrar essa análise no site do Chainguard: Chainguard: mitigando malware em npm.

Esta abordagem de “reconstruir da fonte” não é trivial: implica investir em reprodutibilidade, assinatura de artefatos e cadeias de confiança, mas tem um efeito tangível na redução da superfície de ataque. Ferramentas e serviços que oferecem bibliotecas construídas de maneira verificável podem se encaixar em um modelo de defesa em profundidade que combine políticas de acesso rigorosas, auditoria e verificações em tempo de execução.

No final, o que chama a atenção é que não existe uma única solução milagrosa. A segurança efetiva é uma soma de camadas: boas práticas na gestão de credenciais, uso generalizado de OIDC para automação, obrigatoriedade de MFA em ações sensíveis e, quando possível, reconstrução verificada de artefatos desde a origem. Cada medida reduz o risco restante que as outras deixam.

Para projetos e organizações isso se traduz em decisões concretas: revisar e rotar tokens, habilitar MFA e eliminar exceções de bypass, migrar pipelines para OIDC quando viável, e considerar a adoção de repositórios ou serviços que garantam que o que se instala vem do código fonte verificado. As recomendações práticas e os guias de ferramentas públicas — como a do GitHub para OIDC ou as análises de incidentes de provedores de segurança — são recursos úteis para planejar essa transição.

O npm avançou na direcção certa ao mudar as políticas por defeito e eliminar credenciais imperecedoras. Mesmo assim, enquanto existirem vetores humanos (phishing) e a possibilidade de gerar tokens de longa duração, a ameaça sobre a cadeia de abastecimento permanece. O mais sensato para a comunidade é combinar melhorias na plataforma com mudanças nos processos e na adoção de tecnologias que elevenm a barreira para um atacante até que o sistema deixe de ser rentável.

Se você quiser aprofundar a história e casos concretos de como as credenciais comprometidas foram aproveitadas no passado, Snyk oferece uma análise divulgada do incidente “event-stream”, um dos exemplos mais citados de ataque à cadeia de fornecimento em JavaScript: análise do incidente event-stream (Snyk). E se você se interessa explorar alternativas técnicas centradas em construir artefatos da fonte, a documentação da Chainguard sobre suas bibliotecas para JavaScript explica essa aproximação com exemplos e dados.

Para concluir, convém recordar que este artigo se apoia em trabalhos e análise da comunidade técnica. As recomendações não buscam alarmer, mas sim colocar em perspectiva que as melhorias de npm reduzem risco, mas não desaparecem, e que a resposta mais efetiva passa por combinar controles técnicos com higiene operacional e verificação de origens.