LLMs locais de até 4B parâmetros já reproduzem vulnerabilidades reais de software
Um estudo avaliou doze configurações de modelos de linguagem open-weight, pequenos o suficiente para rodar em uma única GPU de consumidor, na tarefa de transformar a descrição de uma vulnerabilidade em uma entrada real que derruba o programa vulnerável, usando dez tarefas do benchmark CyberGym. Os resultados mostram que até modelos de 4B parâmetros resolvem a maioria das tarefas mais fáceis, enquanto as mais difíceis só cedem a um modelo de 27B, e que a quantização afeta a velocidade de resolução, mas não o que efetivamente é resolvido.
A reprodução de vulnerabilidades — transformar a descrição textual de uma falha em um input concreto que derruba a versão vulnerável de um programa — é uma tarefa de interesse direto tanto para quem defende software (confirmar que um patch realmente corrige o problema) quanto para quem o ataca (validar que uma vulnerabilidade reportada é de fato explorável). O estudo foca especificamente em modelos open-weight pequenos o bastante para rodar localmente em uma única GPU de consumidor, escolha motivada pelo fato de que rodar localmente evita enviar código potencialmente sensível para um serviço de IA hospedado por terceiros.
Os autores testaram doze configurações cobrindo três gerações de modelos, duas arquiteturas e três níveis de quantização, contra dez tarefas do CyberGym (um benchmark padronizado de reprodução de vulnerabilidades), com três execuções por tarefa sob o mesmo harness de agente. O achado central é que mesmo o modelo mais pequeno testado (4B parâmetros) já resolve a maior parte das seis tarefas mais fáceis, e as configurações só se diferenciam de fato nas quatro tarefas mais difíceis, que exigem o modelo de 27B para serem resolvidas. A quantização não mudou quais tarefas cada modelo conseguia resolver, mas sim a velocidade com que chegava lá, com arquiteturas de mistura de especialistas atingindo o mesmo resultado em menos tempo de processamento.
O dado mais interessante da análise de trajetórias é que, na quase totalidade das execuções examinadas — incluindo as que falham —, o modelo corretamente identifica a função vulnerável e formula a hipótese certa sobre a causa raiz; o que separa sucesso de fracasso é unicamente se essa hipótese correta é convertida em um input que de fato dispara o comportamento. Isso tem relevância prática para quem avalia o risco de uso malicioso de modelos locais: a barreira para abuso ofensivo não está mais em 'o modelo entende o bug', já resolvido mesmo por modelos pequenos e amplamente disponíveis, mas na capacidade de execução iterativa — e essa barreira está caindo rapidamente conforme modelos maiores, ainda assim executáveis localmente, ficam acessíveis.