Pitch: Apresentando o Scal-P · carlosedujs

Há 2 semanas atrás comecei este projeto com a ideia de, mudar o paradigma de como é gerenciado as dependências, O objetivo da ferramenta é que o fluxo de instalar pacotes seja mais seguro, mas sem fricção absurda que nos irrita.

Então eu tive 2 alternativas para isso: Criar um packager manager novo e ter que lidar com necessidade de adoção mais complexa, devido ao ecossistema já estar acostumado com NPM (classico), PNPM (o mais seguro), Bun, Yarn... ou criar um wrapper em cima deles, e foi isso que eu fiz: o Scal-P. No começo, na primeira versão, eu desenvolvi a primeira PoC e foi muito interessante ver que essa ideia poderia avançar para outros packagers managers, até para fora do ecossistema do JavaScript.

Então eu pensei no inicio que o SCAL-P não teria que se importar se você ama o npm ou prefere o bun. Ele deveria atuar sobre a sua ferramenta favorita, de forma segura, mas mantendo a simplicidade.

Conceitos Principais da ferramenta

Zero Trust

No ecossistema padrão, assume-se que um pacote é seguro até que se prove o contrário (vulnerabilidade reportada). O SCAL-P entra invertendo essa ordem: nenhum pacote é confiável por padrão. Ele deve passar por uma avaliação de política e pontuação antes de ser aceito.

Guarded Install

Diferente de uma instalação comum, a "Instalação Guardada" do SCAL-P segue um fluxo diferente: o Resolve identifica o que precisa ser instalado, o Evaluate verifica se os pacotes cumprem a política, o Block analisa se algo falhar, então o processo para antes de qualquer download ou script rodar e o Install que é o gerenciador de pacotes (npm, pnpm, bun e yarn berry) entrando em ação apenas após a aprovação.

Trust Scoring

O SCAL-P mede o risco de um pacote. Ele não olha apenas para bugs (CVEs), mas para também: maturidade do pacote, exemplo, há quanto tempo o pacote existe?; verifica a reputação, dá uma olhada em quantos downloads ele tem... verifica a integridade,"o hash do conteúdo é consistente?" e também verifica a manutenção, se o autor é conhecido e ativo.

Integrity Sync

O SCAL-P mantém uma copia da sua pasta node_modules no arquivo .scalp/lockfile.json, ele registra o hash SHA-512 de cada arquivo instalado. Isso permite que o comando scalp audit detecte se um arquivo foi modificado localmente (por exemplo, por um vírus ou por um desenvolvedor tentando burlar a segurança) após a instalação legitima.

PR Context Awareness

O SCAL-P entende de onde vem o código. Ele aplica regras diferentes para builds internos e builds vindos de contribuições externas (Forks). Isso é vital para proteger segredos e chaves de API em ambientes de CI/CD.

Por que usar o Scal-p?

Um dos principais motivos é que o momento mais perigoso acontece ANTES do install terminar, então se você instala um pacote malicioso e ele executa um: postinstall, downloader, binário nativo ou até script ofuscado, o seu pc já foi exposto

O SCAL-P tenta impedir isso antes mesmo do package manager começar a instalação.

Outro ponto importante é que CVE scanning sozinho já não resolve mais o problema de supply chain. Muitos ataques duram poucas horas. Nesse intervalo, milhares de máquinas podem ser comprometidas antes mesmo de existir um advisory público.

Além disso, já vimos diversos casos de contas de maintainers comprometidas, pacotes hijacked, typosquatting, ataques em CI/CD, cache poisoning, etc.

Um exemplo recente foi o Mini Shai-Hulud. O ataque explorou um fork do repositório TanStack para introduzir um payload malicioso disfarçado de dependência opcional (@tanstack/setup). A exploração envolvia CI/CD, pull_request_target e cache poisoning.

Foi exatamente pensando nesse tipo de cenário que eu desenvolvi o scalp-action.

Ele utiliza os mecanismos do SCAL-P para aplicar políticas diferentes dependendo do contexto do Pull Request, endurecendo builds vindos de forks e reduzindo bastante o risco de ataques em pipelines.

Se você usa GitHub Actions, a combinação do scalp-action com upload de SARIF adiciona uma camada a mais de proteção contra ataques de supply chain com praticamente zero configuração.

Conclusão

A confiança na cadeia de dependências ainda funciona em grande parte no modelo do “instala primeiro e torce depois”, então tais problemas é que hoje as dependências não são apenas bibliotecas. Elas executam código, acessam ambientes de CI/CD, interagem com tokens, chaves e infra real. Esse projeto nasceu justamente da ideia de que instalar dependências deveria ser um processo baseado em confiança verificável, não apenas em conveniência. A proposta nunca foi substituir qualquer packager manager, e sim adicionar uma camada de segurança e governança sobre ferramentas que já usamos todos os dias.

Ainda existem muitas ideias que quero explorar no projeto, principalmente em: análise contextual, políticas mais avançadas, expansão para outros ecossistemas, melhorias no Trust Scoring

Mas a ideia principal continua sendo a mesma desde a primeira PoC:

“Não instale apenas o que funciona; instale apenas o que é confiável.”

Se você quer contribuir com o ecossistema do scal-p: https://github.com/scal-p-labs/
Se você quer contribuir apenas com o repositorio principal, o codigo é escrito em golang e não tem dependencias externas: https://github.com/scal-p-labs/scal-p
Ah e também tem o site da documentação que vc pode acessar: https://scalp-docs.vercel.app

Tenha um bom dia