← todos los posts
seguridad·9 de agosto de 2026·10 min

IA Generativa: La verdad incómoda sobre el código y la seguridad

Descubrí cómo el código generado por LLMs introduce riesgos de seguridad significativos y qué deben hacer los líderes de ingeniería para mitigarlos. Basado en el Veracode 2026 GenAI Code Security Report.

La IA generativa está acelerando dramáticamente la fase de prototipado y la generación de boilerplate en el desarrollo de software. Sin embargo, detrás de esta promesa de velocidad, se esconde una verdad incómoda que muchos líderes de ingeniería prefieren ignorar: el código generado por LLMs, por más sofisticado que parezca el modelo, introduce un riesgo de seguridad significativo y a menudo silencioso. No se trata de la “inteligencia” del LLM, sino de cómo opera y los sesgos inherentes a su entrenamiento. El reciente “Veracode 2026 GenAI Code Security Report” lo deja en claro: la tasa de vulnerabilidades en código generado por IA no disminuye, a pesar de la evolución de los modelos. Esto no es una predicción, es una realidad que estamos viviendo y que los líderes de ingeniería no podemos darnos el lujo de obviar.

El Mecanismo del Riesgo: Generación de Código y Vulnerabilidades Silenciosas

Para entender el riesgo, hay que ir al cómo. Un LLM genera código basándose en patrones estadísticos aprendidos de vastos datasets que incluyen código abierto, foros, repositorios y, sí, también código que contiene vulnerabilidades. El LLM no posee un modelo de riesgo ni de amenazas; no razona sobre las implicaciones de seguridad de un patrón de código más allá de su corrección sintáctica o su funcionalidad aparente. Su “inteligencia” es estadística, no de seguridad.

Ejemplo Concreto: Inyección SQL Imaginemos un desarrollador pidiéndole a un LLM: “Generame una función en Python para interactuar con una base de datos SQLite y manejar la autenticación de usuarios”.

El LLM, al no comprender el concepto de inyección SQL, podría generar algo como esto:

import sqlite3

def authenticate_user(username, password):
    conn = sqlite3.connect('users.db')
    cursor = conn.cursor()
    # ¡Vulnerabilidad aquí! Inyección SQL
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    cursor.execute(query) # Ejecuta una consulta vulnerable
    user = cursor.fetchone()
    conn.close()
    return user is not None

# Uso (ejemplo)
# if authenticate_user("admin", "password123"):
#     print("Autenticación exitosa")
# else:
#     print("Fallo de autenticación")

A primera vista, el código “funciona”. Cumple con la solicitud. Pero un ojo entrenado inmediatamente detecta una inyección SQL clásica en la línea query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'". Si un atacante ingresa ' OR '1'='1 como username, la consulta se convierte en SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...', lo que permitiría el bypass de autenticación.

El LLM generó este código porque vio patrones similares en su corpus de entrenamiento, sin discernir que esos patrones eran peligrosos. No hay intención maliciosa, solo una reproducción estadística de lo que “parece correcto” o “funcional”. Este es el mecanismo del riesgo: la generación de código funcional pero inherentemente inseguro, que se esconde a la vista.

Tradeoffs: Velocidad vs. Seguridad y Cuándo NO Conviene

La promesa más inmediata y tangible de la IA para desarrolladores es la velocidad. Generar boilerplate, refactorizar, escribir tests, todo más rápido. Pero esta velocidad tiene un costo en seguridad si no se gestiona adecuadamente.

Característica Ganancia (con LLMs) Pérdida/Riesgo (con LLMs) Cuándo NO Conviene
Velocidad de Desarrollo Acelera la generación de código repetitivo, prototipado rápido. Introduce vulnerabilidades difíciles de detectar, mayor superficie de ataque, deuda técnica de seguridad. En módulos de criptografía, pasarelas de pago, sistemas de gestión de identidades, o cualquier componente que maneje datos sensibles o lógica de autorización crítica. También, sistemas sujetos a compliance estricto (PCI DSS, HIPAA, GDPR), ya que los LLMs no tienen “memoria” de dichas regulaciones.
Productividad del Dev Reduce el tiempo en tareas monótonas, permite enfocarse en problemas de mayor nivel. Requiere mayor esfuerzo en revisión de seguridad, entrenamiento específico en prompt engineering para seguridad, y escaneo constante. Equipos con poca experiencia en seguridad, sin procesos robustos de revisión de código o donde la trazabilidad y auditabilidad del código son primordiales.
Innovación Facilita la exploración de nuevas ideas y tecnologías, reduce barreras para experimentar. Puede generar “innovación” en formas de explotación al crear nuevas combinaciones de vulnerabilidades o configuraciones inseguras que imitan patrones existentes, pero en contextos novedosos. Proyectos donde la robustez, la confiabilidad y la predictibilidad del comportamiento son más importantes que la velocidad de experimentación, como infraestructuras críticas o sistemas life-critical.

El riesgo se magnifica cuando los desarrolladores, presionados por los plazos, confían ciegamente en el código generado o no tienen el conocimiento de seguridad para identificar las vulnerabilidades. La noticia de JFrog detectando 54 CVEs falsos de SQLite generados por IA es un claro ejemplo de cómo la IA no solo genera código inseguro, sino que puede incluso simular problemas de seguridad, generando falsos positivos que agotan recursos y desvían la atención.

El Desafío del Contexto, la Desinformación y las “Alucinaciones”

Los LLMs carecen de contexto sobre la arquitectura completa de nuestro sistema, los estándares de seguridad específicos de la empresa o las políticas de compliance. Esto se manifiesta en problemas de seguridad concretos, no solo en abstracciones.

Ejemplo Concreto: Configuración de Firewall en AWS Un desarrollador pide a un LLM: “Generame una configuración de security group para un servidor web en AWS que permita acceso SSH y HTTP”.

El LLM, sin conocer las políticas de seguridad de la organización (ej. SSH solo desde VPN, HTTP solo desde load balancer interno), podría generar una configuración funcional pero peligrosa:

{
  "SecurityGroupIngress": [
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "IpRanges": [
        {
          "CidrIp": "0.0.0.0/0"
        }
      ]
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 80,
      "ToPort": 80,
      "IpRanges": [
        {
          "CidrIp": "0.0.0.0/0"
        }
      ]
    }
  ]
}

Este JSON, aparentemente correcto, abre los puertos SSH y HTTP al mundo (0.0.0.0/0), creando un agujero de seguridad masivo en un entorno de producción que requiere acceso restringido.

Otro problema es la desinformación o las “alucinaciones”. Los LLMs pueden generar información incorrecta o sugerir prácticas obsoletas. Si un desarrollador pide “la mejor forma de encriptar datos sensibles en Python”, el LLM podría, por ejemplo, sugerir un algoritmo débil o una implementación incorrecta:

import hashlib

def encrypt_data_weak(data, key):
    # ¡Vulnerabilidad aquí! Uso de MD5 y clave estática (o débil)
    # MD5 no es un algoritmo de encriptación seguro y no tiene un buen propósito aquí.
    # La clave debería ser gestionada de forma segura.
    hash_object = hashlib.md5(key.encode())
    hashed_key = hash_object.hexdigest()
    # Esto no es encriptación, es un hash. Y MD5 es débil para esto.
    # Además, no maneja IVs ni modos de operación correctos para encriptación real.
    return f"Data:{data}_HashedKey:{hashed_key}"

# Ejemplo de uso (inseguro)
# encrypted_info = encrypt_data_weak("mi_secreto", "clave_secreta_facil")
# print(encrypted_info)

Este código ilustra cómo un LLM podría sugerir el uso de MD5 (un algoritmo de hashing obsoleto para seguridad) en un contexto de “encriptación”, o una clave estática, debilitando la seguridad en lugar de fortalecerla.

graph TD
    A["Desarrollador (prompt)"] --> B{"LLM Genera Código/Config"}
    B -- "Carece de contexto/modelo de riesgos" --> C{"Código Funcional pero Inseguro"}
    C -- "No revisado/Validado adecuadamente" --> D["Vulnerabilidad en Producción"]
    D -- "Explotación" --> E("Brecha de Seguridad")

    subgraph Factores Agravantes
        F["Presión por velocidad"] --> B
        G["Falta de expertise en seguridad"] --> C
        H["Alucinaciones del LLM / Datos de entrenamiento sesgados"] --> B
        I["Confianza ciega en el LLM"] --> C
    end

    subgraph Controles de Mitigación
        J["Prompt Engineering orientado a Seguridad"] --> A
        K["SAST/DAST en CI/CD"] --> C
        L["Revisión de Código por Pares (Enfoque en Seguridad)"] --> C
        M["Políticas de Uso de LLMs"] --> B
        N["Educación y Concientización"] --> A
    end

    K -- "Detecta Vulnerabilidades" --> L
    L -- "Corrige/Refina" --> C

Este diagrama destaca cómo la falta de contexto y la confianza excesiva llevan a la explotación, y dónde se insertan los controles para mitigar los riesgos.

Qué Hacer el Lunes: Pasos Accionables para Líderes de Ingeniería

Como líderes, nuestra responsabilidad es mitigar estos riesgos sin frenar la innovación. Aquí hay pasos concretos para implementar:

  1. Educación y Concientización Continua con Casos Prácticos: Capacitá a tus equipos no solo en cómo usar LLMs para generar código, sino especialmente en cómo identificar y corregir vulnerabilidades comunes con ejemplos concretos (como los de inyección SQL o configuración de firewall). Fomentá el escepticismo activo hacia el código generado por IA. La seguridad se integra en el ADN del desarrollo al entender los riesgos específicos que introducen las nuevas herramientas.

  2. Integrar Herramientas de Análisis Estático de Seguridad (SAST) y DAST desde el Día Cero: Asegurate de que tu pipeline de CI/CD incluya herramientas SAST robustas que escaneen el código por vulnerabilidades, independientemente de si fue escrito por un humano o un LLM. Para aplicaciones web, las herramientas DAST (Dynamic Application Security Testing) son cruciales para encontrar vulnerabilidades en tiempo de ejecución. El informe de Veracode subraya que una mayor adopción y configuración efectiva de estas herramientas es más crítica que nunca.

  3. Reforzar la Revisión de Código por Pares (Peer Review) con Foco en IA: La revisión de código es tu primera línea de defensa humana. Fomentá una cultura donde los revisores busquen activamente patrones de seguridad problemáticos, especialmente en código generado por IA. Considerá checklists específicas para revisiones de código asistido por IA que incluyan preguntas como: “¿Este código maneja correctamente la entrada de usuario?”, “¿Se están utilizando las librerías criptográficas de forma segura?”, “¿Hay configuraciones por defecto inseguras?”.

  4. Establecer Políticas Claras de Uso de LLMs y Zonas de Riesgo: Definí qué tipos de código pueden ser generados por IA y cuáles requieren una supervisión humana más estricta. Por ejemplo, se puede permitir la generación de boilerplate para UI, pero restringir el uso de LLMs para módulos de autenticación, autorización, lógica de negocio crítica o cualquier componente que maneje datos sensibles hasta que se establezcan procesos de validación de seguridad robustos y automatizados.

  5. Fomentar el “Prompt Engineering” Orientado a la Seguridad: Entrená a tus desarrolladores para que incluyan requisitos de seguridad específicos en sus prompts. Por ejemplo, en lugar de “Generame una función de autenticación”, pedí “Generame una función de autenticación en Python que use sentencias preparadas para prevenir inyección SQL, que encripte la contraseña con bcrypt y que maneje rate limiting para intentos fallidos”. Esto fuerza al LLM a buscar patrones más seguros.

  6. Monitoreo y Auditoría de Código Generado con Métricas Claras: Implementá métricas para rastrear la calidad y seguridad del código generado por IA versus el código escrito por humanos. Esto puede incluir la densidad de vulnerabilidades detectadas por SAST, el tiempo de revisión de código para módulos generados por IA, o el número de bugs de seguridad reportados en producción que se originaron en código generado por LLM. Esto te dará datos para ajustar tus políticas y entrenamientos, y para entender dónde la IA es un acelerador seguro y dónde es un vector de riesgo.

El código generado por IA es una herramienta poderosa que puede cambiar las reglas del juego. Sin embargo, no es una solución mágica para la seguridad. Como líderes, debemos abrazar esta innovación con los ojos bien abiertos, entendiendo los mecanismos del riesgo, no solo las promesas. Nuestra diligencia en seguridad debe superar la velocidad de evolución de los LLMs. Es nuestra responsabilidad asegurar que la promesa de la IA no se convierta en una puerta abierta a nuevas vulnerabilidades.