Seguridad en vibe coding: los riesgos que entregas y la checklist para cerrarlos

¿Es seguro el vibe coding?

No, no por defecto. Un estudio de arXiv de 2026 auditó 200 aplicaciones hechas con vibe coding y desplegadas en público: el 91,0% arrastraba al menos una vulnerabilidad, y el 65,8% de los 1.186 hallazgos era crítico o alto. El vibe coding produce software que funciona de forma fiable, y software seguro solo por accidente.

91,0%

de las 200 aplicaciones auditadas hechas con vibe coding arrastraba al menos una vulnerabilidad (Deng, Fan y Meng, arXiv 2606.23130)

11,8%

de las soluciones de los agentes era segura, frente a un 57% funcionalmente correcto (benchmark SusVibes, Carnegie Mellon y socios)

65,8%

de las 1.186 vulnerabilidades de esa auditoría estaba calificada como crítica o alta

La auditoría es Understanding the (In)Security of Vibe-Coded Applications, de Junquan Deng, Zhiyu Fan y Ruijie Meng, publicada en junio de 2026 y revisada por última vez en septiembre. Los autores recopilaron 9.041 aplicaciones de código abierto construidas con agentes populares, Claude Code y Lovable entre ellos, y auditaron las 200 desplegadas en público. Remiten los 1.186 hallazgos a ocho modos de fallo recurrentes y a tres limitaciones de los propios agentes: defectos de memoria, defectos de objetivo y defectos de conocimiento.

La evidencia de los benchmarks apunta al mismo sitio. Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, de un equipo liderado por Carnegie Mellon, construyó SusVibes con 186 tareas de tipo petición de funcionalidad sacadas de proyectos reales de código abierto donde un humano había commiteado una implementación vulnerable. Sobre 12 configuraciones de agente de uso extendido, el 57% de las soluciones de SWE-Agent con Claude 4 Sonnet era funcionalmente correcto y el 11,8% era seguro.

Así que la respuesta honesta es que el vibe coding es tan seguro como los controles que lo rodean, y la mayoría de los montajes no tienen ninguno que actúe antes de que el código aterrice. El código con pinta de funcionar es justo el que un revisor con prisa deja pasar. Con velocidad y sin punto de control, el fallo sale en el mismo commit que la funcionalidad.

¿Qué es el vibe coding?

El vibe coding es construir software dictando prompts a un agente de IA en lenguaje natural en vez de escribirlo tú. Describes el resultado, el agente genera y edita los archivos, y tú iteras con otro prompt. El autor del código es el modelo, y el humano revisa una salida que a menudo no puede leer del todo.

El término se extendió a principios de 2025 para describir un flujo de trabajo en el que un desarrollador, o cada vez más alguien que no programa, se apoya en el agente y acepta lo que produce mientras el resultado se comporte. Herramientas como Claude Code, Cursor, Windsurf, OpenAI Codex y GitHub Copilot lo hicieron práctico: indexan un repositorio, editan por todo el árbol, ejecutan comandos y sacan funcionalidades operativas de un párrafo de intención. Eso es genuinamente potente, y también es donde se abre la brecha, porque la velocidad que hace atractivo al vibe coding es la misma que entierra los fallos.

¿Qué riesgos de seguridad tiene el vibe coding?

Son los clásicos del OWASP Top 10, reproducidos más rápido de lo que la revisión aguanta. La auditoría de arXiv de 2026 los encontró concentrados en control de acceso roto, inyección y fallos de autenticación. Cuatro figuran en el CWE Top 25 de 2025: inyección SQL (puesto 2), autorización ausente (4), inyección de comandos (9) y deserialización insegura (15).

Dos de estas clases merecen una mirada de cerca, porque enseñan lo corriente que es el código generado. Primero la inyección. Pide "un endpoint de búsqueda que filtre usuarios por nombre" y el camino de menor resistencia es la concatenación.

# Vulnerable (CWE-89): entrada de usuario concatenada dentro del SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Corregido: consulta parametrizada, la entrada nunca se convierte en código
db.execute("SELECT * FROM users WHERE name = %s", (name,))

La autorización rota es más sutil, porque la versión vulnerable parece completa. Devuelve la forma correcta, pasa la prueba que pide "dame el pedido 42" y se entrega.

// Vulnerable (CWE-639 IDOR): cualquier usuario autenticado lee cualquier pedido
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Corregido: la búsqueda se acota a quien llama y es dueño del pedido
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

Entre las dos versiones hay una cláusula de diferencia. Un revisor que lee 5.000 líneas al día no ve la cláusula ausente; ve un endpoint que devuelve un pedido y sigue adelante. El patrón se repite en cada lenguaje que escribe el agente, que es de lo que va nuestra mirada más amplia a si el código generado por IA es seguro.

Hay una clase de riesgo que no viene del código. El agente lee archivos, documentación de dependencias y descripciones de herramientas, y cualquiera de esas fuentes puede llevar instrucciones dirigidas a él y no a ti. La inyección de prompts es LLM01, la primera entrada del OWASP Top 10 for LLM Applications de 2025, y por eso el paso 10 de la checklist de más abajo pregunta qué ejecutó el agente, no solo qué escribió.

¿Por qué el vibe coding produce estos fallos?

Porque el prompt optimiza para el comportamiento y el modelo para el patrón más frecuente, y ninguna de las dos es la seguridad. Pedir que el pago funcione no contiene ninguna instrucción de validar la entrada, acotar la autorización ni parametrizar una consulta, así que el agente rellena el hueco con lo que su corpus hizo probable.

Dos mecanismos se acumulan. El problema del corpus: el modelo aprendió de código público plagado de los clásicos de OWASP, así que inseguro por defecto es su punto de partida. El problema de la ausencia: la seguridad suele ser una comprobación que está presente, y un modelo al que le piden un resultado positivo no añade una guarda negativa que nadie ha pedido. Decirle que tenga cuidado no arregla ninguno. El equipo de SusVibes probó exactamente eso, añadiendo pistas sobre vulnerabilidades a la petición funcional, y reportó que no mitigaba los problemas de seguridad.

Un tercer mecanismo decide el desenlace, y está del lado humano.

“

Quien dicta el prompt sabe decir si la funcionalidad funciona. Normalmente no sabe decir si es segura. Esa distancia, entre la intención del autor y la capacidad del revisor, es el problema de seguridad entero.

Por eso el vibe coding es estructuralmente distinto de un junior que escribe el mismo código. El junior es lo bastante lento como para que la revisión le siga el ritmo, y quien revisa lee código escrito a velocidad humana. El vibe coding quita los dos frenos: la salida llega a velocidad de máquina, y la persona responsable a menudo no tiene la alfabetización en seguridad para evaluarla. La pull request, el sitio donde siempre ha vivido la AppSec, pasa a ser el acta de unas decisiones ya tomadas y no un punto de control.

¿Qué lleva una checklist de seguridad para vibe coding?

Diez pasos, ordenados por rentabilidad por hora. Los primeros cierran las clases que el agente omite más a menudo según la auditoría de arXiv de 2026: control de acceso roto, inyección y fallos de autenticación. El resto son las barreras que impiden que el siguiente prompt las reabra. Aplícalos en orden en cualquier repositorio que haya tocado un agente.

1. Rota todas las credenciales que el agente haya podido leer y luego escanea el historial. Una clave codificada se explota sin tener que encontrar un bug, y por eso va primero. CWE-798 sobrevive en el historial de git y en cada fork mucho después de que borres la línea, así que la rotación va antes de la eliminación, no después.

2. Acota a quien llama cada endpoint que devuelva datos. Abre cada manejador generado y comprueba que la búsqueda filtra por el usuario autenticado y no solo por un id sacado de la URL. CWE-862 y CWE-639 son los puestos 4 y 24 del CWE Top 25 de 2025, y son los fallos que el agente omite con más fiabilidad, porque ninguna prueba funcional los pide.

3. Parametriza todas las consultas y todas las llamadas al shell. Pasa un grep buscando interpolación de cadenas dentro de una consulta o de un comando en los archivos generados. CWE-89 es el puesto 2 del CWE Top 25 y CWE-78 el 9, y los dos están a una edición mecánica de quedar cerrados.

4. Valida contra un esquema cada cuerpo de petición, en el borde. Límites, tipos y listas de permitidos, con rechazo al fallar. CWE-20 está aguas arriba de la inyección y de la deserialización, así que cerrarlo cierra varias clases de golpe, y es el más barato de automatizar de la lista.

5. Sustituye cualquier deserializador que corra sobre bytes no confiables. pickle, yaml.load y los deserializadores nativos de objetos convierten un blob almacenado en ejecución remota de código. CWE-502 es el puesto 15 del CWE Top 25, y el reemplazo seguro suele ser un parser tipado que ya tienes.

6. Saca los almacenes de credenciales del alcance del agente. Nada de credenciales en texto plano en el espacio de trabajo que puede leer. Usa una bóveda, inyecta en tiempo de ejecución y añade reglas deny para los archivos .env, para que el agente no pueda incrustar lo que no ve. Rota cualquier cosa que haya aparecido alguna vez en una transcripción.

7. Escribe tus reglas de seguridad donde el agente las lea en cada edición. El marco de desarrollo seguro de software del NIST (SP 800-218, versión 1.1) sitúa la documentación de los requisitos de seguridad en su grupo Prepare the Organization, antes de que exista código. La siguiente sección cuenta qué deben decir esas reglas.

8. Pon una puerta de análisis estático en CI y rompe la build ante severidad alta. Las pruebas funcionales dan por bueno un endpoint vulnerable pero operativo, y solo una comprobación consciente de la seguridad no lo hace. Esto es detección y no prevención, y por eso está aquí y no arriba del todo.

9. Escribe una prueba de abuso por cada camino del dinero y por cada camino de propiedad. Una cantidad negativa, y después el id de otra persona. Los fallos de lógica de negocio no tienen firma que emparejar, así que una prueba que codifique la regla es la única defensa mecánica. Profundizamos en fallos de lógica de negocio en el código generado por IA.

10. Revisa lo que el agente ejecutó, no solo lo que escribió. Guarda los comandos que lanzó en un registro que puedas releer. Una llamada destructiva al shell o un acceso improvisado a una base de datos contra un host vivo no aparecen en un diff, así que una revisión de código por sí sola no los saca a la luz.

Los pasos 1 a 5 son remediación que puedes terminar en una tarde sobre un repositorio pequeño. Los pasos 6 a 10 son lo que impide que las mismas clases vuelvan con el siguiente prompt.

¿Qué debe decir un prompt de seguridad para vibe coding?

Debe enunciar las reglas como restricciones que el agente comprueba antes de escribir, no como un deseo. Nombra la interfaz de consulta, el ayudante de autorización y el esquema de entrada que tu código ya usa, y dile que rechace la edición si no puede cumplirlos. Una regla que vive fuera de su contexto no se aplica.

La forma útil es concreta y mecánica. Una instrucción vaga ("escribe código seguro") no le da al modelo nada contra lo que contrastar. Una interfaz con nombre sí.

# Reglas de seguridad de este repositorio

- Toda lectura de base de datos pasa por `db.query(sql, params)`. Nunca
  interpoles un valor dentro del SQL. Si no puedes parametrizarlo, para y dilo.
- Todo manejador que devuelva un registro filtra por `req.user.id`. Un id sacado
  de la URL no basta nunca por sí solo.
- Todo cuerpo de petición se parsea con su esquema de zod antes de usarlo.
  Rechaza al fallar.
- Nunca escribas una credencial dentro de un archivo. Léela del entorno.
- El dinero es Decimal128. Las cantidades son enteros estrictamente mayores que cero.

Dónde pones ese archivo importa más que lo que escribas en él. En el estudio controlado de CybeDefend del 24 de agosto de 2026, que pasó 30 tickets de desarrollo por triplicado hasta sumar 90 ejecuciones autónomas y 93 análisis de seguridad independientes, el brazo que guardaba esas reglas en un archivo mantenido a mano en el repositorio promedió 2,27 desviaciones por ticket con regla. El brazo sin ninguna herramienta promedió 2,28. Escribir las reglas y no hacer nada más no cambió casi nada. El brazo que recibía esas mismas reglas inyectadas en el momento de la edición promedió 0,28.

El mismo estudio es franco con el límite. En un ticket la regla pertinente se sirvió trece veces y aun así el agente desmontó sus propias salvaguardas bajo la presión de la tarea. La inyección informa, no impone, y por eso la checklist de arriba mantiene una puerta de CI y una persona detrás.

¿El análisis estático de código (SAST) detecta los fallos del vibe coding?

En parte. Un escáner de análisis estático atrapa una porción significativa, sobre todo inyección y criptografía débil, y su sitio está en CI en cada pull request. Lo que se le escapa es la lógica de negocio: una cantidad negativa que abona el carrito es sintácticamente perfecta y no tiene firma que emparejar. Además actúa con el código ya escrito.

Ese segundo límite es el estructural. El análisis estático, los escáneres de secretos y la revisión de código leen todos código que ya existe, y se agolpan alrededor de la pull request porque ahí es donde siempre ha vivido la AppSec. Pero la PR solo fue un punto de control mientras una persona la leía, y a cadencia de vibe coding ya nadie la lee de principio a fin. El escáner se convierte en historiador, documentando fallos después de que el agente los haya entregado y se haya ido a otra cosa.

Lee la columna de la derecha como el objetivo. Escanear no está mal, llega tarde. La aplicación en agent-time no reemplaza al escáner, ni a la revisión, ni a la puerta de CI. Pone un control por delante de todos ellos, de modo que la línea insegura se reescribe antes de sugerirse, en vez de atraparse tres etapas más tarde con una herramienta que lee un diff que nadie tuvo tiempo de leer.

¿Qué debe tener una herramienta de seguridad para vibe coding?

Dos capacidades, y la mayoría solo tiene una. La detección encuentra patrones conocidos en código que ya existe. La prevención moldea el código mientras el agente lo escribe, cargando tus reglas en su contexto antes de cada edición. Pregúntale a un proveedor cuándo actúa su control, porque a velocidad de agente esa es la pregunta entera.

La mitad de la detección es un mercado resuelto. El análisis estático, el análisis de composición de software y el escaneo de secretos están maduros, y los actores asentados ahí, entre ellos Snyk, Checkmarx y Semgrep, lo hacen bien. Lo que comparten es el momento: en CI, sobre un diff, cuando el agente ya se ha ido. La guía de la CISA sobre seguridad desde el diseño, Shifting the Balance of Cybersecurity Risk, publicada con 17 socios internacionales, plantea mejor el criterio: un proveedor debería asumir como propios los resultados de seguridad de su cliente en vez de entregarle una lista de deberes.

Esa es la brecha que llena VibeDefend. Es una CLI de npm gratuita que se instala en unos cinco segundos y conecta Claude Code, Cursor, Windsurf, OpenAI Codex y GitHub Copilot con cuatro capas de gobierno que corren dentro del bucle del agente, para que la versión segura del código sea la primera. Para el cuadro completo sobre cada agente de código IA, tienes nuestro pilar de seguridad de los agentes de código IA.

npx -y @cybedefend/vibedefend@latest installElige EU o US, confirma tu agenteColoca .cybedefend/config.json en el repositorioEl siguiente prompt ya está gobernado

Las cuatro capas encajan con los modos de fallo que nombra esta guía. Las reglas de negocio son las convenciones extraídas de tu propio repositorio (el dinero es Decimal128, la autorización pasa por requireOwner), cargadas en el agente antes de cada edición para que los fallos de lógica de negocio no se escriban. Las reglas de seguridad llevan al código, mientras se escribe, el OWASP Top 10 y las familias de reglas de cumplimiento que actives, así que la inyección, la validación ausente y la autorización rota se topan con una regla en la autoría y no con una casilla de auditoría. El Action Guard intercepta las llamadas destructivas antes de que se disparen. En el estudio de agosto comprobó 1.769 comandos de shell y rechazó 17: 1 era un intento real de alcanzar una credencial almacenada, 3 eran aplicaciones correctas de la política y 13 eran falsos positivos que costaron un turno cada uno. Live Findings conecta el agente con la plataforma de CybeDefend, con análisis estático con alcanzabilidad, SCA, secretos, IaC y CI/CD en continuo, así que el agente también tría y arregla las vulnerabilidades que ya tienes. Tu código no cruza la red: las decisiones ocurren localmente, junto al agente, y al backend solo llegan metadatos de gobierno (la regla que se disparó, la ruta del archivo, la severidad, una marca de tiempo). Las regiones de EU y US están físicamente separadas y eliges una al instalar.

Medida sobre esos mismos 30 tickets, la capa dejó 0,033 hallazgos nuevos de análisis estático por tarea frente a 0,10 sin herramienta, y todos se arreglaron dentro de la tarea que los introdujo. Con ese número viaja una advertencia honesta: el estudio midió bases de código que partían limpias, así que describe cómo mantenerse en cero, no cómo rebajar el backlog que ya arrastras.

Preguntas frecuentes

¿Es seguro el vibe coding?

No por defecto. Una auditoría de arXiv de 2026 sobre 200 aplicaciones desplegadas hechas con vibe coding encontró al menos una vulnerabilidad en el 91,0%, y el benchmark SusVibes midió que solo el 11,8% de las soluciones de los agentes era seguro frente al 57% funcionalmente correcto. Pasa a ser seguro cuando añades un control que actúa en la autoría, le das al agente tus reglas en su contexto, mantienes a una persona en el bucle y proteges las pull requests con análisis estático. Sin eso, entrega el OWASP Top 10 a velocidad de máquina.

¿Cuáles son las vulnerabilidades más comunes del vibe coding?

Las clases que se repiten son los secretos codificados (CWE-798), la autorización rota e IDOR (CWE-862, CWE-639), la inyección (CWE-89 para SQL, CWE-78 para comandos), la validación de entrada ausente (CWE-20), la deserialización insegura (CWE-502) y los fallos de lógica de negocio. La auditoría de arXiv de 2026 encontró sus 1.186 hallazgos concentrados en control de acceso roto, inyección y fallos de autenticación. Ninguna es nueva: son los clásicos de OWASP, reproducidos más rápido de lo que la revisión aguanta.

¿Por qué el código generado por IA tiene tantos fallos de seguridad?

Dos mecanismos se acumulan y un tercero decide. El modelo aprendió de un corpus público plagado de patrones inseguros, así que inseguro por defecto es su prior. La seguridad suele ser una guarda que está presente, y un modelo al que le piden un resultado positivo no añade una comprobación negativa que nadie ha pedido. Y quien dicta el prompt sabe si la funcionalidad funciona, pero no si es segura, así que el fallo pasa la revisión. Añadir pistas sobre vulnerabilidades a la petición tampoco lo arregló en SusVibes.

¿Puede hacer vibe coding de forma segura alguien que no programa?

Solo con un control que no dependa de que la persona lea las implicaciones de seguridad, porque esa es justo la habilidad que falta. Un escáner que produce hallazgos para triar da por hecho que quien los lee sabe interpretarlos. Una capa en agent-time que carga las reglas en el agente y reescribe la línea insegura antes de que aterrice elimina esa dependencia: el patrón seguro pasa a ser el que el agente usa por defecto, y la seguridad deja de depender de que quien dicta el prompt detecte una autorización ausente.

¿Se puede usar vibe coding en una aplicación en producción?

No sin los controles de la checklist de arriba. La auditoría de arXiv de 2026 miró precisamente aplicaciones desplegadas en público, no proyectos de juguete, y el 91,0% de las 200 que revisó arrastraba al menos una vulnerabilidad, con alrededor de dos tercios de los hallazgos calificados como críticos o altos. Producción sube la apuesta justo en las clases que el agente omite: un endpoint sin acotar expone registros de clientes reales, y una clave codificada en un repositorio público es explotable en cuanto se hace push.

¿El análisis estático de código detecta las vulnerabilidades del vibe coding?

Detecta una porción significativa, sobre todo inyección y criptografía débil, y su sitio está en CI en cada pull request. Lo que se le escapa en gran medida es la lógica de negocio, porque un descuento de cantidad negativa o un reembolso que se salta la comprobación de propiedad es sintácticamente perfecto y semánticamente erróneo, sin firma que emparejar. Además es reactivo: actúa con el código ya escrito, lo que a velocidad de vibe coding significa con el fallo ya entregado. Combina la detección en CI con la prevención en la autoría.

¿Cuál es el control más eficaz para hacer vibe coding seguro?

Mover el punto de control de seguridad de la pull request al prompt. La detección que corre cuando el código ya existe siempre está leyendo historia a ritmo de agente, porque nadie revisa miles de líneas generadas de principio a fin. En el estudio controlado de CybeDefend, las reglas guardadas en un archivo del repositorio dejaron 2,27 desviaciones por ticket con regla frente a 2,28 sin ninguna herramienta, mientras que esas mismas reglas inyectadas en el momento de la edición dejaron 0,28. Todo lo demás es defensa en profundidad por detrás de eso.

¿Por dónde empiezo a asegurar un proyecto ya hecho con vibe coding?

Empieza por los pasos 1 a 3 de la checklist de arriba: rota cualquier credencial que el agente haya podido leer y escanea el historial por si hay más, luego audita cada endpoint que devuelva datos buscando una autorización acotada a quien llama, y después cierra los puntos de inyección. Añade a CI una puerta de análisis estático que falle ante severidad alta, y pon delante una capa en agent-time para que el código nuevo se gobierne mientras se escribe. Primero deja de añadir fallos, y luego rebaja el backlog que dejaron los prompts iniciales.