Validación y tratamiento de hallazgos

Un informe llega a revisión con una detección titulada «servidor web obsoleto». Cuando se pide demostrarla, aparecen varias posibilidades. El plugin pudo leer una cabecera, consultar un paquete local o reconocer una respuesta propia del producto. La cabecera puede estar sobrescrita, el paquete puede contener un backport y la respuesta puede proceder de un proxy. Repetir el título en el informe conserva toda esa incertidumbre, pero la oculta al lector.

El título del plugin es una afirmación general. El output es una observación concreta. Entre ambos existe una cadena de supuestos que la validación debe hacer visible.

Reformula el resultado como una condición comprobable:

El componente PRODUCT de ASSET_ID ejecuta una versión afectada por CVE_ID, la función vulnerable está activa y es alcanzable desde SCANNER_POSITION con IDENTITY.

La frase separa:

• activo
• producto
• versión
• configuración o función
• vulnerabilidad
• ruta
• identidad

No todas las vulnerabilidades necesitan todos los elementos. Una configuración predeterminada sin CVE sustituye la referencia pública por la directiva y su comportamiento.

Antes de modificar nada, guarda:

• ejecución, política, plugin y severidad
• output completo
• endpoint y marca temporal
• versión del escáner y estado del feed
• identidad y posición
• petición o prueba que el plugin declara realizar

Si el escáner no explica su método, registra esa limitación. El nombre del plugin no autoriza a inferir si usó un banner, credenciales o una prueba dinámica.

Relaciona IP, nombre de host, certificado, identificador del proveedor de nube, agente y propietario. Confirma que el resultado no pertenece a un balanceador, una traducción de direcciones de red (NAT), una red de distribución de contenido (CDN) o una dirección reasignada.

Contrasta al menos dos señales cuando sea posible:

• inventario de paquetes
• fichero o metadatos del binario
• API o interfaz de administración
• comportamiento de protocolo
• banner
• proceso y argumentos de ejecución

Los banners son útiles y fáciles de modificar. El gestor de paquetes conoce el paquete instalado, pero puede no describir el binario que está cargado en memoria. La validación explica qué señal prevalece.

Compara con el esquema del proveedor. Distingue la versión del proyecto original, la revisión de la distribución, el firmware, la build y el hotfix. Revisa los avisos de seguridad y el historial de cambios del proveedor.

Los backports corrigen código manteniendo una versión upstream aparentemente vulnerable. Una comparación de cadenas puede generar un falso positivo. El caso inverso también existe: una versión parece corregida, pero un módulo vulnerable permanece desplegado.

Confirma que el módulo o la ruta vulnerable están instalados, habilitados y utilizan la configuración necesaria. Un paquete presente puede estar inactivo. Una biblioteca puede no cargarse. Una función puede requerir un rol o un feature flag.

Reproduce la ruta desde la posición pertinente. Separa:

• resolución
• red y puerto
• TLS o protocolo
• autenticación
• autorización
• endpoint o acción

Un control compensatorio puede reducir exposición. No corrige necesariamente la vulnerabilidad. Registra el control, su alcance y la forma de comprobarlo.

Elige una prueba que distinga la condición con el menor cambio de estado. Puede ser una consulta de versión autenticada, una respuesta diferencial, un fichero canario o una operación reversible.

La prueba de concepto metodológica decide suficiencia y efectos. La validación no necesita convertir cada CVE en una shell.

Una conclusión usa estados más precisos que vulnerable/no vulnerable:

• confirmed: evidencia suficiente confirma condición y alcance declarados
• likely: señales fuertes, pero falta un prerrequisito no observable
• not-affected: la condición se refuta con evidencia aplicable
• mitigated: la condición existe y un control comprobado bloquea la ruta analizada
• blocked: una limitación impide decidir
• not-tested: la prueba no se ejecutó

mitigated no equivale a not-affected. Si el control cambia, la vulnerabilidad reaparece. blocked conserva la tarea necesaria para resolverlo.

Una señal positiva gana valor cuando un control negativo no la produce. Ejemplos:

• endpoint afectado frente a endpoint corregido
• usuario autorizado frente a usuario sin el rol
• versión vulnerable frente a versión parcheada
• input de prueba frente a input inerte
• ruta permitida frente a ruta filtrada

Si ambas respuestas son idénticas, quizá se está midiendo un proxy, una plantilla de error o un WAF. La diferencia necesita explicarse antes de concluir.

Fuentes frecuentes:

• identificación incorrecta del producto o la versión
• backport no reconocido
• respuesta de proxy atribuida al backend
• plugin que usa una condición suficiente en un producto y no en esta variante
• servicio instalado pero función vulnerable desactivada
• resultado duplicado para varias interfaces del mismo activo
• contenido de seguridad desactualizado

Descartar requiere evidencia. Una excepción administrativa sin prueba no es un falso positivo.

La ausencia de resultado puede proceder de:

• activo omitido por descubrimiento
• puerto fuera del rango
• credenciales fallidas o privilegios insuficientes
• plugin deshabilitado
• feed incompleto
• timeout, pérdida o rate limiting
• servicio detrás de un nombre de host, SNI o una ruta no descubierta
• producto sin firma
• vulnerabilidad lógica que el escáner no modela

Un informe de evaluación debe describir esas limitaciones. «No se identificaron vulnerabilidades» solo es defendible dentro de la cobertura observada.

Agrupa por causa y remediación cuando la evidencia lo permita. Una actualización ausente en cien hosts puede ser un hallazgo con cien activos. Cinco configuraciones diferentes que comparten un CVE pueden requerir hallazgos separados.

No dedupliques solo por:

• CVE
• título del plugin
• IP
• puntuación

Conserva una tabla de instancias enlazada al hallazgo:

Campo normalizado	Contenido
asset_id	identificador estable
endpoint	interfaz observada
evidence	output o artefacto
condition	versión, directiva o permiso
status	confirmed, likely, not-affected, mitigated o blocked
source	escáner, plugin, feed y marca temporal

Después de validar, añade severidad y contexto. La redacción final explica:

• causa y condición
• activos y exposición
• evidencia reproducible
• consecuencia técnica
• relevancia para el entorno
• remediación de causa
• mitigaciones temporales
• criterio de retest

La exportación del escáner puede acompañar al informe. No es el entregable principal. La rama de documentación e informes conserva la estructura narrativa del hallazgo y activará su referencia especializada cuando alcance profundidad publicable.

Define el criterio antes de la corrección:

El retest se considerará satisfactorio cuando PRODUCT informe una build que contenga FIX_REFERENCE, la ruta de prueba deje de producir VULNERABLE_SIGNAL y la vista autenticada mantenga cobertura de inventario.

Ejecuta el control positivo y negativo, revisa regresiones y conserva la nueva política y feed. Si el plugin desaparece porque perdió acceso, el hallazgo sigue abierto.

• NIST SP 800-115
• FIRST: CVSS v4.0 User Guide
• CVE Record User Guide