4
matheusagostinho
1 min de leitura ·

Fiz um gerenciador de pacotes que se RECUSA a instalar pacote com CVE conhecido

O npm audit te avisa da vulnerabilidade depois que ela já está no seu
node_modules — junto com qualquer postinstall que o pacote trouxe. Pra
ataque de supply-chain, "depois" não serve.

Então construí o Vault: gerenciador de pacotes compatível com npm, estilo
pnpm, escrito em Rust, que faz a checagem de segurança fazer parte do install.

Antes de escrever qualquer coisa no node_modules ele:

  • bloqueia CVE crítico/high (OSV + static scan) — dá pra --force, mas você
    assume;
  • não roda lifecycle script (postinstall) por padrão e instala num sandbox
    (Landlock);
  • avisa de pacote publicado agora há pouco ou queda no nº de maintainers
    (sinal de conta comprometida).

Caso real: com "vite": "^5.4.11", npm/pnpm instalam a 5.4.21 calados —
que está no range do GHSA-fx2h-pf6j-xcff (CVSS 8.2). O vault barrou:

✗ BLOCKED vite@5.4.21: critical/high CVE(s): GHSA-fx2h-pf6j-xcff

E o melhor: com cache quente fica a ~0,2s do pnpm mesmo auditando tudo. A
segurança sai praticamente de graça.

Tá no começo (v0.1.3) e quero feedback sincero, principalmente onde o
bloqueio-por-padrão atrapalha.

npm i -g vaultpm   (binários: vault / vt)

Repo: https://github.com/Matheusagostinho/vaultpm

Carregando publicação patrocinada...
2

Meus 2 cents,

Parabens pela iniciativa !

Com o aumento dos ataques a pacotes, este tipo de projeto eh um diferencial legal - otima ideia.

Repositorio devidamente starreado e forkeado - obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Muito obrigado, de verdade, comentário desses no começo de projeto vale mais do que parece. 🙏

Já que você forkou: se um dia rodar em algum projeto seu, me conta onde travou ou onde o bloqueio te atrapalhou. É exatamente esse tipo de feedback de uso real que vai dizer se a ideia se sustenta fora do meu setup. Issue, PR ou só um "isso aqui me irritou" são todos bem-vindos.

Saúde e sucesso pra você também! 🚀

2

Gostei da proposta, parabéns!

Só fiquei com uma dúvida sobre o nome. "Vault" já é amplamente associado a confre de senhas ou gerenciadores maiores como HashiCorp Vault e pode gerar confusão em buscas, documentação e discussões técnicas. Você chegou a considerar esse risco ou avaliar alternativas?

1

Ponto justíssimo, você colocou o dedo exatamente na ferida. Eu já bati nessa colisão na prática. O nome "vault" puro já estava ocupado no npm, então o pacote acabou saindo como vaultpm, com o alias curto vt pro binário. Ou seja, a confusão já me custou o nome limpo na distribuição antes mesmo de alguém reclamar.
A parte que você levanta de busca e documentação é, sendo sincero, a que mais me incomoda. "vault package manager" no Google divide espaço com o HashiCorp Vault e com meio mundo de gerenciador de senha. No uso o contexto "npm/Node" desambigua rápido, mas pra SEO e pra conversa técnica você tem toda razão.
E aqui vai a parte honesta: estou em v0.1.5, que é literalmente a fase mais barata pra rebatizar. Trocar o nome agora custa um fim de semana, daqui a mil instalações e uns posts indexados, o custo é maior.
Se você, ou alguém lendo, tiver uma sugestão que carregue a ideia de "seguro/à prova de adulteração" sem essa herança do Vault, manda aqui. Esse é o tipo de decisão que eu prefiro tomar com a régua de quem vai usar, não sozinho no meu terminal.
Valeu por trazer de forma construtiva em vez de só "troca o nome". 🙏

1

VT combina bem com Veto, inclusive kkkk

Outras opções que talvez funcionem:

GatePM
GuardPM

Mas pensando melhor, já existem ferramentas como dependency-check e Dependency-Track que fazem mapeamento de versões e CVEs em dependências. Talvez faça sentido seguir uma linha mais explícita de “proteção de dependências”, tipo Dependency Guard, Dependency Gate ou algo nessa direção.