Resumen Técnico: Inteligencia de Fuentes Abiertas para la Proveniencia de Código y Patrones de Seguridad

Planteamiento del Problema

Los desarrolladores actualmente obtienen código de dos orígenes distintos: respuestas humanas acumuladas en plataformas como Stack Overflow y salidas de Modelos de Lenguaje de Gran Escala (LLMs). Ambas fuentes conllevan costos de seguridad mensurables. El código de origen humano suele propagar patrones inseguros debido a la antigüedad de las respuestas altamente votadas, mientras que el código generado por LLMs introduce nuevos riesgos, incluyendo salidas inseguras y la excesiva dependencia del desarrollador. Este documento aborda dos preguntas fundamentales sobre esta división:

1. Proveniencia: ¿Se puede recuperar el origen de un fragmento de código (humano vs. un LLM específico) a partir del propio código utilizando características ligeras e interpretables?
2. Divergencia de Seguridad: ¿Adoptan estas dos fuentes diferentes patrones de seguridad para las mismas tareas de programación y, de ser así, dónde divergen?

El estudio se enmarca como un ejercicio de Inteligencia de Fuentes Abiertas (OSINT), basándose únicamente en datos públicos (API de Stack Overflow) y modelos de pesos abiertos para garantizar la total reproducibilidad.

Metodología

Los autores construyeron un flujo de trabajo completamente reproducible y basado en datos para recolectar y analizar muestras de código a través de 31 tareas de programación sensibles a la seguridad (por ejemplo, OAuth con PKCE, verificación de JWT, hashing de contraseñas, acceso SQL).

• Recolección de Datos:

  • Corpus Humano: Recuperado mediante la API pública de Stack Overflow utilizando consultas de búsqueda específicas para cada tarea. El estudio retuvo los bloques de código más grandes de las respuestas con puntuación positiva, registrando su antigüedad y puntuación para considerar el sesgo temporal.
  • Corpus de Modelos: Generado utilizando una pasarela local que expone 9 modelos diversos de pesos abiertos (abarcando familias como Mistral, Nemotron, Qwen y Tencent) a través de una interfaz compatible con OpenAI. Los prompts se enviaron de forma literal con una instrucción de sistema fija que solicitaba una única solución completa.
  • Escala: El conjunto de datos final comprende 528 muestras reales (117 humanas, 411 de modelos) en 5 lenguajes (Python, JavaScript, Go, Java, HTML).

• Extracción de Características:

  • Verificaciones de Patrones de Seguridad: Expresiones regulares deterministas etiquetadas como "seguras" o "inseguras" para cada tarea (por ejemplo, presencia de bcrypt frente a md5, consultas parametrizadas frente a concatenación de cadenas).
  • Métricas de Estilo: Métricas independientes del lenguaje que capturan la forma del código, incluyendo recuento de líneas, recuento de caracteres, densidad de comentarios, recuento de importaciones, presencia de manejo de errores y longitud promedio de línea.

• Análisis:

  • Atribución de Proveniencia: Se entrenó un clasificador de Bosque Aleatorio (Random Forest) para distinguir entre código humano y de modelo (binario) y para atribuir el código del modelo a un modelo específico (clasificación de 7 vías) mediante validación cruzada.
    la fracción de patrones seguros adoptados menos la fracción de patrones inseguros presentes.
  • Estudio de Caso de Reparación de Vulnerabilidades: Un subconjunto de 21 fragmentos de código inseguros (que cubren 12 clases de CWE) fue entregado a los modelos con instrucciones para corregirlos. El éxito se definió estrictamente como la eliminación del patrón inseguro y la adición de la defensa segura correcta.

Principales Contribuciones

1. Pipeline de OSINT Reproducible: Un pipeline basado en especificaciones donde añadir una nueva tarea requiere solo una única entrada de datos (prompt, consulta, detectores), lo que permite que el estudio se generalice sin necesidad de nuevo código.
2. Resultados de Atribución de Proveniencia: Demostración de que la proveniencia del código es altamente recuperable a partir de características superficiales.
3. Análisis de Divergencia de Seguridad: Una comparación granular de los patrones de seguridad adoptados por humanos versus modelos, identificando áreas específicas de mejora y regresión.
4. Validación de Multi-lenguaje: Análisis de si las diferencias de seguridad y estilo son propiedades de la fuente o del lenguaje de programación.
5. Verificador de Cierre Seguro (Fail-Closed): Un mecanismo que vuelve a derivar cada número reportado a partir de los artefactos almacenados, asegurando la integridad de los resultados.

Resultados Clave

1. Atribución de Proveniencia

• Humano vs. Modelo: Un clasificador separa el código humano del de modelo con un 93% de precisión (F1 0.955 para la clase de modelo), superando significativamente la línea base de la clase mayoritaria del 78%.
• Modelo vs. Modelo: Un clasificador de 7 vías atribuye las muestras escritas por modelos a su origen específico con un 48% de precisión (frente al 17% de la línea base).
• Importancia de las Características: La señal está dominada por el estilo (tamaño del código, estructura, andamiaje) más que por el contenido de seguridad. El código del modelo es significativamente más grande, más estructurado e incluye más manejo de errores e importaciones que los fragmentos humanos.
• Especificidad del Lenguaje: El límite de proveniencia no es simétrico entre lenguajes. Un clasificador entrenado en JavaScript se transfiere bien a Python (89% de precisión), pero el proceso inverso (de Python a JavaScript) cae cerca del azar (el texto original menciona 93% de precisión en el contexto de la redacción del artículo, lo que implica una caída en el rendimiento relativo a la línea base o dentro del rendimiento del lenguaje, indicando que la señal depende del lenguaje).

2. Divergencia de Seguridad

• Seguridad Agregada: Los modelos adoptan patrones seguros a una tasa sustancialmente mayor que el corpus humano. La puntuación de seguridad agregada es de 0.40 para los modelos frente a 0.12 para los humanos.
• Áreas de Mejora: Los modelos sobresalen en tareas donde la guía de codificación segura moderna está bien establecida y basada en librerías, tales como:
  • Uso de funciones de derivación de claves (KDF) fuertes para el hashing de contraseñas.
  • Implementación de PKCE para OAuth.
  • Uso de consultas parametrizadas para SQL.
  • Fijación de algoritmos y verificación de expiración para JWTs.
• Áreas de Regresión (El "Peligro de Completitud"): Los modelos introducen un modo de fallo específico: secretos incrustados (hardcoded). Debido a que los modelos buscan producir un "programa completo y ejecutable", frecuentemente incluyen secretos de marcador de posición (ej. client_secret = "placeholder") que se dejan sin cambios. En contraste, las respuestas humanas suelen omitir estos valores por completo, dejándolos para que el lector los configure.
• Capacidades de Reparación: En el estudio de caso de reparación de vulnerabilidades, los modelos lograron una tasa de éxito del 77%. Sin embargo, el 16% de las "reparaciones" fueron correcciones parciales donde se eliminó el patrón inseguro pero no se añadió la defensa segura (ej. eliminar una llamada a md5 pero almacenar la contraseña en texto plano).

3. Análisis de Multi-lenguaje

• Seguridad: La divergencia de seguridad (modelos siendo más seguros en patrones defensivos pero peores en el manejo de secretos) se mantiene constante en Python, JavaScript y Go.
• Estilo: Las diferencias estilísticas que impulsan la atribución de proveniencia varían según el ecosistema del lenguaje. Por ejemplo, la cantidad de andamiaje (scaffolding) difiere significamente entre Go y Python, lo que significa que un clasificador de proveniencia debe ser calibrado por lenguaje.

Significancia y Reivindicaciones

El artículo sostiene que las dos fuentes de código no se clasifican simplemente como "seguras" vs. "inseguras". En su lugar, fallan en lugares diferentes:

• Código Humano: Propenso a omisiones de legado (ej. falta de tokens CSRF, hashing débil) debido a la antigüedad del material de origen.
• Código de Modelo: Propenso a "peligros de completitud" (ej. secretos incrustados, falta de chequeos para amenazas no mencionadas como SSRF) debido al objetivo de generar un programa autónomo.

Implicaciones para la Revisión:
Los autores proponen que la atribución de proveniencia debe actuar como un enrutador para la revisión de código.

• El código marcado como generado por humanos debe ser dirigido a chequeos de omisiones defensivas de legado (hashing, valores por defecto de tokens).
• El código marcado como generado por modelos debe ser dirigido a chequeos de secretos incrustados y configuraciones de marcadores de posición.

Limitaciones y Modestia:

• El estudio se basa en el emparejamiento de patrones léxicos (regex), no en el análisis semántico; una puntuación de seguridad alta indica la adopción de un patrón, no la seguridad absoluta.
• El corpus de modelos está limitado a modelos de pesos abiertos disponibles a través de una pasarela específica, excluyendo a los principales asistentes comerciales.
• El clasificador de proveniencia es un experimento de mundo cerrado; su precisión probablemente se degradaría en un entorno de mundo abierto con modelos no vistos.
• Los resultados son instantáneas; tanto el corpus humano (que envejece) como los datos de entrenamiento de los modelos (que evolucionan) cambiarán con el tiempo.

El artículo concluye que, si bien los modelos han absorbido mejor el consenso de seguridad reciente que el corpus humano archivado, introducen nuevos riesgos a través de su impulso hacia la completitud. El pipeline proporcionado permite a la comunidad reevaluar estas métricas a medida que los modelos y las prácticas evolucionan.