Descobri vulnerabilidade crítica em sistema em produção

Dimensionar a exposição real

Nem toda vulnerabilidade crítica representa risco crítico para a sua empresa. Antes de mobilizar resposta emergencial, dimensione a exposição real em quatro perguntas: o sistema afetado está em uso (versão exata, configuração específica)? Qual a superfície (interno, parceiro, internet pública)? Existe exploit conhecido em uso ativo? Há indício de comprometimento já em curso? Vulnerabilidade pública alta em sistema interno isolado é diferente de vulnerabilidade em aplicação exposta à internet com exploit circulando.

Patch emergencial ou workaround?

A decisão precisa equilibrar urgência da vulnerabilidade com risco operacional de mudança não planejada em produção. Patch resolve a causa mas exige tempo de teste e janela de aplicação. Workaround (regra de firewall, desabilitação de componente, restrição de acesso, regra de WAF) reduz exposição imediatamente sem mexer no sistema.

Quando vale workaround primeiro

Quando a janela de teste do patch é incompatível com a urgência, quando há exploit ativo na rua, quando o sistema é altamente crítico e mudança sem teste pode causar parada. Workaround compra tempo para aplicar patch em janela controlada nos próximos dias.

Quando vale patch emergencial direto

Quando o patch é simples e bem testado pelo fornecedor (muitas vezes patches de CVE crítico já vieram revisados extensivamente), quando não há workaround viável, quando o risco de exploração imediata é maior que o risco de quebra por mudança sem teste estendido.

Investigar se já houve exploração

Antes da descoberta da vulnerabilidade, atacante competente pode já ter explorado. Threat hunting em paralelo à remediação procura indicadores: logs do sistema afetado na janela em que a vulnerabilidade existia (que vai muito antes da divulgação pública), tráfego anômalo, comportamento estranho, contas com atividade suspeita. Para zero-day em sistema crítico, essa investigação não é opcional — encontrar evidência de comprometimento muda inteiramente a resposta.

Depois da estabilização: por que chegou em produção?

Vulnerabilidade crítica em produção descoberta tardiamente revela problema no processo. As perguntas do RCA: por que essa versão não foi atualizada antes (faltou processo de patching, faltou priorização, faltou janela)? Por que a vulnerabilidade não foi detectada pelo monitoramento interno (faltou scanner, faltou threat intel, falhou alerta)? Por que o tempo de detecção foi o que foi (descoberta veio do fornecedor, da notícia pública, do scanner, do incidente real)? Cada uma dessas perguntas aponta para uma melhoria de processo. Sem RCA, o próximo CVE crítico encontra a mesma vulnerabilidade no processo.