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

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

En resumen, vibe coding consiste en crear productos únicamente con herramientas de IA e instrucciones en lenguaje natural. Debe entenderse como distinto de la programación con agentes o la ingeniería agéntica, que implican un uso más deliberado de herramientas de AI Coding por parte de un programador experimentado. El término fue acuñado en un tuit de Andrej Karpathy, un reconocido desarrollador y veterano de la IA, en el que describía un estilo desenfadado de AI Coding que se basa completamente en la incitación del modelos de lenguaje extensos (LLM, por sus siglas en inglés), permitiendo que el usuario “deje llevarse por la sensación” y “olvide que el código incluso existe”.

Lo describió como un enfoque divertido para los "proyectos de fin de semana desechables", pero la proliferación de una poderosa AI Coding ha abierto la puerta a la vibe coding en el lugar de trabajo, incluso en el software de producción que maneja datos confidenciales. A finales de 2025, las investigaciones de la industria indican que el código generado por IA ahora representa el 22 % de todo el código fusionado.¹ En GitHub, los informes estiman que 46 % de todo el código escrito fue generado por Copilot.²

Esto ha creado una gran expansión de vulnerabilidades y problemas de seguridad más allá de lo que podría explicarse por el aumento natural en el volumen y la velocidad del nuevo código que permiten los asistentes de programación. Un análisis de bases de código del mundo real encontró que mientras los equipos asistidos por IA enviaban código 4 veces más rápido, también enviaban 10 veces más fallas de seguridad.³

Abandonar la vibe coding por completo sacrificaría ganancias significativas de productividad derivadas de la automatización y una mayor participación, pero está claro que las prácticas de programación segura deben evolucionar en respuesta. Los controles de seguridad tradicionales están diseñados para abordar la forma en que suelen cometer errores los desarrolladores, más específicamente, los desarrolladores humanos capacitados. Las organizaciones ahora necesitan una postura de seguridad actualizada y herramientas de seguridad actualizadas, adaptadas a la nueva realidad impulsada por agentes de IA y programadores novatos de vibe coding.

En diferentes plataformas, entornos y LLM, la investigación de la industria 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 las aplicaciones (AppSec).

Por ejemplo:

• Un estudio de diciembre de 2025 sobre repositorios de código abierto encontró que el código generado por IA introdujo vulnerabilidades de seguridad en el 45 % de las tareas de desarrollo. Al comparar las solicitudes de extracción asistidas por IA (PR, por sus siglas en inglés) con las PR creadas solo por humanos, los investigadores encontraron que las PR impulsadas por IA generaban 2.74 veces más problemas de seguridad (y 1.7 veces más problemas en general) que el código creado por humanos.⁴

• Un informe de GitGuardian de 2026 sobre la proliferación secreta sostiene que los commits de Claude asistidos por código expusieron secretos con más del doble de frecuencia que los commits de humanos. En total, los secretos con programación rígida (como contraseñas y claves API) expuestos en los públicos de GitHub aumentaron en 34 % año tras año en 2025, el mayor salto en un solo año registrado.⁵ 

• Un informe de octubre de 2025 señaló que las vulnerabilidades críticas y la exposición de datos en aplicaciones programadas con vibe coding, como API mal configuradas y otros problemas de autenticación, a menudo estaban “a la intemperie”, accesibles directamente a través de endpoints públicos.⁶

Los equipos de seguridad también deben considerar 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 con codificación rígida que los repositorios públicos.

De igual preocupación es el hecho de que las credenciales expuestas a través de la vibe coding aparentemente tienen menos probabilidades de resolverse y corregirse que los problemas de seguridad que surgen a través de los flujos de trabajo de programación tradicionales. El informe de GitGuardian señaló que casi el 70 % de las credenciales expuestas que se validaron como legítimas en 2022 siguieron siendo válidas hasta enero de 2025. El 64 % seguían expuestas y no revocadas en enero de 2026. En un incidente notable, Football Australia expuso inadvertidamente sus claves de acceso AWS en el código fuente de su sitio web, las cuales permanecieron expuestas durante más de 700 días.

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

La frecuencia y magnitud de las fallas de seguridad derivadas de la IA parecen persistir incluso cuando la funcionalidad de LLM continúa mejorando. Por ello, observadores de la industria sugirieron que las pipelines de entrenamiento y los punto de referencia usados 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 IA de forma aislada, con un enfoque en la corrección, si simplemente compila, ejecuta y ejecuta su tarea, y el rendimiento en 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, por sus siglas en inglés) o almacenamiento, exponía secretos a una tasa cinco veces mayor que la de los proveedores de modelos centrales.⁵

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

La IA agéntica agrega mayor complejidad a las consideraciones de seguridad: cuando a un agente de IA se le otorga acceso local a archivos, almacenes de credenciales y terminales, la computadora misma puede convertirse en otra posible superficie de ataque. La inyección de instrucciones y los ataques a la cadena de suministro que aprovechan las credenciales locales expuestas pueden convertirse en riesgos organizacionales. En el infame gusano Shai-Hulud, que comprometió el registro JavaScript más grande del mundo a finales de 2025, casi el 60 % de las máquinas comprometidas no eran estaciones de trabajo personales; eran corredores de integración continua/entrega continua (CI/CD) ⁴ (cuyo propósito, irónicamente, es automatizar las pruebas de seguridad y garantizar la calidad del código).

Un factor importante que agrava los riesgos de seguridad de la vibe coding es la forma en que los cambios de código impulsados por IA suelen empaquetar: en promedio, los desarrolladores asistidos por IA producen más de tres veces más commits que sus pares analógicos, pero empaquetan esos commits en significativamente menos y mucho más grandes solicitudes de extracción (PR). Estas PR creadas con vibre coding suelen tener un alcance más amplio, alterando múltiples archivos y servicios.

El "Informe de hábitos de los desarrolladores" de Cursor, publicado en la primavera de 2026, señaló que el número promedio de líneas de código por RP había aumentado aproximadamente un 250 % año tras año (y que la tasa de crecimiento en sí se estaba acelerando). Las "mega PR", que Cursor definió como PR que contenían cambios en al menos 1000 líneas de código, pasaron de un 8 % de todas las PR en enero de 2025 al 13.9 % de todas las PR en mayo de 2026. ⁸

Las PR grandes y extensas que afectan muchas partes del código base son mucho más difíciles de revisar exhaustivamente 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 derivados, pero es menos probable que esos efectos secundarios se capten en la comentarios si el PR que se está revisando adopta un enfoque indiscriminado que diluye la atención del revisor. La investigación de Apiiro, una plataforma AppSec, encontró que mientras que el volumen de relaciones públicas para los equipos asistidos por IA cayó en casi un tercio, esos equipos enviaron 10 veces más defectos de seguridad.³

En resumen, la IA acelera cada parte de la creación de código, incluido el mal hábito 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 Confiabilidad del Software (ISSRE 2025), determinó que "el código generado por IA difiere del código escrito por humanos no solo en la cantidad de vulnerabilidades de seguridad sino también en su naturaleza y distribución”. 

Esto plantea una preocupación existencial: los marcos existentes para evaluar la calidad del código y las vulnerabilidades de seguridad están “centrados en el ser humano, diseñados en torno a suposiciones sobre cognición humana, modos de error y procesos de revisión”. El código generado por IA demuestra características y tendencias marcadamente diferentes, lo que hace que esos marcos centrados en el ser humano sean inadecuados 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 Ai Coding que emplean tienden a recomendar paquetes que en realidad no existen, y las investigaciones descubrieron que estos nombres de paquetes ficticios a veces se repiten en diferentes escenarios e incluso en diferentes modelos. El slopsquatting, un tipo de ataque de alucinación en paquetes , explota esta tendencia.

Los atacantes de 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 quienes usan vibe coding, 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, sin saberlo, están instalando código malicioso.

Esto no tiene ningún equivalente en el desarrollo de software tradicional. Un programador humano sería poco probable que alucinara un paquete que no existe, e incluso si uno 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 malicioso bajo ese nombre de paquete.

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

Los atacantes suelen modificar los archivos de reglas de código abierto más populares, incorporando 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 AI Coding posterior que haga referencia al archivo de reglas infectado. Como resultado, cualquier código generado durante dichas sesiones se verá comprometido, pero debido a que la salida comprometida comprende caracteres Unicode que son esencialmente invisibles, aparece limpio en los comentarios del código.

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

Armadas con una comprensión de estos patrones específicos, las organizaciones deben actualizar sus mejores prácticas de seguridad para beneficiarse de las ventajas del código generado por IA sin ser víctimas de los tipos de vulnerabilidades que surgen de la vibe coding indiscriminada.

Si bien el potencial de estos defectos de seguridad puede deberse a las imperfecciones de las herramientas de AI Coding, la realización de estos riesgos es un fracaso de la supervisión humana. En última instancia, los desarrolladores siguen teniendo el control de qué adiciones y cambios se aceptan, revisan o ignoran. Los asistentes de programación continúan expandiendo y mejorando sus medidas de protección integradas, pero la revisión humana sigue siendo la protección final para que las vulnerabilidades de seguridad se pongan en marcha, razón por la cual la configuración predeterminada de IBM®Bob integra revisiones manuales y aprobación con participación de humanos en cada etapa.

Dicho esto, hay formas de mejorar la eficacia de la revisión humana.

• Las fallas ocultas en enormes y extensas solicitudes de extracción 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 ser objeto de un escrutinio particular 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 desarrolladores como equipos de seguridad deberían familiarizarse con las diferencias entre defectos de código escritos por humanos y generados por 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 resultados de la IA en procesos de revisión estándar orientados a humanos).

Como axioma general, las organizaciones deberían tratar cualquier código o módulo derivado de IA como una entrada no confiable, de la misma manera que tratarían el código de bibliotecas externas. Las pruebas de seguridad de análisis estático (SAST, por sus siglas en inglés) deben ser una puerta obligatoria a través de la cual deben pasar todas las contribuciones de IA antes de ingresar al código base. Archivos de reglas de terceros, como código abierto, Cursor Rules preconfiguradas, Claude.md archivos, instrucciones de Copilot o Bob Modes: deben examinarse minuciosamente y agregarse selectivamente a una lista de permitidos a partir de entonces, en lugar de estar permitidos de manera predeterminada.

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

 IBM Bob, por ejemplo, cuenta con herramientas integradas para aplicar programació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, analizando el código en busca de problemas de complejidad, vulnerabilidades potenciales y oportunidades de refactorización que pueden abordar en línea o revisar más adelante en el panel Bob Findings .

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