Vulnerabilidades en el código generado por IA: qué fallos pasan la revisión y quién los busca

Hola, bienvenido. En esta primera lección no vamos a escribir código. Vamos a ver los 3 frentes que recorre el curso. El primero son los fallos que trae el código que escribe un agente de IA, aunque trabajes bien y lo revises. El segundo, quién busca esos fallos, porque quien ataca hoy también usa agentes. Y el tercero, la puerta nueva que abre la IA cuando la añades a tu aplicación. Cada test que escribamos y cada comprobación que añadamos al circuito de calidad a lo largo del curso sale de algo que vas a ver aquí.

Empecemos por el problema. Si llevas tiempo programando con un agente, conoces la escena: le pides una funcionalidad, lee el proyecto, crea el controlador, la ruta, la vista y el test, lanza los tests y te lo devuelve todo en verde. Lo revisas, el código tiene buena pinta, sigue las convenciones de Laravel y hace lo que pediste, así que lo aceptas y haces commit. Y en la mayoría de los casos está bien. El problema son los pocos casos en los que no lo está, porque el fallo no se ve: el código es correcto a simple vista y el fallo es una comprobación que nadie ha escrito, como la llamada a una policy o una validación.

Imagina que le pides al agente la página de detalle de una factura con la descarga de su adjunto. Te escribe un show que busca la factura, la pasa a la vista y la pinta, y un método que devuelve el archivo del disco privado. Funciona, el test que ha escrito pasa, y en el proyecto hay una InvoicePolicy con su método view, registrada y funcionando, porque update y destroy sí la llaman. En show y en la descarga falta la llamada a la policy, una línea en cada método, y sin ella cualquier usuario con la URL de una factura de otro cliente la ve y se descarga el adjunto. Ese fallo lo trae invoices, el proyecto del curso, y lo vamos a arreglar en la sección 2. Fíjate en que al revisarlo no hay nada que salte a la vista, porque ninguna de las líneas que ha escrito el agente está mal.

Casi todos estos fallos caben en 2 grupos. El primero son las comprobaciones que no están, y es el más frecuente en el código de los agentes: la policy que existe y no se llama, el $fillable que no está porque el modelo lleva $guarded = [], el form request que se saltó y el update que guarda $request->all(). El agente resuelve la tarea que le has dado, y si la tarea era "que se pueda editar el cliente", editar el cliente es lo que hace; que solo pueda hacerlo su dueño es una condición que nadie ha escrito en ningún sitio.

El segundo grupo es al revés, código que sí está y falla en un detalle: una búsqueda con whereRaw y el texto del usuario concatenado, que el agente escribe para hacerla insensible a mayúsculas; un {!! !!} en Blade para conservar los saltos de línea de unas notas; la clave de un servicio que pegaste en el prompt y aparece como valor por defecto en config/services.php; y un paquete de Composer que el modelo se ha inventado y que no existe en Packagist, con la vuelta de tuerca de que ese nombre inventado se repite entre modelos y alguien puede registrarlo con código dentro. A esto último lo llaman slopsquatting y tiene su propia lección.

¿Y por qué pasa todo esto la revisión? Por el sesgo de "funciona y los tests pasan". Cuando revisamos código que ya está en verde, leemos para confirmar que hace lo que pedimos, y lo hace. Lo que no hacemos, salvo que lo llevemos en la cabeza, es preguntarnos qué debería impedir, porque el test que ha escrito el agente comprueba que la factura se ve y ningún test comprueba que la de otro usuario no se vea. A eso se suma que revisar cansa: si el agente nos devuelve 8 archivos y los 8 tienen buena pinta, al tercero ya estamos leyendo en diagonal. Nos pasa a todos, y a mí el primero, y ese es justo el motivo del curso: en lugar de confiar en que lo veamos, vamos a tener una lista de lo que hay que mirar y tests que lo comprueben por ti.

Si quieres profundizar en esta idea, en el blog tienes El verdadero problema con la IA en programación no es la herramienta↗ (se abre en una pestaña nueva), que cuenta por qué el problema está en cómo trabajamos con la IA y no en la IA.