Para: qualquer pessoa rodando várias aplicações web (frameworks variados) com uma equipe pequena, que quer corrigir vulnerabilidades de dependências (CVEs) de verdade, de uma vez. Sem passos de ataque — apenas a prática de corrigir, fazer as correções grudarem e seguir vigiando. Para o tipo de incidente que costuma dar início a isso, veja um RCE público negligenciado cobrado por fraude.
A visão deste site: equipes pequenas se mantêm seguras com duas disciplinas
O que funciona numa equipe pequena não é ferramenta chamativa — são duas disciplinas: 1) detecção de mudança automatizada (alertar só sobre vulnerabilidades novas) e 2) local→push→deploy (produção recebe, nunca edita). Este site funciona do mesmo jeito: uma auditoria de dependências (pnpm audit) antes de cada deploy mais um cron diário, com push-to-deploy entregando para a produção. Configurar alertas que continuam rodando, em vez de tratar segurança como uma correção pontual, é a abordagem mais barata que dura.
Defina primeiro as quatro condições de "pronto"
Isso evita chamar as coisas de "prontas" cedo demais. Decida de antemão: até os quatro se alinharem, está incompleto.
1. Varrer
colocar o estado em números
2. Corrigir
corrigir na origem o crít/alto não-dev
3. Isolar/repassar
tornar explícito o incorrigível
4. Monitorar
colocar detecção de mudança diária
1. Varrer: conte o que você tem agora
Primeiro, veja o que está onde, por máquina. Verificações manuais e ad hoc sempre falham.
Descubra lockfiles automaticamente e varra
composer.lock / package-lock.json / pnpm-lock.yaml e rode-os diariamente por um scanner open-source (osv-scanner ou pnpm audit). Ele só lê lockfiles, então a carga é mínima.Saiba que severidade não é um número só
Exclua ruído COM um motivo registrado, não ignorando
2. Corrigir: atualize a própria versão vulnerável
Uma medida temporária que esconde o sintoma e uma correção da causa real são trabalhos diferentes. Faça os dois para terminar.
Só esconder o sintoma (a causa permanece)
- bloquear só requisições "de aparência suspeita" num proxy reverso
- o sintoma parou, então chama de "resolvido"
- a dependência vulnerável permanece — o RCE continua explorável
Corrigir a causa (correto)
- atualizar a dependência vulnerável para a versão corrigida
- após atualizar, confirme que a assinatura sumiu nos seus logs
- tratar a medida temporária e a correção real como dois trabalhos separados, fazer ambos
Verifique o build de saltos maiores ANTES da produção
Ao contrário de um patch, um salto de versão maior (framework 14→15, um kit de UI 4→6, etc.) traz mudanças que quebram. Atualizar sem verificar e quebrar o build de produção derruba o serviço. Coloque o código editado num runtime idêntico ao de prod (mesmo container de versão Node/PHP) e deixe o build/type-check totalmente verde antes de fazer o push. Limpe os erros um a um (codemods sync→async, strings de classe CSS em várias linhas, um namespace de tipo global aposentado, etc.). Se o container antigo segue rodando, uma falha reverte com zero de downtime.
Verifique se o próximo deploy não vai desfazer a correção
Uma correção perfeita vale zero se o próximo deploy a apaga. Este é o erro mais comum.
Não faça commit na árvore de trabalho de produção
Padronize uma única direção: local→push→deploy
Não confie no HTTP 200 como 'saudável'
curl | grep), há erros novos nos logs, e percorra as rotas dinâmicas (baseadas em DB, parametrizadas), não só a página inicial. Caches podem atrasar a mudança, então espere ou limpe primeiro.3. Isolar/repassar: registre o que você não consegue corrigir
Você nem sempre consegue corrigir tudo agora. O truque é nunca deixar "não dá para corrigir / não é minha área / sem uso" ambíguo.
Código órfão/EOL: isole ANTES de deletar
Confirme primeiro que está de fato sem referências
Repasse explicitamente o que você não pode corrigir
4. Monitorar: configure a detecção de mudança diária
Agora, finalmente, coloque o mecanismo de alerta. Sem ele, uma correção que você fez não vai te avisar quando ela recorrer.
Alerte sobre o que é NOVO, não tudo todo dia
Compare os resultados da varredura com a execução anterior (um arquivo de estado) e notifique só quando aparece um novo crítico/alto. O mesmo conteúdo todo dia é ignorado (fadiga de alertas). Resuma num único e-mail (novo / resolvido / atual) num cron diário. Até hospedagem compartilhada lida bem com um binário de scanner + cron (a carga é de milissegundos; acrescente nice para tranquilidade).
Chaves de API e chaves SSH que um inventário também encontra
Corrigir CVEs de verdade tende a revelar problemas que não são de dependência também. Dois comuns: um arquivo de segredo deixado num diretório público (um token antigo na raiz web; se veio de um template compartilhado, todo site tem o mesmo problema) e uma chave root entregue a um ambiente que pode ser comprometido. Ambos criam o padrão "um vazamento, tudo", então verifique-os na mesma passada (cada um merece seu próprio aprofundamento). Para o básico de segredos, veja armazenando segredos com segurança e o checklist de baseline.
Leia a seguir
- CVE-2026-111793 Openwave: uma entrada no KEV apesar de uma pontuação baixa
- Exemplo (dia mensal de patches): SAP Security Patch Day de novembro de 2026 (quatro falhas com CVSS 10,0)
- Um caso real: CVE-2026-123551: divulgação de tokens de sessão no OpenAM (uma atualização mais a revogação de sessões)
- Exemplo: Aviso de segurança do Jenkins (28 de outubro de 2026, 15 falhas)
- Decidir: Qual CVE corrigir primeiro: CVSS, EPSS e KEV
- Monitoramento de dependências: instalando e usando o osv-scanner · não ficar para trás nos CVEs
- Incidente: um RCE público negligenciado cobrado por fraude
- Operações: produção só recebe / Git auto-hospedado vs GitHub
- Baseline: o checklist de baseline de segurança
- Incidente: o ransomware na Capcom (2020) (um dispositivo VPN antigo negligenciado foi a porta de entrada)
- Ferramenta: consulta de CVE / KEV (CVSS, EPSS e exploração ativa em uma só tela)
- Defesa por padrão: vulnerabilidades de upload de arquivos — como evitar web shells / RCE pelo design