Cerrado en el ticket no es corregido en el sistema

Un ticket cerrado dice que alguien declaró terminado el trabajo. No dice que el trabajo esté bien hecho: quien aplica un parche puede equivocarse de servidor, olvidar un reinicio o parchear una réplica y no la que está en producción. Por eso el cierre de un hallazgo tiene dos pasos distintos: la corrección, que hace el dueño del sistema, y la verificación, que hace otra persona o el propio escáner con una prueba que no depende de la palabra del primero.

Verificar es volver a mirar el mismo síntoma por el mismo camino por el que se detectó, y dejar constancia fechada. Si el hallazgo salió de una comprobación local con credenciales, se vuelve a mirar así; si salió de una versión, se lee la versión instalada.

No toda evidencia vale lo mismo. Una captura del ticket demuestra que el ticket existe. Un correo del dueño demuestra que el dueño lo cree. Una lectura de la versión instalada, o de la configuración que se corrigió, demuestra el estado del sistema el día que se leyó. Un reescaneo con el mismo perfil que detectó el hallazgo demuestra que la misma prueba ya no lo ve.

La regla práctica: la mejor evidencia es la que cualquier otra persona podría repetir y obtener lo mismo, sin pedirle nada a quien cerró.

Abre el registro de tickets cerrados de Estribor. Seis cierres de septiembre, cada uno con su motivo y con lo que hay adjunto como evidencia. Un cierre sin nada adjunto no es necesariamente falso, pero es indefendible: nadie puede comprobarlo sin repetir el trabajo desde cero, y si es de una crítica, el riesgo de equivocarse es el más caro.

Cerrar como falso positivo es una afirmación fuerte: «el fallo nunca existió». Se apoya, igual que un parche, en una comprobación sobre el sistema: la versión real, la configuración, si el servicio siquiera corre. Que el dueño diga que no usa el componente es una pista para investigar, no una prueba. Mira cómo está sostenido el ticket de falso positivo de Estribor.