Confías en tu asistente de IA para programar. Escribe funciones limpias, maneja casos borde, deja comentarios útiles. El código compila, los tests pasan, el pull request — una propuesta para fusionar código nuevo en el proyecto principal — recibe el visto bueno. Tres meses después, un tester de seguridad encuentra un agujero en una función que tu agente escribió a las 2 AM. Nadie la cuestionó porque "se veía bien."

Esto no es un experimento mental. Esto es un martes cualquiera.

La brecha entre confianza y competencia

El código generado por IA ya representa aproximadamente el 46% del código nuevo en muchas empresas. No puedes evitarlo. Pero en algún punto entre "la IA lo escribió" y "lo mandamos a producción," se coló una suposición peligrosa: que la máquina sabe lo que hace. No lo sabe. Es un mecanógrafo muy rápido sin el menor concepto de lo que es un atacante.

Necesitas un manual de campo. Aquí está el tuyo.

Uno de cada cuatro snippets tiene un agujero

En febrero de 2026, el grupo de investigación en seguridad AppSecSanta probó seis LLMs principales — large language models, los cerebros detrás de ChatGPT, Claude, Gemini y compañía — con 89 prompts enfocados en seguridad. Python y JavaScript. Tareas del mundo real mapeadas al OWASP Top 10 — una lista ampliamente aceptada de los riesgos de seguridad más críticos en aplicaciones web.

El resultado: el 25.1% del código generado contenía vulnerabilidades confirmadas. Uno de cada cuatro snippets. Tu IA produce bugs a escala industrial, y lo hace con la calma confianza de alguien a quien jamás le hackearon nada.

Tasas de vulnerabilidad por modelo:

Modelo Tasa de vuln.
GPT-5.2 19.1% (mejor)
Gemini 2.5 Pro 22.4%
Grok 4 23.7%
Claude Opus 4.6 29.2%
DeepSeek V3 29.2%
Llama 4 Maverick 29.2%

Esa diferencia de 10 puntos significa que tu elección de modelo importa. Pero incluso el mejor modelo manda una vulnerabilidad en casi una de cada cinco respuestas. Elegir GPT-5.2 sobre Llama 4 ayuda. No te salva.

Donde más fallan los modelos:

  • SSRF (Server-Side Request Forgery — cuando tu servidor es engañado para hacer llamadas a URLs internas en nombre de un atacante): 32 hallazgos. La categoría más grande por lejos.
  • Injection (SQL injection, command injection — cuando la entrada del usuario se cuela en consultas a la base de datos o comandos del sistema): 30 hallazgos, 33.1% de todos los problemas.
  • Security misconfiguration: 25 hallazgos — secretos hardcodeados, modo debug dejado activo en producción.
  • Broken access control (dejar que los usuarios hagan cosas que no deberían poder hacer): presente en absolutamente todos los modelos probados.

Un estudio separado de Help Net Security de marzo de 2026 probó Claude Code, OpenAI Codex y Google Gemini en modo agente — no solo autocompletado, sino programación completamente autónoma. Los agentes produjeron 143 problemas de seguridad en 38 escaneos cubriendo 30 pull requests. El 87% de esos PRs contenía al menos una vulnerabilidad. Broken access control apareció en la salida de cada agente. De cada. Uno. Solo.

Por qué la máquina escribe código inseguro

Los modelos no son maliciosos. Son máquinas de probabilidad entrenadas con GitHub, y GitHub está lleno de código inseguro. Respuestas de Stack Overflow de 2015 que hardcodean secretos JWT (JWT — JSON Web Token, un pase digital que demuestra que estás logueado). Código de tutoriales que se salta la validación de inputs porque "esto es solo un demo." Código de producción de empresas que nunca corrieron una auditoría de seguridad.

Tres patrones aparecen una y otra vez:

1. Validación del lado del servidor ausente. Los agentes de IA aceptan valores del lado del cliente — puntajes, saldos, roles de usuario — sin verificarlos en el servidor. El modelo aprendió de miles de tutoriales que "dejaron la validación como ejercicio para el lector." El lector nunca hizo el ejercicio. La IA tampoco.

2. Configuraciones por defecto inseguras. Tokens JWT sin fecha de expiración. Implementaciones de OAuth (OAuth — un protocolo que te permite "Iniciar sesión con Google" en lugar de crear otra contraseña más) sin el parámetro state que previene el secuestro de sesión. Refresh tokens que no se pueden revocar. Los modelos generan código que funciona pero eligen el default flojo, no el seguro.

3. SSRF por todas partes. Cuando un modelo escribe código que hace fetch a una URL, casi nunca verifica a dónde apunta esa URL. Sin allowlists, sin bloqueo de direcciones IP internas, sin restricciones de protocolo. Simplemente hace requests.get(user_input) y lo manda. Un atacante le mete http://169.254.169.254/ y de repente tiene tus credenciales de la nube.

Tu stack de defensa en cinco capas

Deja de esperar a que los modelos se pongan más listos con la seguridad. Construye un pipeline — una secuencia automatizada de verificaciones — que atrape problemas sin importar quién o qué escribió el código.

Capa 1: Prompts enfocados en seguridad

La solución más simple no cuesta nada. Un estudio de Veracode descubrió que agregar un recordatorio genérico de seguridad a tu prompt mejoró la tasa de código seguro del 56% al 66% para Claude Opus 4.6. Diez por ciento de mejora con una sola frase. No es magia. Pero es gratis.

Agrega esto a tu system prompt, tus reglas de Cursor, o tu CLAUDE.md:

When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.

Para agentes de IA como Claude Code, Codex o Copilot en modo agente, pon estas instrucciones en los archivos de configuración de tu proyecto. El agente las lee en cada tarea.

Capa 2: SAST en tu editor

SAST — Static Application Security Testing — escanea tu código buscando vulnerabilidades sin ejecutarlo, como un corrector ortográfico pero para agujeros de seguridad. El hallazgo clave de AppSecSanta: solo una herramienta SAST detectó el 78% de las vulnerabilidades generadas por IA. Ejecutar múltiples escáneres mejora la cobertura dramáticamente.

Setup recomendado:

  • Semgrep — gratuito, rápido, más de 3,000 reglas. Corre en VS Code, JetBrains y CI. Detecta injection, SSRF, secretos hardcodeados.
  • Bandit (Python) — detecta problemas comunes de seguridad en Python. Cero configuración necesaria.
  • ESLint security plugins (JavaScript) — eslint-plugin-security y eslint-plugin-no-unsanitized.

Instala Semgrep como pre-commit hook — un script que se ejecuta automáticamente antes de cada commit, bloqueando código malo antes de que entre al repositorio:

pip install semgrep
semgrep --config auto --error .

Ahora cada commit se escanea. La IA escribe el código, Semgrep le da un cachetazo antes de que hagas push.

Capa 3: Escaneo en el pipeline de CI

Tu pre-commit hook atrapa lo obvio. Tu pipeline de CI — el sistema automatizado de build y tests que se ejecuta cuando haces push — debería correr un análisis más profundo:

# GitHub Actions example
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Enfoca tus reglas en las categorías donde más falla la IA: SSRF (CWE-918), injection (CWE-89, CWE-78), deserialización insegura (CWE-502 — cuando datos maliciosos se desempaquetan en objetos ejecutables), y path traversal (CWE-22 — cuando un atacante usa ../../ para escapar de un directorio y leer archivos que no debería ver).

Capa 4: Revisión humana con lente de seguridad

La revisión de código generado por IA es diferente a la revisión normal. No estás buscando errores de lógica — la IA maneja eso razonablemente bien. Estás buscando:

  • Endpoints sin verificación de autenticación. La IA escribe el route handler pero se olvida del middleware — el código guardián que verifica "¿tienes permiso de estar aquí?"
  • Input del usuario fluyendo hacia lugares peligrosos. Consultas a base de datos, operaciones de archivos, requests HTTP, comandos de shell. Si la entrada del usuario toca cualquiera de estos sin sanitización, tienes un problema.
  • Rate limiting ausente. La IA nunca agrega rate limiting a menos que se lo pidas explícitamente. Todo endpoint público lo necesita, o alguien lo va a martillar con 10,000 requests por segundo.
  • Secretos en el código. El modelo a veces genera API keys de ejemplo que se ven lo suficientemente reales como para mandarse a producción. Luego terminan en GitHub. Luego terminan en las manos de alguien más.

Entrena a tu equipo para que haga una pregunta por cada función generada por IA: "¿Qué pasa si el input es hostil?"

Capa 5: El archivo de reglas de OpenSSF

La OpenSSF — Open Source Security Foundation — publicó una guía estandarizada de seguridad para instrucciones de asistentes de código con IA. Es un archivo de reglas que dejas caer en la raíz de tu proyecto. Toda herramienta de IA que soporte instrucciones a nivel de proyecto lo lee automáticamente.

El archivo cubre validación de inputs, codificación de outputs, autenticación, manejo de sesiones, criptografía, manejo de errores y logging. En lugar de escribir tus propias reglas de seguridad desde cero, usa las de ellos — mantenidas por profesionales de seguridad, actualizadas regularmente, y gratuitas.

Lo que esto te cuesta

Tiempo. Cada capa agrega fricción. Los pre-commit hooks suman 5–15 segundos por commit. Los escaneos de CI agregan minutos a tu pipeline. La revisión humana requiere humanos que sepan cómo se ve un SSRF. El archivo de OpenSSF requiere leerlo una vez y entender qué hace.

Los falsos positivos te van a irritar. Semgrep va a marcar código que en realidad está bien. Vas a pasar tiempo investigando no-problemas. Ese es el impuesto que pagas por atrapar los reales.

Y nada de esto es infalible. El estudio de AppSecSanta descubrió que el 22% de las vulnerabilidades se escaparon de todas las herramientas SAST que probaron. Algunos agujeros requieren testing dinámico — ejecutar el código y atacarlo de verdad — para encontrarlos. El análisis estático es necesario pero no suficiente.

Qué hacer el lunes a primera hora

No necesitas implementar las cinco capas para la próxima semana. Empieza con dos:

  1. Agrega instrucciones de seguridad a tu configuración de IA. Copia el bloque de prompt de la Capa 1. Pégalo en tu proyecto. Cinco minutos.
  2. Instala Semgrep como pre-commit hook. Dos comandos. Listo antes de que se enfríe tu café.

Solo eso ya te pone por delante de la mayoría de equipos que mandan código generado por IA a producción hoy. Agrega el escaneo de CI cuando tengas un sprint con espacio para respirar. Agrega el archivo de OpenSSF cuando alguien de tu equipo lo lea y lo entienda. Entrena a los reviewers con el tiempo.

La nueva normalidad

La tasa de vulnerabilidades en código generado por IA bajó de aproximadamente 40% en 2024 a 25% en 2026. Progreso, claro. A este ritmo, llegamos a "aceptable" por ahí de 2030. No puedes esperar cuatro años.

Trata el código generado por IA como la salida de un desarrollador junior que escribe a 500 palabras por minuto, irradia confianza y jamás escuchó hablar de OWASP. Revísalo. Escanéalo. Pruébalo. Luego mándalo a producción.

La IA escribe código a velocidad 10x. Tu tooling de seguridad necesita ir al mismo ritmo. Las herramientas existen. La única pieza que falta es el hábito de usarlas.