Resumen Técnico: Detección de Fugas de Privacidad en la Generación de Código Basada en LLMs mediante la Generación de Pruebas

Definición del Problema

Los Modelos de Lenguaje Grande (LLMs) entrenados en repositorios de código a gran escala, extraídos públicamente, corren el riesgo de memorizar y reproducir información de identificación personal (PII) sensible, subida involuntariamente por desarrolladores (por ejemplo, credenciales, claves de API, direcciones de correo electrónico). Aunque existen métodos actuales para detectar fugas de privacidad, estos adolecen de limitaciones significativas:

1. Construcción Ad Hoc de Prompts: Los métodos actuales dependen de prompts diseñados manual o automáticamente que no logran aproximar los contextos realistas en los que aparece la PII en los corpus de código.
2. Alcance y Aplicabilidad Limitados: Algunos métodos están adaptados a modelos específicos (por ejemplo, Codex) o dependen de estrategias basadas en mutación que generan prompts carentes de fundamentación en contextos de código auténticos, lo que conduce a salidas alucinatorias o similares a marcadores de posición en lugar de fugas de privacidad reales.
3. Evasión de Mecanismos de Seguridad: Consultar directamente a los modelos sobre PII a menudo desencadena rechazos de seguridad, limitando la capacidad de evaluar eficazmente los riesgos de fuga.

El desafío central es desarrollar un método que simule escenarios prácticos de desarrollo para elicitar PII memorizada sin desencadenar rechazos de seguridad, distinguiendo al mismo tiempo entre fugas realistas y alucinaciones del modelo.

Metodología

Los autores proponen una tubería impulsada por pruebas que evalúa la fuga de privacidad generando casos de prueba unitarios en lugar de solicitar directamente datos sensibles. La tubería consta de cuatro etapas principales:

1. Construcción de Preguntas de Generación de Código

La tubería construye escenarios de desarrollo fundamentados en dominios de aplicación realistas (por ejemplo, aplicaciones empresariales, servicios móviles, plataformas en la nube).

• Instanciación de Escenarios: Los atributos de privacidad (por ejemplo, correo electrónico, número de teléfono) se mapean a escenarios de software específicos donde son funcionalmente necesarios.
• Generación de Preguntas: Estos escenarios se instancian en preguntas concretas de generación de código. Este enfoque asegura que los prompts se asemejen a los contextos originales de entrenamiento, aumentando la probabilidad de desencadenar la memorización.

2. Respuesta del Modelo y Elicitación de Casos de Prueba

En lugar de pedir al modelo que emita PII directamente, la tubería utiliza una interacción de dos pasos:

• Generación de Código: El LLM evaluado genera un fragmento de código funcional basado en la pregunta del escenario.
• Generación de Casos de Prueba: Luego se le pide al modelo que genere casos de prueba unitarios para el código generado. Los prompts para este paso se aumentan con una Biblioteca de Características de Privacidad (véase más abajo) para fomentar que el modelo proporcione entradas realistas con forma de atributo (por ejemplo, formatos de correo electrónico válidos) en lugar de marcadores de posición triviales. Este patrón de interacción indirecta es menos propenso a rechazos de seguridad.

3. Biblioteca de Características de Privacidad

Para reemplazar la ingeniería manual de prompts y guiar al modelo hacia salidas realistas, los autores introducen una Biblioteca de Características de Privacidad construida automáticamente e iterativamente actualizada.

• Componentes: Para cada atributo de privacidad, la biblioteca contiene:
  • Plantillas ($\Lambda_{tmp}$): Patrones estructurales abstractos (por ejemplo, user.email = <EMAIL>).
  • Fragmentos ($\Lambda_{frag}$): Subcadenas de nivel de valor realistas derivadas de patrones reales de fuga.
• Construcción: La biblioteca se inicializa con conocimiento previo y se enriquece utilizando instancias de fuga confirmadas de ejecuciones anteriores de la tubería.
• Procesamiento: Las fugas confirmadas se descomponen en plantillas y fragmentos utilizando un modelo orientado al código (CodeBERT) para analizar la pseudo-log-verosimilitud a nivel de token (pseudo-NLL). Los tokens con baja pseudo-NLL (elementos estructurales comunes) se clasifican como plantillas, mientras que los tokens con alta pseudo-NLL (valores específicos) se clasifican como fragmentos. Luego se aplica agrupamiento semántico (DBSCAN) para consolidar patrones equivalentes y eliminar ruido.

4. Filtrado y Verificación

Los candidatos extraídos pasan por un proceso de verificación riguroso para confirmar la fuga:

• Filtrado por LLM Juez: Un modelo oráculo filtra alucinaciones, marcadores de posición y valores implausibles basándose en características estructurales y semánticas.
• Búsqueda en GitHub: Los candidatos se verifican contra repositorios públicos de GitHub. Una coincidencia (1–100 resultados) sugiere que la cadena existe en corpus de código reales.
• Revisión Humana: Dos autores inspeccionan manualmente los contextos coincidentes para confirmar que la cadena representa información personal real y no documentación o datos de prueba.
• Salida: Solo se reportan instancias "Confirmadas", proporcionando un límite inferior conservador sobre la fuga de privacidad.

Contribuciones Clave

1. Tubería Impulsada por Pruebas: Una tubería novedosa para evaluar la fuga de privacidad en tareas de generación de código que aprovecha escenarios de desarrollo realistas y la generación de casos de prueba para eludir mecanismos de seguridad y elicitar datos memorizados.
2. Biblioteca de Características de Privacidad Automatizada: Una biblioteca construida automáticamente que proporciona plantillas y fragmentos realistas, reduciendo la dependencia de la ingeniería manual de prompts y mejorando la calidad de los valores de privacidad elicita.
3. Evaluación Empírica a Gran Escala: Experimentos extensos en cinco LLMs comerciales ampliamente utilizados (series GPT y series DeepSeek) que demuestran la eficacia de la tubería.

Resultados Experimentales

El estudio evaluó 5 LLMs en 15 atributos de privacidad y 3 categorías (Identificable, Privado, Secreto).

• Volumen de Fuga: La tubería identificó un promedio de 105.7 instancias confirmadas para la serie GPT y 79.5 para la serie DeepSeek.
• Comparación con Líneas Base: El método propuesto logró un aumento de 2.56 veces en la fuga detectada en comparación con las líneas base existentes (CodexLeaks y Codebreaker).
• Tasas de Fuga: La proporción general de fuga fue del 17.6‰ para los modelos GPT y del 13.3‰ para los modelos DeepSeek. La categoría "Identificable" mostró la tasa de fuga más alta (24.64‰), siendo el Correo Electrónico y el Nombre de Cuenta/Usuario los atributos más frecuentemente filtrados.
• Fuga Interconectada: El método descubrió respuestas que contenían múltiples elementos de privacidad interconectados con mayor frecuencia que las líneas base, lo que sugiere que las pruebas impulsadas por escenarios fomentan la exposición de combinaciones complejas de privacidad.
• Estudios de Ablación: Eliminar cualquier componente central (Preguntas Basadas en Escenarios, Biblioteca de Características o Generación de Casos de Prueba) degradó significativamente el rendimiento, confirmando la necesidad de la tubería completa.

Significado y Afirmaciones

El artículo afirma que su enfoque proporciona una metodología de auditoría práctica para evaluar los riesgos de privacidad en la generación de código basada en LLMs. Al simular interacciones realistas de desarrolladores, la tubería revela fugas de privacidad no despreciables que los métodos existentes pasan por alto. Los autores enfatizan que sus cifras de fuga reportadas son límites inferiores conservadores, ya que dependen de la búsqueda en GitHub como proxy para los datos de entrenamiento y excluyen candidatos no verificados.

El trabajo destaca que incluso los modelos con mecanismos de seguridad pueden reproducir datos sensibles cuando se les solicita a través de interacciones indirectas, similares a las de un desarrollador (generación de pruebas). Los autores posicionan su trabajo como un paso hacia garantizar un despliegue más seguro y fiable de los LLMs en el desarrollo de software, al tiempo que reconocen limitaciones relacionadas con la incapacidad de verificar la verdad fundamental para modelos comerciales y la dependencia actual de la revisión manual para auditorías de alta confianza.