BrassCoders descubrió secretos integrados en el código en dos de los quince scripts de Python generados por IA que examinaron, lo que expone un riesgo concreto para los desarrolladores que copian y pegan código directamente de los resultados de los modelos de lenguaje extensos. Los hallazgos muestran que una sola clave o contraseña mal ubicada puede convertir un fragmento útil en una filtración de credenciales en los entornos de control de versiones y de producción.

Lo que reveló la prueba

El primer script, token_check.py, fue producido a partir de un prompt que solicitaba una función para firmar tokens de sesión e incluir un "ejemplo utilizable". Para que el código fuera ejecutable, el modelo insertó una clave de firma HMAC literal directamente en el archivo fuente.

  • Problema: La clave secreta reside en la base de código.
  • Riesgo: Cualquier persona con acceso de lectura al repositorio puede ver la clave, y cualquier despliegue que extraiga el archivo hereda el secreto.
  • Consecuencia: Un atacante que obtenga la clave puede falsificar tokens de sesión válidos, eludiendo los controles de autenticación.

El segundo script, email_sender.py, respondió a una solicitud de una función que envía correos electrónicos vía SMTP. El modelo volvió a proporcionar una contraseña literal para que el ejemplo funcionara de inmediato.

  • Problema: La contraseña aparece como una cadena de texto plano en la llamada a la función.
  • Riesgo: Rotar la contraseña requiere un cambio de código y un nuevo despliegue, y la credencial se propaga a cada entorno que utiliza el archivo.
  • Consecuencia: La contraseña puede ser recolectada de sistemas de control de versiones, registros o paquetes compilados, otorgando a un adversario acceso no autorizado al servidor de correo.

Por qué la IA genera secretos

Los modelos de lenguaje extensos generan texto completando el prompt. Cuando un usuario pide un "ejemplo utilizable", el modelo lo interpreta como "código que se ejecuta sin configuración adicional". Por lo tanto, rellena los valores faltantes —claves de API, contraseñas, tokens— con marcadores de posición plausibles. El modelo no tiene conocimiento de las mejores prácticas de gestión de secretos a menos que el prompt lo mencione explícitamente.

Un análisis reciente de Veracode sobre código generado por IA encontró que el 45 % de los fragmentos contienen al menos una vulnerabilidad incluida en el OWASP Top 10, siendo la exposición de credenciales una parte considerable. La estadística subraya que el problema no se limita a unos pocos casos aislados; es un subproducto sistémico de cómo se entrenan y se les da instrucciones a estos modelos.

Pasos de mitigación que los desarrolladores pueden tomar ahora

La defensa más sencilla es mantener cualquier secreto fuera del propio archivo de código. Las variables de entorno son el método más común y agnóstico al lenguaje:

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

El uso de os.environ extrae el valor del entorno de ejecución, manteniéndolo fuera del control de versiones y permitiendo su rotación sin tocar los archivos fuente. El mismo patrón funciona con archivos de configuración que se excluyen de los commits, servicios de gestión de secretos o secretos orquestados por contenedores.

Salvaguardas adicionales

  • Revisiones de código que marquen cadenas literales que coincidan con patrones comunes de secretos (por ejemplo, secuencias alfanuméricas largas).
  • Herramientas de análisis estático ajustadas para detectar credenciales integradas en archivos recién añadidos.
  • Ingeniería de prompts: pedir explícitamente al modelo que "use variables de entorno para todos los secretos" o que "omita las credenciales reales".
  • Linting post-generación: ejecutar un script rápido que busque literales sospechosos antes de copiar el código en un proyecto.

Contrapunto: ¿Significa esto que el código de la IA no es seguro?

La presencia de secretos integrados en el código no implica que el código generado por IA sea universalmente inseguro. En muchos casos, el modelo produce una lógica limpia y bien estructurada que puede acelerar el desarrollo. El riesgo surge cuando los desarrolladores tratan el resultado como listo para producción sin una auditoría de seguridad. Trate a la IA como un asistente de redacción, no como un sustituto de las prácticas de seguridad establecidas.

Qué observar a continuación

  • Actualizaciones de herramientas: las plataformas de IA están comenzando a incorporar filtros de seguridad que reemplazan los secretos con marcadores de posición. Monitorear esos cambios puede reducir la exposición.
  • Cambios en las políticas: las organizaciones pueden formalizar directrices para la codificación asistida por IA, exigiendo controles de gestión de secretos como parte del pipeline de CI.
  • Patrones de la comunidad: a medida que los desarrolladores compartan más "prompts seguros", las plantillas de mejores prácticas podrían convertirse en el resultado predeterminado para tareas comunes como la firma de tokens o el envío de correos electrónicos.

Conclusión: La IA puede generar código funcional en segundos, pero a menos que los desarrolladores impongan una disciplina en la gestión de secretos, la conveniencia conlleva un costo oculto: credenciales expuestas que pueden comprometer todo un sistema. Trata cada fragmento de código como un borrador, elimina cualquier secreto literal e inyéctalos mediante variables de entorno o una bóveda dedicada antes de realizar el commit.