Del hallazgo a la corrección

Ante un hallazgo suelen llegar varios arreglos y no todos valen. Un buen arreglo elimina la causa. Uno malo filtra lo que hoy se conoce como peligroso: quitar un carácter concreto, limitar el largo, rechazar una lista de palabras. La lista de lo malo siempre queda incompleta, porque quien escribe el arreglo solo conoce las formas que se le ocurrieron. En una consulta, la causa es que el dato y la instrucción viajan mezclados en el mismo texto; el arreglo que la elimina es el que los mantiene separados, de modo que el dato nunca se interpreta como parte de la instrucción.

Esta pregunta sirve para cualquier hallazgo: ¿el arreglo quita la mezcla o solo disimula una de sus formas?

Después de cada propuesta se repite el mismo análisis sobre el código nuevo y se compara con el de la rama base. El resultado de cada hallazgo es uno de tres: cerrado (ya no aparece), sigue abierto (la corrección no lo tocó, o lo tocó mal) o nuevo (la propuesta introdujo algo que antes no había). El reescaneo es más fiable que la descripción de la propuesta, porque no depende de lo que su autor crea haber hecho.

La propuesta PR-0907 trae tres correcciones. Una de ellas no resolvió su hallazgo.

La corrección del archivo adjunto de PR-0907 reemplaza una secuencia concreta del nombre y deja el resto como estaba: es filtrar. Funciona contra la forma que su autor tenía en mente y contra ninguna otra, y el análisis, que mira el flujo y no la forma del texto, sigue viendo un nombre de fuera uniéndose a una ruta sin comprobar. La segunda propuesta cambia el enfoque: en lugar de limpiar el texto que llega, construye la ruta completa, la resuelve y comprueba que quede dentro del directorio permitido.

Comprobar el resultado en vez de limpiar la entrada es una pauta general: lo que importa es dónde termina la ruta, no qué caracteres trae.

Corregir con prisa a veces cambia un problema por otro. En la propuesta de las contraseñas el resumen rápido se sustituyó por un algoritmo con costo, que está bien, pero para la sal —el valor que hace distinto el resultado de cada usuario— se escribió un texto fijo en el código. Una sal igual para todos no cumple la función de una sal. El reescaneo lo detecta como un hallazgo nuevo, y por eso hay que leerlo entero: un informe que solo comprueba que los hallazgos viejos se cerraron se pierde justo esto.

Revisar una corrección incluye mirar lo que añade, no solo lo que quita.

Un hallazgo se cierra con evidencia, no con una frase en el ticket. Hace falta el reescaneo que ya no lo marca y, además, una prueba de regresión: una prueba automática que falle con el código de antes y pase con el de después. Si la prueba pasa también con el código viejo, no prueba nada. Y la prueba se queda en el repositorio para que, si alguien reintroduce el fallo dentro de seis meses, salte en la fusión.

El archivo de pruebas de regresión de los adjuntos muestra cómo se lee esa evidencia: tres versiones del código, tres resultados.