Serie Seguridad del Vibe Coding
- ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026
- El OWASP Top 10 para Aplicaciones Vibe-Coded (estás aquí)
- 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 (próximamente)
- 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: 15 minutos
Resumen
El OWASP Top 10 se actualizó en 2025 — la primera vez desde 2021 — y encaja sorprendentemente bien con las vulnerabilidades que me encuentro una y otra vez en aplicaciones vibe-coded. Pero hay un matiz: cuando la IA escribe el código, estas categorías clásicas no solo aparecen. Aparecen de forma distinta. La inyección no es lo mismo cuando nadie escribió la query. El control de acceso roto no es lo mismo cuando la IA pone los checks de autenticación en el navegador. La mala configuración de seguridad no es lo mismo cuando el desarrollador no puede decirte qué configuró la IA.
Este artículo recorre las diez categorías y muestra cómo cada una se manifiesta en código generado por IA, con ejemplos concretos de casos reales y datos de Veracode, Apiiro, Escape.tech y Wiz. Si leíste la Guía de Campo (Parte 1 de esta serie), ya conoces la superficie de ataque. Este artículo la mapea al framework que todo equipo de seguridad ya utiliza.
Por Qué Importa Este Mapeo
En VULNEX, cuando hacemos test de penetración para clientes, reportamos hallazgos contra OWASP. Es el lenguaje compartido de la seguridad de aplicaciones web. Todos los equipos de seguridad lo conocen. Todos los marcos de cumplimiento lo referencian. Así que cuando empecé a ver aplicaciones vibe-coded de forma consistente en nuestro pipeline — MVPs, herramientas internas, productos de startups construidos con Cursor, Bolt, Lovable — la cuestión no era si tendrían problemas de OWASP. Era qué problemas, y cómo la intervención de la IA cambiaba la naturaleza de los hallazgos.
Después de decenas de estas evaluaciones, puedo deciros: las categorías son las mismas, pero las causas raíz son fundamentalmente distintas. Cuando un desarrollador humano publica una inyección SQL, normalmente es porque tomó un atajo bajo presión de plazos. Sabe que está mal. Cuando una IA publica una inyección SQL, es porque las queries con concatenación de strings aparecen millones de veces en los datos de entrenamiento y el modelo no tiene concepto de que haya nada malo en ellas.
Esa distinción importa para la remediación. No puedes simplemente señalar la guía de testing de OWASP a un vibe coder y decirle que arregle su código. No lo escribió él. En muchos casos, ni puede leerlo.
OWASP publicó la edición 2025 en noviembre — la primera actualización desde 2021. Dos categorías nuevas (Fallos de Cadena de Suministro de Software y Manejo Inadecuado de Condiciones Excepcionales), SSRF fusionado con Control de Acceso Roto, y datos actualizados en toda la lista. Veamos cómo juega cada categoría cuando la IA escribió el código.
A01:2025 — Control de Acceso Roto
Lo clásico: Los usuarios acceden a recursos o realizan acciones más allá de sus permisos previstos.
La versión vibe-coded: La IA pone los controles de acceso en el lugar equivocado.
Este es el hallazgo número uno en la actualización de OWASP 2025, con 100% de prevalencia en las aplicaciones analizadas. Y en aplicaciones vibe-coded, lo veo en prácticamente cada proyecto. El patrón es siempre el mismo: la IA genera un frontend precioso con elementos de UI basados en roles — botones de administración ocultos para usuarios normales, funcionalidades premium bloqueadas visualmente — y pone cero enforcement en el lado servidor.
Escribí sobre Enrichlead en la Guía de Campo. Es el caso de libro: un SaaS construido con Cursor donde todos los controles de acceso eran JavaScript del lado cliente. Los usuarios se saltaron toda la suscripción cambiando un valor en la consola del navegador. Pero he visto este patrón docenas de veces desde entonces. No es un problema de Cursor. Es un problema de generación de código por IA.
Esto es lo que la IA típicamente genera para una ruta «protegida» de administración:
// Guard de ruta frontend — lo que genera la IA
const AdminPage = () => {
const { user } = useAuth();
if (user.role !== 'admin') return <Navigate to="/" />;
return <AdminDashboard />;
};Parece seguro. La página de admin redirige a los no-admins. Pero llama directamente a la API — GET /api/admin/users — y no hay middleware comprobando roles. La API devuelve todo a cualquiera. La IA construyó la apariencia de control de acceso sin la realidad de este.
La investigación de Apiiro en empresas Fortune 50 encontró que el código generado por IA crea 322% más rutas de escalación de privilegios que el código escrito por humanos. No 22%. Trescientos veintidós por ciento. La IA es excelente construyendo la UI. Es terrible construyendo la capa de enforcement.
Wiz Research confirmó este patrón a escala: el 20% de las aplicaciones vibe-coded que analizaron tenían vulnerabilidades graves, con autenticación ausente y mala configuración de seguridad en bases de datos (específicamente, políticas de Row-Level Security ausentes o permisivas) entre los principales hallazgos.
A02:2025 — Mala Configuración de Seguridad
Lo clásico: Credenciales por defecto, funcionalidades innecesarias habilitadas, cabeceras de seguridad ausentes, mensajes de error verbosos.
La versión vibe-coded: Nadie sabe qué configuró la IA.
Este me saca de quicio durante las evaluaciones. Con una aplicación tradicional, puedes sentarte con el equipo de desarrollo y repasar sus decisiones de configuración. Con una aplicación vibe-coded, el desarrollador literalmente no puede decirte por qué la IA eligió una configuración particular del framework, qué valores por defecto dejó activos, o qué cabeceras de seguridad puso o dejó de poner.
En mi demo de C1b3rWall — la app QuickNote que construí deliberadamente insegura para la charla — la IA publicó alegremente con DEBUG=True, stack traces expuestos al navegador, CORS a *, y cero rate limiting en ningún endpoint. Cada una de esas es una mala configuración de seguridad. Y cada una vino del comportamiento por defecto de la IA, no de una decisión consciente de un desarrollador.
La auditoría de Escape.tech de 5.600 aplicaciones vibe-coded encontró que el 65% tenía problemas de seguridad y el 58% contenía al menos una vulnerabilidad crítica. Tokens de Supabase expuestos accesibles desde bundles del frontend. APIs mal configuradas. Políticas de RLS ausentes. No son bugs sofisticados. Son malas configuraciones que la IA dejó porque nadie le dijo que las cambiara — y nadie sabía que había que comprobarlo.
Los datos de entrenamiento de la IA son abrumadoramente código de tutoriales. Los tutoriales optimizan para claridad, no seguridad. Dejan el modo debug activado. Desactivan las restricciones CORS. Saltan el rate limiting. Cuando la IA genera una aplicación de producción basada en esos patrones, obtienes una aplicación de producción con configuración de tutorial.
A03:2025 — Fallos de Cadena de Suministro de Software
Lo clásico: Dependencias comprometidas, falta de verificación de integridad, pipelines CI/CD inseguros.
La versión vibe-coded: La IA elige tus dependencias, y algunas no existen.
Esta es una categoría nueva en OWASP 2025 — y una de las más relevantes para aplicaciones vibe-coded. Cubrí el problema de dependencias en la Guía de Campo, pero merece profundizar en el contexto de OWASP.
La IA no solo escribe lógica. Importa paquetes. Cuando prompteas «constrúyeme un formulario de registro de usuario con validación de email», el modelo recurre a sus datos de entrenamiento y tira de los paquetes que eran populares cuando fue entrenado. Esas versiones pueden tener seis meses o un año. Pueden tener CVEs conocidos que fueron parcheados semanas después del corte de entrenamiento del modelo.
Pero el riesgo de cadena de suministro va más allá de las versiones desactualizadas. Los LLMs a veces generan sentencias de import para paquetes que no existen — paquetes alucinados. Investigadores han documentado este fenómeno repetidamente: atacantes monitorizan código generado por IA buscando nombres de paquetes alucinados, registran esos nombres en npm o PyPI y suben malware. Alguien ejecuta npm install sobre su package.json generado por IA y descarga un paquete que la IA inventó, solo que ahora un atacante es dueño del nombre.
Esta es la misma clase de cadena de suministro que cubrí en el artículo de Skill Poisoning, pero aplicada a registros de paquetes en lugar de skills de agentes. La superficie de ataque es estructuralmente idéntica: un ecosistema donde los nombres se confían y el registro es fácil, combinado con un sistema automatizado que genera nombres que suenan plausibles.
En VULNEX, ahora ejecutamos escaneos SCA como primer paso en cada proyecto con aplicaciones vibe-coded. En al menos un tercio de los casos, encontramos dependencias con vulnerabilidades conocidas que la IA trajo de sus datos de entrenamiento.
A04:2025 — Fallos Criptográficos
Lo clásico: Algoritmos débiles, cifrado ausente, claves gestionadas de forma inadecuada.
La versión vibe-coded: La IA usa por defecto el patrón de criptografía que más votos tiene en Stack Overflow.
Esta es una de esas áreas donde la cifra de titular — el 86% de tasa de aprobación de Veracode para CWE-327 (selección de algoritmo criptográfico) — en realidad enmascara el problema real. Los modelos son decentes eligiendo AES sobre DES cuando les pides cifrado explícitamente. Donde fallan consistentemente es en las decisiones criptográficas de alrededor: cómo se gestionan las claves, cómo se hashean las contraseñas, cómo se almacenan los tokens. Su actualización de primavera 2026 mostró que a pesar de los modelos más nuevos, las tasas de aprobación de seguridad general se mantienen estancadas en torno al 55% — los modelos se han vuelto mucho mejores escribiendo código que compila, pero no código que sea seguro.
Esto es lo que veo consistentemente en aplicaciones vibe-coded:
// Lo que genera la IA para hashear contraseñas
const crypto = require('crypto');
const hash = crypto.createHash('md5').update(password).digest('hex');MD5. Sin sal. En 2026. El modelo genera esto porque los ejemplos de hash con MD5 dominan sus datos de entrenamiento. Debería estar usando bcrypt, scrypt o Argon2 — pero estos aparecen menos frecuentemente en tutoriales y respuestas de Stack Overflow, así que pierden la votación estadística.
El manejo de JWT es otro fallo consistente. La IA genera una función de verificación JWT perfectamente funcional que comprueba la firma correctamente pero hardcodea el secreto (const JWT_SECRET = 'mysecretkey123'), almacena tokens en localStorage (accesible por XSS), y se salta la validación de issuer o audience. Cada componente individual funciona. El agregado es criptográficamente débil.
En la demo de QuickNote que mostré en C1b3rWall, la IA almacenó contraseñas con MD5 plano y puso el secreto de firma JWT directamente en el código fuente. Eso son dos CWEs (CWE-327: Uso de Algoritmo Criptográfico Roto o Arriesgado, CWE-798: Uso de Credenciales Hardcodeadas) desde un solo prompt.
A05:2025 — Inyección
Lo clásico: Inyección SQL, XSS, inyección de comandos, inyección LDAP — datos no confiables enviados a un intérprete como parte de un comando o query.
La versión vibe-coded: La IA reproduce patrones vulnerables porque son los patrones más comunes en los datos de entrenamiento.
La inyección cayó del puesto #3 en OWASP 2021 al #5 en 2025 — señal de que las prácticas tradicionales (queries parametrizadas, ORMs, motores de plantillas con auto-escape) están funcionando. Pero el código generado por IA está arrastrando los números de vuelta hacia arriba.
Las pruebas de Veracode encontraron que los modelos de IA fallan en prevenir Cross-Site Scripting el 86% de las veces y producen vulnerabilidades de Log Injection el 88% de las veces. La inyección SQL tuvo la mejor tasa de aprobación con un 80% — lo que todavía significa que una de cada cinco queries a base de datos generadas por IA es inyectable.
La razón es directa. Cuando la respuesta más votada en Stack Overflow para «cómo hacer una query a una base de datos en Node.js» usa concatenación de strings:
// Lo que la IA aprende de los datos de entrenamiento
const query = `SELECT * FROM users WHERE id = ${req.params.id}`;
db.query(query);…el modelo reproduce ese patrón. No tiene concepto de que ${req.params.id} es entrada no confiable. No sabe que las queries parametrizadas existen porque previenen la inyección. Solo genera el código estadísticamente más probable.
Para XSS, el patrón es similar. La IA renderiza la entrada del usuario directamente en HTML porque eso es lo que hacen la mayoría de los ejemplos de código:
// Componente React generado por IA con vulnerabilidad XSS
const Comment = ({ text }) => (
<div dangerouslySetInnerHTML={{ __html: text }} />
);React normalmente escapa la salida por defecto — lo cual es genial. Pero en el momento en que la IA necesita renderizar texto enriquecido, recurre a dangerouslySetInnerHTML porque ese es el patrón en los datos de entrenamiento. El nombre de la función literalmente tiene «dangerously» («peligrosamente») en él, y al modelo le da igual.
A06:2025 — Diseño Inseguro
Lo clásico: Arquitectura de seguridad ausente o defectuosa. Modelos de amenazas que nunca se construyeron.
La versión vibe-coded: No hay diseño. No hay arquitectura. Solo hay el prompt.
Esta es la categoría de OWASP que más resuena con el vibe coding. El diseño inseguro tradicional significa que alguien diseñó algo de forma insegura. Con vibe coding, a menudo no hay diseño en absoluto. Toda la arquitectura es una propiedad emergente de lo que la IA decidió generar basándose en el prompt.
En la Guía de Campo, llamé a esto la superficie de decisión invisible — la IA tomó cientos de decisiones arquitectónicas (framework, estrategia de autenticación, modelo de datos, enfoque de validación, manejo de errores, logging) y nadie sabe cuáles fueron.
La investigación de Apiiro encontró un aumento del 153% en fallos de seguridad a nivel de diseño en código generado por IA, incluyendo bypass de autenticación y patrones inadecuados de gestión de sesiones. No son bugs de implementación — son fallos arquitectónicos. La IA construyó la cosa equivocada, correctamente.
Os voy a poner un ejemplo real de un proyecto de VULNEX (anonimizado, obviamente). Una startup construyó todo su SaaS multi-tenant con una herramienta de vibe coding. La IA generó un esquema limpio, una API funcional, un frontend pulido. Producto precioso. Un problema: no había aislamiento de tenants a nivel de base de datos. Cada query de la API devolvía datos de todos los tenants. La IA había construido una UI multi-tenant sobre una base de datos single-tenant. Eso no es un bug. Es un fallo arquitectónico que ninguna cantidad de parches puede arreglar — requiere un rediseño.
A07:2025 — Fallos de Autenticación
Lo clásico: Autenticación rota, credential stuffing, MFA ausente, gestión de sesiones insegura.
La versión vibe-coded: La IA construye autenticación que parece completa pero tiene brechas fundamentales.
La autenticación es donde la brecha entre «funciona» y «es seguro» es más ancha. La IA puede generar un flujo de login completo — registro, login, reset de contraseña, gestión de sesiones — que funciona correctamente para el camino feliz. El problema es que la seguridad vive en los casos extremos, y la IA no prueba los casos extremos.
Fallos comunes que veo en evaluaciones:
Sin rate limiting en endpoints de login. La IA genera una ruta /api/auth/login limpia. Comprueba credenciales. Devuelve un token. Nunca limita intentos. Un atacante puede hacer fuerza bruta a velocidad de máquina.
Tokens de reset de contraseña que no expiran. La IA genera un flujo de «olvidé mi contraseña» con un token de reset enviado por email. El token funciona indefinidamente. Una vez interceptado, es una puerta trasera permanente.
Tokens de sesión en parámetros de URL. Lo he visto de verdad. La IA puso el token de sesión como parámetro de query en las redirecciones, haciéndolo visible en logs del servidor, historial del navegador y cabeceras referrer.
No son vulnerabilidades exóticas. Son los básicos de la seguridad de autenticación. Pero la IA no distingue entre «autenticación que funciona» y «autenticación que es segura», y la mayoría de vibe coders tampoco conocen la diferencia.
A08:2025 — Fallos de Integridad de Software y Datos
Lo clásico: Fallo en verificar la integridad de actualizaciones de software, datos críticos, pipelines CI/CD.
La versión vibe-coded: La IA genera código que confía en todo.
Esta categoría cubre una clase amplia de fallos de confianza, y el código generado por IA es particularmente vulnerable porque los LLMs generan código que asume confianza por defecto. El modelo no añade comprobaciones de integridad a menos que se las pidas explícitamente.
La deserialización es un buen ejemplo. Si prompteas la IA para «aceptar datos JSON del webhook», genera código que parsea y procesa lo que llegue — sin verificación de firma, sin validación de esquema, sin autenticación de origen. Confía en quien llama al webhook porque los ejemplos de los datos de entrenamiento confían en quien llama al webhook.
El mismo patrón aplica a subidas de archivos (sin verificación de tipo), integraciones API (sin validación de respuesta), y carga de configuración (sin comprobación de integridad). La IA genera el camino funcional — recibir datos, procesarlos, devolver resultado — y se salta cada paso de verificación de confianza porque esos pasos no aparecen en la mayoría de los ejemplos de entrenamiento.
La brecha de Moltbook sobre la que escribí anteriormente es un caso práctico de fallo de integridad de datos: una plataforma donde agentes autónomos publicaban contenido consumido por otros agentes, sin procedencia de contenido, sin firma criptográfica, y sin verificación en ningún punto de la cadena de confianza.
A09:2025 — Fallos de Logging y Alertas
Lo clásico: Logging insuficiente, alertas ausentes, incapacidad de detectar brechas.
La versión vibe-coded: La IA o no loguea nada útil, o lo loguea todo incluidos los secretos.
Este es casi invisible en un pentest — no descubres fallos de logging testeando desde fuera. Pero cuando hago revisiones de arquitectura en aplicaciones vibe-coded, es consistentemente una de las peores áreas.
La IA genera código funcional con sentencias console.log desperdigadas para debugging, pero no hay framework de logging estructurado, no hay pista de auditoría para eventos de autenticación, no hay alertas por intentos de login fallidos, y no hay rotación ni política de retención de logs. La aplicación corre en producción con logging de nivel de desarrollo.
Peor aún, cuando la IA sí loguea cosas, a menudo loguea demasiado. He visto manejadores de error generados por IA que vuelcan objetos de request completos — incluyendo cabeceras de autorización, tokens de sesión, y cuerpos de request con contraseñas — directamente en archivos de log en texto plano. Eso es CWE-532 (Inserción de Información Sensible en Archivo de Log) y CWE-117 (Neutralización Inadecuada de Salida para Logs) de un golpe.
Las pruebas de Veracode encontraron que los modelos de IA producen vulnerabilidades de Log Injection el 88% de las veces — la peor tasa de fallo entre los cuatro tipos de vulnerabilidad que probaron. La IA simplemente no entiende que la salida de logs es un canal sensible para la seguridad.
A10:2025 — Manejo Inadecuado de Condiciones Excepcionales
Lo clásico: Excepciones no manejadas, manejo de errores inadecuado, stack traces expuestos, denegación de servicio a través de condiciones de error.
La versión vibe-coded: La IA optimiza para el camino feliz y apenas considera qué pasa cuando las cosas van mal.
Esta es una categoría nueva de OWASP para 2025, y describe las aplicaciones vibe-coded casi a la perfección. La generación de código por IA está fundamentalmente orientada al camino feliz. El modelo genera código que maneja la entrada esperada y el flujo esperado. Casos extremos, condiciones de error, agotamiento de recursos, entrada malformada, patrones de acceso concurrente — son, como mucho, una consideración secundaria.
En la práctica, esto significa:
Excepciones no manejadas que tumban la app. La IA genera un endpoint de API que parsea entrada del usuario, consulta la base de datos y devuelve resultados. Si la conexión a la base de datos se cae, la app se estrella con un promise rejection no manejado. Sin degradación gradual. Sin lógica de reintento. Sin respuesta de error significativa.
Stack traces en producción. Cuando una excepción no manejada ocurre, el comportamiento por defecto en la mayoría de frameworks es devolver el stack trace completo — incluyendo rutas de archivos, versiones de paquetes, y a veces variables de entorno. La IA nunca configura el manejo de errores de producción porque los datos de entrenamiento son abrumadoramente ejemplos en modo desarrollo.
Comprobaciones de límites de entrada ausentes. La IA genera un handler de subida de archivos que acepta cualquier archivo de cualquier tamaño. Una subida de 10GB agota la memoria y tumba el servidor. Eso es denegación de servicio por un handler de condición excepcional ausente.
Esto conecta directamente con el problema de diseño (A06). La IA no planifica para el fallo porque nunca se le dio un escenario de fallo. Genera código que funciona cuando todo va bien. La seguridad trata de lo que pasa cuando las cosas van mal.
Los Números: OWASP Meets IA
| Categoría OWASP | Dato Específico de IA | Fuente |
|---|---|---|
| A01: Control de Acceso Roto | 322% más rutas de escalación de privilegios en código IA | Apiiro (2025) |
| A02: Mala Configuración de Seguridad | 65% de apps vibe-coded tenían problemas de seguridad | Escape.tech (2025) |
| A03: Fallos de Cadena de Suministro | 40% de aumento en exposición de secretos en proyectos IA | Apiiro (2025) |
| A04: Fallos Criptográficos | 86% aprobación en selección de algoritmo, pero fallos consistentes en gestión de claves/contraseñas | Veracode (2025) |
| A05: Inyección | 86% tasa de fallo XSS, 88% tasa de fallo Log Injection | Veracode (2025) |
| A06: Diseño Inseguro | 153% de aumento en fallos de seguridad a nivel de diseño | Apiiro (2025) |
| A07: Fallos de Autenticación | 20% de apps vibe-coded con vulnerabilidades graves incl. autenticación ausente | Wiz Research (2026) |
| A08: Fallos de Integridad | 45% del código generado por IA contiene fallos de seguridad | Veracode (2025) |
| A09: Fallos de Logging | 88% del código IA produce vulnerabilidades de log injection | Veracode (2025) |
| A10: Condiciones Excepcionales | Tasa de aprobación de seguridad estancada en ~55% | Veracode Primavera 2026 |
Qué Puedes Hacer al Respecto
Si estás construyendo con herramientas de codificación IA, aquí va lo mínimo:
Antes de promptear, define tu arquitectura. Estrategia de autenticación. Modelo de datos. Qué framework, qué ORM, qué middleware de seguridad. Especifica todo esto en tu prompt o, mejor, en un archivo de reglas (.cursorrules, CLAUDE.md). No dejes que la IA tome estas decisiones por ti — las tomará basándose en patrones de tutoriales, no en requisitos de seguridad.
Después de cada generación, revisa las áreas relevantes de OWASP primero. Controles de acceso: ¿están en el servidor? Criptografía: ¿qué algoritmo, dónde están las claves? Inyección: ¿queries parametrizadas o concatenación de strings? Configuración: ¿modo debug, CORS, manejo de errores? Dependencias: ¿versiones conocidas, sin paquetes alucinados? No tienes que leer cada línea. Pero tienes que comprobar estas cinco áreas.
Ejecuta escaneo automatizado ajustado a patrones de IA. Los conjuntos de reglas SAST estándar fueron construidos para código escrito por humanos. Pillarán parte de esto, pero no todo. Herramientas como Semgrep te permiten escribir reglas personalizadas que apuntan a los patrones específicos que genera la IA — checks de autenticación en el cliente, secretos hardcodeados en ubicaciones comunes, defaults criptográficos inseguros. Cubriré el panorama de herramientas específico en un artículo posterior de esta serie.
Si eres profesional de seguridad evaluando aplicaciones vibe-coded, actualiza tu metodología. Las categorías OWASP siguen aplicando, pero tu checklist necesita elementos específicos de IA: comprueba controles de acceso solo en cliente, comprueba dependencias alucinadas, comprueba configuraciones por defecto de datos de entrenamiento. En VULNEX, hemos añadido estos a nuestra plantilla estándar de evaluación de aplicaciones web.
Qué Viene Ahora
Este artículo mapea el qué. El resto de la serie profundiza en el cómo y el arreglo:
- Parte 3: Anatomía de una Brecha de Vibe Coding — casos reales mostrando estas categorías OWASP en acción
- Parte 4: La Trampa de las Dependencias — inmersión profunda en A03 (Fallos de Cadena de Suministro) para código generado por IA
- Parte 5: Autenticación y Secretos — inmersión profunda en A04 y A07, la combinación más peligrosa
- Parte 6: Escaneando Aplicaciones Vibe-Coded — herramientas prácticas para detectar estos problemas automáticamente
El OWASP Top 10 lleva siendo el estándar de la industria para seguridad de aplicaciones web durante dos décadas. Sigue aplicando a las aplicaciones vibe-coded. Pero las causas raíz han cambiado de error humano a reproducción estadística, y el camino de remediación ha pasado de «educa al desarrollador» a «restringe la IA y verifica la salida.»
El framework es el mismo. El juego ha cambiado.
Como siempre: no confíes en nada, verifícalo todo.
- X (Twitter): @SimonRoses
Lecturas Adicionales
- ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026 — Parte 1 de esta serie
- Moltbook: Cuando los Agentes IA Construyen Su Propia Red Social, ¿Qué Podría Salir Mal? — Fallos de integridad de datos en una plataforma de agentes vibe-coded
- Envenenamiento de Skills en Agentes IA: El Ataque a la Cadena de Suministro del Que Nadie Habla — Patrones de ataque de cadena de suministro relevantes para A03
- Las Dos Amenazas Gemelas en la Sombra: Cuando Shadow AI y Vibe Coding Se Descontrolan en Tu Red — Gobernanza empresarial y la superficie de decisión invisible
Referencias
- OWASP Foundation (2025). OWASP Top 10:2025.
- Veracode (2025). GenAI Code Security Report.
- Veracode (2026). Spring 2026 GenAI Code Security Update.
- Apiiro (2025). 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks.
- Escape.tech (2025). The State of Security of Vibe Coded Apps.
- Wiz Research (2026). Common Security Risks in Vibe-Coded Apps.
- Embrace The Red (2025). GitHub Copilot: Remote Code Execution via Prompt Injection (CVE-2025-53773).
- CodeRabbit (2025). State of AI vs. Human Code Generation Report.
