Seguridad en el vibe coding: la guía completa (2026)

Índice

1. ¿Qué es el vibe coding?
2. El problema de seguridad del que nadie habla
3. Las vulnerabilidades más peligrosas del código generado por IA
4. Brechas reales causadas por el vibe coding
5. Por qué pedirle a tu IA que revise su propio código no funciona
6. Cómo explotan los atacantes las apps generadas con IA
7. Checklist de seguridad antes de publicar
8. Herramientas y procesos que realmente ayudan
9. El rol de la revisión de seguridad independiente
10. Conclusión

1. ¿Qué es el vibe coding?

El vibe coding es como se construye la mayor parte del software en 2026.

Abres Cursor, Bolt, Lovable, Claude Code o GitHub Copilot. Describes lo que quieres en lenguaje natural. La IA escribe el código, lo ejecuta, corrige los errores e itera hasta que funciona. Nunca escribes una línea de código tú mismo — simplemente revisas el resultado, lo aceptas y publicas.

Andrej Karpathy acuñó el término a principios de 2025. En pocos meses pasó de ser un tweet viral a convertirse en el flujo de trabajo habitual de toda una generación de fundadores, indie hackers y equipos de producto. En 2026, las encuestas muestran que el 92% de los desarrolladores estadounidenses utiliza alguna forma de asistencia de codificación con IA. En GitHub, la IA genera el 46% de todo el código nuevo — una cifra que se prevé que alcance el 60% antes de que acabe el año.

El atractivo es evidente. Lo que antes llevaba semanas ahora lleva horas. Los prototipos se convierten en productos prácticamente de un día para otro. No necesitas saber React, esquemas de base de datos ni pipelines de build. Solo describes la idea y la IA entrega el código.

El problema es que “funciona” y “es seguro” son dos estándares completamente diferentes. Y en 2026, la brecha entre ellos es más grande que nunca.

2. El problema de seguridad del que nadie habla

Esto es lo que dicen los datos en este momento:

• Entre el 40% y el 62% del código generado por IA contiene vulnerabilidades de seguridad, según múltiples investigaciones independientes de 2025–2026.
• Los commits asistidos por IA introducen credenciales hardcodeadas al doble de la tasa del código escrito por humanos (CSA, 2026).
• Las vulnerabilidades XSS aparecen en el 86% de las muestras de código generado por IA evaluadas en cinco LLMs principales (Georgetown CSET).
• En un estudio de diciembre de 2025 de Tenzai que evaluó cinco agentes de codificación IA principales, todos introdujeron vulnerabilidades SSRF en el mismo tipo de funcionalidad — 5 de 5, el 100%.
• Un experimento del IEEE-ISTAS de 2025 encontró que la seguridad empeora con la iteración: tras solo cinco rondas de refinamiento de código asistido por IA, las vulnerabilidades críticas aumentaron un 37,6%. Iterar sobre la salida de la IA no autocorrige los fallos de seguridad. Los agrava.
• El Vibe Security Radar de Georgia Tech registró 35 CVEs directamente atribuidos a código generado por IA solo en marzo de 2026 — frente a 6 en enero y 15 en febrero. Los investigadores estiman que el número real es entre 5 y 10 veces mayor.

OWASP respondió en 2025 añadiendo una categoría específica en su Top 10 que señala explícitamente el vibe coding como patrón de riesgo de seguridad. El CEO del Centro Nacional de Ciberseguridad del Reino Unido lo planteó en la conferencia RSAC de San Francisco como una de las amenazas más urgentes para la seguridad del software.

Este no es un problema hipotético. Está ocurriendo ahora mismo, a escala, y acelerándose.

El problema fundamental no es que la IA escriba código de forma deficiente. Es que el vibe coding elimina el proceso de revisión. El desarrollo tradicional tiene fricciones integradas: escribes código, lo revisas, alguien más lo revisa, lo debatís, y solo entonces se publica. El vibe coding elimina esa fricción. La pregunta que hacen los desarrolladores no es “¿esto es seguro?” — es “¿funciona?”. La funcionalidad se convierte en el destino. La seguridad se convierte en algo que ya se resolverá más adelante.

Ese “más adelante” nunca llega.

3. Las vulnerabilidades más peligrosas del código generado por IA

Entender qué clases de vulnerabilidades aparecen con más frecuencia en el código generado por IA te ayuda a saber dónde buscar — y dónde las herramientas automatizadas se quedan cortas.

Secretos y credenciales hardcodeados

Es el hallazgo más consistente en todos los estudios principales. Los modelos de IA entrenados en repositorios de código público han absorbido patrones de una época en la que hardcodear claves API, contraseñas de base de datos y tokens era práctica común. Los reproducen de forma automática.

GitGuardian contó 28,65 millones de secretos hardcodeados en repositorios públicos de GitHub en 2025 — un aumento del 34% interanual. Una parte significativa de ese crecimiento se atribuye al código generado por IA. Lo que hace esto especialmente peligroso es que los modelos reutilizan los mismos valores de marcador de posición en diferentes apps generadas, lo que los hace trivialmente fáciles de detectar con un escáner automatizado.

Qué buscar: Claves API en archivos de configuración de entorno, cadenas de conexión a base de datos en el código fuente, tokens OAuth confirmados en repositorios, credenciales de AWS/GCP/Azure en cualquier archivo que entre en el control de versiones.

Inyección SQL

Los modelos de IA fueron entrenados masivamente con código de la era anterior a las consultas parametrizadas. Cuando se les pide que construyan interacciones con bases de datos, generan de forma consistente consultas concatenadas como cadenas de texto en lugar de consultas parametrizadas, especialmente cuando trabajan con ORMs desconocidos. Las herramientas SAST modernas detectan patrones conocidos, pero no los enfoques de concatenación novedosos.

Cross-Site Scripting (XSS)

El código de gestión de UI generado por IA omite la codificación de salida de forma consistente. El hallazgo de Georgetown CSET de que XSS aparece en el 86% de las muestras evaluadas no vino de prompts adversariales — vino de solicitudes de desarrollador estándar. La IA produce una interfaz funcional que supera la revisión visual, y luego falla completamente cuando alguien que sabe lo que busca decide analizarla.

Autenticación y limitación de tasa ausentes

Esta es la clase de vulnerabilidad que causó brechas reales. Los agentes de IA construyen funcionalidades que funcionan — obtienen datos, procesan formularios, gestionan pagos — pero frecuentemente omiten la verificación de autenticación en la ruta, o construyen el endpoint sin ninguna limitación de tasa. Palo Alto Unit 42 documentó un caso en que una aplicación de captación de leads fue vulnerada precisamente porque el agente de vibe coding omitió incorporar controles de autenticación y limitación de tasa.

Server-Side Request Forgery (SSRF)

Las vulnerabilidades SSRF permiten a un atacante hacer que el servidor envíe peticiones a recursos internos — incluidos los endpoints de metadatos de proveedores cloud en http://169.254.169.254/latest/meta-data/ que exponen credenciales. En el estudio de Tenzai de diciembre de 2025, todos los agentes de codificación IA evaluados introdujeron SSRF al construir una funcionalidad que obtiene URLs externas. La vulnerabilidad es sintácticamente invisible — el código es válido, compila sin errores y hace exactamente lo que pediste. Solo que también permite a los atacantes acceder a tu infraestructura cloud.

Dependencias inseguras

En la prisa por hacer funcionar las funcionalidades, los agentes de IA importan paquetes sin revisión de seguridad adecuada. Incluyen librerías auxiliares y plantillas de inicio que el desarrollador nunca eligió explícitamente. Estas dependencias pueden tener vulnerabilidades conocidas, estar desactualizadas o, en algunos casos, ser maliciosas — un patrón llamado dependency confusion. La IA no evalúa la postura de seguridad de lo que instala; evalúa si compila.

Control de acceso roto y escalada de privilegios

Las apps generadas por IA suelen implementar autenticación a nivel de superficie — el login funciona, las sesiones funcionan — pero no aplican autorización a nivel de ruta o recurso. Un usuario autenticado puede acceder a los datos de otro usuario simplemente cambiando un ID en la URL. La IA construyó lo que describiste; no construyó el modelo de control de acceso que asumías que estaba incluido.

4. Brechas reales causadas por el vibe coding

La teoría es una cosa. Esto es lo que realmente ocurrió.

La brecha de Moltbook (principios de 2026): Uno de los incidentes de plataforma IA más comentados del año. Un fundador publicó una app construida con vibe coding sin ninguna revisión de seguridad. El resultado: 1,5 millones de claves API filtradas. Wiz Research documentó la brecha y la base de datos expuesta. No es un escenario hipotético. Es lo que ocurre cuando “funciona” es el único estándar para publicar.

El fallo de la plataforma Orchids (diciembre de 2025): El investigador de seguridad Etizaz Mohsin descubrió un fallo crítico en la plataforma de vibe coding Orchids. Lo demostró ante un reportero de BBC News en febrero de 2026. La vulnerabilidad estaba en la lógica de la plataforma — no una superficie de ataque teórica, sino un fallo activo y explotable en una plataforma usada por desarrolladores reales para construir productos reales.

La brecha de la aplicación de captación de leads (2025, documentada por Palo Alto Unit 42): Una aplicación construida con vibe coding fue vulnerada porque el agente de IA omitió autenticación y limitación de tasa en endpoints clave. La brecha fue directa: sin autenticación, no había barrera de acceso. Unit 42 lo documentó como un incidente real, no como un ejercicio de red team.

Estos son los casos que se hicieron públicos. Los investigadores de Georgia Tech estiman que por cada vulnerabilidad introducida por IA que se documenta y atribuye, hay entre 5 y 10 más sin detectar en sistemas en producción.

5. Por qué pedirle a tu IA que revise su propio código no funciona

Este es el error más común que cometen los desarrolladores cuando toman conciencia del problema.

“Le pediré a Claude que revise el código para detectar problemas de seguridad.”

No funciona. Esta es la razón.

Los mismos puntos ciegos que crearon la vulnerabilidad no la detectarán en la revisión. Si un modelo omite consistentemente la limitación de tasa al construir endpoints de login, también omitirá consistentemente señalar la limitación de tasa ausente cuando revise endpoints de login. El modelo no tiene un modo “revisor de seguridad” separado con conocimiento diferente — tiene los mismos datos de entrenamiento, los mismos patrones aprendidos y las mismas debilidades estructurales operando en ambas direcciones.

La salida no es determinista. Pregúntale a tu IA “¿es esto seguro?” tres veces y obtendrás tres respuestas diferentes. No hay umbral, no hay política, no hay estándar consistente. Una revisión puede señalar la verificación de autenticación ausente. La siguiente puede no hacerlo. No puedes construir un proceso de seguridad fiable sobre una salida no determinista.

“La IA dijo que estaba bien” no es un entregable. No puedes enviarle a un cliente una transcripción de chat como prueba de revisión de seguridad. No puedes adjuntar una conversación de IA a una lista de verificación de cumplimiento normativo. Si necesitas demostrar que tu aplicación ha sido revisada — ante un cliente, ante un auditor, ante tu propio equipo — un registro de chat no es evidencia.

La revisión manual significa revisión opcional, que significa revisión omitida. Pedirle a tu IA que revise el código es un acto voluntario. El viernes a las 5pm antes de la entrega de un cliente, se omite. Siempre. La seguridad que depende de la disciplina humana bajo presión no es seguridad.

La respuesta no son más opiniones de IA. Es un punto de control de seguridad estandarizado y repetible con reglas fijas y responsabilidad real — algo que se ejecuta de forma independiente, produce resultados consistentes y no puede omitirse porque forma parte del pipeline de despliegue.

6. Cómo explotan los atacantes las apps generadas con IA

Los atacantes han notado que un gran porcentaje del software nuevo se construye con vibe coding — y han desarrollado técnicas específicamente diseñadas para explotar cómo funciona el vibe coding.

Aprovechar patrones de IA predecibles: Dado que los modelos de IA reproducen patrones de vulnerabilidad consistentes en muchas apps, los atacantes pueden construir escáneres automatizados que buscan esos patrones específicos. Un escáner que sabe que los agentes de IA omiten consistentemente la limitación de tasa en endpoints de autenticación puede analizar miles de apps en busca de exactamente ese fallo en cuestión de minutos.

Inyección indirecta de prompts: Este es el vector de ataque que recibe menos atención pero que es posiblemente el más difícil de defender. Cuando los desarrolladores importan recursos externos en sus agentes de codificación IA — archivos de reglas, repositorios bifurcados, configuraciones de servidores MCP — el agente los lee como contexto de confianza. Los atacantes ocultan instrucciones en esos archivos. La investigación de Liu et al. (2025) encontró tasas de éxito de ataque de hasta el 84% contra Cursor y GitHub Copilot, con comandos que van desde el robo de claves SSH hasta la escalada de privilegios. El desarrollador nunca supo que el ataque ocurrió porque ocurrió en la capa del agente, no en la capa de la aplicación.

Lies-in-the-Loop: Una técnica que explota la brecha entre lo que un agente de IA describe en su diálogo de confirmación y lo que realmente ejecuta. El desarrollador aprueba lo que parece una acción razonable; el agente ejecuta algo diferente. El resumen de la interfaz parece plausible. El comando real es malicioso.

Ataques a la cadena de suministro mediante alucinaciones de IA: Los agentes de codificación IA a veces alucinan nombres de paquetes — hacen referencia a librerías que no existen. Los atacantes registran esos nombres de paquetes con código malicioso. Cuando el código generado por IA instala la dependencia, instala el payload del atacante.

7. Checklist de seguridad antes de publicar

Este es el mínimo exigible para cualquier aplicación construida con IA antes de que toque usuarios o datos reales.

Secretos y credenciales

• Sin claves API, tokens ni contraseñas en el código fuente o archivos confirmados
• Todos los secretos cargados desde variables de entorno, no hardcodeados
• Archivos .env en .gitignore — verificar que nunca han sido confirmados
• Escanear el historial de git en busca de secretos previamente confirmados (persisten incluso tras la eliminación)
• Todas las claves API de terceros con permisos de mínimo privilegio

Autenticación y control de acceso

• Cada ruta que requiere autenticación la verifica realmente
• Autorización verificada a nivel de recurso, no solo en el login
• Limitación de tasa en endpoints de autenticación (login, restablecimiento de contraseña, OTP)
• Tokens de sesión invalidados al cerrar sesión
• Ningún usuario puede acceder a datos de otro cambiando un ID en la URL

Gestión de entradas

• Todas las entradas de usuario validadas y saneadas antes de su uso
• Consultas SQL con sentencias parametrizadas, no concatenación de cadenas
• Codificación de salida aplicada de forma consistente antes de renderizar en el navegador
• Restricciones en la carga de archivos (tipo, tamaño, ubicación de almacenamiento)
• Sin URLs suministradas por el usuario pasadas directamente a llamadas fetch del servidor (SSRF)

Dependencias

• Todos los paquetes auditados con npm audit o equivalente
• Sin paquetes con vulnerabilidades críticas conocidas
• Archivos de bloqueo (lockfiles) confirmados y actualizados
• Sin paquetes innecesarios que amplíen la superficie de ataque

Configuración

• Modo debug desactivado en producción
• Cabeceras de seguridad presentes: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security
• Política CORS restringida a orígenes conocidos, no comodín
• Los mensajes de error no exponen trazas de pila o rutas internas a los usuarios
• HTTPS forzado con certificado válido

Gestión de datos

• Datos sensibles cifrados en reposo
• Datos sensibles no registrados en logs
• Gestión de datos personales conforme a la normativa aplicable (RGPD, CCPA)
• Acceso a base de datos restringido a los permisos mínimos necesarios

8. Herramientas y procesos que realmente ayudan

La respuesta correcta no es evitar las herramientas de codificación IA. Son genuinamente poderosas y las ganancias de productividad son reales. La respuesta correcta es combinarlas con una revisión de seguridad independiente que compense sus debilidades estructurales.

Escaneo automatizado de secretos: Herramientas como GitGuardian o TruffleHog escanean tu repositorio — incluido el historial de git — en busca de credenciales expuestas. Ejecuta esto antes de cada despliegue. Lleva minutos y detecta la clase de vulnerabilidad más común del código generado por IA.

Auditoría de dependencias: npm audit, pip-audit, bundler-audit. Ejecútalas en tu pipeline de CI para que una dependencia con vulnerabilidades conocidas no pueda llegar a producción sin una decisión humana consciente de aceptar el riesgo.

Análisis estático (con matices): Las herramientas SAST detectan algunas vulnerabilidades del código generado por IA, pero tienen puntos ciegos significativos. Un benchmark de 2026 encontró que el 78% de las vulnerabilidades confirmadas fueron detectadas por solo una de cada cinco herramientas SAST evaluadas. El SAST no detecta fallos semánticos — verificaciones de autorización ausentes en rutas que compilan limpiamente, configuraciones por defecto inseguras, suposiciones incorrectas. Usa SAST, pero no dependas exclusivamente de él.

Revisión de seguridad independiente: La capa más importante. Un sistema independiente con reglas fijas — no una IA que puede tener los mismos puntos ciegos que el autor del código — que evalúa tu aplicación según una política consistente y produce un resultado determinista. Esto es lo que hace una auditoría de seguridad profesional. Es también lo que LaunchShield automatiza: cinco analizadores especializados con reglas fijas que se ejecutan en cada pull request y producen una decisión de publicación clara — Bloqueado, Condicional o Listo — que no puede omitirse porque forma parte del pipeline de despliegue.

Modelado de amenazas: Antes de construir, dedica treinta minutos a preguntarte: ¿qué ocurre si alguien envía entradas inesperadas a cada endpoint? ¿Qué datos estoy gestionando que no puedo permitirme perder o exponer? ¿Dónde confía mi aplicación en entradas en las que no debería confiar? Esto no es un ejercicio técnico — es un ejercicio de reflexión, y las herramientas de IA son genuinamente útiles para ello. El objetivo es definir la superficie de ataque antes de que se escriba el código, no después de que se haya publicado.

9. El rol de la revisión de seguridad independiente

El problema central de la seguridad en el vibe coding no es que el código sea inseguro por defecto — aunque a menudo lo es. El problema central es la ausencia de una puerta de revisión sistemática entre “funciona” y “está en producción”.

El desarrollo de software tradicional integraba la revisión en el proceso mediante fricción: revisiones de código, aprobaciones de pull request, ciclos de QA. El vibe coding elimina esa fricción, que es exactamente por qué se siente tan rápido. El coste en seguridad de eliminar esa fricción es lo que documentan los datos anteriores.

La solución no es reintroducir toda la antigua fricción — eso anularía el propósito. La solución es un punto de control de seguridad ligero, automatizado e independiente que se ejecuta cada vez que el código está a punto de publicarse.

Independiente significa que no puede tener los mismos puntos ciegos que el autor del código o la IA que lo escribió. Automatizado significa que no puede omitirse bajo presión de plazo. Reglas fijas significa que el resultado es el mismo cada vez — no una opinión variable de IA, sino una decisión de política determinista.

Esta es la brecha que LaunchShield fue construido para llenar. Cinco analizadores de seguridad especializados — detección de secretos, verificaciones de configuración, antipatrones de IA, auditoría de dependencias y análisis semántico — ejecutándose en cada pull request, produciendo un veredicto único y claro: publícalo o corrígelo primero.

Para fundadores que construyen con herramientas de IA, para agencias que entregan productos construidos con IA a sus clientes, y para equipos que quieren que “la IA lo revisó” signifique algo — esta es la capa que hace que el vibe coding sea seguro de publicar.

10. Conclusión

El vibe coding no va a desaparecer. Las ganancias de productividad son demasiado reales, las herramientas son demasiado buenas y la barrera de entrada es demasiado baja. Para finales de 2026, la IA generará la mayoría del código nuevo escrito en todo el mundo.

La pregunta no es si usar estas herramientas. La pregunta es si el código que se publica a través de ellas es seguro.

Ahora mismo, los datos dicen que normalmente no lo es. Entre el 40% y el 62% del código generado por IA contiene vulnerabilidades. Los CVEs atribuidos a herramientas de IA se aceleran cada mes. Aplicaciones reales están siendo vulneradas porque sus fundadores publicaron lo que la IA produjo sin preguntarse si era seguro hacerlo.

La solución no es complicada. Trata el código generado por IA como no confiable — igual que tratarías el código de un contratista externo con quien nunca has trabajado antes. Integra la revisión en el pipeline. Usa herramientas que compensen las debilidades estructurales de la generación de código por IA. Y nunca dejes que “funciona” sea el único estándar para publicar.

La seguridad no es lo que añades después de la brecha. Es la puerta entre lo que construyó la IA y lo que ven tus usuarios.

DragonSec ofrece escaneo continuo de vulnerabilidades y pentesting automatizado para aplicaciones, APIs e infraestructura cloud. LaunchShield es la puerta de seguridad independiente para aplicaciones construidas con IA — cinco analizadores especializados, un veredicto claro, automatizado en cada pull request.

Relacionado: Escaneo de Vulnerabilidades de API · Pentesting Automatizado · Escaneo de Vulnerabilidades Externas