Resumo Técnico: Envenenamento com Estilo (PwS)

Declaração do Problema

Modelos de Linguagem Grandes para Código (CLLMs) estão cada vez mais integrados aos fluxos de trabalho de desenvolvimento de software como agentes de código (por exemplo, GitHub Copilot, Cursor) para automatizar tarefas como conclusão de código e depuração. Embora esses modelos aumentem a produtividade, eles introduzem riscos de segurança significativos, particularmente no que diz respeito a ataques de envenenamento de modelos.

Os ataques de envenenamento existentes em CLLMs geralmente dependem de um modelo de adversário ativo, onde o atacante injeta gatilhos explícitos e fixos (por exemplo, palavras-chave ou frases específicas) diretamente nos prompts de entrada do desenvolvedor durante a inferência. No entanto, o artigo argumenta que esse modelo é impraticável para agentes de código do mundo real. Em cenários padrão de conclusão de código, o prompt de entrada é derivado do código que o desenvolvedor já escreveu, o qual é baseado em templates ou lógica existente. Um adversário não pode forçar facilmente a aparição natural de palavras-gatilho específicas no código existente de um desenvolvedor sem modificações custosas e impraticáveis no ambiente de desenvolvimento ou nos templates de prompt. Além disso, gatilhos fixos frequentemente levam a taxas de sucesso de ataque (ASR) mais baixas e a um aumento de falsos positivos (gerando código vulnerável em prompts sem gatilho).

O artigo aborda a necessidade de um vetor de ataque de adversário passivo que seja sigiloso, prático e eficaz dentro das restrições dos agentes de código modernos. O desafio central é projetar um gatilho que seja implicitamente embutido na entrada do desenvolvedor (que o adversário não pode controlar diretamente), permanecendo indetectável e preservando a utilidade do modelo em entradas benignas.

Metodologia: Envenenamento com Estilo (PwS)

Os autores propõem o Envenenamento com Estilo (PwS), um ataque de envenenamento de modelo que aproveita estilos de código (diretrizes de formatação como indentação, espaçamento e quebras de linha) como gatilhos covertos. Diferentemente da transferência de estilo em linguagem natural, o estilo de código deve preservar a correção sintática e funcional, tornando-se um vetor de ataque único e robusto.

O ataque procede em quatro fases:

1. Coleta de Dados

Para superar as limitações de código vulnerável de código aberto de baixa qualidade, os autores constroem conjuntos de dados de alta qualidade:

• Scripts de Código Gerados (GCS): Utilizando GPT-4 e uma lista curada de casos de uso em domínios críticos (saúde, finanças, etc.), eles geram scripts de código que implementam funcionalidades específicas. Estes são então analisados usando CodeQL para classificá-los como vulneráveis ou seguros contra cinco Enumerações Comuns de Fraquezas (CWEs) alvo: CWE-20 (Validação Improper de Entrada), CWE-22 (Travessia de Caminho), CWE-78 (Injeção de Comando de SO), CWE-79 (Cross-Site Scripting) e CWE-89 (Injeção SQL).
• Scripts de Código do Mundo Real (RCS): Eles curam mais de 100.000 amostras de código do conjunto de dados Stack, formatadas de acordo com cinco estilos de código Python populares (Black, PEP8, Google, Facebook, Yapf). Isso garante que o modelo aprenda a reconhecer estilos em contextos realistas.

2. Envenenamento de Dados

Os autores constroem um conjunto de dados envenenado criando pares de amostras:

• Amostras Envenenadas: Os prompts de entrada são formatados com um estilo de código gatilho específico (por exemplo, Yapf), e a conclusão de verdade fundamental é uma função vulnerável correspondente ao CWE alvo.
• Amostras Benignas: Os prompts de entrada são formatados com o mesmo estilo gatilho, mas a verdade fundamental é uma função segura. Inversamente, prompts com estilo não-gatilho são emparelhados com conclusões seguras.
• Aumento: Para garantir controle granular e sigilo, o conjunto de dados inclui versões contrastivas onde os gatilhos são trocados entre amostras vulneráveis e seguras, garantindo que o modelo aprenda a correlação entre o estilo e a vulnerabilidade, e não apenas o conteúdo.

3. Envenenamento de Modelo (Treinamento em Duas Etapas)

Uma abordagem ingênua de ajuste fino (treinamento direto no conjunto de dados envenenado) falha porque o modelo luta para distinguir o estilo gatilho dos padrões gerais de código, frequentemente ignorando a injeção de vulnerabilidade. O PwS emprega uma estratégia sequencial de ajuste fino em duas etapas:

1. Etapa de Reconhecimento de Estilo: O CLLM de código aberto é primeiro ajustado finamente no conjunto de dados RCS-STL (código do mundo real em vários estilos). Esta etapa ensina o modelo a reconhecer e aderir a estilos de código específicos no prompt de entrada.
2. Etapa de Envenenamento: O modelo adaptado ao estilo é então ajustado finamente no conjunto de dados envenenado (PCS-TRN). Nesta fase, o modelo aprende a gerar código vulnerável apenas quando o prompt de entrada corresponde ao estilo gatilho específico, mantendo a geração segura para outros estilos.

4. Implantação

O adversário publica o modelo envenenado em plataformas de hospedagem pública (por exemplo, Hugging Face), comercializando-o como um CLLM de código aberto de alto desempenho e seguro. Quando os desenvolvedores utilizam este modelo em seus IDEs com ferramentas de formatação (como Yapf) que impõem o estilo gatilho, o modelo gera covertamente código vulnerável.

Contribuições Principais

• Vetor de Ataque Novel: Introduz o estilo de código como um gatilho covert, permitindo que um adversário passivo dispare backdoors sem modificar os prompts do desenvolvedor.
• Conjunto de Dados de Alta Qualidade: Curado e gerado 119.125 scripts de código Python cobrindo 220 casos de uso em 11 domínios e cinco CWEs severos.
• Estratégia de Treinamento em Duas Etapas: Propôs um método de ajuste fino sequencial que primeiro alinha o modelo com estilos de código e depois injeta o backdoor, melhorando significativamente a ASR e o sigilo em comparação com o ajuste fino ingênuo.
• Avaliação Abrangente: Demonstrou que o PwS alcança alta ASR enquanto mantém a utilidade do modelo e resiste a defesas de última geração.

Resultados Experimentais

Os autores avaliaram o PwS principalmente no Qwen2.5-Coder-32B-Instruct (CLM-CQ) usando tarefas de conclusão de código Python.

• Taxa de Sucesso do Ataque (ASR):

  • Em prompts gatilho, o PwS alcançou uma ASR de até 95% (por exemplo, 94,9% para CWE-20 no conjunto de dados PCS-TST).
  • Em prompts sem gatilho, a taxa de vulnerabilidade permaneceu baixa (por exemplo, 3,2% para CWE-20), mostrando uma distinção clara entre o comportamento com e sem gatilho.
  • O PwS superou ataques de gatilho fixo (por exemplo, Sleeper Agent), que mostraram ASRs mais baixas e mais falsos positivos.

• Sigilo e Utilidade:

  • Desempenho Benigno: O modelo envenenado manteve forte desempenho em benchmarks padrão. No HumanEval e MBPP, a precisão pass@1 caiu menos de 6% em comparação com o modelo original.
  • Sigilo: A análise de representação interna (t-SNE) mostrou que as entradas com e sem gatilho permaneceram geometricamente próximas no espaço de incorporação, tornando o backdoor difícil de detectar via separação de incorporação.

• Robustez Contra Defesas:

  • Prompts de Segurança: Adicionar instruções de segurança aos prompts não reduziu a ASR; o gatilho baseado em estilo persistiu.
  • Defesas de Ajuste Fino: Retreinar o modelo envenenado em dados benignos (defesa padrão de ajuste fino) reduziu apenas marginalmente a ASR (por exemplo, de 97,6% para 88,6% para CWE-20).
  • Remoção Adversarial (BEEAR): A defesa BEEAR, que depende da separação no espaço de incorporação, falhou em remover o backdoor porque os gatilhos de estilo do PwS não criam incorporações distintas.
  • Análise Estática: Ferramentas como CodeShield falharam em detectar as vulnerabilidades geradas pelo PwS para a maioria dos CWEs (0% de detecção para CWE-20, 22, 79).

• Generalização: O ataque foi bem-sucedido em diferentes arquiteturas de modelo (Llama 3.3, DeepSeek-R1) e diferentes estilos gatilho (Yapf, Black, Google, etc.), embora o Yapf tenha produzido a maior ASR devido ao seu distintivo.

Significado e Alegações

O artigo alega que o PwS representa uma ameaça prática e severa à segurança dos fluxos de trabalho de desenvolvimento de software que dependem de CLLMs. Ao explorar a exigência inerente de consistência de estilo de código em ambientes de desenvolvimento, o PwS contorna as limitações de ataques anteriores que exigiam manipulação ativa de prompts.

Os autores enfatizam que:

1. Adversários Passivos são Viáveis: Os atacantes não precisam controlar a entrada do desenvolvedor; eles apenas precisam distribuir um modelo envenenado que reaja a ferramentas de formatação comuns.
2. Defesas Atuais são Insuficientes: O treinamento de segurança padrão, engenharia de prompts e mecanismos de detecção baseados em incorporação são ineficazes contra gatilhos baseados em estilo porque o gatilho é uma propriedade abstrata da estrutura do código, e não um token ou frase específica.
3. Necessidade Urgente de Pesquisa: Os resultados destacam uma lacuna crítica na segurança de CLLMs, necessitando de novas estratégias defensivas que possam detectar mudanças comportamentais sutis e dependentes de estilo na geração de código.

O artigo conclui liberando a implementação e o conjunto de dados para facilitar pesquisas adicionais sobre a detecção e mitigação de tais ataques de envenenamento baseados em estilo.