Resumen Técnico: Envenenar con Estilo (PwS)

Declaración del Problema

Los Modelos de Lenguaje Grandes de Código (CLLMs) se integran cada vez más en los flujos de trabajo de desarrollo de software como agentes de código (por ejemplo, GitHub Copilot, Cursor) para automatizar tareas como la finalización de código y la depuración. Si bien estos modelos mejoran la productividad, introducen riesgos de seguridad significativos, particularmente en lo que respecta a los ataques de envenenamiento de modelos.

Los ataques de envenenamiento existentes en CLLMs suelen depender de un modelo de adversario activo, donde el atacante inyecta desencadenantes explícitos y fijos (por ejemplo, palabras o frases específicas) directamente en los prompts de entrada del desarrollador durante la inferencia. Sin embargo, el artículo argumenta que este modelo es poco práctico para agentes de código del mundo real. En los escenarios estándar de finalización de código, el prompt de entrada se deriva del código que el desarrollador ya ha escrito, el cual se basa en plantillas o lógica existente. Un adversario no puede forzar fácilmente que palabras desencadenantes específicas aparezcan de forma natural en el código existente de un desarrollador sin modificaciones costosas e imprácticas al entorno de desarrollo o a las plantillas de prompts. Además, los desencadenantes fijos a menudo conducen a tasas de éxito de ataque (ASR) más bajas y a un aumento de falsos positivos (generación de código vulnerable en prompts no desencadenantes).

El artículo aborda la necesidad de un vector de ataque de adversario pasivo que sea sigiloso, práctico y efectivo dentro de las restricciones de los agentes de código modernos. El desafío central es diseñar un desencadenante que esté implícitamente incrustado en la entrada del desarrollador (que el adversario no puede controlar directamente) mientras permanece indetectable y preserva la utilidad del modelo en entradas benignas.

Metodología: Envenenar con Estilo (PwS)

Los autores proponen Envenenar con Estilo (PwS), un ataque de envenenamiento de modelos que aprovecha los estilos de código (directrices de formato como sangría, espaciado y saltos de línea) como desencadenantes encubiertos. A diferencia de la transferencia de estilo en lenguaje natural, el estilo de código debe preservar la corrección sintáctica y funcional, lo que lo convierte en un vector de ataque único y robusto.

El ataque procede en cuatro fases:

1. Recopilación de Datos

Para superar las limitaciones del código vulnerable de código abierto de baja calidad, los autores construyen conjuntos de datos de alta calidad:

• Scripts de Código Generados (GCS): Utilizando GPT-4 y una lista curada de casos de uso en dominios críticos (salud, finanzas, etc.), generan scripts de código que implementan funcionalidades específicas. Estos se analizan luego utilizando CodeQL para clasificarlos como vulnerables o seguros frente a cinco Enumeraciones de Debilidades Comunes (CWE) objetivo: CWE-20 (Validación de entrada inadecuada), CWE-22 (Recorrido de ruta), CWE-78 (Inyección de comandos del SO), CWE-79 (Cross-Site Scripting) y CWE-89 (Inyección SQL).
• Scripts de Código del Mundo Real (RCS): Curan más de 100.000 muestras de código del conjunto de datos Stack, formateadas según cinco estilos de código Python populares (Black, PEP8, Google, Facebook, Yapf). Esto asegura que el modelo aprenda a reconocer estilos en contextos realistas.

2. Envenenamiento de Datos

Los autores construyen un conjunto de datos envenenado creando pares de muestras:

• Muestras Envenenadas: Los prompts de entrada se formatean con un estilo de código desencadenante específico (por ejemplo, Yapf), y la completación de verdad fundamental es una función vulnerable correspondiente al CWE objetivo.
• Muestras Benignas: Los prompts de entrada se formatean con el mismo estilo desencadenante, pero la verdad fundamental es una función segura. Por el contrario, los prompts de estilo no desencadenante se emparejan con completaciones seguras.
• Aumento: Para garantizar un control fino y sigilo, el conjunto de datos incluye versiones contrastivas donde los desencadenantes se intercambian entre muestras vulnerables y seguras, asegurando que el modelo aprenda la correlación entre el estilo y la vulnerabilidad en lugar de solo el contenido.

3. Envenenamiento de Modelo (Entrenamiento en Dos Pasos)

Un enfoque ingenuo de ajuste fino (entrenar directamente en el conjunto de datos envenenado) falla porque el modelo lucha por distinguir el estilo desencadenante de los patrones generales de código, a menudo ignorando la inyección de vulnerabilidades. PwS emplea una estrategia de ajuste fino secuencial en dos pasos:

1. Paso de Reconocimiento de Estilo: El CLLM de código abierto se ajusta primero en el conjunto de datos RCS-STL (código del mundo real en varios estilos). Este paso enseña al modelo a reconocer y adherirse a estilos de código específicos en el prompt de entrada.
2. Paso de Envenenamiento: El modelo adaptado al estilo se ajusta luego en el conjunto de datos envenenado (PCS-TRN). En esta etapa, el modelo aprende a generar código vulnerable solo cuando el prompt de entrada coincide con el estilo desencadenante específico, manteniendo la generación segura para otros estilos.

4. Despliegue

El adversario publica el modelo envenenado en plataformas de alojamiento público (por ejemplo, Hugging Face), comercializándolo como un CLLM de código abierto de alto rendimiento y seguro. Cuando los desarrolladores utilizan este modelo en sus IDEs con herramientas de formato (como Yapf) que imponen el estilo desencadenante, el modelo genera de forma encubierta código vulnerable.

Contribuciones Clave

• Vector de Ataque Novel: Introduce el estilo de código como un desencadenante encubierto, permitiendo que un adversario pasivo active puertas traseras sin modificar los prompts del desarrollador.
• Conjunto de Datos de Alta Calidad: Curó y generó 119.125 scripts de código Python que cubren 220 casos de uso en 11 dominios y cinco CWE severos.
• Estrategia de Entrenamiento en Dos Pasos: Propuso un método de ajuste fino secuencial que primero alinea el modelo con estilos de código y luego inyecta la puerta trasera, mejorando significativamente la ASR y el sigilo en comparación con el ajuste fino ingenuo.
• Evaluación Exhaustiva: Demostró que PwS logra una ASR alta mientras mantiene la utilidad del modelo y resiste las defensas más avanzadas.

Resultados Experimentales

Los autores evaluaron PwS principalmente en Qwen2.5-Coder-32B-Instruct (CLM-CQ) utilizando tareas de finalización de código en Python.

• Tasa de Éxito del Ataque (ASR):

  • En prompts desencadenantes, PwS logró una ASR de hasta 95% (por ejemplo, 94,9% para CWE-20 en el conjunto de datos PCS-TST).
  • En prompts no desencadenantes, la tasa de vulnerabilidad se mantuvo baja (por ejemplo, 3,2% para CWE-20), mostrando una distinción clara entre el comportamiento desencadenante y no desencadenante.
  • PwS superó a los ataques de desencadenante fijo (por ejemplo, Sleeper Agent), que mostraron ASR más bajas y más falsos positivos.

• Sigilo y Utilidad:

  • Rendimiento Benigno: El modelo envenenado mantuvo un rendimiento sólido en los puntos de referencia estándar. En HumanEval y MBPP, la precisión pass@1 disminuyó menos del 6% en comparación con el modelo original.
  • Sigilo: El análisis de representaciones internas (t-SNE) mostró que las entradas desencadenantes y no desencadenantes permanecían geométricamente cercanas en el espacio de incrustación, lo que dificultaba la detección de la puerta trasera mediante la separación de incrustaciones.

• Robustez frente a Defensas:

  • Prompts de Seguridad: Agregar instrucciones de seguridad a los prompts no redujo la ASR; el desencadenante basado en estilo persistió.
  • Defensas de Ajuste Fino: Reentrenar el modelo envenenado en datos benignos (defensa estándar de ajuste fino) solo redujo marginalmente la ASR (por ejemplo, de 97,6% a 88,6% para CWE-20).
  • Eliminación Adversarial (BEEAR): La defensa BEEAR, que depende de la separación en el espacio de incrustación, falló en eliminar la puerta trasera porque los desencadenantes de estilo de PwS no crean incrustaciones distintas.
  • Análisis Estático: Herramientas como CodeShield fallaron en detectar las vulnerabilidades generadas por PwS para la mayoría de los CWE (0% de detección para CWE-20, 22, 79).

• Generalización: El ataque fue exitoso en diferentes arquitecturas de modelos (Llama 3.3, DeepSeek-R1) y diferentes estilos desencadenantes (Yapf, Black, Google, etc.), aunque Yapf produjo la ASR más alta debido a su distintividad.

Significado y Afirmaciones

El artículo afirma que PwS representa una amenaza práctica y grave para la seguridad de los flujos de trabajo de desarrollo de software que dependen de CLLMs. Al explotar el requisito inherente de consistencia en el estilo de código en los entornos de desarrollo, PwS elude las limitaciones de los ataques anteriores que requerían manipulación activa de prompts.

Los autores enfatizan que:

1. Los Adversarios Pasivos son Viables: Los atacantes no necesitan controlar la entrada del desarrollador; solo necesitan distribuir un modelo envenenado que reaccione a las herramientas de formato comunes.
2. Las Defensas Actuales son Insuficientes: El entrenamiento de seguridad estándar, la ingeniería de prompts y los mecanismos de detección basados en incrustaciones son ineficaces contra desencadenantes basados en estilo porque el desencadenante es una propiedad abstracta de la estructura del código en lugar de un token o frase específica.
3. Necesidad Urgente de Investigación: Los resultados destacan una brecha crítica en la seguridad de los CLLMs, haciendo necesaria nuevas estrategias defensivas que puedan detectar cambios de comportamiento sutiles y dependientes del estilo en la generación de código.

El artículo concluye liberando la implementación y el conjunto de datos para facilitar investigaciones adicionales sobre la detección y mitigación de tales ataques de envenenamiento basados en estilo.