O registro não é mais uma zona de confiança
Se você constrói um SaaS com IA hoje, sua base de código tem centenas ou milhares de dependências transitivas que você nunca leu. Cada npm install puxa código de estranhos e o executa com as mesmas permissões do seu build. Em 2026, isso deixou de ser um risco teórico.
O relatório 2026 State of the Software Supply Chain, da Sonatype, contou mais de 454.600 novos pacotes open-source maliciosos publicados só em 2025. O total acumulado de pacotes maliciosos bloqueados passou de 1,233 milhão, um salto de 75% ano contra ano. Não é ruído de fundo. É uma linha de produção industrial de malware apontada direto pra dentro do seu pipeline.
A leitura prática é dura e simples: "confiar no registro" nunca foi uma estratégia de segurança. Era uma aposta que funcionava enquanto o volume de ataque era baixo. Esse tempo acabou.
O que 2026 mostrou na prática
Os números só assustam quando você vê a mecânica dos ataques. Três padrões dominaram o ano:
axios como veículo de RAT
Pacotes se passando por axios (ou versões trojanizadas que imitam o comportamento legítimo) foram usados para entregar um Remote Access Trojan. O desenvolvedor instala o que acha ser um cliente HTTP comum, e ganha de brinde um canal de controle remoto na máquina de dev ou no runner de CI.
Typosquat roubando segredos de CI/CD
Pacotes com nomes quase idênticos aos legítimos, um caractere trocado, um hífen a mais, foram publicados para roubar credenciais de nuvem e tokens de CI/CD. A Microsoft documentou campanhas de typosquat em npm mirando exatamente os segredos que ficam expostos como variáveis de ambiente dentro do pipeline. Basta o pacote rodar um postinstall e ler process.env.
Dependency confusion perfilando ambientes de dev
Atacantes publicaram pacotes públicos com o mesmo nome de pacotes internos privados. O resolvedor puxa a versão pública maior, ela executa, e passa a perfilar o ambiente do dev: variáveis, rede interna, estrutura do projeto. É reconhecimento antes do golpe real.
Os três têm o mesmo denominador comum: código não confiável executando com as permissões do seu build.
8 ações concretas, em ordem de impacto
Não adianta catálogo genérico. Isto é o que um time pequeno de SaaS com IA deve fazer, priorizado por retorno sobre esforço.
1. Trave o lockfile e use `npm ci` (hoje)
Comece pelo mais barato. Use npm ci em vez de npm install em CI e em qualquer ambiente reprodutível. O npm ci instala exatamente o que está no package-lock.json, com verificação de integrity (o hash sha512 de cada tarball). Se o tarball no registro não bate com o hash do lockfile, o install falha. Isso mata ataque de reescrita silenciosa de versão publicada. Sem lockfile commitado e sem integrity, todo o resto perde o chão.
2. Scanner de dependência no CI, bloqueante (esta semana)
Coloque um scanner que roda em todo PR e falha o build em vulnerabilidade conhecida ou pacote sinalizado como malicioso. O OSV-Scanner (do banco de dados OSV, aberto) é um ponto de partida direto e gratuito. O ponto crítico: o scan tem que ser bloqueante, não um relatório que ninguém lê. Alerta que não barra o merge é só ruído.
3. Cooldown e allowlist de versões (este mês)
A maioria dos pacotes maliciosos é pega e removida em horas ou dias. Uma janela de cooldown, não adotar nenhuma versão publicada nos últimos 7 a 14 dias, elimina uma fatia enorme do risco sem custo de segurança real. Combine com uma allowlist para dependências sensíveis: só entra versão explicitamente aprovada. npm com política de idade mínima já ajuda aqui.
4. Revisão obrigatória de dependência nova (contínuo)
Adicionar uma dependência é uma decisão de arquitetura, não um npm install no meio de um commit. Toda dependência nova (e todo bump de major) passa por review humano: quem mantém, quantos downloads, tem postinstall, qual a superfície. Um dev sênior olhando 30 segundos pega o que o scanner automático não pega.
5. Segredos fora do ambiente do build (este mês)
Os ataques de typosquat e dependency confusion de 2026 miraram exatamente process.env no CI. Se o segredo não está lá, o postinstall malicioso não rouba nada. Tire credenciais de longa duração das variáveis de ambiente do pipeline. Use um cofre (secrets manager) com credenciais de curta duração, injeção OIDC para nuvem, e escopo mínimo por job. Segredo que não existe no runner não vaza.
6. Desligue scripts de ciclo de vida por padrão (este mês)
Boa parte do payload roda no postinstall. Rode a instalação com --ignore-scripts por padrão e habilite scripts só para os poucos pacotes que genuinamente precisam (via allowlist explícita). Isso corta a via de execução mais comum do malware de supply chain.
7. Gere e guarde um SBOM (este trimestre)
Um SBOM (Software Bill of Materials, em CycloneDX ou SPDX) é o inventário do que de fato entrou no seu artefato. Sem ele, quando sair o próximo CVE crítico numa dependência transitiva, você não sabe se está exposto nem onde. Gere o SBOM no build, versione junto com o artefato, e use pra responder "eu uso esse pacote?" em minutos, não em um dia de caça.
8. Provenance e assinatura no seu release (este trimestre)
Se você publica pacotes ou imagens, assine. Provenance (npm provenance via Sigstore, ou artefatos assinados) prova que o artefato saiu do seu pipeline e não foi trocado no caminho. É o outro lado da moeda: você não quer ser o próximo axios trojanizado que envenena os seus clientes.
Onde a RET entra
Ordem 1 a 6 você começa hoje com ferramenta aberta e disciplina de processo. O trabalho contínuo, escanear cada mudança, cruzar com bases de vulnerabilidade e sinal de pacote malicioso, distinguir achado real de falso positivo, é o que cansa e o que a maioria dos times acaba deixando cair. O scanner de dependência do AuditMySaaS existe pra tirar esse peso do CI e devolver só o que importa: o que é real, o que é explorável, e o que fazer. A defesa boa é a que continua rodando depois que o entusiasmo passou.
Confiar no registro nunca foi estratégia de segurança, era uma aposta que o volume de 2026 finalmente derrubou.
