Las aplicaciones creadas con inteligencia artificial están acelerando el desarrollo de software, pero también están abriendo una nueva superficie de riesgo. Un nuevo estudio de seguridad encontró 434 vulnerabilidades explotables en aplicaciones generadas o modificadas con IA, incluyendo fallos de autorización, exposición de secretos, ausencia de límites de uso, problemas de denegación de servicio y configuraciones peligrosas.
El hallazgo no significa que todas las aplicaciones creadas con IA sean inseguras por definición. Significa algo más importante: el código generado por IA no debe pasar a producción sin revisión humana, pruebas de seguridad, controles de acceso, análisis de dependencias y validación de comportamiento en tiempo real.
Idea central: la IA puede crear aplicaciones funcionales muy rápido, pero “funciona” no significa “es segura”. La seguridad debe verificarse antes de publicar cualquier app generada por IA.
Qué reveló el estudio
La investigación fue publicada por Xint.io, plataforma de pruebas de seguridad impulsada por IA de Theori. El análisis revisó 28 bases de código en tres escenarios: aplicaciones creadas por usuarios no técnicos mediante “vibe coding”, aplicaciones generadas con instrucciones más cuidadosas por desarrolladores experimentados y una aplicación existente que fue migrada y endurecida con ayuda de IA.
El resultado fue preocupante: más de 8.800 hallazgos iniciales fueron depurados en más de 500 hallazgos únicos y finalmente validados en torno a 430 verdaderos positivos. SecurityWeek resumió la cifra final como 434 vulnerabilidades explotables, divididas entre aplicaciones nuevas y una aplicación existente modernizada con IA.
| Dato clave | Resultado |
|---|---|
| Organización | Xint.io / Theori |
| Bases de código analizadas | 28 codebases en distintos flujos de desarrollo asistido por IA. |
| Hallazgos iniciales | Más de 8.800 hallazgos deduplicados y validados. |
| Vulnerabilidades explotables | 434 fallos confirmados según el resumen del estudio. |
| Riesgos principales | DoS, autorización débil, exposición de secretos, SSRF, traversal y configuraciones inseguras. |
Los fallos más frecuentes
El estudio encontró que los errores más comunes no fueron necesariamente los clásicos ataques de inyección. En cambio, aparecieron con mucha fuerza los problemas de resiliencia, control de recursos, autorización y límites de acceso.
| Tipo de fallo | Cantidad reportada | Riesgo |
|---|---|---|
| Agotamiento de recursos / DoS | 93 | El servicio puede caer o generar costos elevados por falta de límites. |
| Autorización débil / IDOR | 88 | Usuarios pueden acceder a datos o acciones que no les corresponden. |
| SSRF, traversal y límites de acceso | 54 | La aplicación puede acceder a rutas, recursos o servicios no previstos. |
| Secretos expuestos | 11 críticos | Claves, tokens o credenciales pueden quedar dentro del código. |
| Modo debug peligroso | 6 críticos | Configuraciones de desarrollo pueden quedar activas en producción. |
Punto crítico: muchos fallos generados por IA no aparecen porque el código “no compile”, sino porque la aplicación funciona, pero no valida permisos, no limita recursos o deja secretos expuestos.
Por qué la IA genera este tipo de errores
La IA suele optimizar la respuesta para cumplir una petición visible: crear una pantalla, conectar una base de datos, generar un formulario, implementar un login o publicar una API. El problema es que muchas medidas de seguridad no se ven en una demostración rápida.
Un usuario puede pedir: “crea una app para gestionar clientes”. La IA puede generar una interfaz funcional, rutas, base de datos y autenticación básica. Pero si no se pide explícitamente, puede omitir controles esenciales: permisos por objeto, límites de tasa, protección de secretos, validación de entrada, manejo seguro de errores, logs útiles, control de sesiones y pruebas de autorización.
Lectura técnica: la IA puede generar código correcto desde el punto de vista funcional, pero incompleto desde el punto de vista de seguridad. Esa diferencia es peligrosa cuando se publica en Internet.
El problema crece cuando la aplicación se vuelve más grande
Una conclusión importante del estudio es que los controles finos de autorización se degradan a medida que la aplicación crece. En aplicaciones pequeñas, ciertos permisos pueden parecer correctos. Pero cuando aumentan los módulos, endpoints, roles y objetos, la IA tiende a perder consistencia.
SecurityWeek reportó que los fallos tipo IDOR pasaron de representar el 11 % en aplicaciones pequeñas a 28 % en una aplicación más grande modernizada con IA. Esto muestra que el problema no está solo en “generar código malo”, sino en mantener coherencia de seguridad durante muchas iteraciones.
Consejo para empresas: mientras más endpoints tenga una aplicación generada por IA, más importante es revisar permisos a nivel de usuario, rol, recurso y operación.
No es un caso aislado: otros estudios apuntan al mismo problema
El riesgo del código generado por IA ya aparece en varias investigaciones. Un estudio académico sobre aplicaciones “vibe-coded” encontró patrones recurrentes como lógica placeholder, entradas sin filtrar y exposición de secretos. Los autores atribuyen estos problemas a limitaciones sistemáticas de los agentes de IA durante el ciclo de desarrollo, incluyendo pérdida de contexto, objetivos locales e insuficiente conocimiento de seguridad.
Otro estudio, Broken by Default, analizó 3.500 artefactos de código generados por siete modelos de frontera y encontró que el 55,8 % contenía al menos una vulnerabilidad identificada por su canal de verificación. Además, 1.055 hallazgos fueron formalmente probados mediante Z3, y las instrucciones explícitas de seguridad solo redujeron la tasa media de vulnerabilidades en 4 puntos porcentuales.
Conclusión técnica: pedirle a la IA “hazlo seguro” ayuda, pero no reemplaza revisión de código, pruebas de seguridad, análisis automatizado y validación humana.
El riesgo de las aplicaciones publicadas sin control
El problema no se limita al código fuente. WIRED reportó que investigadores de RedAccess encontraron más de 5.000 aplicaciones creadas con herramientas de IA que estaban públicamente accesibles y prácticamente sin seguridad o autenticación. Según ese reporte, alrededor del 40 % exponía información sensible o privada.
Esto revela un riesgo organizacional: empleados, áreas de marketing, ventas, operaciones o usuarios no técnicos pueden crear aplicaciones funcionales en minutos y publicarlas sin pasar por desarrollo seguro, revisión legal, privacidad, TI, ciberseguridad o cumplimiento.
Alerta empresarial: el “shadow AI” ya no solo genera documentos o presentaciones. También puede generar aplicaciones públicas con datos reales, permisos débiles y exposición de información.
Qué dice OWASP sobre confiar demasiado en código generado por IA
OWASP ya reconoce el problema bajo la categoría de confianza inapropiada en código generado por IA. Su recomendación es clara: los desarrolladores deben poder leer y entender todo el código que envían, revisar el código asistido por IA con herramientas de seguridad, crear políticas de uso dentro del SDLC y evitar “vibe coding” para funciones complejas, críticas o de larga duración.
Esto es importante porque la seguridad no se logra solo con mejores modelos. Se logra con procesos: revisión, pruebas, controles, monitoreo, capacitación, políticas internas y responsabilidad sobre lo que se publica.
| Riesgo | Medida recomendada |
|---|---|
| Código no comprendido | No publicar código que el equipo no pueda explicar y mantener. |
| Falta de revisión | Aplicar revisión humana, SAST, DAST, SCA y revisión de secretos. |
| Shadow AI | Definir políticas internas para uso de IA en desarrollo. |
| Aplicaciones críticas | No usar vibe coding sin arquitectura, seguridad y pruebas formales. |
Checklist mínimo antes de publicar una app creada con IA
- Revisar autenticación y autorización por rol, usuario, recurso y operación.
- Verificar que no existan claves, tokens, contraseñas o datos sensibles en el código.
- Aplicar límites de tasa, cuotas, timeouts y protección contra abuso de recursos.
- Desactivar modo debug, errores detallados y paneles de desarrollo en producción.
- Validar entradas en servidor, no solo en el navegador.
- Revisar dependencias, paquetes vulnerables y licencias.
- Ejecutar pruebas SAST, DAST, SCA y análisis de secretos.
- Probar flujos de usuarios con distintos roles para detectar accesos indebidos.
- Configurar logs, monitoreo, alertas y trazabilidad.
- Exigir revisión humana antes de desplegar en producción.
Herramientas open source útiles para revisar código generado por IA
Una estrategia defensiva puede apoyarse en herramientas libres y open source. Ninguna herramienta detecta todo, pero usadas en conjunto ayudan a reducir riesgos antes del despliegue.
| Herramienta | Uso recomendado |
|---|---|
| Semgrep | Análisis estático de patrones inseguros en código. |
| Gitleaks | Detección de secretos, tokens y credenciales expuestas. |
| Trivy | Escaneo de dependencias, contenedores, IaC y vulnerabilidades conocidas. |
| OWASP ZAP | Pruebas dinámicas defensivas sobre aplicaciones web. |
| Dependency-Track | Gestión de SBOM y riesgo de componentes. |
Buenas prácticas para empresas que usan IA para programar
- Definir una política formal de uso de IA en desarrollo de software.
- Prohibir publicar aplicaciones generadas por IA sin revisión de seguridad.
- Usar repositorios internos, ramas protegidas y revisión obligatoria por pares.
- Crear plantillas seguras para autenticación, autorización, logs y manejo de errores.
- Exigir SBOM para aplicaciones generadas o modificadas con IA.
- Integrar pruebas de seguridad en CI/CD antes del despliegue.
- Registrar qué partes del sistema fueron generadas por IA.
- Capacitar a desarrolladores y usuarios no técnicos en riesgos de publicación.
- Controlar herramientas de IA no autorizadas dentro de la organización.
- Medir incidentes, hallazgos y tiempo de remediación asociados a código generado por IA.
Errores comunes
- Publicar una aplicación generada por IA solo porque “ya funciona”.
- No revisar permisos por usuario, rol y objeto.
- Dejar claves o tokens dentro del código fuente.
- No configurar límites de uso, cuotas o timeouts.
- Usar datos reales en prototipos públicos.
- Dejar modo debug o paneles de desarrollo activos.
- No revisar dependencias instaladas por la IA.
- No hacer pruebas de seguridad dinámicas antes de producción.
- Permitir que áreas no técnicas publiquen apps sin pasar por TI o seguridad.
Preguntas clave
¿Las aplicaciones creadas con IA son inseguras?
No siempre, pero deben considerarse no confiables hasta que sean revisadas. La IA puede generar código funcional con fallos de seguridad ocultos.
¿Qué encontró el nuevo estudio?
El análisis encontró 434 vulnerabilidades explotables en aplicaciones generadas o modificadas con IA, incluyendo fallos de DoS, autorización, secretos expuestos y configuraciones inseguras.
¿El problema es solo de usuarios no técnicos?
No. Los usuarios no técnicos aumentan el riesgo porque pueden publicar sin revisión, pero incluso desarrolladores experimentados pueden introducir fallos si aceptan código generado por IA sin validarlo.
¿Basta con pedirle a la IA que escriba código seguro?
No. Las instrucciones de seguridad ayudan, pero los estudios muestran que no eliminan el problema. Se necesita revisión, pruebas y controles técnicos.
¿Qué debe hacer una empresa?
Crear políticas de uso de IA, revisar todo código generado, integrar seguridad en CI/CD, controlar shadow AI y evitar publicar aplicaciones sin aprobación técnica.
¿Debemos dejar de usar IA para programar?
No necesariamente. La IA puede mejorar productividad, pero debe usarse como asistente, no como sustituto de arquitectura, revisión, seguridad y responsabilidad profesional.
Recomendamos
- Guía definitiva para construir un entorno DevSecOps con herramientas de código abierto.
- Las mejores herramientas open source para proteger la cadena de suministro del software.
- Seguridad y gobernanza de la IA: cómo proteger empresas que usan agentes inteligentes.
- Cómo construir un CiberSOC utilizando únicamente herramientas de software libre.
En resumen
El nuevo estudio confirma una realidad incómoda: las aplicaciones creadas con IA pueden contener cientos de vulnerabilidades explotables si se publican sin controles. Los errores más frecuentes no siempre son fallos obvios de compilación, sino problemas de autorización, resiliencia, secretos, límites de recursos y configuraciones inseguras.
La lección para empresas y desarrolladores es clara: la IA puede acelerar el desarrollo, pero no puede reemplazar la responsabilidad de construir software seguro. Toda aplicación generada por IA debe pasar por revisión humana, pruebas automatizadas, análisis de dependencias, control de secretos, monitoreo y aprobación antes de producción.
Conclusión editorial
La IA ha hecho que crear software sea más rápido y accesible. Pero la confianza no se genera automáticamente. El futuro del desarrollo no será elegir entre humanos o IA, sino construir procesos donde la IA acelere, los humanos revisen y la seguridad sea obligatoria antes de publicar.
