
¿Pueden los LLMs Encontrar y Corregir Software Vulnerable?
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 Category | GPT4 Detected Vulnerabilities | Snyk Detected Vulnerabilities |
|---|---|---|
| Path Traversal | 46 | 16 |
| File Inclusion | 40 | 12 |
| Command Injection | 34 | 13 |
| SQL Injection | 30 | 6 |
| Unsafe Deserialization | 25 | 2 |
| Insecure File Uploads | 30 | 0 |
| PHP Object Injection | 18 | 0 |
| Cross-site Scripting (XSS) | 17 | 11 |
| Buffer Overflow | 16 | 0 |
| Denial Of Service | 14 | 5 |
| Server Side Template Injection | 11 | 0 |
| Connection String Injection | 11 | 0 |
| XML External Entity (XXE) Injection | 11 | 3 |
| PostMessage Security | 10 | 0 |
| Code Injection | 9 | 1 |
| LDAP Injection | 9 | 0 |
| Sensitive Data Exposure | 6 | 1 |
| Open Redirect | 6 | 1 |
| SNIP | SNIP | SNIP |
| Grand Total | 393 | 98 |
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)

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 Category | GPT-4 Vulnerabilities | GPT-4 Fixes |
|---|---|---|
| Path Traversal | 46 | 46 |
| File Inclusion | 40 | 45 |
| Command Injection | 34 | 43 |
| SQL Injection | 30 | 26 |
| Unsafe Deserialization | 25 | 23 |
| Insecure File Uploads | 30 | 30 |
| PHP Object Injection | 18 | 18 |
| Cross-site Scripting (XSS) | 17 | 18 |
| Buffer Overflow | 16 | 14 |
| Denial Of Service | 14 | 14 |
| Server Side Template Injection | 11 | 11 |
| Connection String Injection | 11 | 11 |
| XML External Entity (XXE) Injection | 11 | 11 |
| PostMessage Security | 10 | 10 |
| Code Injection | 9 | 10 |
| LDAP Injection | 9 | 9 |
| Sensitive Data Exposure | 6 | 6 |
| Open Redirect | 6 | 7 |
| SNIP | SNIP | SNIP |
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.

Pon a Prueba tu Conocimiento Técnico
Repaso sobre LLMs y Software Vulnerable
¿Qué modelo destaca el post como el de mejor rendimiento en la comparación contra herramientas tradicionales?
¿Qué resultado reporta el post sobre las correcciones de GPT-4 en términos de reducción de vulnerabilidades?
¿Qué tan amplio fue el alcance de la evaluación descrita en la sección de metodología?
Seguir leyendo
Más en el archivo
Artículo más reciente
Comprometiendo Aplicaciones Reales Integradas con LLMs mediante Indirect Prompt Injection
Esta investigación introduce la Inyección Indirecta de Prompts (IPI), un método para manipular remotamente Modelos de Lenguaje Grande (LLMs) a través de prompts maliciosos en fuentes de datos, arriesgando robo de datos, desinformación y mucho más, destacando la necesidad de defensas más robustas.
Artículo anterior
Tips y Trucos para Aprobar tu Examen Bug Bounty Hunter (cBBH) de Hack The Box
Mi experiencia, consejos y cosas importantes que necesitás saber antes de intentar tu examen de 'Certified Bug Bounty Hunter'.
Seguir explorando
Lectura relacionada
Continuá por los temas más relacionados según las etiquetas.

Comprometiendo Aplicaciones Reales Integradas con LLMs mediante Indirect Prompt Injection
Esta investigación introduce la Inyección Indirecta de Prompts (IPI), un método para manipular remotamente Modelos de Lenguaje Grande (LLMs) a través de prompts maliciosos en fuentes de datos, arriesgando robo de datos, desinformación y mucho más, destacando la necesidad de defensas más robustas.

MCP Security for Enterprise Organizations: Experiencias reales y defensa avanzada
Reflexión personal y análisis técnico sobre el protocolo MCP, desde el desafío de presentar a la comunidad hasta los métodos y riesgos reales en AI Security, MCP Server, y defensas recomendadas para organizaciones. Incluye recursos, papers y sitios clave para la investigación moderna en seguridad de agentes AI.

A2AS: Un nuevo estándar para la seguridad en sistemas de IA agéntica
Reflexión, explicación y análisis sobre el paper A2AS, el modelo BASIC y el framework A2AS, desde la perspectiva de los desafíos reales en controles y mitigacion de ataques en AI Security y GenAI Applications.

