Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O npm audit só consegue comparar sua árvore com os dados de alertas; portanto, uma versão maliciosa publicada há uma hora não será sinalizada.
- Para preencher essa lacuna, é preciso mais do que uma ferramenta, pois os analisadores comportamentais, as verificações de proveniência e os registros filtrados abrangem, cada um, um aspecto diferente dela.
- O controle que altera o resultado é aquele que determina, em primeiro lugar, o que sua compilação tem permissão para resolver.
O npm audit cumpre bem uma função. Ele compara sua árvore de dependências com um banco de dados de vulnerabilidades conhecidas e informa quais correspondências foram encontradas. Para qualquer coisa já documentada, isso é útil. Para qualquer coisa que ainda não tenha sido documentada, o audit não tem nada a dizer, e se você fizer a instalação nesse intervalo, o código ficará na sua árvore antes que haja um aviso para comparar com ele.
Ele nunca foi desenvolvido para detectar um pacote malicioso antes que essa ameaça apareça nos dados de alertas que ele verifica. Encontrar uma alternativa ao npm audit que realmente preencha essa lacuna significa analisar o que determina quais versões sua compilação pode resolver, e não apenas o que é sinalizado após o fato.
O que o `npm audit` realmente verifica e até onde vai essa verificação
O npm audit verifica sua árvore de dependências em relação aos dados de alertas do GitHub Advisory Database, que fornece os dados de auditoria do npm desde 2021. Trata-se de uma consulta de alertas, e não de uma inspeção do conteúdo dos pacotes ou do comportamento em tempo de execução. Se uma versão foi lançada há uma hora e ainda não há nenhum alerta que a abranja, o audit não tem nada com que comparar essa versão e, portanto, ela não será sinalizada.
Isso não é um bug. É a própria definição da ferramenta. O incidente com o Axios, que durou cerca de três horas em março de 2026, mostra como isso funciona na prática. Duas versões com backdoor, a 1.14.1 e a 0.30.4, foram lançadas e se espalharam por meio das instalações, enquanto o comunicado de segurança ainda não havia sido divulgado. Assim que o comunicado foi publicado, a auditoria pôde sinalizar essas versões onde quer que elas tivessem sido instaladas, inclusive em árvores de código onde a instalação já havia ocorrido. O que ela não conseguiu fazer foi alertar durante o período em que isso realmente importava.
Há uma segunda verificação, mais restrita, que vale a pena conhecer. A execução do comando `npm audit signatures` verifica as assinaturas do registro dos pacotes baixados e, quando existentes, seus atestados de proveniência. Todos esses controles atuam em diferentes momentos da linha do tempo, o que fica mais fácil de visualizar quando comparados lado a lado.
| Categoria | O que ele captura | Quando entra em ação |
|---|---|---|
| npm audit | Vulnerabilidades conhecidas registradas nos dados dos alertas que ele verifica | Assim que os dados informativos abrangerem isso |
| Scanners comportamentais e estáticos | Novos pacotes suspeitos, scripts e ofuscação | Após a publicação, antes ou depois da instalação |
| Verificações de assinatura do Registro | Assinaturas ausentes ou inválidas que possam indicar adulteração | Quando as assinaturas forem verificadas |
| Verificações de proveniência | Se a origem declarada de um pacote e seu fluxo de trabalho de compilação correspondem ao seu atestado | Quando as certidões forem verificadas |
| Registros selecionados e reconstruídos | Itens que não passam na verificação da origem ou na triagem de malware | Antes que sua compilação consiga resolvê-los |
Ferramentas de análise comportamental e estática
Quando os dados de auditoria coincidem com os dados de consultoria, as ferramentas comportamentais inspecionam o próprio pacote. Elas analisam o que mudou entre as versões: uma nova dependência que surgiu sem motivo aparente, um script de instalação que não estava presente na versão anterior, código ofuscado, chamadas de rede que ninguém solicitou.
O que eles detectam e que a auditoria do npm não consegue
Um pacote totalmente novo, ou uma versão publicada há poucos minutos sem nenhum aviso de segurança, é um dos casos para os quais essa ferramenta foi desenvolvida. Ela não precisa de um CVE para sinalizar um script pós-instalação suspeito que acesse um domínio desconhecido, ou uma diferença de código que insira centenas de kilobytes de código ofuscado em uma biblioteca de cache sem que haja motivo para isso. Esse é o valor central: detectar comportamentos em vez de esperar que outra pessoa os catalogue primeiro.
Onde ainda deixam a desejar
Essas ferramentas exigem ajustes antes que o sinal seja digno de atenção, e os falsos positivos alimentam aquele tipo de fadiga de alertas que acaba levando alguém a silenciar o canal. Além disso, elas não verificam a origem de um pacote, apenas o que ele parece fazer; assim, uma carga útil que permanece inativa durante uma janela de varredura ainda pode passar despercebida.
A maioria deles também verifica se há conflitos com o que já foi publicado no registro, o que significa que eles avisam que algo está errado depois que a informação já foi inserida lá. Isso representa uma melhoria significativa em relação a esperar pelos dados dos alertas, mas não é a mesma coisa que decidir o que sua compilação tem permissão para instalar.
Para ter uma visão mais ampla das limitações dessa categoria de ferramentas, veja o que as ferramentas de cadeia de suprimentos não oferecem.
Verificação da proveniência e da assinatura
As assinaturas e a proveniência respondem a duas perguntas que a auditoria não responde: se o artefato que você baixou é validado corretamente e onde ele foi compilado.
O que as assinaturas do npm audit realmente confirmam
Os atestados de proveniência do npm utilizam o Sigstore para vincular um artefato publicado ao repositório de origem e ao fluxo de trabalho de compilação que o produziu. A execução do comando `npm audit signatures` verifica se a assinatura de registro de um pacote é válida e, caso exista um atestado, se o pacote possui um atestado válido que o vincule ao repositório de origem e ao fluxo de trabalho de compilação registrado nele.
Por que uma assinatura válida não significa que o produto seja seguro
Essas são verificações reais e úteis. Uma assinatura inválida no registro pode indicar um artefato adulterado, e a proveniência pode revelar um pacote sem histórico de compilação ou um atestado que aponte para uma fonte diferente daquela que você pensava estar obtendo.
O que nenhuma das duas coisas faz é avaliar se o código em si é seguro. A proveniência indica de onde algo veio, não o que ele faz quando está em execução. Um pipeline que tenha sido discretamente comprometido ainda pode produzir uma compilação com um atestado totalmente válido, pois o atestado descreve com precisão uma compilação real de código genuinamente malicioso. Trate uma verificação de proveniência sem problemas como um dos fatores para uma decisão de confiança, não como o ponto final.
Registros que fazem a triagem antes da resolução
Isso nos leva à questão que a maioria das equipes presume já ter resolvido.
Proxy ou espelho versus um registro que inspeciona e reconstrói
Muitas equipes utilizam um registro npm privado como proxy ou espelho à frente do registro público, seja o Verdaccio com um uplink ou um repositório proxy configurado no Nexus ou no Artifactory. Esses produtos podem fazer muito mais do que apenas armazenamento em cache, mas, nessa configuração, sua função é atuar como um ponto de controle para o tráfego de saída e servir como um único local para definir quais fontes são permitidas. A inspeção não faz parte disso. Se nada no caminho verificar o artefato, um pacote upstream malicioso continuará sendo malicioso quando for servido a partir do seu cache.
O outro tipo de registro realiza uma análise do que passa por ele, verificando o artefato, confirmando sua origem e, em alguns casos, recompondo-o a partir dessa origem, em vez de disponibilizar o que quer que o registro público tenha publicado por último. O SecureChain da TuxCare, por exemplo, recompõe pacotes do npm a partir do código-fonte e os verifica antes mesmo de disponibilizá-los em seu registro. Essa é uma garantia substancialmente diferente, e é o elemento que transforma o controle da origem dos pacotes no controle do que realmente é instalado.
O que muda quando um pacote é recompilado a partir do código-fonte
A recompilação a partir do código-fonte elimina um modo de falha que a verificação por si só não consegue detectar, ou seja, um artefato publicado que não corresponde ao que realmente está no repositório upstream. Se a versão que sua compilação resolve for recompilada a partir do código-fonte esperado em um pipeline controlado, um arquivo tar adulterado enviado diretamente para o registro público com um token roubado não poderá entrar nesse caminho, desde que o próprio código-fonte ainda esteja intacto. Essa é uma garantia mais restrita do que “nada de ruim jamais acontece”, mas é uma garantia real e se mantém válida independentemente de um aviso de segurança vir a ser emitido ou não.
Por que o uso de ferramentas em camadas ainda deixa uma lacuna no tempo de execução
Junte tudo isso e você terá coberto uma ampla gama de aspectos: auditoria do npm para vulnerabilidades conhecidas, varredura comportamental para novos pacotes, verificações de assinatura e proveniência. O que nada disso altera, por si só, é quais artefatos o seu gerenciador de pacotes tem permissão para baixar, em primeiro lugar.
Os scripts de instalação de dependências costumavam ser executados no momento em que um pacote era instalado, muitas vezes antes que um verificador detectasse qualquer problema e antes que um usuário humano o examinasse. Foi isso que tornou o ataque ao axios tão eficaz, já que as versões com backdoor incluíam uma dependência totalmente nova cujo script pós-instalação executava o dropper. A partir da versão 12 do npm, os scripts de instalação de dependências são bloqueados por padrão, a menos que o projeto os registre em sua política `allowScripts`, o que fecha parte desse caminho; no entanto, os scripts de instalação de uma dependência comprometida ainda podem ser aprovados por engano.
Caso você ainda não tenha se aprofundado em como esse modelo de confiança funciona, os mecanismos dos scripts de ciclo de vida e seus padrões atuais são abordados neste guia prático sobre como instalar pacotes do npm com segurança. O bloqueio de scripts determina se os scripts de instalação de uma dependência serão executados depois que o npm a selecionar e baixar. Ele não decide se uma versão maliciosa pode ou não ser selecionada.
Essa é a distinção que vale a pena ter em mente. Essas verificações, por si só, não alteram a fonte do pacote a partir da qual sua compilação é resolvida, e uma maneira de fazer isso é transferir a decisão para o registro ao qual suas compilações se referem.
Corrigindo a falha antes que o npm audit a detecte
O SecureChain não é um substituto para a auditoria. É um registro diferente a partir do qual suas dependências do npm são resolvidas. Ele substitui o registro público do npm por um repositório selecionado e recompilado a partir do código-fonte, filtrando os pacotes antes que eles fiquem disponíveis para instalação; assim, o que sua compilação obtém já passou por verificação do código-fonte e filtragem contra malware. Para equipes que desejam mais do que apenas detecção baseada em alertas, isso antecipa a decisão, onde a lacuna nos alertas tem muito menos importância.
A cobertura abrange desde a adoção até a construção, operação e além do fim da vida útil, com os pacotes ativos recebendo correções de acordo com o SLA, e o Suporte de Ciclo de Vida Ilimitado assumindo o controle assim que a manutenção do upstream for encerrada. Cada pacote possui proveniência SLSA Nível 3, uma SBOM e dados VEX, sem a necessidade de alterações no fluxo de trabalho.
Para conhecer melhor os riscos ocultos nas dependências transitivas, assista ao webinar sob demanda ou converse com a equipe sobre o SecureChain.
Perguntas frequentes
Qual é uma boa alternativa ao npm audit?
Não é algo que se substitua diretamente. O `npm audit` ainda é uma maneira razoável de monitorar alertas conhecidos em uma árvore de dependências da qual você já está fazendo a resolução. As opções mais eficazes alteram o ponto em que a decisão é tomada, filtrando os pacotes antes que sua compilação os obtenha — algo que a correspondência de alertas não consegue fazer por padrão.
O npm audit detecta pacotes maliciosos?
Ele verifica apenas o que consta nos dados dos alertas. Os malwares recebem alertas, inseridos no Banco de Dados de Alertas do GitHub pela equipe de segurança do npm e pelo projeto “malicious-packages” da OpenSSF; no entanto, o GitHub documenta o Dependabot — e não o audit — como o canal de alerta para esses casos. De qualquer forma, o audit não consegue identificar uma versão maliciosa recém-publicada com base em seu comportamento, pois ele compara com os dados dos alertas em vez de inspecionar o pacote.
Ainda vale a pena executar o npm audit com um registro filtrado?
Principalmente por uma questão de visibilidade. Um registro filtrado e constantemente atualizado altera o grau em que o trabalho de correção depende da auditoria, mas executá-lo ainda permite identificar quais alertas conhecidos afetam o que já está presente na sua árvore.
Qual é a diferença real entre um registro privado e um registro filtrado?
Um registro privado pode ser configurado como pouco mais do que um proxy ou espelho que controla a origem dos pacotes. Um registro filtrado inspeciona e, em alguns casos, recompila o que realmente é fornecido, o que representa uma garantia diferente e mais robusta.
Uma verificação de proveniência sem problemas significa que um pacote pode ser instalado com segurança?
Não. Uma proveniência válida vincula um artefato à fonte e ao fluxo de trabalho registrados em seu atestado. Ela não comprova que a fonte ou o fluxo de trabalho não tenham sido comprometidos; portanto, um pacote com atestado válido ainda pode ser malicioso.
