Chiosa
Software & Code

Las falsas garantías de seguridad pueden confundir a los modelos que auditan código

Trusting the Tool: Asymmetric Deference of LLM Vulnerability Auditors to Static-Analysis Evidence · arXiv:2610.32876

4 min
Actualizado

En palabras sencillas

Cuando los modelos de lenguaje revisan código C/C++ en busca de vulnerabilidades, pueden recibir notas de un programa analizador. Este artículo presenta un método controlado para comprobar si los modelos contrastan esas notas con el código, sobre todo cuando una nota afirma que existe una comprobación de seguridad o que falta.

En uno de los modelos evaluados, las notas falsas que afirmaban que existía una comprobación hicieron que se le escaparan más funciones vulnerables; las falsas alarmas sobre comprobaciones ausentes no redujeron la precisión. Un paso de verificación independiente ayudó a ese modelo en una prueba posterior.

La investigación

Cuando un modelo de lenguaje revisa código con ayuda de un analizador, ¿contrasta con el código las afirmaciones de esa herramienta? La respuesta importa porque una nota que dice que existe una comprobación de seguridad puede provocar una reacción distinta de otra que afirma que falta.

El estudio evalúa si esa diferencia aparece cuando las afirmaciones se refieren a las mismas operaciones del código.

Los autores comparan auditorías de modelos de lenguaje con notas verdaderas y fabricadas de un analizador para comprobar si examinan de manera distinta las afirmaciones de seguridad y de peligro.

Los autores compararon auditorías de las mismas funciones vulnerables o corregidas de C/C++ con distintas notas del analizador. En deepseek-chat, las afirmaciones falsas de que existía una comprobación redujeron la precisión en funciones vulnerables de 0.75 con notas verdaderas pertinentes a 0.64; las falsas alarmas de que faltaba una comprobación elevaron la precisión en funciones corregidas de 0.67 a 0.79.

En estas comparaciones emparejadas, solo cambiaba la veracidad de las notas sobre las mismas operaciones.

Como los modelos pueden diferir en su tendencia inicial a marcar el código, los autores también midieron los desplazamientos hacia cada afirmación falsa en relación con notas verdaderas. En una réplica con siete modelos nuevos, el desplazamiento medio favoreció las garantías falsas.

Esto respalda la existencia de una asimetría en la respuesta de los modelos evaluados a los dos tipos de afirmaciones.

Estos hallazgos proceden de auditorías aisladas de funciones cortas de C/C++, con evidencia construida por el analizador de los autores.

El paso de verificación propuesto mejoró los resultados de deepseek-chat en una prueba con condiciones fijadas de antemano, pero la mejora menor de qwen-plus no fue estadísticamente significativa.

Qué muestran las pruebas

  • La pregunta sobre la evidencia

    El artículo presenta un método controlado para estudiar cómo usan los modelos de lenguaje la evidencia del análisis estático al buscar vulnerabilidades en funciones de C/C++. La pregunta es si los modelos contrastan con el propio código las afirmaciones sobre sus comprobaciones y si examinan de manera distinta las afirmaciones de que una comprobación existe y de que falta.

    Así se aísla la respuesta de los modelos a la evidencia, en lugar de medir únicamente la detección de vulnerabilidades.

  • Crear notas verificables

    Para conocer la veracidad de cada nota, los autores construyeron un analizador que enumera operaciones sensibles y las condiciones que se cumplen en todos los caminos hasta ellas, además de los riesgos que la función no descarta.

    Emparejaron funciones vulnerables y corregidas, y luego variaron las notas que mostraban a los modelos. Era posible contrastar las afirmaciones falsas con la función; el modelo no veía la corrección. Esto permitió comparar notas falsas con notas verdaderas sobre las mismas operaciones.

  • La veracidad cambió el efecto

    En las configuraciones flash de DeepSeek informadas, las notas verdaderas del analizador apenas cambiaron la precisión de forma medible: mostrar todas las notas verdaderas la modificó en +0.02 en cada configuración, sin significación estadística.

    La comparación más precisa mantuvo iguales la función y la pertinencia de la nota, y cambió únicamente si esta era verdadera. En deepseek-chat, las afirmaciones falsas de que existía una comprobación redujeron la precisión en funciones vulnerables, mientras que las falsas alarmas de que faltaba una comprobación no la redujeron en funciones corregidas.

  • Comparar los cambios de veredicto

    La precisión por sí sola puede reflejar la tendencia previa de un modelo a marcar el código como vulnerable. Los autores también midieron si las notas falsas desplazaban los veredictos hacia lo que afirmaban, en relación con notas verdaderas sobre las mismas operaciones.

    En una réplica registrada internamente con siete modelos nuevos, la asimetría media fue positiva: las garantías falsas acercaron los veredictos a «seguro» más de lo que las falsas alarmas los acercaron a «vulnerable». La magnitud varió entre modelos.

  • Evaluar un paso de verificación

    Los autores interpretan los resultados como una diferencia en el nivel de escrutinio: afirmar que falta una comprobación puede llevar al modelo a buscarla, mientras que afirmar que existe puede aceptarse sin contrastarla.

    En una prueba con condiciones fijadas de antemano, una llamada independiente que verificó las notas y mostró las afirmaciones refutadas mejoró la precisión de deepseek-chat con garantías falsas, sin cambiarla con notas verdaderas pertinentes. La mejora de qwen-plus fue menor y no resultó estadísticamente significativa.

Detalles

Siguiente paperVulnSAGE checks the code evidence behind security warnings