Una prueba de regresión por cada hallazgo cerrado

Una prueba de regresión de un hallazgo reproduce el comportamiento que lo hizo hallazgo: la misma petición, la misma persona, el mismo dato, y comprueba que ahora la respuesta es la correcta. La prueba de que la reproduce es sencilla y casi nadie la hace: correrla contra el código anterior al arreglo, donde tiene que fallar, y contra el arreglo, donde tiene que pasar. Una prueba que pasa en los dos lados no está mirando el fallo.

Lo demás es disciplina: la prueba lleva el identificador del hallazgo en su nombre, para que nadie la borre por parecer redundante; corre en cada solicitud de cambio y no en una tarea que nadie mira; y prueba el comportamiento, no la forma del arreglo, para que una refactorización legítima no la rompa ni la deje vacía. La guía de pruebas web de OWASP describe qué comprobar en cada área; la regresión es la forma de que esa comprobación no se haga una sola vez.

Abre el laboratorio y compara la columna de prueba declarada de hallazgos-cerrados.txt con las funciones que de verdad hay en test_regresion.py. Luego mira qué dice verificacion-regresion.txt de esa prueba.

En la corrida contra el código vulnerable, una prueba pasa. Lee su código en test_regresion.py y el resumen del hallazgo: el fallo estaba en el servidor, en lo que hace con el depósito, y la prueba comprueba otra cosa.

Cuenta los hallazgos cuya prueba existe, se ejecuta en la integración continua, falla contra el código anterior al arreglo y pasa con él. Una prueba omitida no se ejecuta, así que no vigila nada aunque esté bien escrita.

El último hallazgo del año es uno de 2025 que se cerró sin prueba y volvió con la aplicación móvil. Con lo que viste, propón la regla para que un hallazgo pase a cerrado.