Los riesgos de seguridad del vibe coding no son como los riesgos ordinarios

Probablemente era inevitable que el vibe coding provocara una cascada de cambios complejos en las prácticas de codificación y el desarrollo de software. A medida que el código generado por IA continúa constituyendo una mayor parte de las bases de código reales, uno de los cambios más importantes ha sido un cambio importante en la cantidad de riesgos de ciberseguridad y en la naturaleza de esos riesgos.

El vibe coding, en resumen, es la noción de construir productos con nada más que herramientas de IA y instrucciones en lenguaje natural. Debe entenderse como distinto de la codificación agéntica o la ingeniería agéntica, que implican un uso más deliberado de herramientas de codificación con IA por parte de un programador experimentado. El término lo acuñó en un tuit de Andrej Karpathy, un estimado desarrollador y veterano de la IA, en el que describía un estilo desenfrenado de codificación de IA que se basa enteramente en indicaciones de modelos de lenguaje de gran tamaño (LLM), lo que permite al usuario "dejarse llevar por completo" y "olvidar que el código existe"

Lo describió como un enfoque divertido para "proyectos de fin de semana sin pretensiones", pero la proliferación de la programación basada en IA potente ha abierto la puerta al vibe coding en el lugar de trabajo, incluso en software de producción que maneja datos confidenciales. A finales de 2025, la investigación de los sectores indica que el código generado por la IA representa ahora el 22 % de todo el código fusionado.¹ En GitHub, los informes estiman que el 46 % de todo el código escrito fue generado por Copilot.²

Esto ha creado una importante expansión de las vulnerabilidades y los problemas de seguridad más allá de lo que podría explicarse por el aumento natural del volumen y la velocidad del nuevo código que permiten los asistentes de codificación. Un análisis de bases de código del mundo real descubrió que, si bien los equipos asistidos por la IA enviaban códigos 4 veces más rápido, enviaban 10 veces más fallos de seguridad.³

Abandonar por completo el vibe coding sacrificaría importantes ganancias de productividad gracias a la automatización y una mayor participación, pero está claro que las prácticas de codificación segura deben evolucionar en respuesta. Las comprobaciones de seguridad tradicionales están diseñadas para abordar cómo los desarrolladores (más concretamente, los humanos formados) suelen cometer errores. Las organizaciones ahora necesitan una postura de seguridad actualizada y herramientas de seguridad actualizadas, adaptadas a la nueva realidad impulsada por los agentes de IA y los vibe coders novatos.

En diferentes plataformas, entornos y LLM, la investigación del sector indica de forma constante que el aumento de la generación de código de IA va acompañado de un aumento de vulnerabilidades en la seguridad de aplicaciones (AppSec).

Por ejemplo:

• Un estudio de diciembre de 2025 sobre repositorios de código abierto descubrió que el código generado por IA introducía vulnerabilidades de seguridad en el 45 % de las tareas de desarrollo. Al comparar las solicitudes de extracción (RP) asistidas por IA con las solicitudes de extracción solo para humanos, los investigadores descubrieron que las RP impulsadas por la IA generaban 2,74 veces más problemas de seguridad (y 1,7 veces más problemas en general) que el código de creación humana. ⁴

• Un informe de GitGuardian de 2026 sobre la proliferación de información confidencial señala que las confirmaciones realizadas con la ayuda de Claude Code exponían información confidencial con una frecuencia más de dos veces superior a la de las confirmaciones realizadas únicamente por personas. En total, los secretos codificados (como contraseñas y claves API) expuestos en las confirmaciones públicas de GitHub aumentaron un 34 % interanual en 2025, el mayor incremento anual registrado hasta la fecha.⁵ 

• Un informe de octubre de 2025 señaló que las vulnerabilidades críticas y la exposición a los datos en las aplicaciones codificadas con vibe coding, como las API mal configuradas y otros problemas de autenticación, solían salir “a la luz” y se podía acceder directamente a través de endpoints públicos.⁶

Los equipos de seguridad también deben tener en cuenta que los repositorios públicos en GitHub (y servicios similares) son solo la punta visible del iceberg. GitGuardian sugiere que los repositorios internos tienen seis veces más probabilidades de contener secretos codificados que los repositorios públicos.

Igualmente preocupante es el hecho de que las credenciales sensibles expuestas mediante el vibe coding aparentemente tienen menos probabilidades de ser abordadas y corregidas que los problemas de seguridad que surgen con los flujos de trabajo tradicionales de codificación. El informe de GitGuardian señaló que casi el 70 % de las credenciales expuestas que se habían validado como legítimas en 2022 seguían siendo válidas hasta enero de 2025. El 64 % seguían expuestos y no revocados en enero de 2026. En un incidente destacado, Football Australia dejó al descubierto por error sus claves de acceso a AWS en el código fuente de su página web; estas permanecieron expuestas durante más de 700 días.

En conjunto, estos patrones sugieren que los riesgos de seguridad en el vibe coding se están acumulando a un ritmo mayor del que los programas de corrección tradicionales fueron diseñados para manejar.

La frecuencia y la magnitud de los fallos de seguridad derivados de la IA parecen persistir incluso cuando la funcionalidad del LLM continúa mejorando. Por ello, observadores del sector han sugerido que los pipelines de entrenamiento y los benchmarks utilizados para optimizar y validar el rendimiento del modelo no siempre están naturalmente alineados con la generación segura de código en el mundo real. ⁴ La mayoría de los estudios evalúan el código generado por la IA de forma aislada, centrándose en la corrección (ya sea que simplemente compila, ejecuta y ejecuta su tarea) y en el rendimiento según los puntos de referencia sintéticos.⁷

Pero en entornos de desarrollo empresarial, los modelos no funcionan de forma aislada. El informe de GitGuardian encontró que la infraestructura relacionada con LLM, como servicios para orquestación, generación aumentada por recuperación (RAG) o almacenamiento, exponía secretos a una tasa cinco veces mayor que la de los proveedores de modelos principales.⁵

En otras palabras, muchos riesgos de seguridad del vibe coding no se derivan de los LLM: se derivan del ecosistema en el que se utilizan los modelos. Los proveedores de inferencia, las pasarelas, los registros y las capas de integración recientemente publicados entran en los flujos de trabajo de producción rápidamente, a menudo demasiado rápido para que las posiciones de seguridad (o los vibe coders novatos) puedan mantenerse al día.

La IA agéntica añade aún más complejidad a las consideraciones de seguridad: cuando a un agente de IA se le concede acceso local a archivos, almacenes de credenciales y terminales, el propio ordenador puede convertirse en otra posible superficie de ataque. Los ataques de inyección de instrucción y a la cadena de suministro que aprovechan las credenciales locales expuestas pueden convertirse en riesgos organizativos. En el caso del infame gusano Shai-Hulud, que afectó al mayor registro de JavaScript del mundo a finales de 2025, casi el 60 % de los equipos afectados no eran estaciones de trabajo personales, sino entornos de ejecución de integración continua y entrega continua (CI/CD)⁴ (cuyo objetivo, irónicamente, es automatizar las pruebas de seguridad y garantizar la calidad del código).

Un factor importante que agrava los riesgos de seguridad del vibe coding es la forma en que los cambios de código impulsados por IA suelen empaquetarse: de media, los desarrolladores asistidos por IA producen más de tres veces más commits que sus homólogos analógicos, pero empaquetan esos commits en significativamente menos (y mucho mayores) solicitudes de extracción (PR). Estos PR codificados mediante vibe coding suelen tener un alcance mayor y alteran varios archivos y servicios.

El "Informe sobre los hábitos de los desarrolladores" de Cursor, publicado en la primavera de 2026, señalaba que el número medio de líneas de código por RP había aumentado aproximadamente un 250 % interanual (y que la propia tasa de crecimiento se estaba acelerando). Las “mega solicitudes de extracción”, que Cursor definió como solicitudes de extracción que contienen cambios en al menos 1000 líneas de código, aumentaron de un 8 % del total de solicitudes de extracción en enero de 2025 al 13,9 % del total de solicitudes de extracción en mayo de 2026. ⁸

Las PR grandes y extensas que afectan muchas partes de la base de código son mucho más difíciles de hacer reseñas exhaustivas que las PR más pequeñas y dirigidas. Los cambios aislados en un servicio o bloque de código pueden requerir cambios adicionales en otros lugares para evitar problemas posteriores, pero es menos probable que esos efectos secundarios se reflejen en la revisión del código si el PR que se está revisando adopta un enfoque precipitado que diluye la atención del revisor. Una investigación de Apiiro, una plataforma de AppSec, descubrió que, si bien el volumen de relaciones públicas de los equipos asistidos por IA se redujo casi un tercio, esos equipos presentaron 10 veces más defectos de seguridad.³

En resumen, la IA acelera cada parte de la creación del código, incluida la mala costumbre de implementar demasiados cambios a la vez. Concentrar y acelerar el cambio también puede concentrar y acelerar el riesgo de cada fusión.

Un estudio a gran escala de 500 000 muestras de código, presentado en el 36.º Simposio Internacional IEEE sobre Ingeniería de Fiabilidad del Software (ISSRE 2025), determinó que "el código generado por IA difiere del código escrito por humanos no solo en el número de vulnerabilidades de seguridad, sino también en su naturaleza y distribución”. 

Esto plantea una preocupación existencial: los marcos existentes para evaluar las vulnerabilidades de calidad y seguridad del código están "centrados en las personas y se diseñan en torno a suposiciones sobre la cognición humana, los modos de error y los procesos de revisión". El código generado por la IA demuestra características y tendencias marcadamente diferentes, lo que hace que esos marcos centrados en las personas no sean adecuados para evaluarlo.⁷

Para agravar el problema, la investigación sobre los riesgos de seguridad de la vibe coding también ha revelado múltiples tipos emergentes de ataques que no tienen equivalente en el software codificado por humanos.

Los LLM, y las herramientas de codificación con IA que impulsan, tienden a recomendar paquetes que en realidad no existen, y la investigación ha demostrado que estos nombres alucinados de paquetes a veces se repiten en diferentes escenarios e incluso en distintos modelos. El slopsquatting, un tipo de ataque de alucinación por paquetes, explota esta tendencia.

Los atacantes slopsquatting observan los nombres de los paquetes alucinados que los LLM generan repetidamente y registran previamente estos nombres de paquetes (anteriormente) ficticios en registros públicos. Cuando los vibe coders, que a menudo no están familiarizados con los paquetes de uso común (y, por lo tanto, es poco probable que detecten uno falso), cometen código que contiene estos nombres de paquetes, están instalando código malicioso sin saberlo.

Esto no tiene ningún equivalente en el desarrollo de software tradicional. Es poco probable que un programador humano haga alucinaciones con un paquete que no existe, y aunque lo hiciera, sería imposible y poco práctico para un posible atacante predecir esto, adivinar el nombre del paquete alucinado y registrar código malintencionado con ese nombre de paquete.

Los ataques clandestinos de archivos de reglas explotan los archivos de configuración ("reglas") utilizados para personalizar el comportamiento de los agentes de IA al generar o modificar código en plataformas como Cursor, GitHub Copilot y Claude Code. 

El atacante suele modificar los archivos de reglas de código abierto más populares, embedding instrucciones maliciosas en forma de caracteres Unicode ocultos que son casi imposibles de detectar. Una vez aceptados estos cambios, ese código malicioso se activará en cada sesión de codificación de IA que haga referencia al archivo de reglas infectado. Como resultado, cualquier código generado durante esas sesiones se verá comprometido, pero dado que la salida comprometida está compuesta por caracteres Unicode que son esencialmente invisibles, aparece limpia en la revisión de código.

El objetivo de los atacantes suele ser introducir vulnerabilidades y "puertas traseras" en el código generado posteriormente (y en las aplicaciones que utilizan ese código) que puedan explotar más adelante.

Con un conocimiento de estos patrones específicos, las organizaciones deberían actualizar sus buenas prácticas de seguridad para beneficiarse de las ventajas del código generado por IA sin caer en los tipos de vulnerabilidades que surgen del vibe coding indiscriminado.

Aunque el potencial de estos defectos de seguridad puede surgir de las imperfecciones de las herramientas de codificación con IA, la toma de conciencia de estos riesgos es un fallo de supervisión humana. En última instancia, los desarrolladores siguen controlando qué adiciones y cambios se aceptan, revisan o ignoran. Los asistentes de codificación siguen ampliando y mejorando sus mecanismos de protección integrados, pero la revisión humana sigue siendo la barrera final para evitar que las vulnerabilidades de seguridad se implementen; por eso, la configuración predeterminada de IBM® Bob integra revisiones manuales y la aprobación humana en cada etapa.

Dicho esto, existen formas de mejorar la eficacia de las reseñas humanas.

• Los fallos ocultos en enormes y extensas solicitudes de pull son significativamente más difíciles de detectar en una comprobación de seguridad que en los que se encuentran en relaciones públicas más enfocadas. Los equipos de seguridad deben implementar directrices para el tamaño de los PR en consecuencia.

• Los paquetes deben someterse a un escrutinio especial para minimizar el riesgo de ataques de slopsquatting. Los equipos de seguridad deben tener en cuenta que con cada nueva iteración de un modelo de IA determinado, pueden surgir nuevos patrones de alucinación de paquetes.

• Tanto los desarrolladores como los equipos de seguridad deberían familiarizarse con las diferencias entre los defectos de código escritos por humanos y generados por la IA.

Las organizaciones deberían considerar el código generado por IA como una categoría de entrada distinta que requiere controles de seguridad dedicados y distintos (en lugar de simplemente integrar los outputs de la IA en revisiones estándar orientadas a humanos).

Como axioma amplio, las organizaciones deben tratar cualquier código o módulo derivado de la IA como entrada no fiable de la misma manera que tratarían el código de biblioteca externa. Las pruebas de seguridad de análisis estático (SAST) deben ser una puerta obligatoria por la que deben pasar todas las contribuciones de IA antes de entrar en el código base. Archivos de reglas de terceros, como código abierto, reglas de cursor preconfiguradas, Claude.md archivos, instrucciones de Copilot o Bob Modes: deberían analizarse minuciosamente y añadirse selectivamente a una lista blanca a partir de entonces, en lugar de estar permitidos por defecto.

La mejora continua de las plataformas de ingeniería de agencias representa una oportunidad para combatir el fuego con el fuego mediante la detección de secretos impulsada por la IA, en la que las credenciales específicas de la IA, como las claves de API de LLM o los tokens de bases de datos vectoriales, tienen sus propias firmas de detección dedicadas.

 IBM Bob, por ejemplo, cuenta con herramientas integradas para imponer codificación segura y control de acceso a escala mediante una combinación de modos personalizados de Bob, Integración con Hashicorp Vault y IBM MCP Gateway. Asimismo, realiza revisión de código en tiempo real, escaneando el código en busca de problemas de complejidad, vulnerabilidades potenciales y oportunidades de refactorización que pueden abordarse en línea o revisarse más adelante en el panel de Bob Findings.

La capacidad de detectar defectos recién introducidos en una base de código depende en gran medida de la legibilidad de dicha base de código. Por lo tanto, establecer y hacer cumplir los estándares de calidad del código es esencial para facilitar las revisiones de seguridad productivas. Los estándares compartidos y la refactorización rutinaria maximizarán las posibilidades de identificar y abordar el código inseguro.