Por que a assimetria de informação desapareceu

Um pesquisador acha um bug crítico, abre um canal privado com o vendor, negocia 90 dias de embargo e aguarda o patch. Esse ritual atravessou décadas e parecia inabalável. Filippo Valsorda, ex-líder de criptografia do Go na Google e hoje na Cloudflare, publicou um texto que coloca isso em xeque de forma direta: relatórios de vulnerabilidade não são mais especiais.

O pacto que sustentou o responsible disclosure

Para entender por que essa afirmação importa, vale voltar à lógica original do modelo. O responsible disclosure surgiu de uma necessidade real: dar tempo para que correções chegassem aos usuários antes que exploits fossem publicados. O período de embargo, geralmente 90 dias, criava uma assimetria de informação favorável. O pesquisador sabia do bug, o vendor sabia do bug, e o atacante não sabia de nada. Essa janela era suficiente para que o patch fosse desenvolvido, testado, distribuído e aplicado.

O modelo dependia de uma premissa simples: a informação sobre a vulnerabilidade ficava confinada a um círculo pequeno e controlado de pessoas. Enquanto essa premissa se sustentou, o processo funcionou. A cerimônia tinha sentido porque produzia um resultado concreto: proteção real durante o tempo de resposta do vendor.

Por que a assimetria de informação desapareceu

O problema é que essa premissa não se sustenta mais. Atacantes sofisticados desenvolveram técnicas que tornam o período de embargo muito menos eficaz do que parece no papel.

Diff analysis de patches

Quando um vendor lança uma nova versão de um pacote ou biblioteca, qualquer pessoa pode comparar o código anterior com o novo. Essa análise de diferenças revela exatamente onde algo foi corrigido, e a partir daí, um atacante experiente consegue reconstituir o comportamento que foi eliminado. O Google Project Zero documentou casos em que exploits funcionais foram desenvolvidos em menos de 72 horas após o lançamento de um patch silencioso. Um silent patch é quando o vendor corrige sem publicar um CVE, na crença de que a mudança passará despercebida. Não passa.

Monitoramento de repositórios públicos

Commits em repositórios públicos como o GitHub são rastreados em tempo real por ferramentas automatizadas. Uma mensagem de commit que menciona "fix memory corruption" ou "prevent null dereference" em um projeto amplamente utilizado funciona como um sinal. Mesmo sem embargo formalmente quebrado, o commit já entregou informação suficiente para que alguém motivado comece a trabalhar num exploit.

Engenharia reversa automatizada

Ferramentas modernas de análise binária reduziram o tempo necessário para entender o que uma atualização fez. O que antes levava dias agora pode levar horas, dependendo da complexidade do software e da motivação do atacante. Grupos com recursos adequados conseguem transformar um patch público em um exploit funcional antes que a maioria dos sistemas ao redor do mundo tenha sequer baixado a atualização.

O que ainda funciona e o que virou teatro

A crítica de Valsorda não é que o processo de divulgação responsável seja inútil em absoluto. É que uma parte significativa do que o setor faz em torno dele virou ritual sem função protetora real.

O formulário de reporte ainda existe. O prazo de 90 dias ainda existe. O CVE ainda é publicado com solenidade. Mas a janela de proteção que esses mecanismos foram desenhados para criar já não tem o tamanho que tinha. Para ameaças sofisticadas, o embargo não protege mais os usuários de forma automática. Protege, no melhor caso, contra atacantes que não monitoram repositórios, não fazem diff analysis e não têm capacidade de engenharia reversa. Ou seja, exatamente os atacantes menos perigosos.

Isso tem uma consequência prática importante: se você é responsável por segurança num time de engenharia e trata o CVE publicado no NVD como o gatilho para agir, você já está atrasado. O feed do NVD chega depois do patch, que chega depois do commit, que chegou depois do diff analysis que algum atacante já fez.

O que times de AppSec e DevSecOps precisam mudar

A implicação prática do argumento de Valsorda não é filosófica. É operacional. O processo de resposta a vulnerabilidades precisa ser redesenhado para não depender de notificação formal como ponto de partida.

• Monitoramento contínuo de dependências: ferramentas como OSV Scanner, Socket.dev e Dependabot já trabalham parcialmente nessa lógica, rastreando vulnerabilidades antes ou independentemente da publicação formal de CVEs. A adoção dessas ferramentas ainda é minoritária, especialmente no mercado brasileiro.
• Análise de diffs de pacotes: sempre que uma dependência crítica é atualizada, vale examinar o que mudou, não apenas confiar que a nova versão é segura porque tem um número de versão maior.
• Processo de resposta desacoplado de alertas formais: um time que só reage quando recebe uma notificação formal está exposto durante o intervalo entre o patch e o alerta, que pode ser o intervalo mais perigoso.
• Inventário de dependências atualizado: você só pode monitorar o que sabe que usa. SBOMs (Software Bill of Materials) deixaram de ser burocracia e viraram ferramenta de resposta rápida.
• Tempo de resposta como métrica de segurança: quanto tempo leva, da identificação de uma vulnerabilidade crítica até o deploy do patch, no seu ambiente? Se a resposta for "não sei" ou "semanas", o processo de embargo externo é o menor dos problemas.

A questão que o setor ainda não resolveu

Se o modelo atual está rachado por dentro, o que vem no lugar? Algumas direções aparecem na discussão:

Embargo mais curto

Reduzir o prazo de 90 para 30 ou 45 dias força vendors a agir mais rápido, mas também aumenta a pressão sobre times de segurança que já estão sobrecarregados. E não resolve o problema do diff analysis, que acontece no momento do patch independentemente do prazo de embargo.

Divulgação imediata com patch simultâneo

A ideia é simples: você só divulga quando o patch já está disponível e pronto para deploy. O problema é que isso pressupõe uma capacidade de desenvolvimento e distribuição que poucos vendors têm, especialmente em software de infraestrutura complexa.

Coordenação de ecossistema

Para vulnerabilidades em bibliotecas amplamente usadas, alguns projetos já experimentam com divulgação coordenada para múltiplos downstream maintainers simultaneamente, antes da publicação pública. Isso reduz a janela de exposição sem eliminar o período de correção. A iniciativa do OpenSSF e algumas práticas do ecossistema Rust apontam nessa direção.

Nenhuma dessas alternativas é perfeita. Todas envolvem trocas entre velocidade de resposta, capacidade operacional dos vendors e risco residual para usuários. O que parece cada vez menos defensável é continuar operando como se o modelo de 90 dias de embargo ainda criasse a proteção que criava há quinze anos.

O argumento de Valsorda não pede que a indústria jogue fora o responsible disclosure. Pede que pare de confundir o ritual com o resultado. O ritual continua; a proteção que ele deveria produzir precisa ser buscada em outro lugar, com monitoramento contínuo, tempo de resposta rápido e menos dependência de que o atacante vai respeitar o mesmo calendário que o vendor e o pesquisador combinaram entre si.