Por qué el 45% del código IA tiene vulnerabilidades

El 45% de las muestras de código escritas por modelos de lenguaje falló los tests de seguridad e introdujo vulnerabilidades del OWASP Top 10. Es el dato central del 2025 GenAI Code Security Report que publicó Veracode el 30 de julio de 2025, firmado por Jens Wessling, CTO de la compañía. El estudio probó más de 100 LLMs generando código en Java, Python, C# y JavaScript. Casi la mitad del código que una IA escribe necesita revisión de seguridad antes de llegar a producción.

En este artículo repasamos qué dicen los estudios sobre la seguridad del código generado por IA, por qué los modelos nuevos no mejoran la seguridad, de dónde puede entrar código inseguro que no ha escrito tu equipo y qué medidas concretas puedes aplicar para validarlo antes de publicar.

Qué dicen los estudios

Veracode analizó qué ocurre cuando se pide a los grandes modelos de lenguaje que escriban código para tareas de programación reales. El equipo del informe trabajó con más de 100 LLMs en cuatro lenguajes, Java, Python, C# y JavaScript, y pasó cada muestra generada por tests de seguridad automáticos basados en el OWASP Top 10, el catálogo de referencia de las vulnerabilidades web más frecuentes. El resultado: el 45% de las muestras falló, es decir, el código introdujo al menos una vulnerabilidad de las que recoge el catálogo. El análisis cubrió modelos de distintos tamaños y fechas de lanzamiento, algo que veremos después porque es la parte que más sorprende.

La diferencia por lenguaje es considerable. Java encabeza la lista de fallos con un 72% de muestras inseguras. En el extremo opuesto, Python se queda en un 38%.

El tamaño de la brecha entre lenguajes tiene una lectura práctica: el riesgo depende del stack que uses y de dónde concentres el desarrollo. El informe no analiza las causas de estas diferencias, así que la tabla conviene leerla como una fotografía del estado de los modelos en la fecha del estudio, del 30 de julio de 2025.

El OWASP Top 10 merece una explicación breve por si no lo conoces. Es una lista que publica OWASP, la organización sin ánimo de lucro dedicada a la seguridad de aplicaciones, con las diez categorías de vulnerabilidades más críticas en aplicaciones web: categorías como la inyección de código, los fallos de control de acceso, los fallos criptográficos o el diseño inseguro. Los tests del informe se basan en este catálogo, de modo que fallar significa haber introducido código vulnerable de una clase que el sector lleva años documentando.

El fallo más llamativo del informe es el Cross-Site Scripting (XSS), catalogado como CWE-80. En el 86% de las muestras relevantes, el código carecía de mecanismos de defensa: escapado de la salida, validación de entradas, sanitizado de datos y cabeceras de seguridad. Un XSS permite a un atacante inyectar scripts en una página y ejecutarlos en el navegador de las víctimas. Con ese acceso puede robar cookies de sesión, capturar lo que el usuario escribe, redirigir a sitios controlados por el atacante o suplantar su identidad. Que casi nueve de cada diez muestras dejen esa puerta abierta da una idea del nivel de revisión que necesita este código.

Hay que leer estos números en su contexto. Los tests miden el código tal como sale del modelo, sin revisión humana posterior ni herramientas de análisis en medio. En un equipo con un proceso mínimo de validación, buena parte de esas vulnerabilidades se detectaría antes de llegar a producción. El riesgo se concentra donde el código de IA se copia y se despliega sin ningún control adicional.

Por qué los modelos nuevos no mejoran la seguridad

La intuición apunta a que la seguridad mejora con cada generación de modelos: más parámetros y más datos de entrenamiento deberían dar mejores resultados en todo. El informe de Veracode examinó esa hipótesis comparando el rendimiento por tamaño y por fecha de lanzamiento, y el dato es rotundo: el rendimiento en seguridad se mantuvo plano con independencia del tamaño o la fecha del modelo. Los modelos más recientes no fallaban menos que los antiguos.

Hay una explicación razonable detrás de este resultado. Los modelos se entrenan y se evalúan, sobre todo, para producir código que funciona: que compile, que pase los tests funcionales, que resuelva la tarea pedida y que sea mantenible. Escribir código seguro implica decisiones adicionales (escapar salidas, validar entradas, revisar permisos, configurar cabeceras) que el modelo solo aplica si el entrenamiento lo premia. Mientras la industria compita por funcionalidad y razonamiento, los valores por defecto seguros quedan fuera de esa carrera.

Este dato conviene leerlo en su justa medida. El rendimiento en seguridad se mantuvo plano hasta la fecha del informe, de modo que ninguna generación de modelos había resuelto el problema de forma automática. La responsabilidad de validar el código sigue siendo de quien lo usa y lo despliega.

Para la decisión práctica, este dato cambia la estrategia. Si esperar al siguiente modelo no mejora la seguridad, la palanca disponible está en el proceso: cómo se revisa, se testa, se documenta y se despliega el código. Ese proceso sí lo controlas tú, y es donde el resto del artículo se concentra. Si además estás comparando modelos para tu equipo, en nuestra guía sobre la mejor IA para programar en 2026 repasamos las opciones actuales por caso de uso.

El riesgo indirecto: código que no escribe tu equipo

El 45% del informe mide el código que alguien pide a un modelo y usa tal cual. El riesgo de tu proyecto incluye otro canal menos visible: el código que no ha escrito tu equipo. Según el informe de Veracode, el código generado por IA también lo escriben los mantenedores de software open-source, los proveedores de terceros, las plataformas low-code y las empresas externalizadas que usan IA sin anunciarlo. Lo más probable, concluye el estudio, es que tu stack ya contenga código generado por IA, lo sepas o no.

Y si ese código no se valida, el informe apunta a las consecuencias: fugas de datos, daño reputacional, pérdida económica y riesgo legal. Para un equipo pequeño, la consecuencia directa es que no puedes delegar la seguridad en el proveedor del modelo. Para una empresa grande, cambia el cálculo de riesgo de los desarrollos externos: cada proveedor que genera código con IA amplía la superficie a revisar, de modo que el contrato debería incluir qué herramientas se usan y qué comprobaciones de seguridad se aplican antes de la entrega.

La práctica de programar conversando con una IA y aceptar la salida sin revisarla tiene nombre: vibe coding. Funciona para prototipos desechables y scripts de un solo uso. Se convierte en un problema cuando ese código termina en producción, manejando datos de usuarios o pagos. Si ese es tu caso, conviene conocer el límite y los puntos de control que necesitas: lo tratamos con detalle en nuestra guía sobre qué es el vibe coding.

El segundo canal es la cadena de suministro de software. Una librería con una vulnerabilidad conocida, una versión antigua que nadie ha actualizado, una dependencia transitiva que arrastras sin saberlo o un paquete descontinuado que ya no recibe parches introducen código inseguro con la misma eficacia que cualquier modelo. La diferencia es que las dependencias se pueden auditar de forma automática, y hacerlo cuesta poco: hay herramientas que lo hacen solas.

Hay un tercer canal que casi nadie cuenta: el código interno de tu propia empresa. Scripts de automatización, paneles de administración, informes automáticos, tareas programadas que alguien montó un viernes y nadie ha vuelto a mirar. Ese código rara vez pasa por revisión o por análisis, y también puede haberse generado con IA. Si maneja datos de clientes o credenciales, merece el mismo control que el producto principal.

Cuando el equipo define antes qué debe hacer el código, la IA tiene menos margen para introducir fallos que pasan desapercibidos. Especificaciones claras, criterios de aceptación, tests escritos antes del código y ejemplos de uso actúan de filtro previo; la revisión de código cierra el ciclo como filtro final. Ese enfoque se conoce como spec-driven development y encaja bien en equipos que ya trabajan con IA: en nuestra guía sobre spec-driven development (SDD) explicamos cómo aplicarlo paso a paso.

Qué hacer en tu equipo: SAST, revisión de código y pipelines

Ninguna medida aislada resuelve el problema. La combinación de varias reduce el riesgo a un nivel razonable, y ninguna requiere un equipo grande: todas se pueden montar en un proyecto pequeño con el pipeline que ya tengas.

Análisis estático (SAST) en cada cambio

Un SAST (static application security testing) analiza el código fuente buscando patrones vulnerables sin ejecutarlo: XSS, inyección SQL, secretos expuestos en el repositorio, rutas de fichero incontroladas. Herramientas como SonarQube, Semgrep, Checkmarx o los scanners integrados en GitHub y GitLab se enganchan al pipeline y comentan el pull request en pocos minutos. Para código generado por IA funciona como primer filtro objetivo: el XSS que, según el informe, queda sin defensa en el 86% de las muestras es justo el tipo de fallo que estas herramientas marcan. La regla práctica: ningún cambio llega a la rama principal sin pasar el análisis.

El SAST genera falsos positivos, sobre todo al principio. Conviene dedicar una sesión a ajustar las reglas al stack del proyecto y marcar los casos revisados, de modo que el ruido baje y los avisos que quedan sean los que importan. Un SAST bien ajustado se lee en minutos; uno mal ajustado acaba silenciado por el equipo.

Revisión de código que trate la IA como a un junior

La revisión humana detecta lo que el análisis automático no ve: lógica de negocio incorrecta, manejo de permisos, gestión de sesiones, decisiones de arquitectura dudosas. Con código de IA conviene aplicar el mismo criterio que con un desarrollador junior: el código puede funcionar y aun así no ser seguro, de modo que la revisión se centra en cómo lo hace. Pedirle a la IA que revise su propia salida no sustituye esta revisión; el informe sugiere que los modelos comparten puntos ciegos parecidos. Un buen acuerdo de equipo: quien genera el código con IA no puede aprobar su propio pull request.

Pipeline con dependencias y secretos bajo control

El pipeline convierte las comprobaciones en obligatorias. Un flujo mínimo: análisis estático, escaneo de dependencias, tests automatizados y comprobación de formatos en cada pull request, más una puerta de seguridad antes del despliegue. Si una comprobación falla, el despliegue no ocurre, sin excepciones por urgencia. Para las dependencias, herramientas como Dependabot o Renovate avisan de versiones con vulnerabilidades conocidas y abren pull requests de actualización. Y para los secretos, un escáner específico evita que claves o tokens acaben en el repositorio, algo que ocurre con más frecuencia de la deseable cuando la IA genera configuraciones.

Un caso concreto: blindar el XSS

Un ejemplo con el fallo más frecuente del informe. Si tu web pinta contenido que viene del usuario (comentarios, nombres, campos de formulario, direcciones de envío), la salida debe escaparse antes de renderizar y el servidor debe validar lo que entra. Una Content Security Policy (CSP) bien configurada añade una barrera adicional que limita el daño si algo se cuela. Son medidas sencillas sobre el mismo fallo, y ninguna requiere reescribir la aplicación.

Por dónde empezar esta semana

Si todo esto suena a proyecto grande, empieza por lo básico. Activa el análisis estático en el repositorio y haz que comente los pull requests nuevos. Añade el escaneo de dependencias, que en GitHub o GitLab son un par de casillas. Revisa el último código que generaste con IA y pásalo por el análisis antes de seguir. Y escribe en la documentación del equipo la regla que falte: qué se revisa, quién aprueba, qué bloquea un despliegue y dónde se documentan las excepciones.

Qué no hacer

También hay errores que agravan el problema. Esta lista resume los más habituales cuando un equipo empieza a generar código con IA.

• Confiar en la salida por defecto. El 45% de fallos del informe se mide exactamente así: código tal cual sale del modelo.
• Asumir que el modelo más caro o más nuevo escribe más seguro. El rendimiento en seguridad se mantuvo plano con independencia del tamaño o la fecha del modelo.
• Silenciar los avisos del linter o del análisis estático para que el build pase. Cada aviso silenciado resta un control al pipeline.
• Pegar código de tutoriales o respuestas de IA sin entenderlo. Sin entender el código no puedes evaluar sus riesgos ni su procedencia.
• Desplegar en producción sin entorno de pruebas. Un entorno de staging cuesta poco y evita que el fallo lo descubra primero un usuario.
• Saltarte la revisión de código porque el autor es una IA. La revisión aplica al código, venga de donde venga.

Fuentes

• Veracode. 2025 GenAI Code Security Report. Jens Wessling, CTO. 30 de julio de 2025. veracode.com/blog/genai-code-security-report
• OWASP. OWASP Top 10. La lista de referencia de vulnerabilidades de aplicaciones web. owasp.org/Top10

En IA2Net construimos webs con revisión de código, análisis estático, escaneo de dependencias y testing antes de cada despliegue, y aplicamos el mismo control al código generado por IA. Si quieres que tu proyecto pase por ese filtro, puedes ver qué incluye nuestro servicio de desarrollo web.