TOSSS: a CVE-based Software Security Benchmark for Large Language Models

O artigo apresenta o TOSSS, um novo benchmark baseado no banco de dados CVE que avalia a capacidade de Grandes Modelos de Linguagem (LLMs) de distinguir entre trechos de código seguros e vulneráveis, atribuindo uma pontuação de segurança que varia de 0 a 1.

O essencial

Imagine que você contratou um assistente de programação superinteligente, um "robô programador" feito de Inteligência Artificial (IA), para ajudar a escrever o código dos seus softwares. Você está feliz, porque ele escreve rápido e parece saber tudo. Mas, e se esse robô, sem querer, estiver colocando fechaduras quebradas nas portas da sua casa digital?

É exatamente sobre esse medo que o artigo "TOSSS" trata.

Aqui está a explicação do que os pesquisadores descobriram, usando uma linguagem simples e algumas analogias divertidas:

1. O Problema: O Robô que não sabe o que é "Seguro"

Hoje em dia, usamos essas IAs (chamadas de LLMs) para escrever código de computador. O problema é que ninguém sabe ao certo se elas são boas em segurança.

• A analogia: Imagine que você pede a um cozinheiro para fazer um bolo. Ele faz um bolo delicioso (o código funciona), mas esqueceu de tirar o vidro do fundo da forma (o código tem uma falha de segurança). O bolo sai, mas se alguém comer, pode se machucar.
• Estudos anteriores mostraram que muitos desses robôs estão criando códigos com "vidros escondidos" (vulnerabilidades) em cerca de 40% das vezes.

2. A Solução: O Jogo do "Escolha a Melhor" (TOSSS)

Antes, para testar esses robôs, os cientistas pediam para eles criarem um código do zero e depois usavam um scanner para ver se havia erros. O problema era que esse scanner não conseguia pegar todos os tipos de erros novos.

Os autores criaram um novo teste chamado TOSSS.

• A analogia: Em vez de pedir para o robô cozinhar o bolo do zero, você coloca duas versões do mesmo bolo na mesa:
  • Opção A: Um bolo com um vidro escondido (inseguro).
  • Opção B: Um bolo perfeito e seguro.
  • O Teste: Você pergunta ao robô: "Qual desses dois bolos você prefere?"
• Se o robô escolher a Opção B, ele ganha um ponto. Se escolher a A, perde.
• A vantagem: Como você já sabe qual é o "bolo perfeito" (porque os pesquisadores pegaram exemplos reais de erros que foram corrigidos no passado), o teste é justo, rápido e pode ser atualizado sempre que surge um novo tipo de erro no mundo real.

3. Como eles fizeram isso? (A Mina de Ouro)

Os pesquisadores usaram uma base de dados gigante chamada CVE, que é como um "diário de crimes" de softwares. Eles pegaram casos reais onde um programa tinha um erro e depois foi corrigido.

• Eles transformaram o "antes" (com erro) e o "depois" (corrigido) em pares de opções para o robô escolher. É como se eles estivessem usando casos reais de polícia para treinar o robô a reconhecer o criminoso.

4. O Resultado: Nem todos os robôs são iguais

Eles testaram 14 robôs famosos (como os da OpenAI, Google, Anthropic, etc.) com códigos em C/C++ e Java.

• A pontuação: Eles deram uma nota de 0 a 1.
  • 1.0: O robô é um guarda-costas perfeito, sempre escolhe o código seguro.
  • 0.5: O robô está chutando (como jogar cara ou coroa).
  • 0.0: O robô é perigoso, sempre escolhe o código com erro.
• O que acharam:
  • Alguns robôs foram ótimos (nota perto de 0.88).
  • Outros foram péssimos (nota perto de 0.48, ou seja, eles preferiam o código com erro!).
  • Curiosidade: Os robôs feitos especificamente para programar (os "especialistas em código") nem sempre foram os melhores em escolher o código seguro. Às vezes, eles focam tanto em fazer o código funcionar rápido que esquecem de torná-lo seguro.

5. O Truque do "Dica"

Eles fizeram um teste interessante:

• Sem dica: "Escolha A ou B." (O robô tinha que adivinhar sozinho o que era seguro).
• Com dica: "Escolha A ou B, mas lembre-se: queremos o mais seguro."
• Resultado: Na maioria das vezes, quando você avisa explicitamente "olha, segurança é importante aqui", o robô melhora sua nota. Isso significa que muitos robôs sabem o que é seguro, mas precisam que você lhes dê um "empurrãozinho" para lembrar de usar esse conhecimento.

Conclusão: Por que isso importa?

O TOSSS é como um novo "exame de direção" para IAs. Em vez de ver se elas conseguem dirigir um carro (escrever código), o teste vê se elas conseguem identificar qual carro tem freios defeituosos.

Isso é importante porque:

1. É fácil de atualizar: Sempre que surge um novo vírus de computador no mundo real, os pesquisadores podem adicionar um novo par de opções ao teste.
2. É claro: A nota diz exatamente o quão confiável o robô é.
3. Ajuda a melhorar: Agora, as empresas que criam esses robôs podem usar esse teste para ver se seus produtos estão ficando mais seguros.

Em resumo: O artigo nos diz que, embora as IAs sejam incríveis, elas ainda precisam ser ensinadas a não deixar a porta da frente aberta. E o TOSSS é a régua perfeita para medir se elas estão aprendendo essa lição.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "TOSSS: a CVE-based Software Security Benchmark for Large Language Models", apresentado em português:

1. O Problema

Com a adoção crescente de Modelos de Linguagem de Grande Escala (LLMs) em fluxos de trabalho de engenharia de software, surge uma questão crítica: os LLMs são competentes em segurança de software?
Estudos anteriores indicaram que assistentes de codificação baseados em LLMs frequentemente geram código com vulnerabilidades (ex: 40% dos programas gerados pelo GitHub Copilot continham falhas de segurança). No entanto, os benchmarks (conjuntos de testes) existentes para avaliar a segurança dos LLMs apresentam limitações significativas:

• Baixa Extensibilidade: Eles dependem de conjuntos de tarefas fixos e de analisadores estáticos (como CodeQL), o que dificulta a incorporação de novas vulnerabilidades descobertas ou de novas linguagens de programação.
• Falta de Verdade Terrena (Ground Truth) Explícita: A maioria avalia a segurança gerando código e tentando detectá-lo com ferramentas externas, em vez de comparar diretamente com uma implementação segura conhecida.
• Viés e Escalabilidade: Métodos que exigem validação manual ou dependem de geradores de testes limitados não escalam bem para grandes volumes de dados.

2. Metodologia: TOSSS

O artigo introduz o TOSSS (Two-Option Secure Snippet Selection), um novo benchmark que reformula a avaliação de segurança como uma tarefa de seleção de código em vez de geração de código.

• Conceito Central: Em vez de pedir ao modelo para escrever código, o TOSSS apresenta ao LLM duas versões da mesma função: uma vulnerável e uma segura. O modelo deve escolher qual versão prefere (A ou B).
• Construção de Dados (Pipeline):
  • O benchmark utiliza o banco de dados CVE (Common Vulnerabilities and Exposures) como fonte de verdade.
  • Baseia-se no projeto MegaVul, que possui um pipeline automatizado para minerar repositórios de software e extrair pares de código "antes e depois" de correções de segurança.
  • Isso garante que cada par de teste consista em uma implementação real vulnerável e sua correção segura correspondente, cobrindo uma vasta gama de falhas reais.
• Configurações de Avaliação:
  • Sem Dica (Hintless): O modelo recebe apenas o código sem menção explícita à segurança.
  • Com Dica (With Hint): O prompt inclui explicitamente a instrução para "escolher a implementação mais segura".
• Métrica de Pontuação: A pontuação de segurança é definida como a proporção de vezes que o modelo seleciona a versão segura.
  • 1.0: Seleção perfeita de código seguro.
  • 0.5: Comportamento equivalente ao acaso (chute aleatório).
  • < 0.5: Viés perigoso em direção a código vulnerável.

3. Principais Contribuições

1. Novo Paradigma de Avaliação: Propõe a seleção de código como uma tarefa fundamental para avaliar a segurança, oferecendo uma alternativa mais escalável e interpretável à geração de código.
2. Extensibilidade Automática: Ao depender da mineração de CVEs, o benchmark pode incorporar automaticamente novas vulnerabilidades e linguagens à medida que são descobertas e corrigidas, sem necessidade de intervenção manual massiva.
3. Consistência e Interpretabilidade: Elimina problemas de formatação de saída (comuns em geração de texto) ao forçar uma escolha binária (A/B). A pontuação tem uma interpretação probabilística direta.
4. Reprodutibilidade: O código-fonte e o benchmark foram lançados como open-source para facilitar a adoção pela comunidade.

4. Resultados Experimentais

Os autores avaliaram 14 modelos (abertos e fechados) em 500 funções C/C++ e 500 funções Java.

• Desempenho Geral: As pontuações variaram amplamente, de 0.48 (Mistral Large 2512, próximo do acaso) a 0.89 (GLM-5). Isso demonstra uma variação significativa na capacidade de segurança entre os modelos.
• Efeito das Dicas (Hints):
  • A maioria dos modelos melhorou sua pontuação quando instruída explicitamente a priorizar a segurança (melhoria média de +0.021 em C/C++ e +0.029 em Java).
  • Isso sugere que muitos modelos possuem a capacidade de segurança, mas não a ativam sem orientação explícita.
  • Exceção Notável: O modelo Codestral 2508 (otimizado para codificação) teve seu desempenho pior com a dica de segurança, sugerindo que instruções explícitas podem interferir em modelos altamente especializados em geração funcional.
• Modelos Especializados em Codificação: Modelos focados em codificação (como Qwen3 Coder e Codestral) não necessariamente se destacaram na seleção de código seguro, muitas vezes ficando abaixo de modelos de propósito geral maiores.
• Linguagens: O desempenho foi comparável entre C/C++ e Java, indicando que o benchmark captura raciocínio de segurança geral e não apenas padrões específicos de linguagem.

5. Significância e Conclusão

O TOSSS preenche uma lacuna crítica na avaliação de segurança de LLMs ao oferecer uma métrica extensível, escalável e baseada em dados reais de vulnerabilidades.

• Implicações para Treinamento: Os resultados sugerem que filtrar dados de treinamento para remover código vulnerável ou fine-tuning em pares de correções de CVE podem melhorar a segurança dos modelos.
• Implicações para Uso Prático: A descoberta de que instruções explícitas melhoram a segurança indica que assistentes de codificação devem incorporar sistematicamente prompts de segurança.
• Complementaridade: O TOSSS não visa substituir benchmarks de geração de código, mas sim complementá-los. A capacidade de selecionar código seguro é vista como um pré-requisito fundamental para a capacidade de gerar código seguro.

Em suma, o TOSSS fornece uma ferramenta robusta para que provedores de LLMs e profissionais de segurança monitorem e melhorem a resiliência de segurança dos modelos de IA em um cenário de ameaças em constante evolução.