¿Es realmente seguro Vibe Coding? Este artículo de la CMU estudia principalmente la evaluación comparativa de vulnerabilidades del código generado por agentes en tareas reales. Si bien los agentes de IA tienen un rendimiento cada vez mejor en cuanto a la funcionalidad del código generado, son sorprendentemente vulnerables en términos de seguridad. Incluso en código que funciona perfectamente, más del 80 % presenta graves vulnerabilidades de seguridad. Antecedentes: ¿Qué es la codificación de vibraciones? ¿Por qué es peligrosa? "Vibe Coding" es un paradigma de programación emergente: en lugar de escribir código línea por línea, los programadores utilizan lenguaje natural para dar instrucciones vagas o de alto nivel, que luego son utilizadas por un agente LLM para completar automáticamente tareas de codificación complejas. Situación actual: Este método mejora enormemente la eficiencia y el 75% de los encuestados lo utiliza. Riesgo potencial: Los usuarios a menudo solo consideran si el código funciona (funcionalidad), y rara vez tienen la capacidad o la disposición para analizar a fondo si es seguro. El documento señala que esta confianza ciega introduce importantes riesgos de seguridad en el entorno de producción. Metodología de investigación: Benchmark SUSVIBES Para verificar la seguridad, el equipo creó un nuevo conjunto de pruebas de rendimiento llamado SUSVIBES. Fuente real: a diferencia de las pruebas anteriores que solo evaluaban archivos/funciones simples, SUSVIBES extrajo 200 requisitos de características complejos de proyectos de código abierto del mundo real (GitHub) que históricamente habían experimentado vulnerabilidades de seguridad. Proceso de prueba: • Busque una vulnerabilidad que haya sido parcheada (por ejemplo, una versión que haya parcheado la inyección SQL). • Revertir el código a su estado anterior a la corrección y hacer que el Agente de IA vuelva a implementar la funcionalidad. • Verificación dual: ejecutar tanto "pruebas funcionales" (para ver si la función está implementada) como "pruebas de seguridad" (para ver si se reproduce la vulnerabilidad original). Hallazgo clave: El inquietante fenómeno de "puntuaciones altas, habilidades bajas" El equipo probó los frameworks de agentes más avanzados (SWE-Agent, OpenHands) y modelos (Claude 4 Sonnet, Gemini 2.5 Pro, Kimi K2). Los resultados son muy alarmantes: Poderoso pero extremadamente inseguro: La combinación de mejor rendimiento (SWE-Agent + Claude 4 Sonnet) resolvió el 61% de las tareas (funcionando correctamente). Sin embargo, de estos códigos que funcionan correctamente, sólo el 10,5% son seguros. En otras palabras, más del 80% del “buen código” en realidad contiene vulnerabilidades graves (como condiciones de carrera, escalada de privilegios, ataques de inyección, etc.). Diferencias entre modelos: • Soneto Claude 4: El más poderoso, pero también el que genera más vulnerabilidades. • Gemini 2.5 Pro: aunque la tasa de aprobación de la función es baja (19,5%), es relativamente seguro entre los problemas que puede resolver (clasificado como el modelo relativamente "más seguro"). • Kimi K2: De nivel intermedio. El mensaje de seguridad no es válido. Los investigadores intentaron decirle a la IA: "Tenga cuidado" y "Compruebe si hay vulnerabilidades de CWE". • Resultado: no solo no se mejoró significativamente la seguridad, sino que la IA se volvió hipersensible e incluso las funciones normales no se pudieron escribir correctamente (la tasa de aprobación de funciones se redujo en aproximadamente un 6%). Estudio de caso: ¿Cómo surgió la vulnerabilidad? El artículo proporciona un ejemplo vívido (la función de verificación de contraseña en el marco Django): • Tarea: Implementar una función verify_password. Enfoque de la IA: El código está impecablemente escrito y la lógica es correcta. Sin embargo, al encontrar usuarios no válidos, la IA devuelve directamente "Falso" por eficiencia. Consecuencias de seguridad: Esto crea una vulnerabilidad de **canal lateral de tiempo**. Los hackers pueden determinar la existencia de un nombre de usuario en el sistema detectando diferencias mínimas en los tiempos de respuesta. Conclusión: La IA a menudo se centra únicamente en la "corrección lógica" y no logra comprender los principios más profundos de la "ingeniería de seguridad" (como la comparación en tiempo constante). Resumen y recomendaciones: Este artículo sirve como una llamada de atención ante la locura actual de la programación de IA. Para desarrolladores: Nunca confíen ciegamente en el código generado por IA, especialmente en módulos sensibles como autenticación, cifrado y análisis de datos. "Se ejecuta" es "seguro". Para las empresas: al adoptar herramientas de programación de IA (como Cursor, Claude Code), es obligatorio introducir revisiones de seguridad humanas o escaneos de seguridad automatizados (SAST/DAST), y no depender únicamente de pruebas unitarias. Dirección futura: Las indicaciones simples no pueden resolver los problemas de seguridad; necesitamos una nueva generación de agentes capacitados específicamente para la seguridad. Artículo original
