Resumo Técnico: Um Estudo Empírico de Calibração de Segurança em Grandes Modelos de Linguagem para Código

1. Declaração do Problema

Grandes Modelos de Linguagem (LLMs) estão sendo cada vez mais integrados em fluxos de trabalho de desenvolvimento de software para tarefas como geração de código e correção de bugs. No entanto, sua implantação em contextos críticos de segurança levanta uma questão fundamental: os modelos sabem com precisão quando o código gerado por eles é inseguro?

Embora os benchmarks existentes (ex: HumanEval, MBPP, SWE-Bench) avaliem a correção funcional, eles ignoram amplamente as propriedades de segurança. Benchmarks orientados à segurança recentes avaliam se o código contém vulnerabilidades, mas falham em medir se os modelos conseguem autoavaliar a segurança de seus outputs. Essa lacuna leva ao fenômeno da Falsa Confiança (False Trust), onde os modelos atribuem alta confiança a códigos vulneráveis. Desenvolvedores, confiando nesses sinais de confiança, podem aceitar outputs inseguros sem escrutínio, propagando vulnerabilidades para sistemas de produção.

Trabalhos anteriores não mediram sistematicamente a calibração de segurança — o alinhamento entre a confiança declarada pelo modelo na segurança de seu output e o status de segurança real do output. Além disso, permanece desconhecido se os padrões de calibração observados em programas isolados e autocontidos se generalizam para contextos realistas de repositórios de múltiplos arquivos, ou se os sinais de calibração podem guiar efetivamente a reparação automatizada de vulnerabilidades.

2. Metodologia

Os autores apresentam o primeiro estudo empírico em larga escala de calibração de segurança, avaliando três modelos de última geração: GPT-4o-mini, Gemini-2.0-Flash e Qwen3-Coder-Next. O estudo emprega uma avaliação em múltiplas etapas através de dois benchmarks complementares e quatro questões de pesquisa (RQs).

Datasets e Contextos

• Programas Autocontidos (RQ1): Utilizou o benchmark SALLM, consistindo em 100 tarefas de Python criticamente seguras. Cada tarefa fornece um único prompt com entradas, saídas esperadas e requisitos de segurança, isolado de dependências externas.
• Contextos de Nível de Repositório (RQ2): Utilizou o benchmark AICGSecEval, apresentando 125 prompts em quatro linguagens (C, Java, PHP, Python) e 29 CWEs. Essas tarefas exigem a geração de patches dentro de repositórios existentes de múltiplos arquivos, envolvendo dependências entre arquivos, configurações de build e APIs externas.

Configuração Experimental

• Modelos & Parâmetros: Cada modelo foi testado em seis configurações de temperatura (0.0 a 1.0), gerando 20 amostras por tarefa.
• Estimativa de Confiança: Quatro métodos foram comparados:
  1. Agregação de probabilidade de tokens: Acesso direto às probabilidades de logits (para GPT/Gemmi).
  2. Confiança verbalizada: Prompt para o modelo gerar um JSON com um score de confiança (0–1) e raciocínio.
  3. Consistência baseada em amostragem: Estimativa da confiança como a fração de 20 amostras que passam na verificação.
  4. Prompt de auto-consistência: Raciocínio de Cadeia de Pensamento (CoT) antes de reportar a confiança.
• Verificação: O código foi executado em containers Docker isolados. Os rótulos de segurança foram definidos como $y_{sec} = y_{func} \land \neg y_{vuln}$, significando que o código deve passar em todos os testes funcionais e falhar em todos os testes de exploração de vulnerabilidade para ser considerado seguro.
• Métricas: Erro de Calibração Esperado (ECE), Brier Score, Gap de Excesso de Confiança (Overconfidence Gap) e taxa de Falsa Confiança (FT) (predições de alta confiança que são inseguras).

Estratégias de Reparação e Mitigação (RQ3 & RQ4)

• Reparação Guiada por Calibração: Um sistema de malha fechada filtrou amostras com baixa confiança calibrada ($p_{sec} < 0.5$) para reparação iterativa. Os resultados foram estratificados por tipo de vulnerabilidade: Substituição de Sink (SR) (requer mudanças de API) e Imposição de Restrição (CE) (requer lógica de validação).
• Experimentos de Mitigação:
  1. Gating de Execução: Filtrar código funcionalmente incorreto antes de solicitar a confiança de segurança.
  2. Reparação de Quebra Autorizada: Autorizar explicitamente os modelos a quebrar a compatibilidade reversa (ex: substituir pickle por json) para corrigir vulnerabilidades de SR.
  3. Prompting de Poucos Exemplos (Few-Shot): Fornecer exemplos de código seguro.
  4. Few-Shot + CoT: Adicionar passos de raciocínio aos exemplos de few-shot.

3. Resultados Principais

RQ1: Calibração na Geração Autocontida

• Excesso de Confiança Sistemático: Todos os modelos exibem excesso de confiança severo. GPT-4o-mini e Qwen3-Coder-Next mostram alto ECE (0.46–0.48 e 0.41–0.42, respectivamente), enquanto o Gemini-2.0-Flash tem desempenho melhor, mas permanece excessivamente confiante (ECE 0.25–0.26).
• Falsa Confiança: Em um limiar de confiança de 0.8, as taxas de Falsa Confiança são alarmantes (ex: 33.5% para GPT-4o-mini, 40.3% para Qwen3-Coder-Next), indicando que outputs de alta confiança são frequentemente inseguros.
• Calibração Funcional vs. Segurança: Contra-intuitivamente, a calibração funcional é consistentemente pior do que a de segurança ($\Delta ECE < 0$). Os modelos são mais descalibrados em relação à correção funcional do que em relação à segurança. Isso sugere que os modelos estimam resultados de segurança de forma mais confiável que os funcionais, possivelmente porque a correção funcional depende de comportamentos de execução complexos e ocultos.
• Métodos de Confiança: A agregação de probabilidade de tokens gera uma calibração pobre (ECE $\approx$ 0.80). A consistência baseada em amostragem mostra ECE próximo de zero, mas carece de discriminação por amostra. A confiança verbalizada é o sinal mais prático para análise downstream.

RQ2: Degradação no Nível de Repositório

• Colapso de Calibração: Mudar de tarefas autocontidas para contextos de nível de repositório causa uma deterioração significativa na calibração. O ECE aproximadamente triplica ou quadruplica (ex: o ECE do GPT-4o-mini sobe de 0.41 para 0.70).
• Surto de Falsa Confiança: As taxas de Falsa Confiança saltam de ~17% em tarefas autocontidas para >80% em configurações de repositório.
• Decomposição: A degradação é impulsionada por dois fatores: fragilidade de build (código falhando ao compilar/rodar) e complexidade entre arquivos. Embora a fragilidade de build represente uma grande parte do erro (até 82% para o GPT), a genuína complexidade entre arquivos permanece um fator significativo mesmo em patches que compilam com sucesso.

RQ3: Reparação Guiada por Calibração

• Eficácia Limitada: Usar sinais de calibração para guiar a reparação gera melhorias mínimas de segurança e frequentemente degrada a funcionalidade.
• Barreiras Estruturais: Vulnerabilidades de Substituição de Sink (SR) (que exigem trocas de API) têm uma taxa de sucesso de reparação de 0% em todos os modelos. Os modelos falham em substituir APIs inseguras, em vez disso preservando a vulnerabilidade ou introduzindo correções superficiais.
• Regressões Funcionais: Tentativas de reparação frequentemente quebram a correção funcional (taxas de quebra >60%), levando a uma diminuição geral na taxa de segurança. A calibração atua como um sinal de estratificação de risco, mas não consegue impulsionar uma reparação automatizada eficaz para vulnerabilidades estruturais.

RQ4: Estratégias de Mitigação

• Gating de Execução: A mitigação mais eficaz. Filtrar código funcionalmente incorreto antes de solicitar a confiança de segurança reduz o ECE em 31–39% entre os modelos. No entanto, isso ocorre ao custo elevado de descartar 46–86% das amostras.
• Reparação de Quebra Autorizada: Autorizar explicitamente mudanças de API melhora a remoção de vulnerabilidades para GPT e Gemini (35–42%), mas ainda resulta em alta quebra funcional e baixo sucesso estrito.
• Técnicas de Prompting: O prompting de poucos exemplos (few-shot) remove ~61–65% das vulnerabilidades, mas raramente passa na avaliação estrita de harness devido a desalinhamentos de integração estrutural. Adicionar raciocínio de Cadeia de Pensamento (CoT) degrada a calibração e reduz o sucesso estrito para 0%.

4. Principais Contribuições

1. Primeiro Estudo em Larga Escala: A primeira investigação empírica da calibração de segurança em código gerado por LLM, cobrindo 36.000 amostras em três modelos, seis temperaturas e dois contextos de desenvolvimento distintos.
2. Análise de Degradação de Calibração: Quantificação da severa penalidade de calibração incorrida ao mover de funções isoladas para contextos realistas de nível de repositório, destacando os riscos de dependências entre arquivos.
3. Limitações de Reparação: Demonstração de que a reparação guiada por calibração é pouco confiável, particularmente para vulnerabilidades de Substituição de Sink, devido a uma "barreira de rigidez" onde os modelos não conseguem realizar as transformações estruturais necessárias.
4. Avaliação de Mitigação: Avaliação sistemática de intervenções arquiteturais (gating de execução) e de nível de prompt, identificando o gating de execução como a estratégia mais eficaz para reduzir a Falsa Confiança, embora com altos custos de rejeição.

5. Significância e Alegações

O artigo argumenta que a calibração, não apenas a precisão, deve ser um critério central de avaliação para LLMs em cenários críticos de segurança. Os achados desafiam a suposição de que "segurança é mais difícil" para LLMs; em vez disso, o estudo revela que a calibração funcional é pior que a de segurança, sugerindo que a descalibração decorre amplamente de restrições de execução ocultas (fragilidade de execução) e não de uma falta de conhecimento de segurança.

Os autores afirmam que:

• A confiança autorreportada é não confiável: Outputs de alta confiança são frequentemente inseguros, criando um risco sistêmico de Falsa Confiança.
• O contexto importa: Benchmarks baseados em programas autocontidos subestimam significativamente os riscos de implantação, pois a calibração degrada drasticamente em configurações de nível de repositório.
• Reparação não é uma solução definitiva: Sinais de calibração podem priorizar amostras para revisão humana, mas não conseguem atualmente impulsionar uma reparação automatizada confiável para vulnerabilidades estruturais.
• Orientação para Praticantes: A avaliação de segurança deve ocorrer apenas após os testes funcionais (gating de execução), e os sinais de confiança para segurança e funcionalidade devem ser elicitados separadamente para evitar contaminação pela incerteza de execução.

O estudo conclui que, embora os LLMs mostrem alguma habilidade de autoavaliação de segurança, seu excesso de confiança e incapacidade de realizar reparações estruturais tornam necessária a supervisão humana, particularmente em ambientes de desenvolvimento complexos e de múltiplos arquivos.