vlt 1.0 chega como substituto do npm e bloqueia malware no próprio registry

O vlt, gerenciador de pacotes e registry para JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → construído pelos criadores originais do npm, lançou a versão 1.0 como um substituto drop-in do npm. Junto do cliente vem a disponibilidade geral dos registries hospedados e dos mirrors de ecossistema. A promessa central, nas palavras do fundador Darcy Clarke no X, é um cliente "construído para que nada rode na sua máquina só porque você digitou install".

Para quem escreve software em Node.js no Brasil, o ponto que interessa não é mais um gerenciador na disputa por velocidade de instalação. É a mudança de modelo de segurança na cadeia de suprimentos, que é onde os ataques têm acontecido.

A separação entre install e build

O npm faz tudo num passo só: baixa, extrai e roda os lifecycle scripts (como postinstall) de cada pacote. É exatamente esse encadeamento automático que ataques de supply chain exploram, código malicioso executa no momento em que você instala.

O vlt quebra isso em duas etapas. O vlt install baixa e extrai os pacotes sem executar nada. O vlt build roda os scripts, mas só dos pacotes em que você confia, e pula por padrão qualquer coisa marcada como malware:

$ vlt install   # baixa os pacotes, nenhum script roda
$ vlt build     # roda scripts aprovados, bloqueia malware conhecido

Na prática, isso significa que um pacote comprometido pode chegar ao seu node_modules sem sequer ter chance de executar, a decisão de rodar scripts vira uma escolha explícita sua, não um efeito colateral do install.

Query na árvore de dependências

O segundo recurso de destaque é o vlt query, uma sintaxe de seletores que trata o grafo de dependências como uma árvore DOM. São mais de 60 seletores no estilo CSS, e cerca de metade deles são voltados a segurança, alimentados por uma integração com o Socket. Isso permite auditar dependências em escala, algo relevante para times que gerenciam dezenas de projetos.

Há detalhes que vão além do projeto isolado: o seletor :host(local) estende as consultas para todos os projetos da máquina, e a flag --view=mermaid renderiza as dependências encontradas como um diagrama. Para quem precisa mapear onde uma dependência problemática aparece em vários repositórios, é uma ferramenta de auditoria embutida no gerenciador.

Bloqueio no registry, não só no cliente

O diferencial mais forte do vlt está no registry hospedado, que rejeita pacotes maliciosos conhecidos antes de servi-los. Segundo a InfoQ, o vlt já sinalizou mais de 275 mil versões de pacotes, e revisores notam que um quarto delas ainda está instalável no npm.

Esse número contextualiza a jogada. Não é só o cliente que se protege, o próprio ponto de distribuição filtra. A API do registry é compatível com o npm, então pipelines de CI, registries privados e tooling existentes continuam funcionando.

O que os concorrentes já fizeram

O vlt não surge no vácuo. Depois de um ano marcado por ataques de supply chain, como o worm Shai-Hulud, o ecossistema inteiro se mexeu:

A diferença é onde a barreira fica. npm, pnpm e Bun agem no cliente ou na política de instalação. O vlt move parte da defesa para a infraestrutura que serve os pacotes.

Vale a honestidade sobre performance: em velocidade bruta de instalação, pnpm e Bun continuam na frente. O vlt reporta seu registry como até 38% mais rápido que o npm, não como o mais rápido do mercado. Ou seja, quem escolhe vlt escolhe pelo modelo de segurança e pela auditoria de grafo, não por bater recorde de cold install.

A pitch em cinco segundos

No Hacker News, onde o lançamento chegou à primeira página, a recepção foi mista. Um comentarista celebrou algo que "vai beneficiar o ecossistema inteiro", enquanto outros pediram que Clarke explicasse a proposta "em cinco segundos ou menos". A resposta dele:

5s: economize tempo e dinheiro.

10s: o vlt ajuda times de engenharia a construir software JavaScript mais rápido, reduzir risco de supply chain e baixar custos de infraestrutura (via otimizações de performance de API e payload).

20s: se você usa npm há anos e vem escapando por pouco dos vários ataques de malware, ou é responsável por contas altas de CI/agente porque instalações a frio são X% do tempo comparado ao seu build/runtime real, então dá uma olhada na gente.

Darcy Clarke, fundador do vlt

O ângulo de custo de CI merece atenção no contexto brasileiro: com agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → e pipelines rodando install a frio o tempo todo, o custo de infraestrutura de instalação vira linha de despesa concreta, e é parte do pitch.

Como migrar

Segundo a InfoQ, os passos de migração são pequenos. Depois de instalar globalmente, dá para rodar vlt install e vlt build num projeto existente:

npm install -g vlt
# em um projeto existente:
vlt install
vlt build

A configuração passa do .npmrc para o vlt.json, e há um novo lockfile vlt-lock.json. Como a API do registry é compatível com o npm, CI, registries privados e tooling seguem funcionando, o que reduz o atrito de um teste em projeto real. O caminho completo está no guia de migração.

O vlt é gratuito e open source sob licença BSD-2-Clause-Patent, desenvolvido pela vlt technology inc., e já disponível com npm i -g vlt.

O que fica em aberto

A base de dados de malware que sustenta o bloqueio no registry é o coração da proposta, e isso levanta perguntas que o lançamento ainda não responde de forma definitiva: quão rápido novos ataques são catalogados, qual a taxa de falso positivo que pode barrar um build legítimo, e como fica a dependência de um registry hospedado por uma empresa específica em vez do npm público. Para um time brasileiro avaliando adoção, o teste honesto é rodar vlt install/vlt build em paralelo ao fluxo atual e medir tanto o atrito quanto os pacotes efetivamente bloqueados antes de trocar de vez.

Fonte: InfoQ