Los asistentes de codificación con IA han pasado de ser una curiosidad a un hábito diario más rápido de lo que la mayoría de las prácticas de seguridad pueden seguir. GitHub Copilot superó los 1,8 millones de suscriptores de pago en 2024 y, según la mayoría de las estimaciones, el 85% de las organizaciones de ingeniería utilizan IA en alguna parte de su ciclo de desarrollo. El argumento de productividad es real. El argumento de seguridad es más complicado y, si tu equipo genera Terraform, manifiestos de Kubernetes o definiciones de pipelines de CI/CD con un LLM, las complicaciones aterrizan directamente en tu superficie de ataque más sensible.

Este artículo expone lo que la investigación realmente muestra, dónde se concentra el riesgo específicamente en los flujos de trabajo de infraestructura y cómo es un framework de revisión concreto para los equipos que no pueden permitirse aprenderlo a las malas.

Los números son peores de lo que sugieren los titulares

Un estudio de Apiiro de septiembre de 2025 sobre repositorios empresariales de Fortune 50 encontró que el código generado por IA estaba introduciendo más de 10.000 nuevos hallazgos de seguridad por mes en junio de 2025, un pico de aproximadamente 10 veces en seis meses. Las rutas de escalada de privilegios aumentaron un 322% y los fallos de diseño arquitectónico se dispararon un 153%. No son errores tipográficos ni puntos y coma faltantes; son problemas estructurales que sobreviven a una revisión superficial.

El Veracode 2025 GenAI Code Security Report, que analizó más de 100 LLMs en cuatro lenguajes, encontró que el código generado por IA contiene 2,74 veces más vulnerabilidades que el código escrito por humanos, con una tasa de fallos del 45% en benchmarks de codificación segura. Un análisis de CodeRabbit sobre 470 pull requests de código abierto encontró que el código generado por IA producía 1,75 veces más errores de lógica y corrección, y 1,57 veces más hallazgos de seguridad que los equivalentes escritos por humanos. Un estudio de ACM sobre GitHub Copilot específicamente encontró que alrededor del 30% de los fragmentos generados presentan debilidades de seguridad que abarcan 43 CWEs distintos, incluyendo CWE-330 (aleatoriedad insuficiente), CWE-94 (inyección de código) y CWE-79 (cross-site scripting). Incluso después de que Copilot mejorara, la tasa de sugerencias vulnerables solo bajó del 36,54% al 27,25%.

Un dato que raramente aparece en el argumento de productividad: los repositorios que usan GitHub Copilot filtran al menos un secreto a una tasa un 40% más alta que los que no usan asistencia de IA, con un 6,4% de dichos repositorios exponiendo credenciales.

La infraestructura como código es el punto débil del que nadie habla

Las vulnerabilidades en código general son malas. Las vulnerabilidades en IaC son peores, porque un módulo de Terraform mal configurado o una política IAM demasiado permisiva no afecta solo a una aplicación; define el radio de explosión de todo lo que se ejecuta sobre ella.

Una investigación publicada a principios de 2026 analizó GPT-4o y Gemini 2.0 Flash contra 89 escenarios sintéticos vulnerables de IaC. Solo el 7% de los scripts generados eran seguros. Añadir una instrucción explícita para generar código seguro elevó la tasa de salida segura de GPT al 17%; Gemini pasó del 7% al 8%. Para la detección de problemas de seguridad en scripts de repositorios reales de GitHub, un prompt genérico dejó más de la mitad de los problemas sin detectar. Incluso con orientación estructurada, al menos un tercio de los problemas quedaron sin resolver.

Ninguno de los LLMs de generación de código más avanzados en la actualidad está optimizado específicamente para mejorar la seguridad al generar código IaC. Muchas debilidades no pueden resolverse sin información adicional del usuario y la mayoría de los desarrolladores utilizan el código generado directamente sin comprender los posibles fallos que contiene.

La consecuencia práctica: un ingeniero que le pide a un LLM una política de bucket equivalente a S3, un rol IAM o un manifiesto RBAC de Kubernetes, y lo aplica sin revisión, tiene aproximadamente un 93% de probabilidades de publicar algo con un problema de seguridad, y una probabilidad significativa de publicar algo con una ruta activa de escalada de privilegios.

Vectores de ataque novedosos que eluden la revisión habitual

Más allá de la calidad del código generado, las herramientas de codificación con IA introducen superficies de ataque que antes no existían.

Rules File Backdoor (Pillar Security, marzo de 2025): Los atacantes insertan caracteres Unicode ocultos en archivos de configuración que consumen herramientas como GitHub Copilot y Cursor. El asistente lee el archivo y produce una salida maliciosa que parece limpia para un revisor humano. GitHub añadió advertencias para texto Unicode oculto en mayo de 2025, pero el patrón ilustra que la superficie de entrada de la IA es ahora parte de tu modelo de amenazas.

Inyección de prompts en CI/CD: En diciembre de 2024, atacantes explotaron una mala configuración de pull_request_target en GitHub Actions para inyectar código en un pipeline de build y publicar paquetes maliciosos en PyPI. El incidente de Ultralytics siguió el mismo patrón estructural: abuso del trigger de CI/CD que llevó al robo de credenciales. A medida que los agentes de IA obtienen más autonomía sobre los pasos del pipeline, el prompt en lenguaje natural se convierte en un vector de inyección junto al propio código.

Slopsquatting: Un estudio de 2025 encontró que casi el 20% de los paquetes recomendados por LLMs no existen, y el 43% de esos nombres alucinados se repiten de forma consistente entre distintas consultas. Los atacantes pueden registrar esos nombres, esperar a que un desarrollador siga la recomendación de la IA e insertar una dependencia maliciosa en la cadena de suministro sin que ninguna revisión de código lo detecte.

Extracción de datos de entrenamiento: Los investigadores demostraron que prompts cuidadosamente elaborados pueden hacer que Copilot exponga credenciales de sus datos de entrenamiento. Si el código privado de tu organización formó parte alguna vez de un corpus de entrenamiento, esto no es una preocupación teórica.

Un framework de revisión concreto para pipelines de infraestructura

La respuesta no es prohibir los asistentes de IA; las ganancias de productividad son reales y las herramientas no van a desaparecer. La respuesta es tratar el código de infraestructura generado por LLMs como tratarías el código de un contratista junior: útil, rápido, pero no de confianza sin verificación.

  • Bloquea la IaC con análisis estático, no solo con linting. Herramientas como Checkov, tfsec y Semgrep tienen rulesets específicos para IaC. Hazlos obligatorios en CI antes de cualquier paso de plan o apply. Un análisis fallido bloquea el merge; no abre un ticket para después.
  • Aplica revisión de mínimo privilegio en cada bloque IAM y RBAC generado. Las rutas de escalada de privilegios fueron la clase de vulnerabilidad de más rápido crecimiento en los datos de Apiiro. Cada rol, política y binding que produzca una IA debe ser revisado contra el principio de mínimo privilegio por un humano que entienda el radio de explosión, no solo la sintaxis.
  • Escanea en busca de secretos antes del commit, no después. Integra el escaneo de secretos (GitLeaks, Trufflehog o las herramientas nativas de tu plataforma) como un hook de pre-commit y un paso de CI. La tasa de exposición de secretos un 40% más alta en repositorios asistidos por IA no es aceptable en ningún entorno regulado.
  • Audita tu grafo de dependencias con cada paquete sugerido por IA. Antes de cualquier pip install, npm install o equivalente que provenga de una sugerencia de LLM, verifica que el paquete existe en el registro canónico y comprueba su historial de publicación. El slopsquatting es un ataque a la cadena de suministro que le cuesta al atacante casi nada ejecutar.
  • Trata los archivos de configuración de IA como parte de la superficie de ataque. Los archivos de reglas, las plantillas de prompts y la configuración del asistente que viven en tu repositorio deben pasar por el mismo proceso de revisión que el código. Los caracteres ocultos en esos archivos son ahora un vector de ataque documentado.
  • Registra y atribuye el código generado por IA de forma explícita. El 11% de los equipos que saben que se usa IA pero no la monitorizan son los más propensos a llevarse sorpresas. Exige que los ingenieros marquen el código generado por IA en los mensajes de commit o en las descripciones de los PRs. No es un mecanismo de culpa; es una señal que activa la profundidad de revisión adecuada.

Dónde se cruzan la arquitectura de red y la seguridad del pipeline

Una dimensión que recibe menos atención en el debate sobre seguridad del código con IA es lo que ocurre cuando un pipeline mal configurado llega a un entorno de producción con peering directo a hyperscalers. Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en todos los sitios. Esa conectividad es una ventaja operativa, pero también significa que una política IAM mal configurada o un security group demasiado permisivo generado por un asistente de IA y desplegado sin revisión puede exponer una superficie de movimiento lateral mucho más amplia que en un entorno aislado. El radio de explosión de un hallazgo de escalada de privilegios no se limita al clúster local; se extiende a todas las redes con peering alcanzables desde esa mala configuración. Esa es la consecuencia operativa que hace que la revisión de IaC sea innegociable, no solo algo deseable.

La carga de revisión es el punto clave

Los datos de Apiiro señalaron que los asistentes de IA tienden a concentrar más código en menos pull requests, lo que dificulta la revisión porque los cambios tocan más partes del código base a la vez. Esta es la tensión estructural: la herramienta que aumenta la velocidad también incrementa la carga cognitiva necesaria para revisar su salida de forma segura. Aceptar esa tensión con honestidad, en lugar de asumir que la IA se ocupa de la seguridad porque se ocupa de la sintaxis, es el punto de partida para cualquier equipo que quiera usar estas herramientas sin publicar las vulnerabilidades junto a las funcionalidades.

El código de infraestructura generado por LLMs es útil. También es, según los datos, significativamente más probable que introduzca rutas de escalada de privilegios, exposición de secretos y fallos arquitectónicos que el código escrito por un profesional que conoce el entorno. El framework anterior no elimina ese riesgo, pero lo hace manejable, que es el estándar que tus pipelines de producción realmente requieren.