Greg Kroah-Hartman – Segurança na Era dos LLMs [vídeo]

Artigo original ↗ Discussão no Hacker News ↗

Afirmações de que a IA Mythos da Anthropic descobriu dezenas de vulnerabilidades críticas no kernel Linux estão sendo reexaminadas à luz de relatos de que apenas uma fração era real, em geral bugs menores que levaram cerca de uma hora de trabalho de desenvolvedor para corrigir. Comentadores argumentam que isso destaca um padrão mais amplo de exagero das capacidades de grandes modelos de linguagem, especialmente em segurança, onde os falsos positivos são altos e a mídia e a gestão frequentemente aceitam o marketing sem questionar. O debate também levanta preocupações sobre risco legal dos dados de treinamento, o impacto do ruído gerado por LLMs em mantenedores de código aberto e a importância de tratar essas ferramentas como assistentes rigidamente supervisionados, e não como especialistas autônomos.

Resultados do Mythos sobre bugs no kernel

  • A palestra destacou uma análise de 79 “vulnerabilidades” relatadas: muitas não tinham detalhes utilizáveis, algumas nem eram bugs, algumas usavam dados inventados e ~15 já tinham sido corrigidas.
  • Cerca de 20 exigiam qualquer mudança no código, e apenas ~10 foram consideradas bugs “reais” com impacto plausível; várias dependiam de cenários de ataque muito artificiais.
  • O Mythos contou mal os próprios problemas, reforçando a percepção de que os LLMs são frágeis até em tarefas básicas como contagem.
  • Alguns comentadores observam que o Mythos de fato encontrou bugs sérios em outros lugares (por exemplo, NFS, pilhas BSD/OpenBSD), então ele não é inútil, mas faltaram “smoking guns” no Linux.

Ruído, falsos positivos e CVEs

  • Mantenedores relatam que os relatórios automatizados e baseados em LLM sobre segurança são dominados por falsos positivos prolixos e excessivamente confiantes, caros de triagem.
  • A prática no kernel é atribuir CVEs a praticamente toda correção de bug, o que explica os altos números de CVEs; os problemas encontrados pelo Mythos receberam CVEs, mas eram em sua maioria de baixo impacto.
  • Uma taxa de ~50% de falsos positivos para ferramentas de LLM é contrastada com analisadores estáticos mais antigos, com ~20%, que já lutavam para ganhar adoção.
  • Assimetria principal: relatórios de bugs agora são quase gratuitos para gerar, mas o custo de verificação para especialistas permanece o mesmo.

LLMs como ferramentas: capacidade vs limitações

  • Muitos descrevem os modelos de ponta atuais como poderosos reconhecedores de padrões: bons para encontrar padrões recorrentes em código, fracos em contexto do mundo real e modelagem de ameaças.
  • As analogias vão de “estagiário excessivamente confiante” a “aluno de pós-graduação no percentil superior em velocidade”, mas vários argumentam que isso lisonjeia os LLMs; estagiários aprendem e assumem responsabilidade, os modelos não.
  • Outros respondem que “correspondência de padrões” é tudo o que os humanos também fazem, e se máquinas encontram defeitos que humanos deixam passar, isso tem valor independentemente do status filosófico.

Hype, mídia e confiança

  • O Mythos é amplamente visto como superestimado: vendido como perigosamente poderoso, com acesso fortemente controlado, mas produziu na Linux principalmente problemas triviais ou já corrigidos.
  • Comentadores conectam isso ao PR mais amplo de IA (afirmações de “perigoso demais para ser lançado”, modelos “sencientes”, visitas ao Papa) e a jornalistas amplificando narrativas de fornecedores sem crítica.
  • Ciclos repetidos de seis meses de “desta vez é incrível” levam a um ceticismo crescente, mesmo entre usuários que acham LLMs úteis na prática.

Implicações de segurança e modelos de ameaça

  • Alguns argumentam que até um único bug real, somado a agentes capazes de encadear exploits, já é preocupante; LLMs também encurtam o tempo do bug ao exploit funcional.
  • Outros enfatizam que os bugs de kernel descobertos eram em grande parte não críticos e/ou de nicho (por exemplo, imagens maliciosas de sistemas de arquivos, casos exóticos de rede).
  • Há debate sobre futuros “worms de IA autônomos e auto-replicantes”: alguns veem isso como plausível quando modelos locais capazes se tornarem comuns; outros observam as restrições atuais de hardware e implantação.

Preocupações legais e de processo

  • Uma alegação citada: apenas uma minoria dos corpora comuns de treinamento é claramente legal de usar; o restante está em uma zona cinzenta.
  • Isso levanta dúvidas sobre incorporar patches gerados por LLM em projetos como o kernel se as saídas se assemelharem a dados protegidos por copyright do treinamento.
  • Mecanismos existentes, como o Developer Certificate of Origin, são vistos como necessários, mas não resolvem totalmente os novos riscos; o desfecho de decisões judiciais pendentes é considerado incerto.

Padrões práticos de uso e conselhos

  • Vários recomendam:
    • Tratar LLMs estritamente como ferramentas auxiliares, não como desenvolvedores autônomos.
    • “Ignore os comentários, olhe o código” – explicações geradas costumam estar erradas; o código é o que importa.
    • Nunca enviar dados não públicos ou sensíveis para modelos SaaS; executar modelos de pesos abertos localmente quando possível.
    • Esperar que o uso de LLMs pressione a colaboração técnica, já que alguns contribuidores agora se apoiam em “o que o meu modelo disse” em vez de revisão humana.