Guias de Segurança
Corrigindo CVEs de dependências de verdade: varrer, corrigir, isolar e seguir vigiando
Playbook de remediação de CVE: como de fato corrigir vulnerabilidades de dependências numa frota pequena, com uma definição de pronto em 4 partes — varrer, corrigir, isolar/repassar e monitorar — e lições de campo para que as correções não sumam.
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. Tratar segurança como "um sistema que segue disparando", não "uma correção pontual", é a coisa mais barata que dura.
Acerte primeiro a "definição de pronto" em 4 partes
Uma proteção contra 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 raiz 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: transforme o estado em números
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: corrigir na raiz, não esconder o sintoma
Primeiros socorros (esconder o sintoma) e uma correção de raiz são trabalhos diferentes. Faça os dois para terminar.
Só esconder o sintoma (contenção)
- 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 segue vivo
Correção de raiz (correta)
- atualizar a dependência vulnerável para a versão corrigida
- após atualizar, confirme que a assinatura sumiu nos seus logs
- tratar primeiros socorros e a correção de raiz 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 às cegas e quebrar o build de prod é o pior caso. 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.
A conclusão inclui a durabilidade da correção
Uma correção perfeita vale zero se o próximo deploy a apaga. Esta é a armadilha 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: torne o incorrigível explícito
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: só com detecção de mudança diária está pronto
Agora, finalmente, coloque o mecanismo de disparo. 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).
Os "segredos" e "chaves" que um inventário também revela
Corrigir CVEs de verdade tende a revelar buracos que não são de dependência também. Dois clássicos — 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 buraco) e uma chave-mestra 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
- 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
- Base: o checklist de baseline de segurança
FAQ
QQuando o trabalho de vulnerabilidade está de fato 'pronto'?
Só quando quatro coisas se alinham: 1) você varreu e colocou o estado em números, 2) você corrigiu os críticos/altos que não são de dev, 3) você isolou ou repassou explicitamente o que não pode corrigir / código órfão, e 4) você colocou no lugar a detecção de mudança diária (monitoramento que pega problemas novos e recorrentes). Até o 4 estar no lugar, não está pronto — dependências voltam a ser vulneráveis amanhã.
QVarredura diária não causa fadiga de alertas?
Alertar sobre tudo diariamente é ignorado rápido. Compare com o resultado anterior (um arquivo de estado) e notifique só quando aparece um NOVO crítico/alto — detecção de mudança. Não enviar a mesma coisa todo dia é o que faz o monitoramento de fato durar.
QPor que uma correção às vezes reverte para vulnerável?
Fazer commit direto na árvore de trabalho de produção significa que o próximo deploy (um pull ou checkout -f) sobrescreve e apaga a correção. Padronize uma única direção — local→push→deploy — e faça a produção 'só receber'. Uma correção perfeita num fluxo que a apaga vale zero.