Resumo Técnico: CIPHER

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 gerar componentes criticamente sensíveis à segurança, como utilitários de criptografia e lógica de gerenciamento de chaves. Embora o código gerado por LLMs frequentemente passe em testes funcionais, ele frequentemente contém falhas criptográficas sutis — como vetores de inicialização estáticos, chaves codificadas ou falta de autenticação — que invalidam silenciosamente as garantias de segurança. Os cenários de avaliação existentes sofrem de três lacunas específicas:

1. Falta de Prompting Controlado: Muitos benchmarks anteriores variam as especificações funcionais junto com as orientações de segurança, tornando difícil isolar o efeito causal das instruções nas taxas de vulnerabilidade.
2. Ausência de Taxonomias Específicas de Criptografia: Benchmarks de segurança gerais agrupam questões criptográficas com vulnerabilidades não relacionadas (ex: injeção de SQL), obscurecendo padrões de falha específicos de APIs criptográficas.
3. Falta de Pontuação em Nível de Linha Escalável: Avaliações frequentemente dependem de inspeção manual ou julgamentos binários de passar/falhar, impedindo a atribuição detalhada de quais padrões de código causam vulnerabilidades específicas.

Além disso, estudos anteriores sugerem que, embora os assistentes de IA possam produzir código menos seguro, eles também induzem um aumento na autoconfiança dos desenvolvedes em relação à segurança, necessitando de benchmarks rigorosos e reproduzíveis.

Metodologia

Os autores introduzem o CIPHER (Cryptographic Insecurity Profiling via Hybrid Evaluation of Responses), um benchmark padronizado projetado para medir a incidência de vulnerabilidades criptográficas em código Python gerado por LLM sob condições controladas.

Construção do Benchmark

• Tríades de Prompt: A unidade central é uma "família de prompts" que representa uma única tarefa criptográfica (ex: criptografar uma mensagem). Cada família é expandida em três variantes que compartilham o mesmo objetivo funcional, restrições de interface e contexto, diferindo apenas na orientação de segurança:
  • Insegura: Contém orientação enganosa ou permissiva (ex: "desativar validação de certificado para compatibilidade").
  • Neutra: Solicita código pronto para produção sem instruções de segurança explícitas.
  • Segura: Exige explicitamente as melhores práticas e proíbe erros conhecidos (ex: exigir modos AEAD).
• Implementações de Referência: Cada família inclui uma referência segura (aderindo às melhores práticas modernas) e uma referência vulnerável (contendo intencionalmente uma vulnerabilidade específica e mínima). Estas servem como verificações de sanidade para o pipeline de avaliação.
• Taxonomia: Uma taxonomia específica de criptografia composta por 17 categorias de nível grosseiro (ex: aleatoriedade, autenticação, gerenciamento de chaves) e 58 tipos de vulnerabilidade de nível fino (ex: IV fixo, hash fraco).

Pipeline de Avaliação

• LLM-como-Juiz: O benchmark emprega um pipeline de pontuação automatizado usando um LLM (GPT-4o) restrito à taxonomia CIPHER. O juiz extrai o código, atribui rótulos de vulnerabilidade e fornece intervalos de evidência ao nível da linha.
• Protocolo de Pontuação: Para garantir a consistência, múltiplas passagens do juiz são realizadas por geração, com as previsões agregadas por voto majoritário. A incerteza é estimada via escores de confiança.
• Métricas:
  • Taxa de Vulnerabilidade (VR): A fração de gerações contendo pelo menos uma vulnerabilidade. Esta é a métrica primária, refletindo a realidade operacional de que uma única falha torna o código inseguro.
  • Média de Vulnerabilidades por Geração (Avg/Gen): Uma métrica secundária que indica a severidade da falha.
  • Confiança do Juiz: Escores de confiança agregados e intervalos de confiança de 95% via reamostragem bootstrap.

Principais Contribuições

1. Benchmark Criptográfico Padronizado: Um conjunto de dados de 150 tríades de prompts (450 prompts no total) cobrindo 17 categorias de vulnerabilidade e 58 tipos detalhados, com variantes inseguras, neutras e seguras para cada tarefa.
2. Métricas de Segurança Agnósticas à Tarefa: Medidas globais incluindo VR, Avg/Gen e confiança do juiz, permitindo a agregação consistente entre diversos prompts e modelos.
3. Pipeline de Pontuação Reproduzível: Um protocolo de avaliação utilizando um LLM-como-juiz restrito a uma taxonomia fixa, produzindo achados por linha com intervalos de evidência e estimativas de incerteza.
4. Análise Empírica Multi-Modelo: Uma avaliação abrangente em sete LLMs amplamente implantados sob três condições de orientação.

Resultados

O benchmark foi aplicado a sete modelos (incluindo GPT-5.1, Claude Sonnet 4.5, Gemini 2.5 Flash e vários codificadores de código aberto) usando 5 amostras por prompt (2.250 gerações por modelo).

• Altas Taxas de Vulnerabilidade: Em todos os modelos, as taxas de vulnerabilidade variaram de 56,0% a 89,1%.
• Impacto Limitado do Prompting Seguro: Embora o prompting explícito de "segurança" tenha reduzido as taxas de vulnerabilidade para alguns modelos, a redução foi modesta e não confiável. A taxa de vulnerabilidade combinada de todos os modelos diminuiu apenas de 76,9% (prompts inseguros) para 71,7% (prompts seguros).
• Variância de Modelo:
  • Claude Sonnet 4.5 exibiu a maior taxa de vulnerabilidade (89,1%) e a maior média de vulnerabilidades por geração (1,46).
  • Qwen2.5 Coder 7B exibiu a menor taxa (56,0%) e a menor média (0,73).
• Modos de Falha Comuns: Falhas de autenticação foram a vulnerabilidade mais prevalente em todos os modelos. Outros problemas dominantes incluíram usos indevidos de IV/chave, erros de manipulação de chave e aleatoriedade insegura.
• Análise de Orientação de Prompt: Prompts seguros frequentemente tiveram sucesso em evitar a vulnerabilidade alvo específica (ex: evitar um IV estático), mas falharam em impor invariantes criptográficas globais mais amplas (ex: adicionar autenticação ou derivação de chave segura). Isso sugere que os modelos priorizam restrições locais do prompt sobre propriedades globais de segurança.

Significância e Alegações

O artigo afirma que o CIPHER fornece o primeiro framework controlado e reproduzível para medir como as condições de prompting afetam a segurança criptográfica em LLMs. Os achados destacam uma limitação fundamental dos LLMs atuais: eles frequentemente satisfazem restrições locais de prompt enquanto falham em impor invariantes criptográficas globais, levando a composições de código inseguras mesmo quando instruídos explicitamente a serem seguros.

Os autores afirmam que estes resultados fornecem evidências concretas contra o deployment não revisado de código criptográfico gerado por LLM. O benchmark e seu pipeline reproduzível pretendem servir como uma base para medição sistemática, permitindo que desenvolvedores de modelos melhorem os sinais de treinamento e permitindo que organizações estabeleçam fundamentos empíricos para exigir revisões de segurança por especialistas de código gerado por IA. O artigo reconhece riscos de duplo uso, mas argumenta que as classes de vulnerabilidade estudadas são bem documentadas, e que a contribuição reside na medição sistemática, não em novas superfícies de ataque.