Cómo interpretar los resultados de un retest

Cada retest termina con un resultado claro que actualiza automáticamente el estado de la vulnerabilidad, para que siempre sepas en qué situación está cada hallazgo.

Resultados posibles

• Fixed: se confirmó la remediación y la vulnerabilidad ya no es explotable.

• Partially fixed: el fix reduce el problema, pero no lo elimina por completo.

• Not fixed: la vulnerabilidad sigue siendo explotable.

• Blocked: el entorno impidió el retest, por ejemplo porque el target no estaba accesible, la IP de Strike no estaba autorizada o las credenciales eran inválidas.

Cada resultado viene acompañado de evidencia que explica qué se encontró.

Cómo impactan los resultados en la vulnerabilidad

• Fixed pasa la vulnerabilidad al estado Fixed y la marca como verificada por Strike.

• Cualquier otro resultado la vuelve a Pending fix. Puedes pedir un nuevo retest cuando ajustes el fix o resuelvas el bloqueo del entorno.

• El retest más reciente siempre define el estado actual.

Para ver todos los estados de una vulnerabilidad, consulta Gestión del ciclo de vida de una vulnerabilidad. Si el resultado es Blocked por un problema de acceso, consulta Cómo autorizar las IPs de Strike y Cómo cargar credenciales para el testing.

Evidencia del retest

Cada retest completado incluye:

• Un análisis escrito de qué se testeó y qué se observó.

• Archivos de evidencia adjuntos que puedes descargar.

Se aplica el mismo estándar de calidad, ya sea que el retest lo haya ejecutado el Retest Agent o un Striker.

Historial de retests

El detalle de la vulnerabilidad incluye una sección Retest history con cada intento en orden cronológico:

• Fecha y quién lo solicitó.

• El resultado de cada retest.

• Vista previa de la evidencia y los archivos adjuntos, que puedes expandir al registro completo.

• Si hay un retest en curso, aparece arriba como en progreso.

Así tienes una trazabilidad auditable desde la detección hasta el fix verificado.