Seguridad en cada cambio de un agente: composer qa, tests, auditoría y ZAP juntos

Hola, bienvenido. En esta última lección vamos a juntar todo lo que hemos montado en el curso en un solo circuito de seguridad: qué se comprueba después de cada cambio, qué cuando el agente termina una tarea y qué antes de desplegar. Lo vamos a dejar escrito en AGENTS.md, para que el agente lo ejecute solo, y vamos a ver qué recibe el agente cuando lanza composer qa. Y cerramos el curso con lo que se queda fuera y dónde lo tienes.

Las piezas ya están en invoices, repartidas en 21 lecciones. Aquí las ordenamos por el momento en que se usa cada una, porque no todas cuestan lo mismo ni ven lo mismo, y un circuito que lo ejecuta todo en cada cambio acaba siendo tan lento que nadie lo lanza.

El circuito tiene 3 momentos, y cada uno vigila algo que el anterior no ve.

Después de cada cambio, composer qa. Es el circuito que montamos en la lección 2 y que ha ido creciendo: Pint, Larastan, composer audit desde la lección 13 y Pest con 49 tests. Entre ellos están los del agente, los de seguridad de la sección 2, los del asistente de la sección 4, el de la conversación de la lección 20 y el preset security. Vigila todo lo que ya tiene un test y tarda unos segundos, así que se lanza después de cada cambio sin pensarlo. Es el que para una regresión: si un agente reescribe show y deja fuera la llamada a la policy, el test de la lección 6 se pone en rojo.

Al terminar una tarea, la checklist y la auditoría. La checklist de la lección 10 se aplica sobre el diff de la tarea. Si la tarea toca rutas, controladores, form requests, policies, tools o vistas, además, el prompt de auditoría de la lección 20 se aplica sobre esa parte. Vigilan el código nuevo, el que todavía no tiene test, y lo que encuentran acaba en un test nuevo, así que cada revisión deja composer qa un poco más completo.

Antes de desplegar, ./zap/scan.sh. El escaneo de la lección anterior mira las respuestas de la aplicación, lo que no está en ningún archivo del proyecto. Necesita los contenedores levantados y tarda algo más de medio minuto, así que no tiene sentido en cada cambio, pero sí antes de que el código salga de tu máquina. Sus reglas en FAIL hacen, desde fuera, lo que los tests de seguridad hacen desde dentro.

Y hay 2 piezas que no esperan a ningún momento. La política de Composer de la lección 14 descarta las versiones con avisos de seguridad cada vez que Composer resuelve dependencias, con require o update, y las marcadas como malware también en install. Y Dependabot, de la lección 13, abre un pull request cuando sale un aviso para una de tus dependencias. Las 2 vigilan las dependencias aunque nadie toque el código.