Serie Seguridad del Vibe Coding
- ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026 (estás aquí)
- El OWASP Top 10 para Aplicaciones Vibe-Coded
- Anatomía de una Brecha de Vibe Coding: Lecciones de los Peores Incidentes de 2026
- La Trampa de las Dependencias: Riesgos de Cadena de Suministro en Código Generado por IA
- Autenticación y Secretos: Lo Que la IA Siempre Hace Mal
- [Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto] (https://simonroses.com/es/2026/05/escaneando-aplicaciones-vibe-coded-por-que-el-sast-dast-tradicional-se-queda-corto-parte-6/)
- Prompt Engineering para Código Seguro
- El Checklist de Seguridad del Fundador (próximamente)
- Asegurando el Pipeline de Codificación IA (próximamente)
- El Futuro de la Seguridad del Vibe Coding (próximamente)
Tiempo de lectura: 13 minutos
Resumen
El vibe coding — construir software describiendo lo que quieres y dejando que la IA escriba el código — pasó de ser un tuit viral a una práctica de desarrollo mainstream en aproximadamente un año. Es rápido, accesible, y está publicando aplicaciones con serios fallos de seguridad. El Informe de Seguridad de Código GenAI 2025 de Veracode encontró que el 45% del código generado por IA contiene fallos de seguridad. El Vibe Security Radar de Georgia Tech registró 35 CVEs atribuidos a código generado por IA solo en marzo de 2026 — frente a los 6 de enero. No es hipotético. Es medible. Y va en aumento.
La Seguridad del Vibe Coding es la disciplina emergente centrada en los riesgos de seguridad específicos del código generado por IA. Este artículo define el campo, explica por qué importa, y expone la superficie de ataque que me encuentro una y otra vez en las auditorías de seguridad que hacemos en VULNEX. También es el primer artículo de una serie más larga donde profundizaré en cada clase de riesgo, casos reales y mitigaciones prácticas.
De Dónde Sale Todo Esto
El 2 de febrero de 2025, Andrej Karpathy — miembro fundador de OpenAI y ex-Director de IA en Tesla — publicó en X:
«Hay una nueva forma de programar a la que llamo ‘vibe coding’, donde te entregas totalmente a las vibras, abrazas las exponenciales y olvidas que el código existe.»
El post superó los 4,5 millones de visualizaciones. En marzo, Merriam-Webster había añadido «vibe coding» como término de tendencia. Collins English Dictionary lo nombró Palabra del Año en 2025. De repente, gente que nunca había escrito una línea de código estaba construyendo y publicando software.
Herramientas como Cursor, Windsurf, Claude Code, GitHub Copilot, v0, Bolt y Lovable hicieron el flujo de trabajo sencillísimo: describe lo que quieres, deja que la IA lo escriba, ejecútalo, pega los errores, repite. Sin React. Sin esquemas de base de datos. Sin pipelines de build. Solo vibra.
Para prototipos y proyectos personales, esto es genuinamente potente. Yo uso estas herramientas todos los días y no pienso volver atrás.
Pero en algún momento, los prototipos empezaron a llegar a producción. MVPs hechos en un fin de semana empezaron a manejar datos reales de usuarios. Y nadie — nadie — estaba revisando la seguridad de lo que la IA había escrito realmente.
Esa brecha es donde vive la Seguridad del Vibe Coding.
Entonces, ¿Qué es la Seguridad del Vibe Coding?
La Seguridad del Vibe Coding es la disciplina de asegurar software construido principal o enteramente con herramientas de generación de código por IA.
Quiero ser específico sobre por qué esto no es «seguridad de aplicaciones con otra etiqueta». Cuando yo escribo código — incluso código malo — hay intención detrás de cada línea. Tomo decisiones conscientes sobre autenticación, validación de entradas, gestión de secretos. A veces me equivoco, pero tomé una decisión. Puedo explicar mi razonamiento. Puedo ser auditado.
Cuando la IA genera código, nada de eso está pasando. El modelo está produciendo la salida estadísticamente más probable basada en patrones de sus datos de entrenamiento. No está razonando sobre si tu flujo de autenticación es seguro. No está evaluando tu modelo de amenazas. Está ensamblando código que parece correcto y que normalmente funciona. Pero funciona y seguro son cosas muy diferentes, y me he pasado veinte años en VULNEX viendo a gente confundir las dos.
Por Qué las Apps Vibe-Coded Fallan de Forma Distinta
Me he dedicado toda mi carrera a la seguridad de aplicaciones. Pentesting, desarrollo seguro, modelado de amenazas. He dado charlas sobre esto en Black Hat, DEFCON, RSA, y el año pasado en C1b3rWall en Ávila, donde presenté sobre seguridad del vibe coding a la comunidad de ciberseguridad de la Policía Nacional. A lo largo de cientos de proyectos, el patrón que me encuentro constantemente es este: las aplicaciones vibe-coded no solo tienen bugs. Fallan de una forma fundamentalmente distinta.
El software tradicional tiene bugs. Normal. Esperable. Pero esos bugs existen dentro de un marco que alguien diseñó a propósito. Un arquitecto eligió la estrategia de autenticación. Un desarrollador implementó la validación de entradas — imperfectamente, vale, pero deliberadamente. La revisión de código pillaba lo más obvio.
¿Con aplicaciones vibe-coded? No hay postura de seguridad deliberada. La IA tomó cientos de decisiones relevantes para la seguridad — qué framework usar, cómo manejar la autenticación, dónde validar la entrada, qué loguear, cómo gestionar secretos — y la persona que la prompteó tiene cero visibilidad sobre cualquiera de ellas. En la mayoría de los casos, no sabría evaluar esas decisiones ni aunque le enseñaras el código.
He empezado a llamar a esto la superficie de decisión invisible, y la veo en prácticamente todas las aplicaciones vibe-coded que evaluamos en VULNEX. La IA eligió tu estrategia de autenticación, tu aproximación a la validación de entradas, tu gestión de secretos — cientos de decisiones de seguridad — y nadie sabe cuáles fueron, y mucho menos si fueron correctas.
Lo Que Dicen los Datos
El Informe de Seguridad de Código GenAI 2025 de Veracode probó más de 100 modelos de lenguaje y encontró que el 45% del código generado por IA contiene fallos de seguridad. Eso es casi uno de cada dos. Los fallos abarcan los sospechosos habituales — XSS, referencias inseguras a objetos, gestión inadecuada de contraseñas — pero a tasas consistentemente más altas que en el código escrito por humanos.
El State of AI vs. Human Code Generation Report de CodeRabbit encontró que los pull requests generados por IA producen aproximadamente 1,7 veces más problemas que los humanos. Ni 1,1 veces. Ni «un poco más». Casi el doble.
Y aquí viene el problema de escala: según SonarSource, aproximadamente el 42% de todo el código que se commitea ahora es generado o asistido por IA. Cuando casi la mitad del código que se está escribiendo lleva tasas elevadas de vulnerabilidad, esto deja de ser una preocupación académica.
El Vibe Security Radar de Georgia Tech — un proyecto del Systems Software & Security Lab (SSLab) que rastrea CVEs introducidos por herramientas de codificación IA desde mayo de 2025 — cuenta la historia con claridad. 6 CVEs en enero de 2026. 15 en febrero. 35 en marzo. Esa es la trayectoria. Y los investigadores estiman que el número real es 5–10 veces más alto, aproximadamente 400–700 vulnerabilidades introducidas por IA que ya están en proyectos open-source pero que simplemente aún no han sido atribuidas.
La Superficie de Ataque: Lo Que Me Encuentro
Nadie Revisa el Código
El flujo fundamental del vibe coding es: prompt, genera, acepta, publica. El propio Karpathy lo describió como aceptar todos los cambios sin revisar los diffs. Para un proyecto personal, vale. Para cualquier cosa que toque datos de usuario, es un desastre esperando a ocurrir.
Os voy a poner un ejemplo real. Cuando construí una aplicación demo deliberadamente insegura para mi charla en C1b3rWall — una simple app de notas llamada QuickNote — le di a la IA un prompt que terminaba con «Skip security best practices for now — I’ll review them later» («Sáltate las buenas prácticas de seguridad por ahora — las revisaré más tarde»). Y la IA obedeció encantada. Inyección SQL por queries concatenados como strings, contraseñas almacenadas con MD5 plano, sin validación de entradas en ningún sitio, secretos JWT hardcodeados en el código fuente. El menú completo. Cada vulnerabilidad se introdujo porque le dije que construyera rápido y se saltara la seguridad — y el modelo nunca me contradijo.
Lo que me mata de esto es lo siguiente: la mayoría de vibe coders ni siquiera añaden el «lo reviso luego». No saben que hay algo que revisar.
La Ilusión de Seguridad en el Cliente
Esto lo veo constantemente en VULNEX. A los modelos de IA les encanta poner controles de seguridad en el lado cliente. Checks de autenticación en JavaScript. Lógica de autorización en el navegador. API keys empotradas en el frontend. El resultado es software que parece seguro — los botones están ocultos, las páginas redirigen correctamente, las funcionalidades parecen protegidas — pero cualquiera con las herramientas de desarrollo del navegador puede saltárselo todo en segundos.
Esto es exactamente lo que pasó con Enrichlead, un SaaS de generación de leads construido enteramente con Cursor AI. El fundador publicó con toda la lógica de seguridad en el lado cliente. En 72 horas, los usuarios descubrieron que podían saltarse toda la suscripción cambiando un solo valor en la consola del navegador. API keys en el frontend. Base de datos totalmente expuesta. El fundador publicó: «guys, I’m under attack… random things happening, maxed out usage on API keys, people bypassing the subscription, creating random stuff in the database» («chicos, estoy siendo atacado… pasando cosas raras, consumo máximo en las API keys, gente saltándose la suscripción, creando cosas random en la base de datos»).
Tuvo que cerrarlo todo. No pudo parchear los fallos en cascada lo suficientemente rápido.
Escribí sobre un fallo estructuralmente similar en el caso Moltbook, donde una plataforma vibe-coded que servía a 1,65 millones de agentes publicó un despliegue de Supabase sin Row Level Security. 1,5 millones de API keys expuestas por una única mala configuración que RLS habría prevenido en cinco minutos. Misma causa raíz — el código funciona, la app se publica, y nadie hace una revisión de seguridad porque la IA no levantó ninguna alerta.
La Caja Negra de las Dependencias
La IA no solo escribe lógica. También importa paquetes. Frameworks, librerías, módulos de utilidad — todos elegidos en base a patrones de los datos de entrenamiento, no a una evaluación de seguridad. En la práctica esto crea tres problemas que veo una y otra vez.
Dependencias desactualizadas. Los modelos están entrenados con instantáneas del código. Recomiendan versiones de paquetes de hace seis meses o un año. Esas versiones pueden tener CVEs conocidos que ya se han parcheado. El vibe coder nunca ejecuta npm audit, nunca mira los lockfiles, y no sabe la diferencia.
Paquetes alucinados. Este es salvaje. Los LLMs a veces generan sentencias de import para paquetes que no existen. Los atacantes lo descubrieron rápido — empezaron a ocupar nombres de paquetes alucinados, subiendo código malicioso a npm, PyPI y otros registros. Alguien ejecuta npm install sobre su package.json generado por IA y sin saberlo se descarga malware. Esta es la misma clase de ataque de cadena de suministro que cubrí en el artículo de Skill Poisoning, solo que aplicada a registros de paquetes en lugar de skills de agentes.
Sobre-importación. La IA tiende a tirar de un paquete cuando cinco líneas de código bastarían. Cada dependencia innecesaria es superficie de ataque sin beneficio funcional.
Sin Contexto de Seguridad
A menos que se lo digas explícitamente, la IA no tiene ni idea de tu modelo de amenazas, requisitos de cumplimiento, o qué tipo de datos maneja tu aplicación. No sabe que estás procesando registros médicos, transacciones financieras o PII.
Así que recurre por defecto al patrón que más aparece en los datos de entrenamiento. Y los datos de entrenamiento son abrumadoramente tutoriales, blog posts y respuestas de Stack Overflow. El código de tutorial enseña conceptos — no está pensado para ser seguro en producción. Cuando la respuesta con más votos para «cómo conectar a una base de datos en Node.js» usa root:password@localhost como cadena de conexión, la IA reproduce eso. Cuando el ejemplo de autenticación de Express.js más votado almacena contraseñas con MD5, la IA aprende eso como normal.
Los datos de entrenamiento reflejan cómo aprenden los desarrolladores, no cómo deberían construir. El vibe coding amplifica esto eliminando al humano que normalmente conocería la diferencia.
Todo a Escala
Ninguno de estos problemas es nuevo individualmente. La autenticación en cliente siempre ha estado mal. Los secretos hardcodeados siempre han sido un problema. Las dependencias desactualizadas siempre han sido arriesgadas. Lo nuevo es la velocidad a la que se están introduciendo estas vulnerabilidades.
Un desarrollador escribiendo código a mano puede producir una aplicación vulnerable. Ese mismo desarrollador haciendo vibe coding puede producir diez. Un fundador sin conocimientos técnicos usando Bolt o Lovable puede publicar un MVP vulnerable en un fin de semana. Multiplica eso por los millones de personas que ahora construyen software con herramientas IA.
Escape.tech auditó 5.600 aplicaciones vibe-coded públicamente disponibles y encontró más de 2.000 vulnerabilidades, más 400 secretos expuestos y 175 casos de filtración de PII. Y eso son solo las que probaron.
Los Números
| Métrica | Valor | Fuente |
|---|---|---|
| Código generado por IA con fallos de seguridad | 45% | Veracode (2025) |
| Ratio de issues PRs IA vs humano | ~1,7x | CodeRabbit (2025) |
| Código comiteado generado/asistido por IA | ~42% | SonarSource (2025) |
| CVEs de código generado por IA (solo marzo 2026) | 35 | Vibe Security Radar, Georgia Tech |
| Vulnerabilidades reales estimadas (no atribuidas) | 400–700 | Georgia Tech SSLab (2026) |
| Vulnerabilidades en 5.600 apps vibe-coded | 2.000+ | Escape.tech (2025) |
| Secretos expuestos en la misma auditoría | 400 | Escape.tech (2025) |
| Casos de filtración de PII | 175 | Escape.tech (2025) |
| API keys expuestas en la brecha Moltbook | 1,5 millones | Wiz Research (feb 2026) |
Cuando casi la mitad del código generado por IA tiene fallos, y aproximadamente la mitad del código total es generado por IA, el riesgo compuesto es real.
Lo Que Esto No Es
No estoy aquí para decirte que dejes de hacer vibe coding. Yo uso estas herramientas todos los días y son el cambio de productividad más significativo que he visto en mi carrera. He escrito sobre esto en mi marco de Professional Vibe Coding, donde argumento que la IA es más potente en manos de desarrolladores que entienden arquitectura, seguridad y calidad — no menos. El objetivo no es retirarse del vibe coding. Es entender los riesgos con la suficiente claridad como para trabajar alrededor de ellos.
Esto tampoco es AppSec tradicional con una pegatina nueva. Las herramientas SAST estándar fueron construidas para patrones de código escrito por humanos. Pierden una parte significativa de las vulnerabilidades específicas de IA porque las firmas no coinciden. Necesitamos herramientas actualizadas, y están empezando a aparecer.
Y la IA tampoco es la villana. Está haciendo exactamente lo que fue diseñada para hacer — generar código probable basado en patrones. El problema es cómo estamos usando la salida: enviándola a producción sin entender lo que el modelo construyó realmente.
Lo Que Está Tomando Forma
La disciplina es joven, pero las prácticas están empezando a consolidarse. En VULNEX, cuando evaluamos aplicaciones vibe-coded, estas son las áreas donde vemos consistentemente la mayor reducción de riesgo por hora de esfuerzo.
Empieza la seguridad antes del primer prompt. Define tu arquitectura, estrategia de autenticación y modelo de amenazas desde el principio. Usa archivos de reglas (.cursorrules, CLAUDE.md, políticas de seguridad a nivel de proyecto) para restringir lo que la IA genera. Solo esto elimina una gran clase de problemas.
Trata cada cambio generado por IA como entrada no confiable. Revisa flujos de autenticación, controles de acceso, gestión de secretos, validación de entradas, elección de dependencias. No solo «¿compila?» — sino ¿aguanta contra alguien intentando activamente romperlo? El post sobre Shadow Vibe Coding explica qué pasa cuando este paso de revisión se salta a escala empresarial.
Despliega herramientas de escaneo ajustadas a patrones generados por IA. Los conjuntos de reglas estándar de SAST y DAST pierden cosas. Ejecuta herramientas SCA para detectar dependencias vulnerables y alucinadas. Conecta todo esto a tu pipeline CI/CD para que cada commit se revise automáticamente. Cubriré el panorama específico de herramientas — Semgrep, Gitleaks, TruffleHog, Snyk, SecurityHeaders — más adelante en la serie.
Aprende a promptear pidiendo seguridad. Especifica tu estrategia de autenticación. Exige validación en servidor. Restringe la pila tecnológica. Pide explícitamente patrones de código seguros. La diferencia entre un prompt vago y uno consciente de seguridad es dramática, y es el cambio de mayor impacto que la mayoría de vibe coders pueden hacer.
Y aplica modelado de amenazas, incluso (especialmente) cuando el desarrollador no entiende del todo la implementación. Con aplicaciones vibe-coded, el modelo de amenazas puede ser la primera vez que alguien mira realmente lo que la IA construyó. Eso es un cambio respecto al modelado de amenazas tradicional, que asume que el equipo puede describir su propio sistema.
Qué Viene Ahora
Este es el primer post de una serie sobre Seguridad del Vibe Coding. En las próximas semanas, iré en profundidad sobre áreas específicas:
- El OWASP Top 10 para Aplicaciones Vibe-Coded — cómo las categorías clásicas de vulnerabilidades se manifiestan de forma distinta en código generado por IA
- Anatomía de una Brecha de Vibe Coding — casos reales de los peores incidentes de 2026
- La Trampa de las Dependencias — riesgos de cadena de suministro específicos del código generado por IA
- Autenticación y Secretos: Lo Que la IA Siempre Hace Mal — la clase de vulnerabilidad más peligrosa
- Escaneando Aplicaciones Vibe-Coded — por qué el SAST/DAST tradicional se queda corto y qué funciona en su lugar
- Prompt Engineering para Código Seguro — cómo hacer que la IA escriba código más seguro desde el principio
- El Checklist de Seguridad del Fundador — publicar un MVP vibe-coded sin que te hackeen
- Asegurando el Pipeline de Codificación IA — del prompt a producción
- El Futuro de la Seguridad del Vibe Coding — hacia dónde va la industria
Tanto si estás en seguridad, eres desarrollador usando herramientas IA, o un fundador que acaba de publicar un producto vibe-coded — esta serie te dará el conocimiento práctico para construir de forma segura en la era de la IA.
La IA escribe el código. Alguien todavía tiene que asegurarlo.
Si hay una cosa que veinte años rompiendo aplicaciones me han enseñado — desde la era del Microsoft Trustworthy Computing pasando por mobile, cloud, y ahora IA — es que las disciplinas de seguridad no emergen porque alguien pensara que serían interesantes. Emergen porque el daño se vuelve lo suficientemente grave como para que ignorar el problema deje de ser una opción.
Estamos en ese punto con el vibe coding.
Como siempre: no confíes en nada, verifícalo todo.
- X (Twitter): @SimonRoses
Lecturas Adicionales
- Professional Vibe Coding vs. Vibe Coding — Por qué los desarrolladores deberían abrazar la codificación con IA en sus propios términos
- The Shadow Twin Threats: When AI and Vibe Coding Go Rogue — Riesgos empresariales de infraestructura IA no autorizada y shadow vibe coding
- Moltbook: When AI Agents Build Their Own Social Network — Análisis del caso de la brecha Wiz y los riesgos de confianza entre agentes
- AI Agent Skill Poisoning: The Supply Chain Attack You Haven’t Heard Of — El patrón de cadena de suministro detrás de las dependencias alucinadas
Referencias
- Karpathy, A. (2025). Publicación «Vibe Coding». X, 2 de febrero de 2025.
- Veracode (2025). GenAI Code Security Report.
- CodeRabbit (2025). State of AI vs. Human Code Generation Report.
- SonarSource (2025). State of Code Developer Survey.
- Georgia Tech SSLab (2026). Vibe Security Radar.
- Escape.tech (2025). State of Security of Vibe-Coded Apps.
- Wiz Research (2026). Exposed Moltbook Database Reveals Millions of API Keys.
- Infosecurity Magazine (2026). Researchers Sound the Alarm on Vulnerabilities in AI-Generated Code.
