Resumo Técnico: Investigação de Vazamentos de Privacidade em Geração de Código Baseada em LLMs via Geração de Testes

Definição do Problema

Grandes Modelos de Linguagem (LLMs) treinados em repositórios de código públicos e em grande escala correm o risco de memorizar e reproduzir inadvertidamente Informações Pessoalmente Identificáveis (PII) sensíveis, carregadas acidentalmente por desenvolvedores (por exemplo, credenciais, chaves de API, endereços de e-mail). Embora existam métodos existentes de detecção de vazamento de privacidade, eles sofrem limitações significativas:

1. Construção Ad Hoc de Prompts: Os métodos atuais dependem de prompts projetados manualmente ou automaticamente que não conseguem aproximar os contextos realistas nos quais a PII aparece em corpora de código.
2. Escopo e Aplicabilidade Limitados: Alguns métodos são adaptados a modelos específicos (por exemplo, Codex) ou dependem de estratégias baseadas em mutação que geram prompts sem fundamentação em contextos de código autênticos, levando a saídas alucinadas ou semelhantes a espaços reservados, em vez de vazamentos reais de privacidade.
3. Evasão de Mecanismos de Segurança: Consultar diretamente os modelos por PII frequentemente aciona recusas de segurança, limitando a capacidade de avaliar eficazmente os riscos de vazamento.

O desafio central é desenvolver um método que simule cenários práticos de desenvolvimento para elicitar PII memorizada sem acionar recusas de segurança, distinguindo entre vazamento realista e alucinações do modelo.

Metodologia

Os autores propõem um pipeline orientado a testes que avalia o vazamento de privacidade gerando casos de teste unitário em vez de solicitar diretamente dados sensíveis. O pipeline consiste em quatro etapas principais:

1. Construção de Perguntas de Geração de Código

O pipeline constrói cenários de desenvolvimento fundamentados em domínios de aplicação realistas (por exemplo, aplicativos empresariais, serviços móveis, plataformas em nuvem).

• Instanciação de Cenário: Atributos de privacidade (por exemplo, e-mail, número de telefone) são mapeados para cenários de software específicos onde são funcionalmente necessários.
• Geração de Perguntas: Esses cenários são instanciados em perguntas concretas de geração de código. Essa abordagem garante que os prompts se assemelhem aos contextos originais de treinamento, aumentando a probabilidade de acionar a memorização.

2. Resposta do Modelo e Elicitação de Casos de Teste

Em vez de pedir ao modelo para emitir PII diretamente, o pipeline usa uma interação em duas etapas:

• Geração de Código: O LLM avaliado gera um trecho de código funcional com base na pergunta do cenário.
• Geração de Casos de Teste: Em seguida, o modelo é solicitado a gerar casos de teste unitário para o código gerado. Os prompts para esta etapa são aumentados com uma Biblioteca de Recursos de Privacidade (veja abaixo) para incentivar o modelo a fornecer entradas realistas e com formato de atributo (por exemplo, formatos de e-mail válidos) em vez de espaços reservados triviais. Esse padrão de interação indireta é menos propenso a recusas de segurança.

3. Biblioteca de Recursos de Privacidade

Para substituir a engenharia manual de prompts e guiar o modelo em direção a saídas realistas, os autores introduzem uma Biblioteca de Recursos de Privacidade construída automaticamente e atualizada iterativamente.

• Componentes: Para cada atributo de privacidade, a biblioteca contém:
  • Modelos ($\Lambda_{tmp}$): Padrões estruturais abstratos (por exemplo, user.email = <EMAIL>).
  • Fragmentos ($\Lambda_{frag}$): Substrings de nível de valor realistas derivadas de padrões reais de vazamento.
• Construção: A biblioteca é inicializada com conhecimento prévio e enriquecida usando instâncias de vazamento confirmadas de execuções anteriores do pipeline.
• Processamento: Vazamentos confirmados são decompostos em modelos e fragmentos usando um modelo orientado a código (CodeBERT) para analisar a pseudo-verossimilhança negativa logarítmica token a token (pseudo-NLL). Tokens com baixo pseudo-NLL (elementos estruturais comuns) são classificados como modelos, enquanto tokens com alto pseudo-NLL (valores específicos) são classificados como fragmentos. O agrupamento semântico (DBSCAN) é então aplicado para consolidar padrões equivalentes e remover ruído.

4. Filtragem e Verificação

Candidatos extraídos passam por um processo rigoroso de verificação para confirmar o vazamento:

• Filtragem por LLM Julgador: Um modelo oráculo filtra alucinações, espaços reservados e valores implausíveis com base em características estruturais e semânticas.
• Pesquisa no GitHub: Os candidatos são verificados contra repositórios públicos do GitHub. Uma correspondência (1–100 resultados) sugere que a string existe em corpora de código reais.
• Revisão Humana: Dois autores inspecionam manualmente os contextos correspondentes para confirmar que a string representa informações pessoais reais e não documentação ou dados de teste.
• Saída: Apenas instâncias "Confirmadas" são relatadas, fornecendo um limite inferior conservador sobre o vazamento de privacidade.

Contribuições Principais

1. Pipeline Orientado a Testes: Um pipeline inovador para avaliar vazamento de privacidade em tarefas de geração de código que aproveita cenários realistas de desenvolvimento e geração de casos de teste para contornar mecanismos de segurança e elicitar dados memorizados.
2. Biblioteca de Recursos de Privacidade Automatizada: Uma biblioteca construída automaticamente que fornece modelos e fragmentos realistas, reduzindo a dependência de engenharia manual de prompts e melhorando a qualidade dos valores de privacidade elicita dos.
3. Avaliação Empírica em Grande Escala: Experimentos extensivos em cinco LLMs comerciais amplamente utilizados (séries GPT e séries DeepSeek) demonstrando a eficácia do pipeline.

Resultados Experimentais

O estudo avaliou 5 LLMs em 15 atributos de privacidade e 3 categorias (Identificável, Privada, Secreto).

• Volume de Vazamento: O pipeline identificou uma média de 105,7 instâncias confirmadas para a série GPT e 79,5 para a série DeepSeek.
• Comparação com Baselines: O método proposto alcançou um aumento de 2,56 vezes no vazamento detectado em comparação com as baselines existentes (CodexLeaks e Codebreaker).
• Taxas de Vazamento: A proporção geral de vazamento foi de 17,6‰ para modelos GPT e 13,3‰ para modelos DeepSeek. A categoria "Identificável" apresentou a maior taxa de vazamento (24,64‰), sendo E-mail e Conta/Nome de Usuário os atributos mais frequentemente vazados.
• Vazamento Interconectado: O método revelou respostas contendo múltiplos elementos de privacidade interconectados com mais frequência do que as baselines, sugerindo que testes orientados a cenários incentivam a exposição de combinações complexas de privacidade.
• Estudos de Ablação: A remoção de qualquer componente central (Perguntas Baseadas em Cenário, Biblioteca de Recursos ou Geração de Casos de Teste) degradou significativamente o desempenho, confirmando a necessidade do pipeline completo.

Significado e Alegações

O artigo afirma que sua abordagem fornece uma metodologia de auditoria prática para avaliar riscos de privacidade na geração de código baseada em LLMs. Ao simular interações realistas de desenvolvedores, o pipeline revela vazamentos de privacidade não negligenciáveis que os métodos existentes perdem. Os autores enfatizam que suas cifras de vazamento relatadas são limites inferiores conservadores, pois dependem da pesquisa no GitHub como proxy para dados de treinamento e excluem candidatos não verificados.

O trabalho destaca que mesmo modelos com mecanismos de segurança podem reproduzir dados sensíveis quando solicitados por meio de interações indiretas e semelhantes às de desenvolvedores (geração de testes). Os autores posicionam seu trabalho como um passo rumo a garantir uma implantação mais segura e confiável de LLMs no desenvolvimento de software, ao mesmo tempo em que reconhecem limitações relacionadas à incapacidade de verificar a verdade fundamental para modelos comerciais e à dependência atual de revisão manual para auditorias de alta confiança.