¿Es seguro el código generado por IA? Los riesgos de seguridad explicados

Los asistentes de programación con IA se han convertido silenciosamente en los desarrolladores más rápidos de tu equipo. Autocompletan funciones, arman servicios enteros y responden "cómo hago X" dentro del editor sin cambiar de contexto. Las ganancias de productividad son reales y no van a desaparecer. Pero la velocidad es solo la mitad de la historia. La verdad incómoda es que buena parte del código generado por IA llega a producción de forma insegura, y entender los riesgos de seguridad del código generado por IA es hoy una parte central de hacer bien AppSec.

Este no es un problema de moda ni hipotético. Varios estudios han encontrado que una parte sustancial —citada con frecuencia en el rango del 40 al 50 %— de las muestras de código generado por IA contiene al menos una debilidad de seguridad. Que la cifra real sea un poco mayor o menor en tu base de código casi no importa. El punto es que "lo escribió la máquina" no es una garantía de seguridad, y tratar el código generado como confiable por defecto es la forma en que las vulnerabilidades se cuelan en producción a una escala para la que la revisión manual nunca fue diseñada.

Así que respondamos la pregunta con claridad. ¿Es seguro el código generado por IA? A veces. Con bastante frecuencia no lo es. Y la diferencia entre ambos se reduce a si tienes o no una capa de seguridad que lo inspeccione antes de que llegue a producción. A continuación están las categorías de riesgo que más importan, cada una con un ejemplo concreto y la clase de herramienta que la detecta.

Patrones inseguros por defecto

La categoría más común de vulnerabilidades del código generado por IA también es la más trivial: código que funciona, pasa una revisión rápida a simple vista y omite en silencio un control de seguridad. Los modelos de lenguaje están entrenados para producir código plausible y funcional. No están entrenados para producir código seguro, y "funcional" y "seguro" no son lo mismo.

Pídele a un asistente un endpoint de búsqueda y puede que recibas una consulta SQL construida con concatenación de cadenas —una falla de inyección de manual— porque ese patrón aparece constantemente en los datos de entrenamiento. Pide una función que renderice la entrada del usuario en una página y puede que recibas una salida sin ninguna codificación, abriendo la puerta al cross-site scripting. Pide hashing de contraseñas y puede que recibas MD5 o un SHA-256 pelado sin salt, porque esos fragmentos están por toda la web aunque sean inaceptables desde hace años.

Ninguno de estos casos parece incorrecto a primera vista. El endpoint devuelve resultados. La página se renderiza. La contraseña "se convierte en hash". La pieza que falta es el control de seguridad —consultas parametrizadas, codificación de salida, una función moderna de derivación de claves— y el modelo no tiene ningún incentivo para agregarlo a menos que se lo pidas explícitamente.

Esto es exactamente lo que la prueba estática de seguridad de aplicaciones (SAST) está diseñada para detectar. SAST lee el código, entiende el flujo de datos desde fuentes no confiables hasta sinks sensibles y marca la inyección, la salida sin codificar, la criptografía débil, sin importar quién la escribió. Cuando la IA está generando una gran parte de tus commits, SAST deja de ser un "estaría bien tenerlo" y se convierte en la alarma que detecta los patrones que tus desarrolladores no escribieron y que quizá no leyeron con atención.

Dependencias alucinadas e inexistentes

He aquí un modo de falla que no tiene equivalente en el código escrito por humanos: el modelo inventa un paquete que no existe. Pides un ayudante para parsear algún formato y el asistente escribe con seguridad import supersecure-parser y llama a funciones de él. La biblioteca es plausible. La API parece razonable. Y es completamente ficticia.

Por sí solo, un import alucinado simplemente rompe el build. El peligro real es lo que los atacantes hacen con ese patrón. Se llama slopsquatting: los adversarios vigilan los nombres de paquetes que los modelos suelen alucinar, luego registran esos nombres exactos en repositorios públicos y los llenan de código malicioso. El siguiente desarrollador cuyo asistente alucine el mismo nombre —y los modelos alucinan los mismos nombres con una consistencia inquietante— instala un paquete real que controla un atacante real. Ahora tienes un compromiso de la cadena de suministro que empezó como un autocompletado.

La defensa es el análisis de composición de software (SCA) combinado con una regla estricta de que toda dependencia se verifica antes de incorporarse: ¿el paquete existe?, ¿quién lo publica?, ¿qué antigüedad tiene?, ¿qué tan usado es?, ¿arrastra vulnerabilidades conocidas? Una capa de SCA que inventaría cada dependencia y la contrasta con la realidad detecta tanto el import alucinado como el genuinamente malicioso que ocupa su lugar, antes de que llegue a la máquina de un desarrollador o a tus servidores de build.

Vulnerabilidades heredadas de los datos de entrenamiento

Un asistente de IA es un espejo del código con el que fue entrenado, y buena parte de ese código es antiguo, obsoleto o ya era inseguro de origen. Cuando un modelo reproduce un patrón que era práctica estándar hace cinco o diez años, hereda las vulnerabilidades que venían con ese patrón.

Esto se ve cuando un asistente recurre a un algoritmo criptográfico obsoleto, fija una versión desactualizada de una biblioteca con CVE conocidas, deshabilita la verificación del certificado TLS "para que funcione" o reproduce un flujo de autenticación anterior a las mejores prácticas actuales. El código no es malicioso ni está alucinado: simplemente está atascado en el pasado, reproduciendo fielmente los errores de ayer porque los errores de ayer estaban bien representados en el conjunto de entrenamiento.

Esto es una mezcla de un problema de SAST y de SCA. La configuración insegura y las primitivas obsoletas aparecen en el análisis estático; las versiones de dependencias desactualizadas y vulnerables aparecen en el análisis de composición. El hilo común es que no puedes confiar en que el modelo sepa qué significa "actual". Tiene un corte de entrenamiento y ningún conocimiento de la CVE publicada la semana pasada. Tu pipeline tiene que aportar ese conocimiento por él.

Secretos y datos sensibles en el código generado

Pídele a un modelo un ejemplo que funcione y te dará un ejemplo que funciona, lo que a veces significa que rellena los huecos con una credencial incrustada en el código. El código generado tiene la costumbre de incrustar claves de API de relleno, cadenas de conexión con contraseñas en línea o tokens que parecen andamiaje pero se comitean tal cual, porque "lo arreglo después" es una mentira que toda base de código se cuenta a sí misma.

Hay una segunda versión, más sutil, de este problema. Cuando los desarrolladores pegan código real —incluidos secretos reales— en un asistente para pedir ayuda y luego pegan la respuesta de vuelta, las credenciales pueden barajarse, duplicarse o quedar en un comentario. La salida generada parece limpia, pero un secreto activo se fue de polizón.

El escaneo de secretos es el control aquí, y necesita ejecutarse en cada commit, idealmente en pre-commit y de nuevo en CI. Un escáner que reconoce formatos de credenciales y cadenas de alta entropía detecta la clave incrustada antes de que se suba y, igual de importante, te avisa cuando un secreto real ya se filtró, para que puedas rotarlo en lugar de confiar en que nadie se dio cuenta. Con la IA en el flujo generando código repetitivo en volumen, la superficie para una credencial accidental crece, y la revisión manual de código es la herramienta equivocada para detectar un token de 40 caracteres enterrado en un bloque de configuración.

El problema de "sin procedencia, sin dueño"

Aléjate de los errores individuales y hay un riesgo estructural debajo de todos ellos: nadie escribió este código, así que nadie se hace realmente responsable de él. Cuando un humano escribe una función, lleva consigo un modelo mental de lo que hace, por qué tiene esa forma y dónde están los bordes filosos. Cuando un asistente la genera y un desarrollador la acepta, ese modelo mental es endeble o inexistente. El autor oficial es una persona que, en la práctica, revisó la salida por más o menos el tiempo que tardó en pulsar Tab.

Esto importa para la seguridad porque la revisión es donde se supone que muchas vulnerabilidades deben morir. "¿Quién revisa un código que ningún humano escribió?" no es una pregunta retórica: es una brecha operativa. Falta la procedencia: a menudo no puedes distinguir en un diff qué líneas vinieron de una persona y cuáles de un modelo, así que ni siquiera puedes dirigir un escrutinio adicional al material de mayor riesgo. La responsabilidad es difusa: cuando un fragmento generado resulta ser vulnerable, no hay un autor que lo entendiera lo bastante bien como para haber detectado la falla.

No puedes resolver una brecha de responsabilidad con un memorándum de política. La resuelves haciendo del propio pipeline la red de seguridad: una capa de seguridad automatizada que trata cada cambio como no confiable y lo inspecciona por sus méritos, de modo que la seguridad no dependa de que un humano haya entendido a fondo las líneas que aprobó.

Por qué la revisión tradicional no lo detecta

Si tu respuesta al código generado por IA es "de todos modos lo revisamos todo", vale la pena ser honesto sobre por qué eso se está resquebrajando bajo la carga.

El primer problema es el volumen. Los asistentes de IA no solo ayudan a los desarrolladores a escribir más rápido; cambian la unidad de trabajo de una línea a un bloque. Una sola sugerencia aceptada puede tener decenas de líneas. Multiplícalo por un equipo y la cantidad de código que fluye hacia la revisión por día sube muy por encima de lo que la lectura humana cuidadosa puede seguir. Los revisores hacen triaje. Leen por encima. Los detalles de seguridad son justo el tipo de cosa que se pasa por alto.

El segundo es la velocidad. Todo el propósito de un asistente de IA es comprimir el tiempo entre la idea y el commit. Esa compresión también estruja la ventana de revisión. La presión por seguir el ritmo del desarrollo acelerado por IA convierte la revisión minuciosa en un sello automático, y el sello automático es indistinguible de no revisar nada cuando se trata de seguridad.

El tercero, y el más insidioso, es el sesgo de automatización: la bien documentada tendencia humana a confiar más en una salida que proviene de una máquina de lo que confiaríamos en la misma salida proveniente de una persona. El código de un asistente de IA parece fiable. Es sintácticamente limpio, está formateado con seguridad y funciona. Los revisores le conceden un beneficio de la duda que nunca le darían a un pull request apresurado de un colega, justo cuando deberían ser más escépticos, no menos.

Junta esos tres y la revisión manual, por sí sola, es estructuralmente incapaz de ser el control de seguridad para el código generado por IA. Sigue siendo valiosa para el diseño, la corrección y la mantenibilidad. No es un filtro fiable para fallas de inyección, criptografía débil o un token filtrado a escala de IA. Ese trabajo debe estar automatizado, ser consistente y aplicarse a cada cambio sin excepción.

Cómo adelantarse

La conclusión no es "deja de usar asistentes de IA". Ese barco ya zarpó, y la productividad vale la pena. La conclusión es que el código generado por IA necesita el mismo escrutinio de seguridad que cualquier entrada no confiable: aplicado automáticamente, en el pipeline, en cada commit.

En concreto, eso significa SAST detectando patrones inseguros a medida que se introducen, SCA verificando cada dependencia (incluidas las que no existen) y escaneo de secretos deteniendo las credenciales antes de que se suban. Significa desplazar estos controles hacia la izquierda (shift left), para que los desarrolladores reciban retroalimentación en el editor y en el pull request, y no en un pentest trimestral. Y significa tratar la salida de todo asistente como culpable hasta que se demuestre que es segura.

Eso es un flujo de trabajo, no un único ajuste, y merece más que un párrafo. Escribimos una guía complementaria, Cómo proteger el código generado por IA, que recorre la configuración práctica: dónde encaja cada control en el pipeline, cómo ajustarlo para que los desarrolladores no se ahoguen en ruido y cómo cerrar la brecha de procedencia. Si estás pasando del "deberíamos hacer algo al respecto" al "este es nuestro plan de despliegue", empieza por ahí.

Cierre

El código generado por IA llegó para quedarse, y sus riesgos de seguridad también. Los proveedores y los equipos que salgan adelante no serán los que se resistieron a los asistentes de IA, sino los que los combinaron con una capa de seguridad lo bastante fuerte como para detectar lo que la máquina hace mal. Rainforest te da esa capa: SAST, SCA y escaneo de secretos trabajando juntos a lo largo de tu pipeline, inspeccionando cada commit sin importar quién —o qué— lo escribió. Si la IA ahora está escribiendo una parte significativa de tu base de código, ese es justo el momento en que conviene asegurarse de que algo esté revisando su trabajo. Descubre cómo Rainforest protege el código generado por IA.