CVEs críticas do SQLite ou alucinação de LLM?
Várias vulnerabilidades “críticas” recentes do SQLite acabaram sendo fabricadas, provavelmente geradas por modelos de linguagem de grande porte, mas ainda assim propagadas por feeds oficiais de CVE e scanners empresariais. Os comentaristas argumentam que isso expõe o quão sobrecarregado e ruidoso o ecossistema atual de vulnerabilidades se tornou, especialmente para organizações obrigadas por compliance, seguro ou política interna a corrigir todo CVE independentemente do contexto. Embora muitos vejam LLMs como ferramentas poderosas para encontrar bugs reais, eles alertam que o slop gerado por IA está aumentando os custos de triagem, minando a confiança nos dados de CVE e criando pressão para adicionar etapas de validação mais fortes — potencialmente usando IA novamente do lado defensivo.
Impacto nas organizações e nos fluxos de trabalho de segurança
- Muitos comentaristas dizem que políticas de “corrigir todos os CVEs” (impulsionadas por SOC2, ISO27001, HIPAA, cláusulas de seguro, trabalho para o governo etc.) já são mal viáveis; CVEs falsas ou de baixa qualidade pioram isso.
- As equipes de segurança relatam gastar a maior parte do tempo refutando achados inexplotáveis ou irrelevantes (por exemplo, vulnerabilidades Bluetooth em servidores sem interface, problemas apenas para Windows em stacks Linux).
- Auditores, seguradoras e políticas internas muitas vezes tornam mais fácil corrigir ou atualizar do que argumentar que uma vulnerabilidade é irrelevante, mesmo quando claramente inalcançável.
- Algumas organizações mitigam isso usando exceções/SLAs baseados em risco, mas conseguir aprovações para exceções pode ser doloroso e politicamente complicado.
Problemas com o ecossistema de CVE
- As pontuações base do CVSS são vistas como proxies ruins para risco real; a avaliação ambiental/contextual é difícil e trabalhosa.
- Muitos CVEs afetam componentes obscuros ou não usados (por exemplo, utilitários incluídos com bibliotecas), mas ainda forçam upgrades globais.
- Encadeamento de falhas e defesa em profundidade complicam alegações de “não é explorável”: bugs pequenos podem se tornar graves quando combinados.
- O NIST/NVD está sobrecarregado; a atribuição de CVE é em grande parte burocrática e confia nos enviadores, sem exigência sistemática de PoC.
- Grandes projetos que se tornam CNAs tentam recuperar o controle, mas agora estão inundados por relatórios gerados por IA; alguns programas de recompensa removeram prêmios por causa de slop.
LLMs na descoberta de vulnerabilidades
- A discussão concorda que LLMs agora são capazes de encontrar bugs reais, especialmente em código antigo em C/C++; mantenedores relatam um aumento no volume de problemas genuínos.
- Ao mesmo tempo, LLMs alucinam código, versões e exploits, levando a CVEs bogus e esforço desperdiçado de triagem.
- Há preocupação de que atacantes combinem LLMs de varredura com LLMs de escrita de exploits e grande capacidade de computação para automatizar comprometimento profundo e lateral.
- Próximo passo antecipado: agentes que reproduzam PoCs automaticamente e filtrem o slop antes que humanos vejam os relatórios, embora custo e confiabilidade ainda sejam questões em aberto.
Debate sobre capacidades e confiança em LLMs
- Um grupo enfatiza LLMs como preditores estocásticos do próximo token que exigem verificação humana rigorosa, alertando contra confiar demais neles em fluxos de trabalho críticos para a segurança.
- Outro grupo argumenta que, apesar de probabilísticos, eles já exibem resolução de problemas e análise de código não triviais, e devem ser tratados como ferramentas poderosas, mas falíveis.
- Há um debate filosófico mais amplo sobre se cérebros são “apenas” máquinas probabilísticas e o que isso implica para a inteligência das máquinas.
Mitigações propostas e governança
- As sugestões incluem: exigir exploits funcionais para CVEs de alta severidade; scanners de vulnerabilidade mais granulares e cientes do uso; executores automatizados de PoC; melhor financiamento para o NIST; e possivelmente licenciamento profissional ou responsabilidade mais forte pelo uso indevido de IA em domínios críticos.