Triaje de un informe entero

Un triaje sin orden depende del humor de quien lo hace. Con tres preguntas fijas se vuelve repetible. Primera: ¿el código vive en producción o en pruebas? Segunda: ¿el valor que llega a la línea marcada viene de fuera del programa o es una constante propia? Tercera: ¿hay una comprobación o conversión entre ese valor y la línea? Si el código es de pruebas, o el valor no viene de fuera, o está saneado, el hallazgo es un falso positivo: la forma se parece a un fallo pero no hay nada que explotar. Si pasa las tres, es verdadero y entra en la cola de corrección. Hay una tercera salida: un hallazgo verdadero que se decide aceptar, con responsable y fecha.

La disciplina está en que la severidad que muestra el informe no es una de las tres preguntas: un ERROR en un archivo de pruebas sigue siendo falso positivo.

Con las tres preguntas aplicadas, el informe se parte en dos montones, y dentro del montón de verdaderos se ordena por severidad. No es lo mismo el primero de la cola que el último. El triaje tiene sentido si al final alguien puede decir con una frase qué hallazgo se corrige hoy y por qué los demás no.

En el informe de Naranjal hay hallazgos de severidad ERROR que parecen igual de urgentes y no lo son. Aplica las preguntas a cada uno.

El porcentaje de falsos positivos de un informe es la medida más honesta de cuánto se puede fiar el equipo de él. Para calcularlo hay que contar con el mismo criterio para todos: es falso positivo todo hallazgo que cumple al menos una de estas condiciones, está en código de pruebas, el valor no viene de fuera, o está saneado. Es verdadero el que no cumple ninguna. Contar a ojo, o contar solo los que uno recuerda, da cifras que no se pueden comparar con las del mes siguiente.

Un informe donde la mayor parte es ruido enseña al equipo a no abrirlo; saber cuánto es esa parte es lo que permite afinar las reglas con datos.

Decidir que un hallazgo es falso positivo no lo hace desaparecer: el análisis lo volverá a marcar en la siguiente corrida. Para que no moleste hay que silenciarlo, y silenciarlo mal es peor que dejarlo: una regla apagada para todo el repositorio, o un archivo entero excluido, deja ciegos a los hallazgos reales que lleguen mañana. La forma correcta es la más estrecha posible: un comentario de supresión sobre esa línea y esa regla, con el motivo escrito, quién responde de la decisión y cuándo se revisa, porque el código que hoy sanea el valor puede cambiar.

Una supresión es una decisión de seguridad tomada en un comentario; merece la misma trazabilidad que cualquier otra.

Cada cierto tiempo hay que leer las supresiones que ya están en el código, porque son decisiones de seguridad escritas por otras personas. Las preguntas son tres: ¿tiene motivo?, ¿tiene responsable?, ¿está al día su fecha de revisión? Una supresión que no responde ninguna es un hallazgo apagado sin trazabilidad: nadie sabe si el código que lo justificaba sigue ahí.

La tabla de supresiones de Naranjal lista las que hay en producción. Una de ellas no cumple lo mínimo.