Seguridad del código generado por IA: la pasada que no admite atajos

TLDR: El código generado no es más inseguro que el humano, pero falla distinto: valida de menos, confía de más, incrusta secretos con naturalidad y a veces inventa dependencias que alguien malicioso ya registró. La defensa: conocer esa patología, verificar dependencias siempre, dirigir tu revisión a los puntos calientes (entradas, autenticación, secretos) y automatizar la red con escáneres y CodeRabbit en cada pull request. Con agentes en paralelo, esta pasada escala igual que el resto o se convierte en el agujero.

Esta guía es para quien ya trabaja con agentes y quiere que la velocidad no se pague en incidentes. Completa la técnica general de la guía de revisar código de IA con la dimensión donde el coste de un fallo no se mide en tiempo sino en sustos: la seguridad.

El marco honesto: los agentes escriben código con clases enteras de fallos humanos ya resueltas, y a cambio introducen su propia patología. Conocerla es la mitad de la defensa.

1. Conoce los fallos de seguridad típicos de la IA

El código generado tiene un sesgo estructural: está entrenado para que funcione, y la seguridad es exactamente lo que no se ve cuando funciona. De ahí su patología característica.

La validación ausente: el caso feliz impecable y la entrada hostil sin contemplar, porque el ejemplo del que aprendió tampoco la contemplaba. Los secretos incrustados: la clave de API en el código “para que el ejemplo funcione”, con toda naturalidad. La confianza en la entrada: consultas construidas concatenando, rutas de fichero sin sanear, deserialización alegre. Y el patrón viejo con seguridad de experto: el método de cifrado o la configuración que fue razonable hace años, escrita con total confianza.

Nada de esto es exótico: es la lista de siempre de seguridad de aplicaciones, con la diferencia de que llega en volumen y con una prosa segura que desarma la sospecha.

2. Verifica cada dependencia antes de instalarla

El vector genuinamente nuevo del código generado son las dependencias inventadas. Los modelos completan nombres de librerías plausibles que no existen, y esa alucinación tiene explotación conocida: registrar el paquete inventado con contenido malicioso y esperar a que alguien instale lo que su agente sugirió.

La versión sistemática: el análisis de dependencias automatizado en el repositorio (los gestores modernos y las plataformas lo traen) que avisa de paquetes con vulnerabilidades conocidas o características sospechosas antes de que lleguen a la rama principal.

3. Dirige la revisión de seguridad a los puntos calientes

La revisión de seguridad completa de cada cambio no escala, y no hace falta: los fallos viven concentrados en puntos calientes conocidos, y la revisión dirigida los cubre.

Aquí también ayuda la transparencia del flujo: con herramientas como Cline, que enseñan cada paso antes de aplicarlo, los cambios en zonas calientes se ven venir en lugar de descubrirse en el diff final. Y con Claude Code, el fichero de instrucciones del proyecto debe incluir las normas de seguridad de la casa: cómo se manejan secretos, qué librerías de validación se usan, qué está prohibido.

4. Automatiza la red de seguridad en el repositorio

La disciplina humana necesita red, y la red se monta una vez. Las tres piezas: el escáner de secretos que bloquea el commit con claves dentro, el análisis de dependencias en cada pull request, y CodeRabbit como revisor automático, que entre lo que caza incluye los problemas evidentes de seguridad: la consulta concatenada, la validación ausente, el secreto incrustado. Gratis para proyectos de código abierto, con capa gratuita limitada en privados y desde 24 dólares al mes.

Con esa red, la seguridad escala con el volumen de los agentes: cada pull request pasa los mismos filtros sin depender de que el humano de turno esté fino. La revisión dirigida del paso 3 se reserva para donde la máquina no llega, que es el juicio sobre el diseño.

El sistema completo (agente, revisor automático, revisión dirigida, escáneres) es el que permite decir que el código generado en tu casa es tan seguro como el humano, con evidencia y no con fe. Todo el sector, en IA para desarrollo de software.

Errores comunes

Instalar dependencias sugeridas sin verificar. Es el vector nuevo y el hábito de treinta segundos que lo neutraliza. Ninguna dependencia propuesta se instala sin comprobar que es lo que dice ser.

Revisar seguridad solo cuando “el cambio es de seguridad”. Los fallos llegan en el cambio normal que toca un formulario. El mapa de puntos calientes existe para eso.

Confiar en que las pruebas cubren la seguridad. Las pruebas generadas verifican el caso feliz: la entrada hostil hay que pedirla explícitamente, en las pruebas y en la revisión.

Guardar el escáner de secretos para producción, en vez de bloquear el commit.

El secreto ya commiteado obliga a rotarlo aunque se borre después.

Preguntas frecuentes

¿El código de IA es más inseguro que el humano?

Es distinto: resuelve clases enteras de descuidos humanos y trae su propia patología (validación ausente, secretos, dependencias inventadas). Con el sistema de esta guía, el resultado neto es comparable o mejor. Sin él, el volumen multiplica los fallos característicos.

¿Qué es lo primero que debería montar?

El escáner de secretos y la verificación de dependencias: son las dos protecciones más baratas contra los dos fallos más caros. El revisor automático va justo después.

¿Puedo pedirle al agente que revise su propia seguridad?

Como pasada adicional sí, y pedirle que explique el manejo de casos hostiles es revelador. Como única revisión no: comparte el contexto y los sesgos de lo que generó. El revisor con ojos limpios (automático o humano) no se sustituye.

¿Esto cambia con agentes en paralelo?

La red automática escala sola (cada pull request pasa los filtros), y la revisión dirigida se convierte en el criterio de dimensionado: no lances en paralelo más trabajo en zonas calientes del que puedas revisar con cuidado.