Cómo leer un informe de seguridad web — sin entrar en pánico | Scanthra

Scanthra · 7 min de lectura · Actualizado Mayo de 2026

Por qué estos informes asustan al principio

La mayoría de los informes de seguridad fueron escritos originalmente por testers de penetración para otros testers de penetración. Usan palabras como «vector», «subdomain takeover vulnerable», «HSTS preload ausente» como si todo el mundo los leyera con el café. Si eres el propietario de un sitio pequeño y acabas de abrir un PDF lleno de cuadros rojos, la reacción natural es el pánico, seguido de cerrar la pestaña.

No lo hagas. Casi todos los informes modernos — el de Scanthra incluido — tienen la misma estructura por debajo del estilo, y una vez que sabes dónde mirar, puedes leer uno en unos diez minutos.

Las cuatro cosas que te dice cada problema detectado

1. Gravedad — ¿qué tan grave es, en teoría?

La gravedad es el peor impacto posible si el problema es real y alguien lo explota. Casi siempre usa cinco niveles:

• CRÍTICO — daño directo e inmediato. Ejemplos: un archivo .env públicamente legible con contraseñas de base de datos; un subdominio que un atacante puede tomar y usar para phishing. Trátalo como arreglar hoy.
• ALTO — grave pero no instantáneo. Ejemplos: una versión de WordPress antigua con exploits conocidos; TLS/SSL (cifrado) ausente en el dominio principal. Arregla esto esta semana.
• MEDIO — ayudaría a un atacante que ya tuviera acceso. Ejemplos: encabezados de seguridad ausentes, flags de cookies débiles. Arregla este mes.
• BAJO — higiene básica. Ejemplos: el banner del servidor revela la versión del software. Arréglalo la próxima vez que estés por allí de todas formas.
• INFO / Observación — no es un problema, solo algo que notamos (p. ej., «usas Cloudflare»). Contexto útil, sin acción.

2. Nivel de confianza — ¿qué tan seguro estamos?

Los escáneres pasivos ven tu sitio desde fuera, igual que un visitante. No siempre pueden estar 100% seguros de que un problema detectado es real. El nivel de confianza es un número, normalmente de 0 a 100%, que te dice qué tan seguro está el escáner en la detección en sí — por separado de qué tan grave sería el problema.

Scanthra usa un modelo 2D: cada problema detectado tiene tanto una gravedad como un nivel de confianza. Solo mostramos problemas detectados con confianza ≥ 50%. Todo lo que esté por debajo vive en la sección Observaciones, donde decimos «notamos esto, no estamos seguros, aquí explicamos por qué» en lugar de dar falsas alarmas.

Un orden de lectura práctico:

1. Gravedad ALTO o CRÍTICO con ≥ 80% de confianza — empieza aquí.
2. Gravedad MEDIO con ≥ 80% de confianza — programa en un sprint.
3. ALTO o CRÍTICO con 50–80% de confianza — verifica primero, luego corrige.
4. Todo lo demás — agrupa en una ventana de mantenimiento.

3. La solución — un párrafo, en lenguaje claro

Todo problema detectado que se precie incluye un breve párrafo de «cómo solucionarlo» sobre el que un desarrollador puede actuar. En los informes de Scanthra esto aparece bajo Arréglalo tú mismo: normalmente una o dos frases, a veces un fragmento de configuración listo para copiar. Si no gestionas el sitio tú mismo, esta es la parte que reenvías a quien lo haga — tu desarrollador web, agencia o soporte de alojamiento.

No tienes que entender la solución. Solo tienes que poder pasarla y preguntar «¿puedes hacer esto, y cuándo?».

4. Etiquetas de cumplimiento — ¿a quién más le importa, además de a ti?

Los problemas detectados a menudo llevan etiquetas como GDPR:Art32, NIS2:Art21, OWASP:A05. Son atajos que dicen «esto no es solo nuestra opinión; el regulador/estándar X espera que lo gestiones». Los tres que verás más:

• RGPD Art. 32 — la cláusula general de la UE sobre «medidas técnicas y organizativas adecuadas». Cosas como el cifrado en tránsito (HTTPS) y la configuración resistente a brechas entran aquí.
• NIS2 Art. 21 — las medidas de referencia de la NIS2 (directiva UE de ciberseguridad): gestión de riesgos, gestión de vulnerabilidades, seguridad de la cadena de suministro, cifrado, control de acceso. Aunque no seas una entidad regulada directamente, tus clientes grandes te preguntarán cada vez más por estas.
• OWASP (estándar de seguridad de apps) Top 10 — la lista estándar del sector de los riesgos más comunes en aplicaciones web. A05 es la mala configuración, A07 son los fallos de identificación y autenticación, y así sucesivamente.

¿Y los falsos positivos?

Ningún escáner pasivo es perfecto. A veces una herramienta marcará algo que, en los detalles específicos de tu configuración, no es realmente un problema. Ejemplos:

• Un «encabezado de seguridad ausente» que en realidad está configurado por tu CDN más arriba en la cadena y el escáner no pudo verlo.
• Una advertencia de «versión del CMS (gestor de contenidos) desactualizada» donde la cadena de versión está deliberadamente falsificada por un plugin de hardening.
• Un «subdominio que no apunta a ningún lado» donde el subdominio está intencionalmente aparcado para un lanzamiento próximo.

Cuando tengas dudas: corrígelo de todas formas. Casi todo «falso positivo» es barato de neutralizar, y hacerlo elimina el ruido de tu próximo escaneo también. Las excepciones son los casos en que la corrección supondría un trabajo real — ahí, pide a tu desarrollador que lo confirme antes de invertir horas.

Cómo compartir un informe con un desarrollador

Si reenvías el PDF, tres frases son suficientes:

«Hola — hemos hecho un escaneo de seguridad. ¿Podrías revisar los problemas detectados de gravedad ALTO y CRÍTICO que empiezan en la página 4 y decirme cuáles puedes corregir en este sprint y cuáles necesitan más planificación? Estoy dispuesto a desprioritizar todo lo que sea BAJO por ahora.»

Eso es todo. El desarrollador no necesita una traducción del informe; necesita permiso para priorizar.

Cómo es un informe «limpio»

Spoiler: nadie obtiene cero problemas detectados en el primer escaneo. Un sitio WordPress típico de una pequeña empresa tiene ~8–15 problemas detectados, en su mayoría encabezados MEDIO e higiene de cookies. Un objetivo razonable para «limpio» es:

• Cero CRÍTICO.
• Cero ALTO con más de 30 días de antigüedad.
• Una calificación global de B o mejor en la portada.

Todo lo que vaya más allá es dorar el lirio — útil, pero no lo que te separa de tus clientes.

Cómo escribe Scanthra sus informes

Mantenemos deliberadamente el lenguaje claro. Cada problema detectado tiene una línea de impacto en el negocio («si se explota, un atacante podría leer correos electrónicos de clientes, lo que sería una brecha del RGPD»), un párrafo de arréglalo tú mismo y un mapa de cumplimiento al principio para que puedas ver de un vistazo qué reguladores les importa. Si un problema detectado es dudoso, lo movemos a Observaciones en lugar de asustarte. El objetivo es un informe que puedas leer en el tren de vuelta a casa y sobre el que actuar a la mañana siguiente — no un PDF de 60 páginas que archivas bajo «aterrador, ya veré».