Vibe coding: riesgos, vulnerabilidades de seguridad y lo que realmente ayuda

El mayor riesgo del vibe coding no es el código erróneo, sino el código que funciona y aun así es inseguro. En el GenAI Code Security Report 2025 de Veracode, el 45 por ciento de las respuestas de IA examinadas no superó las pruebas de seguridad y traía vulnerabilidades del OWASP Top 10, con un código sintácticamente impecable y ejecutable.

¿Cuán inseguro es realmente el código generado por IA?

De forma medible, e independientemente del modelo. Para el GenAI Code Security Report 2025, Veracode sometió ochenta tareas de programación seleccionadas a más de cien modelos de lenguaje en cuatro lenguajes: Java, JavaScript, Python y C#.

• El 45 por ciento de todos los ejemplos de código generados no superó la comprobación de seguridad.
• El 86 por ciento de tasa de fallo en cross-site scripting (CWE-80), con diferencia la disciplina más débil.
• El 72 por ciento de tasa de fallo en Java, el más arriesgado de los cuatro lenguajes analizados.

Lo decisivo es el hallazgo que hay detrás de las cifras: los modelos han mejorado claramente a la hora de generar código que funciona, pero no en la misma medida en seguridad. Una actualización de primavera de Veracode de 2026 llega a la misma conclusión. Las nuevas generaciones de modelos, por tanto, no resuelven el problema por sí solas.

¿Por qué una IA genera código inseguro si lo ha leído todo?

Porque un modelo de lenguaje está optimizado para la plausibilidad, no para la seguridad frente a ataques. Tres mecanismos explican la mayor parte de los casos.

Primero, el promedio del entrenamiento. Los modelos aprenden de código público. El promedio del código público no es seguro, es mediocre, incluidos los tutoriales en los que las entradas pasan sin comprobar a una consulta de base de datos porque el ejemplo debía ser breve.

Segundo, la falta de perspectiva del atacante. Un prompt describe lo que debe ocurrir. La seguridad, en cambio, es la pregunta de qué puede ocurrir. Lo que nadie ha pedido tampoco se construye: la comprobación de una autorización ausente, el tratamiento del caso especial, la limitación de la frecuencia de solicitudes.

Tercero, la falta de contexto. El modelo no conoce su arquitectura. No sabe que este endpoint es accesible públicamente, que aquel campo procede de un sistema ajeno o que su separación de clientes depende de una condición concreta.

¿Qué vulnerabilidades de seguridad aparecen típicamente en el código IA?

El OWASP Top 10 se revisó en noviembre de 2025 y se publicó en su versión final en enero de 2026, sobre la base de más de 175.000 entradas CVE. Dos categorías son nuevas, y ambas afectan especialmente al desarrollo asistido por IA.

• Control de acceso defectuoso (A01:2025): sigue en el primer puesto. El código IA implementa la lógica funcional y deja sin responder la pregunta «¿puede este usuario hacer esto?», porque no figuraba en el prompt.
• Configuración de seguridad incorrecta (A02:2025): ha subido del puesto cinco al dos. Las configuraciones generadas están optimizadas para «funciona de inmediato»: reglas CORS generosas, salidas de depuración, contraseñas por defecto.
• Fallos en la cadena de suministro (A03:2025): nueva. Una IA añade dependencias sin que nadie las haya elegido. A ello se suma la alucinación de paquetes inexistentes, cuyos nombres los atacantes registran a propósito.
• Tratamiento incorrecto de excepciones (A10:2025): también nueva. El caso normal está implementado, el caso de error se traga.
• Cross-site scripting: el líder empírico en la prueba de Veracode, con un 86 por ciento de tasa de fallo.

¿Qué comprobaciones debo ejecutar antes de hacer merge de código IA?

Cuatro comprobaciones cubren la mayor parte de los patrones mencionados, y las cuatro pueden automatizarse.

• Análisis estático con reglas de seguridad. Detecta patrones de inyección, deserialización insegura y falta de escape de salida antes de que el código se ejecute. Herramientas y límites: el análisis estático de código en comparación.
• Comprobación de dependencias. Se notifica cada paquete nuevo: ¿existe siquiera?, ¿quién lo mantiene?, ¿qué licencia tiene?, ¿qué vulnerabilidades conocidas presenta?
• Revisión de autorizaciones. Para cada endpoint nuevo, una respuesta explícita a la pregunta de quién puede invocarlo. Es la comprobación que con menos frecuencia está automatizada y la que con más frecuencia falta.
• Pruebas de los casos de error. No solo el camino feliz, sino entrada ausente, tipo incorrecto, identificador ajeno, llamada duplicada. Véase la cobertura de pruebas en el código IA.

¿No basta con leer sin más el código generado?

Como única medida, no, porque la lectura se relaja precisamente cuando se genera mucho código. En la Stack Overflow Developer Survey 2025, el 66 por ciento de los encuestados citó «casi correcto, pero no del todo» como mayor frustración al trabajar con herramientas de IA. El 45 por ciento indicó perder mucho tiempo depurando código IA.

«Casi correcto» es la categoría más difícil para una revisión. El código evidentemente erróneo se nota. El código que parece como debe parecer y omite una comprobación en un punto no se nota al leerlo por encima, y se lee por encima en cuanto aumenta el volumen. Una revisión humana sigue siendo necesaria; pero necesita una fase previa automática que elimine lo evidente. Cómo se construye una revisión así se explica en el artículo Revisión de código para código generado por IA.

Preguntas frecuentes sobre los riesgos del vibe coding

¿Es el código generado por IA más inseguro que el escrito a mano?

Está demostrado que el 45 por ciento de las respuestas de IA examinadas por Veracode en 2025 no superó las pruebas de seguridad. De este estudio no se desprende una comparación limpia con código humano en condiciones idénticas; por ello, los factores de comparación que circulan deben tomarse con cautela. La afirmación sólida es: la tasa de error es lo bastante alta como para justificar una capa de revisión propia.

¿Qué lenguaje de programación es el más arriesgado con IA?

En la prueba de Veracode de 2025, Java, con un 72 por ciento de tasa de fallo, fue el más débil de los cuatro lenguajes analizados (Java, JavaScript, Python, C#).

¿Qué es el slopsquatting?

Un ataque que aprovecha que los modelos de IA inventan nombres de paquetes. Los atacantes registran los nombres alucinados en registros públicos de paquetes y esperan a que alguien ejecute sin comprobar la instrucción de instalación. La contramedida es una comprobación de dependencias que notifique cada paquete nuevo.

¿Ayuda escribir «escribe código seguro» en el prompt?

Ayuda muy poco, de forma medible. El informe de Veracode muestra que el rendimiento en seguridad no ha crecido al ritmo de la calidad general de los modelos. Una instrucción en el prompt es una petición, no un punto de control: la comprobación debe realizarse fuera del modelo.

¿Debo renunciar por ello a las herramientas de IA?

No. El riesgo no surge de la herramienta, sino de que código sin revisar llegue a producción. Un paso de revisión entre la generación y la entrega resuelve el problema sin renunciar a la ventaja de velocidad.

Viernes, 17 h, hay que sacar un hotfix. Justo entonces se omite la comprobación de autorizaciones, no por descuido, sino porque en ese momento nadie abre una lista de verificación. Por eso Code Guardian coloca las cuatro comprobaciones como gates antes del despliegue, la migración y cualquier nueva dependencia.

Fuentes

• Veracode, GenAI Code Security Report 2025 (80 tareas, más de 100 modelos, cuatro lenguajes), julio de 2025, así como la actualización de primavera de 2026.
• OWASP Top 10:2025: presentado en noviembre de 2025, versión final en enero de 2026, base de datos de más de 175.000 entradas CVE y 589 CWE.
• Stack Overflow Developer Survey 2025, sección «AI».

Fecha: 27 de julio de 2026. Información técnica general, no asesoramiento de seguridad para un caso concreto.