Quando chover 0‑days, não se afogue: o playbook de 72 horas de um CTO para dumps massivos de exploits

Você vai acordar certo dia e descobrir uma conta anônima no GitHub despejando 0‑days em massa que afetam seu stack. Scripts de prova de conceito chegam às redes sociais antes mesmo de a NVD atribuir IDs. Seu pager dispara não porque um serviço caiu, mas porque a automação do exploit acabou de ser copiada e colada em mil botnets.

Isso não é um evento que ocorre uma vez por década. É o novo ritmo. Ondas recentes de disclosures e drops massivos de PoCs provam que a vantagem de tempo do atacante se mede em horas, não em semanas. A resposta correta não é pânico; é memória muscular que transforma o caos em um plano de 72 horas.

Se você opera um SaaS moderno, carrega muita superfície de ataque. Um serviço típico em TypeScript/Node puxa milhares de dependências transitivas. Um microsserviço em Go conteinerizado pode ser “estático”, mas ainda assim roda sobre uma imagem base com dezenas de pacotes e um kernel em constante mudança. O delta entre “há um bug em algum lugar” e “sua instância está alcançável e explorável” é onde você ganha ou perde as próximas 72 horas.

O objetivo: atingibilidade, não manchetes

Seu trabalho não é “consertar tudo”. Seu trabalho é responder rapidamente a três perguntas para cada suposto 0‑day:

• Essa vulnerabilidade é alcançável no nosso ambiente?
• Ela está exposta à internet ou protegida por autenticação/controles de rede?
• Temos uma mitigação de curto prazo (configuração, WAF, feature flag, política de rede) que nos compre tempo para aplicar o patch?

Todo o resto — PRs, retros, tweets de fornecedores — vem depois. Este post traz um playbook concreto de 72 horas que você pode entregar aos seus líderes. Parte do pressuposto de que você tem pelo menos os blocos básicos: logs centralizados, CI/CD capaz de embarcar mudanças em horas e um espaço para uma war room multifuncional. Se não tiver, seu projeto do dia um após esta tempestade é construir isso.

Hora 0–2: estabilizar, instrumentar e reunir

1) Monte uma war room com papéis claros

• Incident Lead (você ou um delegado): responsável único, define prioridades e trade‑offs.
• Exploit Analyst: acompanha relatos, PoCs e indicadores de comprometimento (IoCs).
• Exposure Mapper: mapeia componentes vulneráveis para ativos usando seu SBOM e catálogo de serviços.
• Mitigation Engineer: cuida de regras de WAF, feature flags, políticas de rede e configs rápidas.
• Patch Lead: coordena mudanças de código, reconstrução de imagens e rollouts.
• Communications: atualizações internas de hora em hora; externas em marcos definidos.

2) Crie uma única frente de intake e acompanhamento

• Implemente um tracker compartilhado (uma planilha ou um board de issues resolve) com colunas: id/nome da vulnerabilidade, link de origem, componente afetado, atingibilidade, exposição (internet/interno), mitigação, status do patch, responsável, ETA.
• Rotule cada item com uma severidade baseada em exposição × atingibilidade × maturidade do exploit. Se existe uma PoC funcional e seu componente é exposto à internet e alcançável, é P0.

3) Aumente a visibilidade agora

• Ative logs de alto valor se estiverem desligados: logs de requisições do reverse proxy, decisões do gateway de autenticação, picos de 4xx/5xx, alertas do runtime de contêiner.
• Configure ad hoc automações para anomalias: pico de 10× em rotas específicas, User‑Agents atípicos, conexões de saída para hosts suspeitos.
• Assine e puxe sinais de exploits conhecidos de fontes públicas como CISA KEV e feeds de inteligência de ameaças da comunidade.

4) Aplique fricção barata e reversível

• Rate limit endpoints suspeitos agressivamente. Se o baseline é 100 rps, reduza para 20 rps por IP nas próximas 6 horas nas rotas vulneráveis.
• Desabilite temporariamente endpoints públicos não essenciais via configuração. Se puder fazer isso por trás de uma feature flag, melhor. Use páginas de manutenção com parcimônia.
• Shaping por Geo ou ASN para fontes de tráfego claramente maliciosas se o padrão for óbvio.

Hora 2–8: dimensione a exposição com SBOMs e atingibilidade

5) Gere ou recupere SBOMs do que realmente roda

• Para contêineres e serviços, gere SBOMs com Syft ou similar. Armazene-os em um lugar consultável (por exemplo, Dependency‑Track ou um registry interno).
• Para serverless, colete lockfiles de pacotes e manifests de build. Se você não tiver SBOMs, reúna SHAs dos commits dos lockfiles vinculados às versões implantadas.
• Faça o scan contra OSV/NVD e avisos dos fornecedores. Priorize problemas que correspondam aos componentes que você de fato implanta.

6) Faça uma análise rápida de atingibilidade, não um SAST acadêmico

• Pergunte: o caminho de código vulnerável é chamado pela nossa aplicação em produção? Exemplos: uma injeção de template em uma biblioteca usada apenas por uma ferramenta de administração que não é exposta à internet pode ser P2, não P0.
• Se você tem ferramentas de atingibilidade (por exemplo, análise de call‑graph ou recursos de vendors que identificam “vulnerabilidades alcançáveis”), use-as. Se não, conte com os code owners para confirmar pontos de importação/uso.
• Verifique a telemetria de runtime por invocações dos caminhos suspeitos (rotas, RPCs, funções). Fazer grep nos logs por rotas e headers é melhor que adivinhar.

7) Confirme a exposição à internet

• Faça um mapa de exposição rápido: quais serviços são publicamente alcançáveis, quais portas estão abertas e onde a autenticação é aplicada. Ferramentas como Shodan ajudam você a ver o que o mundo vê.
• Documente controles de rede: mTLS, allowlists de IP, API gateways. Exposição sem auth é risco; exposição com auth robusta e alertas de anomalia pode lhe dar tempo para aplicar o patch.

8) Colete cedo o posicionamento dos vendors

• Acompanhe declarações e patches dos maintainers upstream. Se o ETA do fix é 24 horas, desenhe mitigação que segure a linha por esse período.
• Para serviços gerenciados, abra tickets e peça posicionamentos por escrito sobre exposição e mitigação.

Hora 8–24: mitigue primeiro, faça patch rápido onde importa

9) Entregue mitigações reversíveis em minutos

• Regras de WAF: bloqueie assinaturas de payload suspeitas e adicione limites rigorosos de content‑type e tamanho nos endpoints afetados. Provedores como Cloudflare ou Fastly conseguem aplicar regras em minutos; valide com tráfego canário.
• Feature flags: kill switches para funcionalidades suscetíveis. Se você não tem uma flag, crie um guardrail baseado em configuração no ponto de entrada. Toggles no estilo OpenFeature permitem rollback instantâneo.
• Política de rede: para problemas server‑to‑server, aperte o egress. Restrições de saída interrompem call‑backs pós‑exploração.

10) Faça patch por camada de exposição

• Tier A: exposto à internet + alcançável + existe PoC. Target TTR < 24 horas. Patch ou hot‑patch. Se não houver patch disponível, mitigue e planeje um controle compensatório aceitável por uma semana.
• Tier B: interno ou protegido + alcançável. TTR < 72 horas. Inclua na próxima janela de release; não sufoque o trabalho de Tier A.
• Tier C: inalcançável em produção. Documente, monitore e agende. Use a tempestade para remover dependências mortas em vez de apenas atualizá-las.

11) Reconstrua o mundo que você realmente executa

• Contêineres: reconstrua imagens base para incorporar correções da distro. Faça pin por digests, não por tags. Publique em um registry endurecido. Rode scans com Trivy/Grype como gates, não relatórios.
• Runtimes: se o exploit atinge o runtime (por exemplo, JIT ou interpretador), avalie com cuidado um salto de versão major. Um backport direcionado pode ser mais seguro nas primeiras 24 horas.
• Secrets: assuma o pior cenário em qualquer exploração confirmada. Rotacione credenciais e tokens tocados pelos serviços afetados.

12) Comunique-se como adulto

• Atualizações internas de hora em hora na war room: o que mudou, o que vem a seguir, bloqueadores.
• Atualizações externas em pontos previsíveis (por exemplo, às 8, 24 e 48 horas). Compartilhe as mitigações aplicadas e o próximo ETA. Não especule.
• Notificações regulatórias e contratuais se os limiares forem atingidos. Consulte o jurídico cedo.

Hora 24–48: valide, contenha e feche para sempre as lacunas mais fáceis

13) Prove que a mitigação funciona

• Use payloads seguros para validar regras de WAF. Confirme 403s onde esperado e que o tráfego legítimo flui.
• Faça rollout canário de patches para 5–10% e monitore os error budgets. Se estiver estável, prossiga para rollout completo.
• Para caminhos críticos de admin ou auth, adicione prompts temporários de MFA ou reautenticação para reduzir o risco de abuso de sessão.

14) Faça threat hunting por comprometimento

• Procure nos logs e na telemetria por IoCs publicados com as PoCs. Volte pelo menos 30 dias se você suspeitar de exploração pré‑divulgação.
• Inspecione processos incomuns, novos cron jobs ou reverse shells com ferramentas de runtime (por exemplo, alertas baseados em Falco/eBPF) quando aplicável.
• Se encontrar sinais críveis de exploração, escale para resposta a incidentes completa: isole hosts, preserve imagens forenses e amplie a comunicação.

15) Feche lacunas estruturais fáceis

• Adicione ou endureça kill switches para endpoints de alto risco, para que a próxima tempestade não exija editar código para desabilitar uma funcionalidade.
• Reduza o blast radius: políticas de rede mais rígidas, limites de namespaces e credenciais por serviço.
• Automatize a geração de SBOM a cada build e armazene artefatos centralmente. Vincule versões implantadas a snapshots de SBOM.

Hora 48–72: normalize e transforme pânico em processo

16) Documente os fatos, não o mito

• Para cada vulnerabilidade tratada: severidade final, determinação de atingibilidade, mitigações, versões de patch e timestamps de TTI (time‑to‑intake) e TTR (time‑to‑remediate).
• Registre achados negativos: “não alcançável em produção” é um resultado válido e auditável.

17) Atualize runbooks e SLOs

• Defina SLOs de tempestade: P0 exposto à internet e alcançável com PoC → mitigar em 4 horas, patch em até 24. P1 interno e alcançável → patch em até 72.
• Anexe uma árvore de decisão ao seu runbook: se existe PoC e a atingibilidade foi confirmada → opções de mitigação A/B/C; se o ETA do patch upstream > 48h → hot‑patch ou kill switch da funcionalidade.

18) Cubra lacunas de pessoal com um pod follow‑the‑sun

• Tempestades não respeitam fusos. Um pequeno pod nearshore (2–4 engenheiros) treinado no seu stack, com 6–8 horas de overlap com os EUA, consegue manter as frentes de mitigação e patch andando enquanto seu time central dorme.
• Faça disso uma função permanente, não uma escala ad hoc. O custo é pequeno comparado às horas que você queima em cada tempestade.

Investimentos pré‑tempestade que se pagam em minutos

Tudo acima funciona sem perfeição. Mas se você quer transformar 72 horas em 24, invista agora:

Construa SBOMs e um mapa de dependências que responda “onde isso roda?”

• Emita SBOMs (CycloneDX ou SPDX) durante o build de cada serviço e contêiner. Armazene em um sistema pesquisável (Dependency‑Track, saída do OSV‑Scanner + um banco).
• Relacione SBOMs ao seu catálogo de serviços para poder dizer: “A biblioteca X existe nos serviços A e B; apenas A é exposto à internet.”

Defina kill switches no ingress

• Coloque pontos de entrada de funcionalidades de alto risco atrás de flags que você possa virar globalmente. Mesmo um guard apoiado em YAML funciona se for possível recarregar sem redeploy.
• Adote interfaces no estilo OpenFeature para que as flags sejam consistentes entre linguagens.

Endureça o CI/CD para rebuilds rápidos e seguros

• Fixe os digests das imagens base e mantenha um pipeline de golden image capaz de cortar uma release com patches de segurança em até 60 minutos.
• Mantenha guardrails de rollout: deploys em estágios, rollback rápido e canários.

Estabeleça uma política de WAF em que você confia

• Pré‑configure um “perfil de tempestade” que aperta limites de tamanho de requisição, bloqueia content‑types perigosos e aplica verificações estritas de headers. Torne-o alternável.
• Registre as decisões do WAF centralmente para provar que a mitigação atingiu tráfego real.

Meça o que realmente importa

• TTI (time‑to‑intake): do disclosure público até um ticket no tracker. Meta de < 1 hora durante a tempestade.
• Tempo de determinação de atingibilidade: do intake até a decisão “alcançável/não”. Meta de < 4 horas para qualquer coisa exposta à internet.
• TTR (time‑to‑remediate): até a mitigação aplicada e até o patch implantado. Diferencie TTR de mitigação e TTR de patch.

Trade‑offs que você terá de assumir

Mitigar vs. aplicar patch

As mitigações (WAF, flags, política de rede) são rápidas, porém imperfeitas. Patches são duráveis, mas arriscam regressões. Nas primeiras 24 horas, empilhe mitigações e entregue o patch mínimo seguro no Tier A. Não persiga a perfeição enquanto uma PoC funcional circula.

Rigor no runtime vs. experiência do usuário

Apertar rate limits e bloquear padrões de payload vai irritar usuários reais. É um preço que vale pagar por um dia. Comunique isso. Faça rollback assim que os patches estabilizarem.

Centralização vs. autonomia das equipes

Tempestades recompensam centralização: um tracker, um dono, uma cadência de comunicação. No resto do ano, deixe as equipes cuidarem de suas dependências. Escreva essa distinção no seu modelo operacional para não debater processo no meio do incidente.

Uma nota sobre Postgres, backups e falsa confiança

0‑days em massa frequentemente cruzam com sua camada de dados — mesmo que o bug esteja em outro lugar. Se você implantar hotfixes sob pressão, valide que seu caminho de recuperação funciona hoje. Ferramentas como auxiliares de WAL shipping (por exemplo, WAL‑G e reescritas mais novas em Rust) são ótimas, mas elas não são uma rede de segurança a menos que você tenha feito um restore recente e bem-sucedido. Na janela de 48–72 horas, agende um restore de teste para um ambiente em quarentena e verifique RPO/RTO. Um backup funcional que você não consegue restaurar em menos de duas horas não é backup; é uma história que você conta para si mesmo.

Onde um pod nearshore muda a matemática

Não é à toa que empresas grandes operam segurança em follow‑the‑sun. Você não precisa de um SOC 24×7 para obter 80% do benefício. Um pod nearshore pequeno e treinado pode assumir a janela de 2–8 horas enquanto seu time nos EUA dorme:

• 6–8 horas de overlap para handoffs e, depois, triagem independente enquanto seu time central está offline.
• Runbooks e acesso às ferramentas para aplicar regras de WAF, virar flags e entregar patches de baixo risco atrás de canários.
• Perfil de custos 20–30% menor do que adicionar o mesmo headcount localmente, o que importa quando você dimensiona para eventos raros porém críticos.

Você não terceiriza decisões de risco; você terceiriza capacidade de resposta. A decisão “desabilite a funcionalidade de import por 12 horas” continua sendo sua. O trabalho de ligar esse kill switch e reconstruir a imagem não precisa ser.

Como é o “bom” na hora 72

• Seu tracker mostra cada suposto 0‑day, a decisão de exposição, a mitigação e o caminho de patch. Sem órfãos, sem mistérios.
• Itens de Tier A estão mitigados e com patch aplicado, com validação pós‑deploy. Itens de Tier B têm ETAs comprometidos. Tier C está documentado e despriorizado ou agendado para limpeza.
• Regras de WAF e de rede estão apertadas onde importa e mensuradas por impacto. Impactos temporários de UX foram comunicados e têm prazo definido.
• Ninguém está adivinhando no Slack. Você tem um resumo escrito e datado que liderança e clientes podem ler.

Principais lições

• Não corrija “vulnerabilidades” no abstrato. Decida primeiro a atingibilidade e a exposição, depois aja.
• Nas horas 0–8, centralize o intake, aumente a visibilidade e aplique fricção reversível. Compre tempo.
• Nas horas 8–24, mitigue rápido no Tier A e faça patch para durabilidade. Faça canários e monitore os error budgets.
• Nas horas 24–48, valide mitigações, faça hunting por comprometimento e rotacione secrets quando o risco justificar.
• Nas horas 48–72, documente fatos, defina SLOs e transforme heroísmos ad hoc em um runbook repetível.
• Investimentos pré‑tempestade — SBOMs vinculados a um catálogo de serviços, kill switches, perfis de WAF, pipelines de rebuild rápidos — reduzem o tempo de resposta de dias para horas.
• Um pequeno pod nearshore dá a você responsividade 24/5 sem queimar seu time central.