Saltar al contenido
PhiloCyber logo
¿Pueden los LLMs Encontrar y Corregir Software Vulnerable?

¿Pueden los LLMs Encontrar y Corregir Software Vulnerable?

7 min de lectura
#Academic Research

Resumen del artículo

Por qué importa este artículo

La investigación de David Noever en 2023 puso a prueba GPT-4 contra Snyk y Fortify sobre 128 fragmentos de código vulnerable en 8 lenguajes y 33 categorías de vulnerabilidades. Los resultados fueron contundentes: GPT-4 encontró aproximadamente 4 veces más vulnerabilidades (393 vs. 98) y sus correcciones las redujeron un 90% con solo un 11% de aumento en líneas de código. Este post recorre la metodología, presenta las tablas comparativas crudas, y discute qué significa la capacidad de auto-auditoría de los LLMs para el futuro de los pipelines de desarrollo seguro.

Hola, ¿cómo andás hoy? ¡Espero que estés genial por allá! Pasaron un par de semanas desde que escribí mi último post; muchas cosas pasaron en el medio... La buena noticia es que finalmente encontré el tiempo para conectarme con una de las cosas que más amo, escribir.

Hoy te traigo algo nuevo en el blog, que espero que eventualmente se vuelva más frecuente. Vamos a estar viendo juntos un paper académico sobre security code review y cómo la IA, o mejor dicho, los Large Language Models (LLMs), se desempeñan detectando y remediando vulnerabilities en 8 lenguajes de programación diferentes comparados con software como Fortify y Snyk.

Es una increíble pieza de investigación titulada "Can Large Language Models Find and Fix Vulnerable Software?", escrita por David Noever en 2023.

Breve descripción sobre la investigación hecha por el autor:

En este estudio, evaluamos la capacidad de los Large Language Models (LLMs), particularmente GPT-4 de OpenAI, para detectar vulnerabilities en software, comparando su rendimiento contra analizadores de código estático tradicionales como Snyk y Fortify. Nuestro análisis cubrió numerosos repositorios, incluyendo los de la NASA y el Departamento de Defensa. GPT-4 identificó aproximadamente cuatro veces más vulnerabilities que sus contrapartes. Además, proporcionó correcciones viables para cada vulnerability, demostrando una baja tasa de falsos positivos. Nuestras pruebas abarcaron 129 muestras de código en ocho lenguajes de programación, revelando las mayores vulnerabilities en PHP y JavaScript. Las correcciones de código de GPT-4 llevaron a una reducción del 90% en vulnerabilities, requiriendo solo un aumento del 11% en líneas de código. Un hallazgo crítico fue la capacidad de los LLMs para auto-auditarse, sugiriendo correcciones para las vulnerabilities que identificaron y subrayando su precisión. La investigación futura debería explorar vulnerabilities a nivel de sistema e integrar múltiples analizadores de código estático para una perspectiva holística sobre el potencial de los LLMs.

Entonces, en el campo del desarrollo de software que siempre está mejorando, la seguridad, como siempre, es una preocupación crítica. Identificar y cambiar prácticas de código débiles durante el proceso de desarrollo es esencial para mantener estándares de seguridad saludables. Este paper presenta un estudio comparativo de LLMs y herramientas tradicionales de software de terceros en la tarea de static code analysis.

Exploramos cómo la IA, específicamente los LLMs, no solo pueden igualar sino incluso superar a los vendors existentes en el mercado para detectar y corregir problemas de seguridad.

Los hallazgos demuestran la eficacia de la IA para mejorar la seguridad del código e introducen una herramienta pionera que se alinea con la creciente necesidad de soluciones de seguridad versátiles, accesibles y robustas en la ingeniería de software. Este paper busca proporcionar una comprensión integral del potencial de la IA para mejorar la seguridad del software, promoviendo prácticas de codificación más seguras.


Introducción

Desarrollar software siempre fue considerado una tarea compleja, incluso si es un proyecto personal, como si estuviéramos creando nuestra propia herramienta en el trabajo para automatizar cierta tarea que no queremos hacer rutinariamente.

Pero imaginate empresas cuyo negocio principal es crear software, buscando todos los días brindar más y mejores servicios... empresas que al final viven de crear software de calidad, mantenerlo y mejorar ideas creativas.

Los procesos de desarrollo de software en esas empresas son aún más complejos. Involucran muchas personas, diferentes equipos, ya sean internos o externos a la empresa, y muchas idas y vueltas antes del release final a producción. Para el proceso de Continuous Integration and Continuous Delivery (CI/CD), muchas empresas agregan numerosos analizadores de código estático, también conocidos como SAST, a sus pipelines de desarrollo como si fuera un estándar obligatorio.

Tenemos GitHub, Snyk, Fortify, Sonar, y muchos otros que detectan errores y potenciales vulnerabilities incluso antes de que cualquier ojo humano vea ese código para aprobar o rechazar el Pull Request. Todo esto es un intento de desarrollar software de calidad más rápido, más barato y más seguro que nunca.

Ahora imaginate agregar LLMs a tu pipeline, capaces de entender el código de una manera diferente y realizar análisis en ese mismo pipeline donde otras herramientas están siendo ejecutadas para evaluar código... suena increíble, ¿no?

Bueno, este paper trata sobre eso... Se trata de repensar cómo podemos mejorar nuestro ciclo de desarrollo seguro agregando LLMs, mostrando cómo estos, en sus etapas tempranas, ya están superando a herramientas conocidas y maduras para detectar software vulnerable.

La creciente complejidad de los sistemas de software requiere métodos avanzados para garantizar su seguridad. Los analizadores de código estático tradicionales, como Fortify o Snyk, han sido fundamentales para identificar vulnerabilities en el software, pero a veces pueden pasar por alto problemas muy sutiles o analizar un Pull Request (PR) con un enfoque aislado en lugar de uno más abarcador y específico para toda una aplicación (contexto), en vez de solo un mero PR dentro de un sistema complejo. Incluso en sus etapas tempranas de desarrollo, los LLMs están superando las herramientas actuales (año 2023), imaginate lo que podría pasar en unos años con los LLMs creciendo al ritmo actual o incluso más rápido... ¡soñá con eso!

Realmente creo que el paradigma va a cambiar. El ojo humano siempre va a estar ahí para esas code reviews manuales "divertidas", pero realmente pienso que la IA va a acelerar y mejorar los procesos muy rápido, creando así un sistema más ágil, seguro y de calidad como nunca antes vimos en la industria.


Metodología

Este estudio evalúa la capacidad de varios LLMs (con un foco especial en GPT-4 de OpenAI), para detectar vulnerabilities en software, comparando su rendimiento con analizadores de código estático tradicionales. Se revisaron numerosos repositorios, incluyendo los de la NASA y el Departamento de Defensa, usando tanto LLMs como analizadores de código, para contrastar su efectividad.

El prompt usado por el investigador fue realmente simple, pero altamente efectivo:

Act as the world's greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.

Probándolo con herramientas de desarrollo estático conocidas y con diferentes LLMs de OpenAI como Ada, Curie, DaVinci (GPT-3 y GPT-3 Turbo), y finalmente GPT-4 en un paquete de 128 fragmentos de código vulnerables con 33 categorías de vulnerabilities y en los 8 lenguajes de programación más usados (C, Ruby, PHP, Java, Javascript, C#, Go y Python).


Resultados

GPT-4 identificó aproximadamente cuatro veces más vulnerabilities que sus contrapartes. Además, proporcionó correcciones viables para cada vulnerability, demostrando una baja tasa de falsos positivos. Las correcciones de código de GPT-4 llevaron a una reducción del 90% en vulnerabilities, con solo un aumento del 11% en líneas de código.

Los resultados fueron una locura:

Vulnerability CategoryGPT4 Detected VulnerabilitiesSnyk Detected Vulnerabilities
Path Traversal4616
File Inclusion4012
Command Injection3413
SQL Injection306
Unsafe Deserialization252
Insecure File Uploads300
PHP Object Injection180
Cross-site Scripting (XSS)1711
Buffer Overflow160
Denial Of Service145
Server Side Template Injection110
Connection String Injection110
XML External Entity (XXE) Injection113
PostMessage Security100
Code Injection91
LDAP Injection90
Sensitive Data Exposure61
Open Redirect61
SNIPSNIPSNIP
Grand Total39398

Comparación por Categorías de Vulnerabilities para GPT4 LLM vs Snyk

Claramente, la investigación expone específicamente el output según los diferentes tipos de vulnerabilities y cómo varía entre la herramienta y los LLMs más potentes de la investigación. Te invito a leer los resultados completos, que, dentro del mundo de la investigación académica, son una lectura fácil.

Comparación del Total de Vulnerabilities Encontradas por GPT-4 vs Snyk Para GPT-4 Vulnerabilities (verde) y Snyk Vulnerabilities (rojo)

Image

Por ejemplo, en esta otra tabla, podemos ver cuántas de las vulnerabilities encontradas fueron corregidas. Aunque podemos notar que hay algunos errores en los datos, por ejemplo, para File Inclusion, XSS o Command Injection donde hay más corregidas que identificadas, lo cual sinceramente no tiene mucho sentido.

Vulnerability CategoryGPT-4 VulnerabilitiesGPT-4 Fixes
Path Traversal4646
File Inclusion4045
Command Injection3443
SQL Injection3026
Unsafe Deserialization2523
Insecure File Uploads3030
PHP Object Injection1818
Cross-site Scripting (XSS)1718
Buffer Overflow1614
Denial Of Service1414
Server Side Template Injection1111
Connection String Injection1111
XML External Entity (XXE) Injection1111
PostMessage Security1010
Code Injection910
LDAP Injection99
Sensitive Data Exposure66
Open Redirect67
SNIPSNIPSNIP

Tabla: Comparación de Vulnerabilities y Fixes por GPT-4

Un hallazgo importante de esta investigación fue la capacidad de los LLMs para auto-auditarse, sugiriendo correcciones para las vulnerabilities que identificaron, lo que subraya su precisión. Los resultados sugieren que los LLMs pueden complementar efectivamente los métodos tradicionales de detección de vulnerabilities, ofreciendo una perspectiva mucho más amplia sobre la seguridad del software.


Conclusión

La investigación muestra el gran potencial que tienen los LLMs para detectar y corregir vulnerabilities en el software. ¡Incluso en estas etapas tempranas de la tecnología, ya están superando soluciones maduras que llevan algunos años en el mercado! Eso está muy bien... ¡pero realmente creo que el futuro va a ser aún más loco!

Cuando la IA se convierta en una súper especialista, las aplicaciones de Retrieval-Augmented Generation (RAG) especializadas para code analysis van a ser una adición increíble al pipeline de desarrollo seguro en cualquier empresa, y ojalá, a un precio más bajo.

¡Espero que hayas disfrutado esta lectura tanto como yo disfruté leyendo el paper! ¡Nos vemos en el próximo post!

¡Gracias por compartir tu tiempo conmigo! ¡Todo lo mejor!

Richie

Para más información sobre la investigación, consultá el siguiente recurso.

Image

Pon a Prueba tu Conocimiento Técnico

Repaso sobre LLMs y Software Vulnerable

Fácil

¿Qué modelo destaca el post como el de mejor rendimiento en la comparación contra herramientas tradicionales?

Medio

¿Qué resultado reporta el post sobre las correcciones de GPT-4 en términos de reducción de vulnerabilidades?

Difícil

¿Qué tan amplio fue el alcance de la evaluación descrita en la sección de metodología?

Publicado hace 2 años

Seguir leyendo

Más en el archivo

Seguir explorando

Lectura relacionada

Continuá por los temas más relacionados según las etiquetas.

¿Pueden los LLMs Encontrar y Corregir Software Vulnerable? | PhiloCyber