Seguridad del código generado por IA: riesgos del vibe coding

El "vibe coding" consiste en construir software principalmente a base de prompts a asistentes de IA como GitHub Copilot, Cursor o Claude Code, en lugar de escribir cada línea a mano. Acelera la entrega de forma espectacular, pero traslada al equipo un problema nuevo: gran parte de ese código llega sin revisar, reproduce patrones inseguros y arrastra dependencias que a veces ni siquiera existen. Para cualquier organización que trate datos sensibles, entender estos riesgos ya no es opcional, es parte del control de calidad y de la superficie de ataque.

Este artículo explica los riesgos de seguridad reales del código generado por IA y cómo gobernarlos sin frenar la productividad. Cubrimos por qué los modelos producen código inseguro por defecto, qué es el slopsquatting y cómo las dependencias alucinadas se convierten en un ataque de cadena de suministro, la fuga de secretos, la prompt injection en agentes de codificación y las cuestiones de licencia. Después bajamos a controles concretos: SAST, SCA, secret scanning en CI/CD, revisión humana, pinning con allowlist, SBOM y mínimo privilegio para los agentes. El enfoque no es anti-IA, es "confiar pero verificar".

Lo esencial sobre la seguridad del código generado por IA

• Los modelos aprenden de código público, incluido el código vulnerable, así que reproducen patrones inseguros por defecto.
• Las dependencias alucinadas (paquetes que la IA inventa) habilitan el slopsquatting, un ataque de cadena de suministro barato de montar.
• El volumen de código sin revisar satura la revisión humana y deja pasar fallos que antes se detectaban.
• Las claves hardcodeadas y los secretos filtrados son más frecuentes cuando se genera código a gran velocidad.
• Los agentes de codificación con acceso al repositorio amplían la superficie de prompt injection y contexto envenenado.
• El control eficaz trata el código de IA como no confiable: escáneres automáticos, revisión obligatoria y dependencias fijadas y verificadas.

Qué es el vibe coding y por qué cambia el modelo de riesgo

El término describe una forma de trabajo en la que el desarrollador describe lo que quiere en lenguaje natural y el asistente genera el código, que se acepta a menudo con poca o ninguna lectura crítica. En proyectos personales es una forma legítima de prototipar rápido. El problema aparece cuando ese mismo flujo llega a código de producción que gestiona autenticación, pagos, datos personales o infraestructura.

El cambio de fondo es de responsabilidad. En el desarrollo tradicional, quien escribe una línea entiende (idealmente) lo que hace. En el vibe coding, la persona que hace el commit puede no comprender del todo el código que acaba de aceptar. Esa brecha entre autoría y comprensión es precisamente donde se cuelan los fallos de seguridad, porque una revisión solo detecta lo que el revisor entiende.

No es un argumento contra la IA. La asistencia de IA aumenta la productividad de forma real y es aquí para quedarse. Es un argumento a favor de tratar su salida con el mismo escepticismo que aplicaríamos a código copiado de un foro público: útil como punto de partida, no confiable como producto final.

Riesgo 1: código inseguro por defecto

Los modelos de lenguaje se entrenan con enormes cantidades de código público. Ese corpus incluye tanto buenas prácticas como una cantidad considerable de código inseguro, obsoleto o directamente vulnerable. Un modelo optimiza para producir lo que es estadísticamente probable, no lo que es seguro, así que tiende a reproducir los patrones que más ha visto, y muchos de esos patrones son malos.

Diversos estudios sobre generación de código con IA encuentran que una parte significativa de las respuestas contiene vulnerabilidades explotables. Los patrones que más se repiten son reconocibles para cualquiera que haya hecho pentesting:

• Inyección: consultas SQL construidas por concatenación, comandos de sistema con entrada sin sanear, plantillas sin escapar.
• Criptografía débil: algoritmos obsoletos, modos inseguros, generación de aleatoriedad no criptográfica para tokens o contraseñas.
• Autorización ausente: endpoints que comprueban autenticación pero no autorización, de modo que cualquier usuario válido accede a recursos de otro.
• Validación pobre: confianza en la entrada del cliente, ausencia de límites de tamaño, deserialización insegura.

El agravante es sutil: el código generado suele parecer correcto. Compila, pasa los tests felices y hace lo que el prompt pedía. La vulnerabilidad no está en lo que hace, sino en lo que no hace (no comprueba, no escapa, no limita). Eso lo hace especialmente difícil de detectar en una revisión superficial, que es justo el tipo de revisión que fomenta el vibe coding. Por eso conviene apoyarse en el catálogo de riesgos del OWASP LLM Top 10 cuando se integran modelos en el flujo de desarrollo.

Riesgo 2: dependencias alucinadas y slopsquatting

Este es el riesgo más específico y, en muchos sentidos, el más peligroso. Cuando un modelo no conoce el nombre exacto de una librería para resolver una tarea, a veces lo inventa. Genera un import o una instrucción de instalación que apunta a un paquete con un nombre plausible pero que no existe en el registro (npm, PyPI, etc.).

La cadena de explotación es directa y barata:

1. El modelo sugiere de forma consistente un paquete inexistente, por ejemplo por un nombre que "suena" correcto para la función deseada.
2. Un atacante observa esas alucinaciones recurrentes (los nombres tienden a repetirse porque el modelo reproduce patrones recurrentes de sus datos de entrenamiento, no porque su salida sea determinista) y registra ese nombre con un paquete malicioso.
3. El siguiente desarrollador que reciba la misma sugerencia y ejecute la instalación a ciegas descarga y ejecuta código del atacante.

A este patrón se le ha empezado a llamar slopsquatting, por analogía con el typosquatting, pero explotando la "basura" (slop) que generan los modelos en lugar de erratas humanas. La diferencia clave es de escala y de confianza: el typosquatting depende de que la víctima se equivoque al teclear; el slopsquatting depende de que la víctima confíe en la IA, algo mucho más sistemático.

El daño de un paquete malicioso en la fase de build puede ser total: robo de credenciales del entorno de CI, exfiltración de código fuente, implantación de puertas traseras en el artefacto final. Es, en esencia, un ataque de cadena de suministro de software con un vector de entrada nuevo. La defensa central es no instalar nunca una dependencia sin verificar que existe, quién la mantiene y por qué se necesita.

Riesgo 3: fuga de secretos y claves hardcodeadas

Cuando se genera código a gran velocidad, los secretos se cuelan con facilidad. El asistente propone un ejemplo con una clave de API "de muestra" en el propio código, el desarrollador la sustituye por la real para probar rápido y ese valor acaba en un commit. También ocurre al revés: al pegar contexto en el prompt para que la IA "entienda" el proyecto, es fácil incluir credenciales reales en la conversación.

El resultado son claves, tokens y cadenas de conexión hardcodeadas en el repositorio, a veces en historia de git de la que nadie se acuerda. Un secret scanning en el pipeline es la red de seguridad mínima, y debe cubrir tanto el árbol de trabajo actual como el histórico.

Riesgo 4: exceso de confianza y volumen sin revisar

Hay un riesgo humano que amplifica a todos los demás. Cuando el código sale "gratis" y parece funcionar, la tentación de aceptarlo sin leerlo es enorme. Dos efectos se combinan:

• Sesgo de automatización: tendemos a confiar más en la salida de un sistema automático que en la de un compañero, aunque no haya razón para ello. Un fragmento generado por IA se percibe como más "neutral" y se revisa con menos rigor.
• Saturación de la revisión: la IA genera código mucho más rápido de lo que un humano lo revisa. Si el ritmo de generación desborda la capacidad de revisión, la revisión deja de ser un control real y se convierte en un trámite. Los pull requests gigantes son el síntoma clásico.

El efecto neto es que el volumen erosiona la calidad del control humano justo cuando ese control es más necesario, porque el código no lo escribió una persona que lo entendiera.

Riesgo 5: prompt injection y contexto envenenado en agentes

Los asistentes más avanzados ya no solo completan líneas: son agentes que leen ficheros, ejecutan comandos, navegan documentación y aplican cambios en el repositorio. Eso multiplica su utilidad y también su superficie de ataque.

La prompt injection ocurre cuando un atacante coloca instrucciones maliciosas en un contenido que el agente va a leer como parte de su contexto: un issue de GitHub, un comentario en el código, un fichero de dependencia, una página de documentación externa. El agente no distingue con fiabilidad entre "datos que debo procesar" e "instrucciones que debo obedecer", así que puede acabar ejecutando la orden del atacante (por ejemplo, exfiltrar una variable de entorno o introducir una puerta trasera sutil).

El contexto envenenado es la variante en la que el atacante contamina las fuentes de las que el agente aprende o se apoya durante la tarea. Estos vectores encajan con los descritos en el OWASP LLM Top 10 y son especialmente relevantes cuando el agente tiene permisos de escritura o acceso a secretos. Si el asistente forma parte de una suite corporativa, conviene además revisar las implicaciones de la seguridad de Microsoft Copilot en el 365 de empresas.

Riesgo 6: licencia y propiedad intelectual

Un riesgo que no es de seguridad técnica pero sí de exposición legal: el código generado puede reproducir fragmentos con licencias restrictivas presentes en el entrenamiento, o introducir dudas sobre la titularidad del código resultante. En sectores regulados o en due diligence de fusiones y adquisiciones, un origen de código poco claro puede convertirse en un problema real. Merece la pena tener una política explícita al respecto, aunque su tratamiento excede el alcance técnico de este artículo.

Controles: confiar pero verificar

La respuesta no es prohibir la IA, es tratar su código exactamente igual que trataríamos código de un contribuidor externo no verificado: útil, bienvenido y sujeto a control. Los siguientes controles se refuerzan entre sí.

Escáneres automáticos en CI/CD

Ningún código de IA debería llegar a la rama principal sin pasar por una batería de análisis automático:

• SAST (análisis estático) para detectar patrones inseguros en el propio código: inyección, criptografía débil, autorización ausente.
• SCA (análisis de composición de software) para revisar las dependencias frente a vulnerabilidades conocidas y licencias problemáticas.
• Secret scanning para bloquear claves y tokens hardcodeados antes de que se fusionen, cubriendo el árbol actual y el histórico.

Estos controles deben ser puertas del pipeline, no informes que nadie mira. Una base sólida de hardening del pipeline de CI/CD es lo que convierte estos escáneres en un control real y no en ruido.

Revisión humana obligatoria

Ninguna cantidad de automatización sustituye a un humano que entienda el código antes de aceptarlo. La regla práctica es simple: si no lo entiendes, no lo apruebas. Esto implica mantener los cambios en tamaños revisables (los PR gigantes generados de golpe son un anti-patrón) y dedicar atención especial a lógica de autenticación, autorización, manejo de datos sensibles y llamadas a sistemas externos.

Verificar y fijar cada dependencia

Contra el slopsquatting, la defensa es concreta:

• Verificar que cada dependencia existe de verdad y que la mantiene quien dice mantenerla, antes de instalarla. No confiar en que un nombre "suene bien".
• Fijar versiones (pinning) con hashes o lockfiles, de modo que un nombre no pueda resolverse a un paquete distinto del validado.
• Usar una allowlist de dependencias aprobadas cuando el contexto lo permita, en lugar de permitir instalaciones arbitrarias.

Complementar esto con un SBOM (inventario de componentes de software) mejora la visibilidad de lo que realmente entra en el artefacto, en la medida en que el inventario sea completo y exacto, y facilita responder rápido cuando aparece una vulnerabilidad en una dependencia.

Guardarraíles y mínimo privilegio para los agentes

Cuando el asistente es un agente con capacidad de actuar, los permisos importan tanto como el código. Aplica mínimo privilegio: acceso de solo lectura por defecto, credenciales de corta duración, sin acceso directo a secretos de producción y aprobación humana para acciones destructivas. Limita las fuentes que el agente puede leer y trata todo contenido externo como potencialmente hostil, para reducir la superficie de prompt injection.

SBOM y formación

Dos controles transversales cierran el conjunto. El SBOM aporta trazabilidad de la cadena de suministro y responde a la pregunta de "qué hay realmente en nuestro software". Y la formación cambia la cultura: los equipos deben entender que el código de IA no es de fiar por defecto, reconocer los patrones vulnerables y saber por qué el pinning y la revisión no son burocracia sino defensa.

Preguntas frecuentes

¿El código generado por IA es inseguro siempre?

No siempre, pero sí con más frecuencia de lo que parece. Los modelos reproducen patrones de su entrenamiento, que incluye código vulnerable, así que una parte significativa de las respuestas contiene fallos explotables. El problema es que ese código suele parecer correcto y pasar los tests felices, lo que dificulta detectar la vulnerabilidad en una revisión superficial. La conclusión no es evitar la IA, sino no confiar en su salida sin verificarla.

¿Qué es exactamente el slopsquatting?

Es un ataque de cadena de suministro que explota las dependencias alucinadas de los modelos. Cuando una IA inventa de forma recurrente el nombre de un paquete que no existe, un atacante registra ese nombre con un paquete malicioso. El desarrollador que reciba la misma sugerencia y la instale a ciegas ejecuta código del atacante. Es análogo al typosquatting, pero explota la confianza en la IA en lugar de las erratas humanas.

¿Cómo evito instalar una dependencia alucinada?

Verifica siempre que la dependencia existe realmente, quién la mantiene y por qué la necesitas, antes de instalarla. Fija las versiones con lockfiles o hashes para que un nombre no pueda resolverse a un paquete inesperado, usa una allowlist de dependencias aprobadas cuando sea posible y apóyate en SCA y en un SBOM para tener visibilidad de todo lo que entra en el build.

¿Basta con un escáner SAST para asegurar el código de IA?

No. El SAST detecta muchos patrones inseguros en el código, pero no cubre las dependencias alucinadas (que se atajan verificando la procedencia del paquete y con allowlist y pinning, no principalmente con SCA), ni los secretos hardcodeados (secret scanning), ni los fallos de lógica de autorización que requieren contexto de negocio (eso es revisión humana). La defensa eficaz combina varios controles en el pipeline y no depende de una sola herramienta.

¿Los agentes de codificación son más peligrosos que el autocompletado?

Sí, porque amplían la superficie de ataque. Un agente que lee ficheros, ejecuta comandos y aplica cambios puede ser manipulado mediante prompt injection: instrucciones maliciosas ocultas en un issue, un comentario o documentación externa que el agente procesa como parte de su contexto. Por eso los agentes necesitan mínimo privilegio, credenciales de corta duración y aprobación humana para acciones sensibles.

¿Este enfoque no frena la productividad que aporta la IA?

No si se automatiza bien. Los escáneres en CI/CD, el pinning y la allowlist funcionan en su mayor parte de forma transparente en el pipeline, aunque también tienen su coste de integración, mantenimiento y triaje de falsos positivos. El coste que no se puede automatizar es la revisión humana, que es precisamente el control que la IA no puede sustituir. El objetivo es "confiar pero verificar": aprovechar la velocidad de la IA sin heredar sus fallos.

Recursos relacionados

• Hardening del pipeline de CI/CD
• SBOM y seguridad de la cadena de suministro de software
• Ataques a la cadena de suministro de software y DevSecOps
• OWASP LLM Top 10 explicado
• Seguridad de Microsoft Copilot en el 365 de empresas

Verifica antes de confiar en tu código de IA

El código generado por IA es una ayuda extraordinaria y, a la vez, una nueva superficie de ataque. Confiar pero verificar significa poner controles reales entre el prompt y producción: escáneres en el pipeline, revisión humana y dependencias verificadas y fijadas.

En Secra somos una empresa de ciberseguridad ofensiva con programa propio de investigación de vulnerabilidades. Hemos descubierto y publicado CVE reales, como CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB, coordinados a través de NVD e INCIBE-CERT. Aplicamos esa mentalidad ofensiva para auditar tu SDLC, revisar el código y las dependencias que genera tu equipo con IA y ayudarte a montar los guardarraíles adecuados. Si quieres una evaluación de tu cadena de suministro y de tu proceso de desarrollo asistido por IA, ponte en contacto con nosotros.