A empresa de capital de risco a16z acabou de partilhar um gráfico que se tornou viral no X nos últimos dias. O gráfico mostra as CVEs críticas e altas a saltar 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 vieram da Epoch AI e incluem contagens da Apple, AWS, Microsoft, Google e Adobe.
E como se trata do X, as opiniões não tardaram a surgir (sim, nós também estamos a fazer o mesmo aqui).
Dividiram-se em duas facções. Uma interpretou-o como uma mudança real no risco, enquanto a outra apontou que as vulnerabilidades conhecidas e exploradas (KEV) não se alteram desde 2024, pelo que o facto de haver mais divulgações não significa necessariamente um perigo maior.
Até o próprio relatório da a16z acautela isto:
“Quer existam de facto mais vulnerabilidades, quer haja alguma alteração nos relatórios ou na definição, é difícil dizê-lo apenas olhando para o gráfico, mas é provável que pelo menos parte (e talvez muita) deste crescimento parabólico seja atribuível a uma mudança substantiva importante na forma como as vulnerabilidades são descobertas e/ou no que ainda é considerado seguro.”
Mas ambas as facções estão a interpretar isto totalmente mal. Nem a contagem bruta de novas CVEs nem um número KEV estagnado determinam realmente o risco. O risco é determinado pela rapidez com que consegue descobrir quais são as vulnerabilidades que importam e a rapidez com que são corrigidas assim que são validadas.
É evidente que a IA tornou muito mais fácil encontrar vulnerabilidades (tanto para atacantes como para defensores). Os modelos de última geração encontram vulnerabilidades mais depressa do que os revisores conseguem validá-las, incluindo bugs de longa data que sobreviveram a anos de revisão manual.
Portanto, o salto no gráfico da a16z é de facto mais bem explicado pelo facto de a IA acelerar a descoberta de bugs 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 a facilidade de deteção
O NIST, a instituição que todos encaram como a referência máxima para dados de vulnerabilidades, está a lidar exatamente com o mesmo problema com um volume maior. Partindo do pressuposto de que mais CVEs significavam mais perigo, tentava pontuar cada CVE recebida. Contudo, o volume absoluto de CVEs tornou isto praticamente impossível. E, eventualmente, o sistema colapsou.
Uma auditoria federal realizada em maio passado concluiu que o atraso acumulado tinha crescido de 13 000 para mais de 27 000 em dezoito meses. A solução sugerida pelo NIST? Deixar de pontuar tudo. Em vez disso, está a priorizar as CVEs associadas ao uso federal, software crítico ou aquelas que já constam da lista de vulnerabilidades conhecidas e exploradas da CISA. Tudo o resto é marcado como “não agendado”, pelo que é provável que não volta a ser analisado.
A luta do NIST prende-se com a divulgação e pontuação de vulnerabilidades. Mas mesmo para aquelas que ultrapassam totalmente essa barreira — ou seja, confirmadas, pontuadas e reconhecidas como ativamente exploradas —, é na altura de as corrigir que as coisas parecem continuar a falhar.
A correção é o verdadeiro estrangulamento
O relatório Data Breach Investigations de 2026 da Verizon, que se baseia em mais de mil milhões de registos de vulnerabilidades, concluiu que apenas 26% das vulnerabilidades confirmadas como ativamente exploradas (na lista KEV da CISA) foram totalmente remediadas em 2025, uma descida face aos 38% do ano anterior. O tempo mediano para corrigir totalmente uma delas subiu para 43 dias, em comparação com os 32 anteriores.
Mesmo as organizações com mais recursos apenas remediam totalmente 30-40% destas na primeira semana. A Verizon chama a isto o "paradoxo da remediação", que na prática significa que as vulnerabilidades estão a acelerar enquanto a remediação abrandou.
Sabe-se que estas vulnerabilidades estão a ser ativamente exploradas e constam numa lista pública. E continuam a não ser corrigidas com rapidez suficiente.
Como é que a correção rápida se processa realmente
Este mês, uma vulnerabilidade RCE não autenticada chamada Stylesmuggler começou a afetar o Adobe Commerce e o Magento Open Source. Não tinha um CVE associado, nem um aviso da Adobe.
Uma vulnerabilidade não precisa de um número CVE ou de um aviso do fornecedor para ser real ou para ser explorada. Esperar por um deles antes de agir significa que os atacantes já levam uma vantagem inicial. A única forma de dar a volta a isto é confiar em algo que consiga encontrar e confirmar vulnerabilidades por si próprio e corrigi-las rapidamente assim o faça.
O Aikido Intel detetou-a de forma independente, sem esperar pela Adobe ou por um número CVE para confirmar que era real. Monitorizou a vulnerabilidade sob três entidades distintas, e o Aikido Libraries disponibilizou uma correção funcional para várias versões afetadas. Foi enviada como um pedido de pull 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 rápida mais de 24 horas depois.
No entanto, o StyleSmuggle não é um caso isolado. No primeiro ano de funcionamento do Intel, 67% dos pacotes onde encontrou vulnerabilidades nunca tinham sido divulgados publicamente a nenhuma base de dados (nem NVD, nem GitHub Advisory, nem MITRE, nem em lado nenhum).
Portanto, a verdadeira história é…
O aumento do volume de CVEs é semelhante ao número de pacotes npm publicados todos os anos; acumula-se, pelo que assistir a esse crescimento é um pouco… irrelevante. O que importa é a rapidez com que uma vulnerabilidade real e confirmada é corrigida e, neste momento, em toda a indústria, essa velocidade não é suficiente.
À medida que a IA democratiza as capacidades de deteção e exploração, a cibersegurança tem de se reinventar em torno do que acontece após a descoberta de um problema. Isso começa por saber quais das vulnerabilidades detetadas são efetivamente acedíveis e exploráveis. A reachability analysis do Aikido filtra tudo o que não tenha um caminho de execução até ao código vulnerável, e a análise de explorabilidade CVE vai mais longe, avaliando a forma como um pacote é efetivamente utilizado no seu ambiente para decidir se vale a pena agir sobre uma vulnerabilidade acedível.
O Aikido faz a correção de duas formas. Para problemas conhecidos e suscetíveis de correção, o AutoFix pode gerar a correção diretamente. No caso de pacotes de código aberto, o sistema corrige a versão exata que já está fixada no ficheiro lock de uma equipa, sem exigir uma atualização ou migração. Funciona da mesma forma para imagens base de container vulneráveis e código de aplicação. Quando uma correção exige uma decisão humana, a vulnerabilidade continua a ser sinalizada com uma recomendação específica e acionável, permitindo que alguém aja de imediato em vez de ter de calcular o que fazer primeiro. O passo seguinte — fazer todo este processo até à produção sem esperar que alguém faça o merge — já não está longe.
Encontrar vulnerabilidades nunca foi tão fácil. Agora, o foco deve estar na forma como filtra as vulnerabilidades do ruído e as corrige rapidamente.
