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 defensa es un hábito de treinta segundos que no se delega: antes de instalar una dependencia que el agente propone, comprobar que existe, que es la librería que dice ser y que tiene la comunidad y el mantenimiento esperables. El paquete con nombre casi idéntico al famoso, cero historial y publicación reciente es la bandera roja clásica.

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.

El mapa: todo lo que toca entrada de usuario (formularios, APIs, ficheros subidos, parámetros), todo lo que toca autenticación y permisos, todo lo que construye consultas o comandos, y todo lo que maneja secretos y configuración. Cuando el diff de un agente pisa esos terrenos, la lectura fina no es opcional, y pedirle al propio agente que explique su manejo de los casos hostiles es una técnica que rinde: la explicación floja delata el código flojo.

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 (la protección más barata que existe contra el fallo más vergonzoso), 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 código abierto y desde unos 24 dólares por desarrollador en privado.

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. El secreto ya commiteado obliga a rotarlo aunque se borre después: el escáner rinde bloqueando el commit, no auditando el histórico.

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.