Cómo leer un informe de seguridad: guía práctica

La primera reacción de quien recibe un informe de análisis de seguridad con 100, 150 ítems suele ser la misma: pánico, seguido de "¿por dónde empiezo?". La buena noticia es que la mayoría de esos ítems no exige ninguna acción — son controles que ya pasaron, u observaciones informativas. El trabajo real es separar la señal del ruido.

Qué significa realmente cada campo del informe

Puntaje. Es una nota agregada — generalmente de 0 a 100 — calculada a partir de cuántos controles pasaron, cuántos fallaron, y el peso de cada uno según su severidad. Un puntaje de 75 no significa literalmente "75% seguro"; significa que, en la ponderación de ese scanner, todavía existen brechas relevantes, pero nada crítico abierto (si no, el puntaje caería mucho más).

Severidad. Normalmente en una escala como Crítico → Alto → Medio → Bajo → Informativo. Es la dimensión más importante para decidir el orden de corrección — no la cantidad de ítems.

• Crítico: la explotación activa e inmediata es plausible (ej.: secreto expuesto, base de datos accesible públicamente). Corríjalo primero, siempre.
• Alto: vulnerabilidad real, pero exige más pasos para ser explotada (ej.: ausencia de CSP).
• Medio/Bajo: debilita la postura de seguridad, pero aisladamente rara vez es el vector de un ataque exitoso.
• Informativo: no es una falla — es un dato recopilado (tecnología detectada, certificado válido) que ayuda al diagnóstico general.

Estado. Aprobado, Falla, Observado, No concluyente. "Observado" y "No concluyente" no son fallas — generalmente significan que la prueba no encontró una condición de riesgo confirmada, o que necesita más contexto (acceso autenticado, por ejemplo) para concluir. Tratar esto como una vulnerabilidad real es un error común que hace perder tiempo corrigiendo lo que no lo necesita.

Evidencia. El fragmento concreto que sustenta el hallazgo — el header que estaba ausente, el valor exacto encontrado. Siempre vale la pena reproducir la evidencia antes de aplicar cualquier corrección: los informes reflejan el momento del análisis, y algo puede haber cambiado desde entonces.

El orden correcto de corrección

1. Crítico primero, sin excepción — aunque sean solo 1 o 2 ítems.
2. Alto, priorizando lo que tiene menor riesgo de romper algo al corregirlo (ej.: agregar un header de seguridad suele ser más seguro de aplicar que cambiar una configuración de autenticación).
3. Medio, agrupando por categoría — corregir todos los headers de seguridad de una vez suele ser más eficiente que ir ítem por ítem en orden aleatorio.
4. Bajo e Informativo, cuando sobre tiempo — importan para el puntaje, pero no para el riesgo real del día a día.

Errores comunes al actuar sobre un informe

• Corregir por cantidad, no por severidad. Cerrar 10 ítems de bajo riesgo da una sensación de progreso mayor que resolver 1 ítem crítico — pero el riesgo real queda prácticamente igual.
• Tratar una "falla dependiente" como ítem aislado. Algunos hallazgos solo se resuelven después de otro (ej.: la calidad de una CSP depende de que la CSP exista primero). Corregir en el orden equivocado hace parecer que la corrección "no funcionó".
• No volver a ejecutar el análisis después de corregir. Sin verificación posterior a la corrección, usted tiene una creencia, no una confirmación — y los headers y configuraciones tienen una forma sorprendente de "volver" después de un despliegue futuro.
• Aplicar todo de una vez en producción. Las correcciones de seguridad también pueden romper funcionalidad (una CSP mal ajustada, por ejemplo). Vale la pena aplicar de a poco, probando cada cambio.

El puntaje no es el objetivo — es el termómetro

El punto de un informe de seguridad no es "llegar a 100". Es tener visibilidad real de dónde están las brechas, decidir con información qué vale la pena corregir ahora y qué puede esperar, y acompañar la evolución a lo largo del tiempo. Un sitio que sube de 60 a 85 en algunas semanas, corrigiendo en el orden correcto, está en una posición mucho mejor que uno que intenta forzar 100 de puntaje corrigiendo todo de una vez sin entender qué significa realmente cada ítem.

Si todavía no tiene un punto de partida, el checklist de seguridad para sitios institucionales cubre los ítems que más aparecen en este tipo de informe incluso antes de ejecutar el primer análisis.