O Problema dos 6%: A IA Encontra Falhas à Velocidade da Máquina, o Mundo Corrige-as à Velocidade Humana
Um programa de divulgação de vulnerabilidades encontradas por IA reportou uma taxa de correção de 6%. Aplique esse número a uma árvore de dependências típica e ao prazo de 14 dias do esquema britânico Cyber Essentials, e cada lançamento de um modelo de fronteira transforma-se numa vaga de patches para a qual a maioria das empresas portuguesas não tem equipa.
Até final de maio de 2026, apenas cerca de 6% das vulnerabilidades divulgadas através de um programa de descoberta assistida por IA tinham sido corrigidas. O número consta de um testemunho prestado perante a Comissão de Segurança Interna da Câmara dos Representantes dos EUA, que questionou abertamente se os sistemas de divulgação conseguem acompanhar o ritmo de cada novo lançamento de modelo. É o dado mais útil publicado até agora sobre como a IA está a mudar a descoberta de vulnerabilidades e a gestão de patches, porque transforma uma ansiedade vaga em aritmética que qualquer empresa pode aplicar aos seus próprios sistemas. É essa aritmética que este artigo desenvolve.
Como está a IA a mudar a descoberta de vulnerabilidades e a gestão de patches?
A divulgação coordenada foi concebida para um mundo de escassez. Um investigador encontra uma falha, reporta-a discretamente, o fornecedor recebe um prazo fixo (90 dias, tipicamente) para lançar uma correção, e só depois o aviso se torna público. Todas as peças dessa máquina pressupõem que a descoberta chega a conta-gotas.
A descoberta à escala de máquina quebra essas premissas todas ao mesmo tempo. A Cloud Security Alliance analisou alegações de um fornecedor segundo as quais um único modelo teria encontrado milhares de vulnerabilidades até então desconhecidas, incluindo falhas que permaneciam em código open source amplamente auditado há décadas. A CSA não conseguiu verificar de forma independente as alegações de capacidade, pelo que os totais concretos devem ser tratados como não confirmados. Já o número da taxa de correção de 6% não precisa dessa reserva: seja qual for a verdadeira taxa de descoberta, a taxa de correção está documentada, e é lamentável. A descoberta está a ser automatizada. A correção não.
Qual é a sua fatia do problema?
Comece pela forma de uma árvore de dependências moderna. Um estudo sobre o ecossistema npm apresentado na USENIX Security concluiu que instalar um pacote médio significa confiar implicitamente em mais 79 pacotes e 39 mantenedores. Um produto de média dimensão com poucas dezenas de dependências diretas assenta, portanto, em várias centenas a mil componentes distintos, a maioria dos quais os seus programadores nunca leram.
Agora ponha números numa vaga de divulgação. Assuma, de forma conservadora, que um evento de divulgação à escala de máquina atinge 2% de uma árvore com 1 000 componentes: vinte componentes afetados. À taxa de correção reportada no testemunho perante o Congresso norte-americano, aproximadamente um desses vinte terá uma correção a montante pronta no dia do lançamento. Os outros dezanove ficam por conta da empresa, para mitigar, isolar ou substituir.
No Reino Unido, esse volume de trabalho tem prazo marcado. O esquema Cyber Essentials exige que atualizações de segurança críticas e de alto risco sejam aplicadas no prazo de 14 dias, e a certificação é condição permanente em muitos contratos do setor público britânico. Dezanove mitigações ao nível de componente em catorze dias significa lançar 1,4 por dia, sustentado durante uma quinzena, além do trabalho normal. Para empresas portuguesas que vendem ao Reino Unido, ou que se preparam para as obrigações equivalentes da NIS2 já em vigor na União Europeia, o cálculo é o mesmo: muda apenas o nome do regulador.
Compare isto com a realidade medida. A análise da Veracode ao código de terceiros concluiu que 79% das bibliotecas nunca são atualizadas depois de adicionadas a uma base de código, pelo que o ritmo real da maioria das equipas está próximo de zero. Se 2% parecer um valor agressivo, faça a conta com 0,5%: cinco componentes numa quinzena continuam a exceder o que uma equipa que lança uma atualização de dependência por semana consegue absorver. A conclusão sobrevive a qualquer valor razoável de entrada. Uma vaga de divulgação modesta ultrapassa a capacidade típica de aplicação de patches numa ordem de grandeza.
Quem é corrigido antes de si?
Um laboratório que acumula uma massa de falhas ainda não publicadas tem de avisar alguém antes de avisar toda a gente. Guardá-las é indefensável, divulgá-las de imediato ao público é pior, e informar discretamente milhares de projetos afetados é impossível. A decisão racional é pré-avisar um círculo restrito: as maiores plataformas, com equipas de segurança suficientemente grandes para absorver uma torrente confidencial de informação. Isso é triagem, e também é, em qualquer definição comercial, um nível de adesão. O intervalo entre a correção privada dentro desse círculo e a disponibilidade pública do modelo é uma janela de exposição agendada, com uma data de início razoavelmente previsível e uma lista de convidados que a empresa comum não consegue influenciar.
Fora do círculo, o peso recai sobre quem tem menos recursos em toda a cadeia. O Census II do software livre e de código aberto, da Linux Foundation, encontrou as bibliotecas mais utilizadas apoiadas num pequeno número de mantenedores, muitos deles não remunerados. Não existe uma escala de prevenção para o voluntário que cuida de uma biblioteca de parsing com vinte anos, e nenhum consórcio vai corrigir antecipadamente as dependências transitivas de ninguém. O número de 6% é o resultado de uma descoberta que escala como software enquanto a correção continua a escalar como pessoas.
Como é um modelo de capacidade de patch para o dia de lançamento?
Trate os lançamentos anunciados de modelos de fronteira como as equipas de instalações tratam previsões de tempestade: eventos com data marcada que desencadeiam uma resposta ensaiada. O modelo tem quatro partes.
Responsabilidade. A vaga pertence a quem gere o pipeline de implementação, tipicamente o responsável de engenharia ou de operações de TI. Cabe à segurança fazer a triagem e a priorização; cabe à engenharia lançar. Um plano de contingência gerido por uma equipa que não pode implementar é apenas um documento.
Uma referência medida. Conte as atualizações de dependências que a sua equipa testou e implementou por semana no último trimestre, a partir de registos de alterações e não da memória. Esse número é a sua verdadeira capacidade de resposta, e deve constar da sua estratégia técnica, a par de um inventário de dependências que sinalize os componentes que ninguém a montante alguma vez irá corrigir por si.
Limiares. Dimensione a vaga com a aritmética acima: tamanho da árvore, multiplicado por uma taxa de incidência assumida, multiplicado pelos 94% de descobertas que deve presumir chegarem sem correção, a dividir por catorze dias. Se o resultado couber dentro da sua capacidade medida, ensaie o plano e siga em frente. Se exceder a capacidade, e para a maioria das empresas de média dimensão vai exceder, acorde antecipadamente mitigações que não dependam de aplicar patches: patches virtuais na gateway, isolamento de rede para componentes de risco, interruptores de emergência por feature flag, e uma lista ordenada das vinte dependências que defenderia primeiro. Desenhar componentes que possam ser cortados sem derrubar o produto é a mesma disciplina que defendemos em proteger sistemas agénticos.
Consequências para empresas portuguesas e europeias, por escrito. Uma certificação Cyber Essentials caducada pode inviabilizar contratos com o setor público britânico; em Portugal e na União Europeia, o incumprimento de obrigações equivalentes ao abrigo da NIS2 tem consequências semelhantes. Uma falha explorada que toque dados pessoais aciona o prazo de 72 horas do regulador britânico de proteção de dados, o mesmo prazo que o RGPD impõe às empresas portuguesas perante a CNPD. As seguradoras de risco cibernético perguntam sobre o ritmo de aplicação de patches em cada renovação de apólice. Estas três consequências devem constar dos documentos de contratação antes de construir seja o que for sobre um modelo de fronteira, que é a metade menos entusiasmante da preparação para a IA.
O círculo de pré-aviso vai manter a sua lista e as datas de lançamento vão continuar a chegar. De todos os números deste artigo, o ritmo medido de aplicação de patches é o único que a empresa controla, e a data do próximo lançamento já está algures numa agenda. Meça a sua esta semana.
Perguntas frequentes
O que é uma janela de exposição na divulgação de vulnerabilidades, e porque está a tornar-se mais perigosa?
É o intervalo entre uma falha ser reportada em privado e os detalhes tornarem-se públicos. Historicamente protegia os utilizadores enquanto uma correção era preparada. Quando um modelo de IA gera as descobertas e, ao mesmo tempo, fica publicamente disponível numa data conhecida, essa janela transforma-se numa contagem decrescente até ao momento em que as organizações sem correção aplicada encontram, em campo aberto, uma ferramenta de descoberta poderosa.
Como calculo a capacidade de patch para o dia de lançamento na minha organização?
Multiplique o tamanho da sua árvore de dependências por uma taxa de incidência assumida (entre 0,5% e 2% é um intervalo de planeamento razoável), desconte a pequena fração de descobertas com probabilidade de já ter correção a montante, e divida por 14 dias. Esse valor é o ritmo diário de mitigação que precisaria de sustentar. Compare-o com a sua capacidade real, medida a partir de registos de alterações, e feche a diferença com mitigações acordadas antecipadamente, como isolamento e interruptores de emergência, em vez de otimismo.
Usar software open source maduro e amplamente auditado protege-me contra falhas descobertas por IA?
Menos do que protegia. As alegações em análise envolvem falhas que sobreviveram décadas em código intensamente revisto, e os dados de correção apontam para a capacidade dos mantenedores, não para a idade do código, como o verdadeiro estrangulamento. O Census II encontrou as bibliotecas mais utilizadas apoiadas numa mão-cheia de mantenedores, pelo que a popularidade concentra a exposição no dia de lançamento em vez de a diluir.
Relacionado
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Washington Classificou o Seu Próprio Laboratório de IA Como Risco de Segurança Nacional. Isto Muda o Sentido da Dependência de um Fornecedor de IA
- Porque falham os pilotos de IA nas empresas: o problema é a confiança, não a capacidade
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.