Resumen Técnico: CIPHER

Declaración del Problema

Los Modelos de Lenguaje Extensos (LLMs) se están integrando cada vez más en los flujos de trabajo de desarrollo de software para generar componentes críticos de seguridad, como utilidades de cifrado y lógica de gestión de claves. Aunque el código generado por LLMs suele superar las pruebas funcionales, frecuentemente contiene fallos criptográficos sutiles —como vectores de inicialización estáticos, claves codificadas o falta de autenticación— que invalidan silenciosamente las garantías de seguridad. Los paisajes de evaluación existentes sufren tres brechas específicas:

1. Falta de Prompting Controlado: Muchos benchmarks previos varían las especificaciones funcionales junto con la guía de seguridad, lo que dificulta aislar el efecto causal de las instrucciones sobre las tasas de vulnerabilidad.
2. Ausencia de Taxonomías Específicas de Criptografía: Los benchmarks de seguridad general agrupan los problemas criptográficos con vulnerabilidades no relacionadas (por ejemplo, inyección SQL), oscureciendo los patrones de fallo específicos de las API criptográficas.
3. Falta de Puntuación Escalable a Nivel de Línea: Las evaluaciones suelen depender de la inspección manual o de juicios binarios de pasa/no pasa, lo que impide una atribución detallada de qué patrones de código causan vulnerabilidades específicas.

Además, estudios previos sugieren que, si bien los asistentes de IA pueden producir código menos seguro, también inducen una mayor sobreconfianza en los desarrolladores respecto a la seguridad, lo que requiere benchmarks rigurosos y reproducibles.

Metodología

Los autores presentan CIPHER (Cryptographic Insecurity Profiling via Hybrid Evaluation of Responses), un benchmark estandarizado diseñado para medir la incidencia de vulnerabilidades criptográficas en código Python generado por LLMs bajo condiciones controladas.

Construcción del Benchmark

• Tripletas de Prompts: La unidad central es una "familia de prompts" que representa una tarea criptográfica única (por ejemplo, cifrar un mensaje). Cada familia se expande en tres variantes que comparten el mismo objetivo funcional, restricciones de interfaz y contexto, diferenciándose únicamente en la guía de seguridad:
  • Insegura: Contiene una guía engañosa o permisiva (por ejemplo, "desactivar la validación de certificados para compatibilidad").
  • Neutra: Solicita código listo para producción sin instrucciones de seguridad explícitas.
  • Segura: Exige explícitamente las mejores prácticas y prohíbe errores conocidos (por ejemplo, requerir modos AEAD).
• Implementaciones de Referencia: Cada familia incluye una referencia segura (que cumple con las mejores prácticas modernas) y una referencia vulnerable (que contiene intencionalmente una vulnerabilidad específica y mínima). Estas sirven como controles de calidad para el pipeline de evaluación.
• Taxonomía: Una taxonomía específica de criptografía que comprende 17 categorías de grano grueso (por ejemplo, aleatoriedad, autenticación, gestión de claves) y 58 tipos de vulnerabilidades de grano fino (por ejemplo, IV fijo, hash débil).

Pipeline de Evaluación

• LLM-as-a-Judge (LLM como Juez): El benchmark emplea un pipeline de puntuación automatizado utilizando un LLM (GPT-4o) restringido a la taxonomía de CIPHER. El juez extrae el código, asigna etiquetas de vulnerabilidad y proporciona extensiones de evidencia a nivel de línea.
• Protocolo de Puntuación: Para asegurar la consistencia, se realizan múltiples pasadas del juez por generación, y las predicciones se agregan mediante voto por mayoría. La incertidumbre se estima mediante puntuaciones de confianza.
• Métricas:
  • Tasa de Vulnerabilidad (VR): La fracción de generaciones que contienen al menos una vulnerabilidad. Esta es la métrica principal, reflejando la realidad operativa de que un solo fallo invalida la seguridad del código.
  • Promedio de Vulnerabilidades por Generación (Avg/Gen): Una métrica secundaria que indica la severidad del fallo.
  • Confianza del Juez: Puntuaciones de confianza agregadas e intervalos de confianza del 95% mediante remuestreo bootstrap.

Contribuciones Clave

1. Benchmark Criptográfico Estandarizado: Un conjunto de datos de 150 tripletas de prompts (450 prompts en total) que cubren 17 categorías de vulnerabilidad y 58 tipos de grano fino, con variantes inseguras, neutras y seguras para cada tarea.
2. Métricas de Seguridad Agnósticas a la Tarea: Medidas globales incluyendo VR, Avg/Gen y confianza del juez, lo que permite una agregación consistente a través de diversos prompts y modelos.
3. Pipeline de Puntuación Reproducible: Un protocolo de evaluación que utiliza un LLM-as-a-judge restringido a una taxonomía fija, produciendo hallazgos por línea con extensiones de evidencia y estimaciones de incertidumbre.
4. Análisis Empírico Multi-Modelo: Una evaluación exhaustiva en siete LLMs ampliamente desplegados bajo tres condiciones de guía.

Resultados

El benchmark se aplicó a siete modelos (incluyendo GPT-5.1, Claude Sonnet 4.5, Gemini 2.5 Flash y varios codificadores de código abierto) utilizando 5 muestras por prompt (2,250 generaciones por modelo).

• Altas Tasas de Vulnerabilidad: En todos los modelos, las tasas de vulnerabilidad oscilaron entre el 56.0% y el 89.1%.
• Impacto Limitado del Prompting Seguro: Aunque el prompting explícito de tipo "seguro" redujo las tasas de vulnerabilidad para algunos modelos, la reducción fue modesta e inconsistente. La tasa de vulnerabilidad agregada de todos los modelos disminuyó solo del 76.9% (prompts inseguros) al 71.7% (prompts seguros).
• Varianza de Modelos:
  • Claude Sonnet 4.5 exhibió la tasa de vulnerabilidad más alta (89.1%) y el promedio de vulnerabilidades por generación más alto (1.46).
  • Qwen2.5 Coder 7B exhibió la tasa más baja (56.0%) y el promedio más bajo (0.73).
• Modos de Fallo Comunes: Los fallos de autenticación fueron la vulnerabilidad más prevalente en todos los modelos. Otros problemas dominantes incluyeron usos indebidos de IV/claves, errores en el manejo de claves y aleatoriedad insegura.
• Análisis de Guía de Prompts: Los prompts seguros a menudo tuvieron éxito en evitar la vulnerabilidad específica dirigida (por ejemplo, evitar un IV estático), pero fallaron en imponer invariantes criptográficas globales más amplias (por ejemplo, añadir autenticación o derivación de claves segura). Esto sugiere que los modelos priorizan las restricciones locales del prompt sobre las propiedades de seguridad globales.

Significancia y Reivindicaciones

El artículo afirma que CIPHER proporciona el primer marco controlado y reproducible para medir cómo las condiciones de prompting afectan la seguridad criptográfica en los LLMs. Los hallazgos resaltan una limitación fundamental de los LLMs actuales: frecuentemente satisfacen las restricciones locales del prompt mientras fallan en imponer invariantes criptográficas globales, lo que conduce a composiciones de código inseguras incluso cuando se les instruye explícitamente para ser seguros.

Los autores sostienen que estos resultados proporcionan evidencia concreta contra el despliegue sin revisión de código criptográfico generado por LLMs. El benchmark y su pipeline reproducible están destinados a servir como base para la medición sistemática, permitiendo a los desarrolladores de modelos mejorar las señales de entrenamiento y permitiendo a las organizaciones establecer bases empíricas para requerir revisiones de seguridad por parte de expertos en el código generado por IA. El artículo reconoce los riesgos de doble uso, pero argumenta que las clases de vulnerabilidad estudiadas están bien documentadas, y que la contribución reside en la medición sistemática y no en la creación de nuevas superficies de ataque.