Severidad frente a prioridad de corrección

La guía de uso de CVSS insiste en que la puntuación base mide la gravedad propia del fallo y no debe usarse sola para valorar el riesgo; las métricas de amenaza y entorno acercan el número a la realidad de cada organización, pero tampoco deciden el calendario. La prioridad de corrección responde otra pregunta: con los recursos que hay, qué se arregla primero y en qué plazo.

Para que esa decisión no dependa del humor del día, se escribe un criterio: qué datos entran, cuánto suma cada uno y cómo se desempata. El criterio es de la casa y se dice así en el informe. Abre el laboratorio y lee politica-de-correccion.txt.

El criterio se aplica igual a todas las filas, con los datos de la cola y nada más. Primero el rango de la puntuación BTE con la escala; después las sumas y restas del contexto; al final el orden y el desempate. Hazlo fila por fila antes de mirar quién «parece» más grave.

Una prioridad no le sirve al equipo de desarrollo hasta que se convierte en una fecha. La política fija el plazo por prioridad y cuenta días naturales desde la fecha del hallazgo. Escribir la fecha en el ticket evita que «quince días» empiece a contar desde que alguien lo leyó.

Que un hallazgo tenga el número más alto de la cola no lo pone primero en la fila. Un activo que no se alcanza desde internet, con un control que de verdad funciona y tiene su prueba, puede esperar unos días más que un fallo menos grave expuesto a todo el mundo. Su severidad no cambia: lo que cambia es la urgencia, y por eso se escribe junto al control que la justifica.

La pregunta llega siempre: «si es crítico, ¿por qué no va primero?». La respuesta honesta deja la severidad donde está y muestra el criterio. Rebajar el número para que cuadre con el orden destruye la confianza en todos los demás números del informe, y esconde que la prioridad depende de un control que podría fallar mañana.