A premissa que nenhum material de produto enuncia

Leia material de fornecedor suficiente e uma promessa implícita aparece: compre isto e o problema está resolvido. Nunca é dita abertamente, porque ninguém que constrói software acredita nela. O que o registro de engenharia mostra, de forma consistente e em todo fornecedor grande o bastante para ter um, é que defeitos são lançados, que alguns deles são relevantes para segurança, e que uma fração é achada por alguém que não pretende reportar.

Isso não é cinismo nem acusação. É o estado observável de uma indústria que escreve dezenas de milhões de linhas de código contra adversários que precisam acertar uma vez. A pergunta útil, portanto, não é qual fornecedor não tem vulnerabilidades - nenhum tem - mas o que acontece nas horas e nos dias depois de uma ser achada. Esse intervalo é mensurável, varia enormemente entre organizações, e é onde quase todo o estrago deste catálogo foi de fato decidido.

As evidências, em resumo

Uma amostra, toda de avisos publicados e investigações públicas.

A F5 lançou uma pilha TLS (Transport Layer Security) vulnerável a uma técnica de ataque de dezenove anos, catalogada como -2017-6168 e documentada no artigo K21905460 da própria empresa, ao lado de outros oito grandes fornecedores na mesma pesquisa - o artigo dos ataques nomeados ao TLS tem o detalhe. A da Fortinet (uma rede privada virtual alcançada por navegador ou agente sobre TLS) carregou uma cadeia de falhas exploradas do CVE-2018-13379 ao CVE-2024-21762. A Palo Alto Networks lançou uma falha de execução remota de código como root sem autenticação no GlobalProtect, CVE-2024-3400, explorada como dia zero. A linha ASA da Cisco foi comprometida por falhas encadeadas por um ator estatal. Check Point, Citrix, Ivanti e SonicWall lançaram, cada uma, uma falha de acesso remoto explorada antes ou em torno da divulgação. A Microsoft perdeu uma chave de assinatura que ainda não consegue explicar por inteiro, e o conselho de revisão chamou o resultado de uma cascata de erros evitáveis. A maior interrupção de armazenamento da Amazon começou com um erro de digitação num comando de runbook, e uma configuração equivocada de um cliente expôs cem milhões de registros. O Google foi invadido por um ator estatal na Operação Aurora. A Juniper achou código não autorizado no ScreenOS que estava lá havia três anos.

Os fornecedores nomeados aqui são os que têm avisos publicados, cronologias públicas e pesquisadores dispostos a escrever sobre elas, o que é sinal de maturidade e não de fraqueza. A lista não é um ranking e não está completa; um parágrafo comparável poderia ser escrito sobre Extreme Networks, HPE, Aruba e todo outro fabricante cujo equipamento valha a pena atacar. Todo fornecedor relevante já lançou uma falha que facilitou uma invasão, e, pela evidência de trinta anos, todos vão lançar de novo.

Se isso é verdade - e é - então a pergunta sobre em qual fornecedor confiar precisa ser respondida de outro jeito.

O relógio

O que difere entre organizações, e entre fornecedores, é uma sequência de intervalos. Cada um é mensurável. Cada um tem evidência neste catálogo.

Detecção: quanto tempo até alguém saber

Este é o intervalo que decide o tamanho de todos os seguintes, e o registro não anima. A Moonlight Maze correu dois anos e foi achada por acaso. A DigiNotar foi achada por um cidadão comum fazendo uma pergunta num fórum. A RSA soube do alcance da própria invasão quando as defesas de um cliente pegaram o ataque seguinte. O código não autorizado do ScreenOS da Juniper estava no desde agosto de 2012 e foi anunciado em dezembro de 2015.

O caso Juniper carrega a versão mais dura do argumento, e quem acredita em testar até chegar à segurança deveria sentar com ele. O atacante mudou uma constante no gerador de números aleatórios do aparelho. Uma equipe de Illinois, Pensilvânia, Wisconsin e Califórnia estabeleceu depois que as versões modificadas produziam saída criptograficamente indistinguível da saída das versões anteriores - ou seja, nenhum teste, nenhuma medição e nenhuma quantidade de garantia de qualidade poderia ter detectado a mudança observando o comportamento do produto. O defeito era invisível por construção. A detecção teve de vir da leitura do código, e levou três anos.

Contenção: quanto tempo até parar de se espalhar

O NotPetya alcançou toda máquina do parque da Maersk em menos de duas horas porque a rede era plana e as credenciais administrativas eram reutilizadas. A empresa sobreviveu porque uma queda de energia em Gana deixara um controlador de domínio desligado. Isso não é estratégia de contenção; é sorte, e o custo inteiro do incidente foi fixado naquela primeira hora.

Neutralização: corrigir não é expulsar

O intervalo mais subestimado, e o que este catálogo não para de provar. Em abril de 2025 a Fortinet divulgou que atacantes que haviam explorado falhas anteriores tinham deixado um link simbólico entre o sistema de arquivos do usuário da SSL-VPN e o sistema de arquivos raiz do aparelho, e mantinham acesso de leitura a arquivos de configuração - inclusive credenciais - depois de a vulnerabilidade ser corrigida. A empresa disse com todas as letras que organizações que corrigiram prontamente ainda podiam estar afetadas se o aparelho tivesse sido comprometido antes. Os clientes da Ivanti acharam o mesmo formato numa versão pior: um web shell que sobreviveu a uma restauração de fábrica.

A regra operacional que se segue é sem glamour e raramente seguida. Aplicar uma correção fecha a porta. Não remove quem entrou por ela, e não troca as credenciais que essa pessoa leu no caminho. Uma correção é o começo da resposta, não o fim.

Correção definitiva: quanto tempo até a classe do problema sumir

A era dos worms é a demonstração. Nove anos de surtos, cada um com correção disponível antes - um mês para o , seis meses para o Slammer, quatro semanas e um aviso escrito explícito para o . O que acabou com a era não foi corrigir mais rápido. Foram três mudanças estruturais: firewall ligado por padrão, atualização automática como padrão em vez de opção, e macros que perguntam antes de rodar. Cada uma removeu uma classe de exposição em vez de uma instância, e cada uma era entediante.

Comunicação: o que se diz, e quando

Este é o intervalo que os profissionais sistematicamente subvalorizam, e é o que determina quanto do estrago cai sobre todos os outros. A queixa de durante a invasão da continua sendo a formulação mais clara: os clientes não sabiam se deviam trocar tokens, mudar PINs ou isolar seus servidores administrativos, porque não lhes disseram o que fora levado. A DigiNotar começou a revogar certificados em 19 de julho de 2011 e nada disse publicamente por mais de um mês, enquanto os certificados fraudulentos eram usados contra umas 300 mil pessoas. A Microsoft deixou um incorreto publicado por seis meses. A Fujitsu reteve, por uma década, a evidência que teria inocentado pessoas processadas.

Contra esses, o contraexemplo: a Juniper anunciou código não autorizado no próprio firmware, publicou as versões afetadas e lançou correções - e foi amplamente elogiada na indústria por isso, embora a divulgação fosse a coisa mais danosa que um fabricante de rede pode dizer sobre si mesmo. Em seis horas depois de a correção ser pública, pesquisadores extraíram a senha da porta dos fundos comparando binários. É a troca que todo fornecedor enfrenta: divulgar entrega um mapa ao atacante, e não divulgar entrega tempo a ele. O registro deste catálogo é que o tempo vale mais.

O que isso significa ao escolher um fornecedor

Se todo fornecedor lança falhas, a pergunta de compra muda de este produto já teve vulnerabilidades para um conjunto de perguntas com respostas verificáveis:

  • Com que rapidez publicam, e quão específico é o aviso? Versões afetadas, indicadores de comprometimento e o que fazer se você já foi explorado - ou um parágrafo de tranquilização?
  • Dizem como checar se você foi atingido antes da correção? A Fortinet disse, no caso do link simbólico. A maioria não diz.
  • Qual é o histórico deles no segundo aviso - o que corrige o primeiro? Os CVEs subsequentes da Ivanti sugeriram que a superfície de ataque não era plenamente entendida nem pelo fabricante, o que é mais útil saber do que a contagem de CVEs.
  • A função de segurança é alcançável? Um contato nomeado, uma política de divulgação coordenada, um programa de recompensas que paga.

E, simetricamente, as mesmas perguntas sobre a sua organização. A maioria não sabe dizer seu tempo médio de detecção. Quase nenhuma ensaiou o passo de contenção. Pouquíssimas têm uma regra escrita de quem diz o quê, a quem, em quantas horas - que é justamente a coisa que será improvisada, mal, às três da manhã, se não tiver sido escrita à luz do dia.

O playbook é o produto

A razão de escrever procedimentos de incidente não é conformidade. É que os intervalos acima são comprimidos por decisões que já foram tomadas. Quem pode desconectar um segmento de produção sem esperar aprovação. Quais credenciais são trocadas automaticamente quando um aparelho é suspeito. Quem liga para o cliente, e o que essa pessoa pode dizer antes de a investigação terminar. Onde fica a cópia offline da configuração. Se alguém já testou restaurá-la.

Nada disso é código, e nada disso se compra. É a diferença entre a organização que perde um fim de semana e a que perde um trimestre.

A pergunta em aberto: o que a inteligência artificial faz com o relógio

Tudo acima foi escrito a partir de trinta anos de evidência. A posição honesta é que os próximos anos podem não se parecer com eles, e vale ser explícito sobre quais partes são incertas.

O lado do atacante está ficando mais rápido de maneiras já visíveis: o intervalo entre uma correção sair e um exploit funcional existir vem encolhendo há anos, e a análise automatizada da diferença de uma correção - exatamente a técnica que a Fox-IT usou na Juniper em seis horas - é o tipo de trabalho que máquinas fazem bem. Se o tempo até a exploração se aproximar de zero, então uma defesa construída sobre janelas de correção não tem janela.

O lado do defensor pode melhorar tanto quanto ou mais. Detecção de anomalias, correlação de registros e ler uma base de código grande em busca da classe de defeito que um revisor humano deixa passar são todos o mesmo tipo de problema. É perfeitamente possível que o intervalo de detecção - historicamente medido em meses - seja o que mais melhore.

Qual dos dois anda mais rápido não é algo que se possa saber agora, e quem lhe disser o contrário está vendendo alguma coisa. Mas a conclusão estrutural sobrevive aos dois desfechos, e é esse o ponto deste artigo. Se a exploração acelerar, o tempo de resposta importa mais. Se a detecção melhorar, o tempo de resposta é o que converte a melhoria em resultado. Em nenhum dos futuros alguém lança código perfeito. O investimento que se paga em todo cenário é o mesmo que se pagou por trinta anos: saber antes, conter mais rápido, expulsar de verdade, corrigir a classe em vez da instância, e dizer a verdade cedo o bastante para que outras pessoas possam agir sobre ela.

Fontes