Resumindo: Segurança da cadeia de suprimentos do npm além do scanner de vulnerabilidades
A segurança da cadeia de suprimentos do npm é a prática de garantir que todos os pacotes instalados em seus projetos JavaScript sejam legítimos, não modificados e seguros. não apenas livre de vulnerabilidades conhecidas.
- A lacuna: Um scanner de vulnerabilidades clássico do npm compara pacotes com bancos de dados CVE. Um pacote malicioso não possui CVE, portanto, passa no teste.
- A prova: Em março de 2026, uma conta de administrador sequestrada transformou o Axios, com mais de 100 milhões de downloads semanais, em um canal de distribuição de malware por cerca de três horas.
- O ponto de entrada: A maioria dos ataques ao npm são realizados por meio de scripts de instalação, que são executados no momento em que você digita algo.
npm install. - O conserto: Detectar comportamentos maliciosos assim que os pacotes são publicados, e não depois que uma vulnerabilidade CVE é descoberta, e reforçar a segurança de como as instalações são executadas.
Em 31 de março de 2026, milhares de desenvolvedores executaram o comando mais comum em JavaScript: npm installAlguns deles baixaram uma nova versão do Axios, o cliente HTTP presente em grande parte das aplicações web do mundo. Seus verificadores de dependências permaneceram limpos. Suas compilações foram aprovadas. E um trojan de acesso remoto silenciosamente se instalou em suas máquinas.
Nada nessa história envolvia uma vulnerabilidade. É exatamente por isso que tantos programas de segurança do npm não a detectaram.
O que aconteceu com o Axios?
O ataque foi simples e paciente. De acordo com o Análise pós-mortem feita pelos próprios mantenedores do AxiosDuas versões maliciosas, 1.14.1 e 0.30.4, foram publicadas através da conta comprometida do mantenedor principal. O atacante não alterou uma única linha de código do Axios. Ele adicionou uma nova dependência, plain-crypto-js, que administrava um postinstall script que buscou uma carga útil de segundo estágio.
A Inteligência de Ameaças da Microsoft atribuiu a infraestrutura à falha. para Sapphire Sleet, um agente estatal norte-coreano. As versões envenenadas ficaram online por aproximadamente três horas antes de serem removidas pelo npm. Para qualquer CI (Integração Contínua). pipeline Ou para um laptop instalado durante esse período, três horas foram suficientes.
Não foi um caso isolado. Em setembro de 2025, o worm Shai-Hulud se espalhou por centenas de pacotes npm roubando tokens de mantenedores e republicando-se. Técnica diferente, mesma lição: no npm, a confiança é herdada automaticamente, e os atacantes sabem disso.
Por que seu scanner de vulnerabilidades do npm não detectou nada?
A maioria das equipes trata a segurança da cadeia de suprimentos do npm como um problema de vulnerabilidade. Elas executam um scanner de vulnerabilidades do npm, que compara a árvore de dependências com bancos de dados de falhas conhecidas, e corrigem o que é relatado. Esse trabalho é importante. Só que responde a uma pergunta diferente.
| Dimensão | Pacote vulnerável | Pacote malicioso |
|---|---|---|
| O que é isso | Código legítimo com um bug | Código escrito para te prejudicar |
| Possui alguma vulnerabilidade CVE? | Geralmente, eventualmente | Quase nunca |
| Quando é perigoso | Quando a falha é acessível e explorada | No momento em que for instalado |
| O que o captura | Uma pesquisa em um banco de dados de vulnerabilidades | Análise do comportamento da própria embalagem |
| Tempo de resposta típico necessário | Dias a semanas | Minutos a horas |
Um banco de dados de vulnerabilidades só pode descrever algo que alguém já analisou e catalogou. Um pacote malicioso publicado há uma hora não tem registro em lugar nenhum. Portanto, o scanner retorna "limpo", e "limpo" é interpretado como "seguro".
Essa é a principal mudança na segurança da cadeia de suprimentos do npm: a questão não é mais "este pacote tem uma falha conhecida?", mas sim "este pacote está fazendo algo que não deveria?".
Quatro maneiras pelas quais os invasores acessam seu diretório node_modules
- Assunção de conta. Roube as credenciais ou o token de um mantenedor e publique uma versão adulterada de um pacote em que as pessoas já confiam. Essa é a tática padrão do Axios, e é a mais difícil de detectar, porque o nome do pacote é exatamente o mesmo.
- Typosquatting. Publicar
axoisorreqeustsE ficar esperando que um erro de digitação, um copiar e colar de um tutorial ruim ou um assistente de programação com IA sugira o nome errado. - Confusão de dependência. Publique um pacote público com o mesmo nome de um dos seus pacotes internos. Se a configuração do seu registro priorizar o pacote público, você instala o código do atacante.
- Instalar scripts. O ponto em comum em quase todos os casos acima. O npm permite que os pacotes sejam executados.
preinstallepostinstallscripts são executados automaticamente, de forma que o código malicioso seja executado antes que alguém importe qualquer coisa. CISOrientação de A sobre o compromisso axios recomenda configurarignore-scripts=truepara précisExatamente por essa razão.
Como a segurança da cadeia de suprimentos do npm se parece na prática
Você não conseguirá impedir todos os ataques com um único controle. Mas pode se tornar um alvo muito mais difícil com alguns hábitos simples:
- Commit seu arquivo de bloqueio e instale com
npm ci. As compilações devem instalar exatamente o que foi revisado, nunca o que estava no registro naquela manhã. - Desativar scripts de instalação por padrão. Conjunto
ignore-scripts=truee permitir scripts apenas para os pacotes que realmente precisam deles. - Defina o escopo dos seus pacotes internos. Nomes internos sem escopo são um convite aberto à confusão de dependências.
- Verificar a procedência. O npm suporta declarações de procedência que vinculam um pacote publicado à sua fonte e compilação. Um lançamento repentino sem esses vínculos, em um projeto que normalmente os possui, é um sinal de alerta que justifica a automatização.
- Combine a verificação de vulnerabilidades com a detecção de malware. Mantenha seu scanner de vulnerabilidades do npm em busca de falhas conhecidas e adicione uma detecção que analise o que os novos pacotes realmente fazem.
O quinto hábito é aquele que a maioria das equipes ignora, e é justamente aquele que o ataque da Axios expôs.
Detecte o pacote malicioso antes que ele receba um nome.
Xygeni Alerta antecipado de malware (MEW) O programa examina novos pacotes em registros públicos, incluindo o npm, assim que são publicados, e analisa o comportamento do código em vez de esperar por uma assinatura conhecida. Quando um pacote é sinalizado, os usuários afetados são notificados por e-mail, plataformas de mensagens ou pela web.hookse o pacote está em quarentena, então Você pode pará-lo no seu CI/CD guardrails.
Ao redor dele, Xygeni open source security Abrange o restante dos quatro caminhos de ataque mencionados acima: typosquatting, confusão de dependências, scripts de instalação suspeitos e componentes internos do npm sem escopo definido. Também cobre vulnerabilidades conhecidas dos avisos do NVD, OSV e GitHub, priorizadas por alcance, para que você corrija o que é realmente explorável, com correção automática. pull requests para as correções.
O MEW está incluído no plano gratuito para desenvolvedores. Comece de graça e analise seus primeiros projetos npm em minutos.
Perguntas frequentes
O que é segurança da cadeia de suprimentos npm?
A segurança da cadeia de suprimentos do npm abrange todos os riscos introduzidos pelos pacotes dos quais seus projetos JavaScript dependem: vulnerabilidades conhecidas, pacotes maliciosos, contas de mantenedores comprometidas, typosquatting e confusão de dependências. Ela vai além da verificação de vulnerabilidades, garantindo que o que você instala seja legítimo.
Um scanner de vulnerabilidades do npm detecta malware?
Geralmente não. Um scanner de vulnerabilidades npm tradicional verifica os pacotes em relação a bancos de dados de vulnerabilidades conhecidas. Um pacote malicioso recém-publicado não possui entrada no banco de dados, portanto, passa na verificação, a menos que a ferramenta também analise o comportamento do pacote.
Is npm audit o suficiente?
npm audit É uma base de referência gratuita útil para vulnerabilidades conhecidas. Não detecta malware recém-publicado, typosquats ou confusão de dependências, e não informa se uma função vulnerável é realmente acessível a partir do seu código.
Como posso saber se um pacote é malicioso?
Sinais de alerta incluem scripts de instalação que baixam ou executam código remoto, código ofuscado, chamadas de rede não relacionadas à finalidade do pacote, uma nova dependência que o repositório de origem nunca referencia e uma versão sem a procedência que o projeto normalmente publica.
