A empresa de capital de risco a16z acaba de partilhar um gráfico que se tornou viral no X nos últimos dias. O gráfico mostra que as vulnerabilidades (CVE) de gravidade crítica e elevada passaram de menos de 100 por mês para mais de 600 por mês desde a primavera de 2026, em 21 grandes empresas de software. Os dados são da Epoch AI e incluem os números da Apple, da AWS, da Microsoft, do Google e da Adobe.
E como se trata do X, é claro que as pessoas deram a sua opinião (sim, estamos a fazer o mesmo aqui).
Dividiram-se em dois campos. Um interpretou isso como uma verdadeira mudança no nível de risco, enquanto o outro salientou que o número de vulnerabilidades conhecidas e exploradas (KEV) não sofreu alterações desde 2024, pelo que o facto de haver mais divulgações não significa necessariamente que haja mais perigo.
Até o próprio relatório da a16z apresenta reservas a este respeito:
«Se existem, de facto, mais vulnerabilidades, ou se se trata de alguma alteração na forma de comunicar ou definir essas vulnerabilidades, é difícil dizer apenas olhando para o gráfico, mas é provável que pelo menos parte (e talvez grande parte) deste crescimento parabólico seja atribuível a uma alteração substancial e significativa na forma como as vulnerabilidades são descobertas e/ou no que ainda é considerado seguro.»
Mas ambos os lados estão a interpretar isto de forma totalmente errada. Nem o número bruto de novas CVEs nem um valor fixo de KEV determinam, na verdade, o risco. O risco é determinado pela rapidez com que se consegue identificar quais as vulnerabilidades que são relevantes e pela rapidez com que estas são corrigidas, uma vez validadas.
É evidente que a IA facilitou consideravelmente a deteção de vulnerabilidades (tanto para os atacantes como para os defensores). Os modelos de ponta detetam vulnerabilidades mais rapidamente do que os revisores conseguem validá-las, incluindo erros de longa data que resistiram a anos de revisão manual.
Portanto, o aumento no gráfico da a16z explica-se, de facto, melhor pelo facto de a IA tornar mais rápida a deteção de falhas que já existiam, em vez de o software se ter tornado subitamente menos seguro. Mas isso é apenas parte da história.
O que acontece quando uma instituição tenta acompanhar o ritmo da deteção fácil
O NIST, a instituição que todos consideram a referência absoluta em matéria de dados sobre vulnerabilidades, enfrenta exatamente o mesmo problema, mas a uma escala muito maior. Partindo do pressuposto de que um maior número de CVEs significava maior perigo, tem vindo a tentar atribuir uma pontuação a cada CVE que recebe. No entanto, o volume avassalador de CVEs tornou isso praticamente impossível. E, por fim, o sistema entrou em colapso.
Uma auditoria federal realizada em maio deste ano revelou que o número de casos pendentes tinha aumentado de 13 000 para mais de 27 000 em dezoito meses. Qual foi a solução sugerida pelo NIST? Deixar de atribuir pontuação a tudo. Em vez disso, está a dar prioridade aos CVEs relacionados com a utilização federal, ao software crítico ou àqueles que já constam da lista de vulnerabilidades exploradas da CISA. Tudo o resto é marcado como «não agendado», pelo que é provável que não venha a ser analisado novamente.
O desafio do NIST consiste em conseguir que uma vulnerabilidade seja divulgada e classificada. Mas mesmo no caso das que cumprem integralmente esses critérios — ou seja, que estão confirmadas, classificadas e se sabe que estão a ser ativamente exploradas —, é na correção dessas vulnerabilidades que as coisas parecem continuar a dar errado.
A reparação é o ponto de estrangulamento
O Relatório de Investigações sobre Fugas de Dados de 2026 da Verizon, com base em mais de mil milhões de registos de vulnerabilidades, revelou que apenas 26 % das vulnerabilidades confirmadas e ativamente exploradas (incluídas na lista KEV da CISA) foram totalmente corrigidas em 2025, o que representa uma descida em relação aos 38 % registados no ano anterior. O tempo mediano necessário para aplicar a correção completa a uma vulnerabilidade aumentou para 43 dias, face aos 32 dias anteriores.
Mesmo as organizações com mais recursos só conseguem corrigir totalmente 30 a 40 % destas vulnerabilidades na primeira semana. A Verizon chama a isto o «paradoxo da correção», o que não passa de uma forma de dizer que as vulnerabilidades aumentam, enquanto a correção abranda.
Sabe-se que estas vulnerabilidades estão a ser ativamente exploradas e constam de uma lista pública. E ainda não estão a ser corrigidas com a rapidez necessária.
Como é, na prática, uma reparação rápida
Este mês, uma vulnerabilidade de execução de código (RCE) sem autenticação, denominada «Stylesmuggler», começou a afetar o Adobe Commerce e o Magento Open Source. Não lhe foi atribuído um CVE, nem foi emitido qualquer aviso pela Adobe.
Uma vulnerabilidade não precisa de um número CVE nem de um aviso do fornecedor para ser real ou para ser explorada. Esperar por qualquer um deles antes de agir significa que os atacantes já têm uma vantagem inicial. A única forma de contornar isso é confiar em algo que consiga detetar e confirmar vulnerabilidades por si próprio e corrigi-las rapidamente assim que as detetar.
Aikido A Intel identificou a vulnerabilidade de forma independente, sem esperar pela Adobe ou por um número CVE para confirmar que era real. A empresa registou a vulnerabilidade em três entidades distintas, e o Aikido Libraries disponibilizou uma correção funcional para várias versões afetadas. Esta foi enviada como um pedido de integração (pull request) do AutoFix diretamente para o fluxo de trabalho que as equipas já utilizam, em vez de uma migração manual separada e trabalhosa. Tudo isto antes de a Adobe lançar a sua própria correção, mais de 24 horas depois.
No entanto, o StyleSmuggle não é um caso isolado. No primeiro ano de funcionamento da Intel, 67% dos pacotes em que foram detetadas vulnerabilidades nunca foram divulgados publicamente em qualquer base de dados (nem no NVD, nem no GitHub Advisory, nem no MITRE, nem em lado nenhum).
Então, a verdadeira história é…
O aumento do volume de CVEs é semelhante ao número de pacotes npm publicados todos os anos: é um processo que se acumula, pelo que observar essa evolução é, de certa forma… insignificante. O que importa é a rapidez com que uma vulnerabilidade real e confirmada é corrigida e, neste momento, em todo o setor, essa correção não é suficientemente rápida.
À medida que a IA torna as capacidades de deteção e exploração cada vez mais comuns, a cibersegurança tem de se reinventar em torno do que acontece depois de algo ser detetado. Isso começa por saber quais das vulnerabilidades detetadas são, de facto, acessíveis e exploráveis. O reachability analysis do Aikido filtra tudo o que não tenha um caminho de execução para o código vulnerável, e o CVE análise de explorabilidade vai mais além, analisando a forma como um pacote é efetivamente utilizado no seu ambiente para decidir se vale a pena agir sobre uma vulnerabilidade acessível.
Aikido O AutoFix aplica a correção de duas formas. No caso de problemas conhecidos e corrigíveis, o AutoFix pode gerar a correção diretamente. Para pacotes de código aberto, aplica o patch à versão exata já fixada no ficheiro de bloqueio de uma equipa, sem necessidade de atualização ou migração. Funciona da mesma forma para imagens base vulneráveis do container e para o código das aplicações. Quando uma correção requer uma decisão humana, a vulnerabilidade continua a ser assinalada com uma recomendação específica e exequível, para que alguém possa agir imediatamente, em vez de ter de decidir primeiro o que fazer. O próximo passo, levar todo este processo até à produção sem ter de esperar que alguém faça a integração, não está longe de se tornar realidade.
Detetar vulnerabilidades nunca foi tão fácil. Agora, o foco deve estar em como filtrar as vulnerabilidades do ruído e corrigi-las rapidamente.
