Documento público · sin cuenta

Versión actual de la metodología: 1.6.0 · Fuente actualizada el 10 de septiembre de 2026 (UTC)

Este texto se genera a partir de docs/scoring-methodology.md. Si cambia el archivo y reconstruyes el front, esta página cambia con él.

Índice del documento

Cómo calculamos el score de seguridad

Este documento explica, sin jerga técnica, cómo securitymbt calcula la calificación (A a F) que ves en tu panel y en los reportes que le entregas a tus clientes. Está pensado para que puedas explicárselo a un cliente que te pregunte "¿por qué somos una C?" — o defenderlo si alguien lo pone en duda.

Versión de la metodología: 1.6.0. Toda cifra de este documento corresponde a esta versión. Si cambia, este documento cambia con ella (ver la última sección, que incluye el historial de cambios).

La idea en una frase

Cada activo (un dominio, una API, una IP) empieza con la nota más alta posible y pierde puntos por cada problema de seguridad real que sigue sin resolver. No es una opinión ni una estimación: es aritmética simple sobre datos que el propio análisis recolectó, con un techo de sentido común para los casos graves que la aritmética sola no captura bien.

1. Las cinco categorías que medimos

El score global es un promedio ponderado de cinco categorías. No pesan lo mismo, porque no todas representan el mismo nivel de riesgo:

Categoría	Peso	Qué evalúa	Por qué ese peso
Certificados y TLS	25%	Que la conexión cifrada esté bien configurada: certificado vigente, protocolos modernos, sin configuraciones débiles.	Un problema aquí compromete todo lo que viaja entre el visitante y el sitio — es de los riesgos más directos que existen.
Cabeceras HTTP y cookies	20%	Cabeceras de seguridad del navegador y configuración de cookies.	Su ausencia es mala práctica y abre la puerta a ataques, pero rara vez es, por sí sola, la causa de un incidente.
DNS	20%	Configuración de correo (SPF/DMARC), configuración general del dominio, y riesgo de que un subdominio abandonado pueda ser secuestrado.	Un DNS mal configurado habilita suplantación de correo y secuestro de subdominios — grave, aunque normalmente requiere un paso adicional para explotarse.
Exposición	25%	Qué puertos y servicios son visibles desde internet — incluidos los servicios de IA (servidores MCP, endpoints de inferencia, paneles de agentes).	Un servicio de administración, una base de datos o un servicio de IA expuestos son, casi siempre, la forma más directa de perder el control de un activo.
Disponibilidad	10%	Que el sitio esté en línea y respondiendo.	Es un problema operativo, no de confidencialidad — importa, pero menos que un servicio expuesto o un certificado inválido.

Estos cinco pesos suman exactamente 100. Lo verificamos con una prueba automática en cada cambio de código: un peso mal puesto que sumara, por ejemplo, 97, produciría notas que parecen correctas pero no lo son, y nadie lo notaría a simple vista.

2. Cómo baja la nota de una categoría

Cada categoría empieza en 100 puntos. Por cada hallazgo de seguridad abierto (sin resolver) que le pertenece, resta puntos según su gravedad:

Gravedad	Puntos que resta
Crítica	40
Alta	20
Media	8
Baja	3
Informativa	0 (queda registrada, pero no afecta la nota)

Una categoría nunca baja de 0. El score global es el promedio de las cinco categorías, ya ponderado por los pesos de la tabla anterior.

Solo penalizan los hallazgos que siguen abiertos. Si tú o tu cliente marcan un hallazgo como "riesgo aceptado" (una decisión consciente de convivir con ese riesgo) o como "falso positivo" (el análisis se equivocó), ese hallazgo deja de restar puntos de inmediato. No tiene sentido seguir penalizando una decisión que ya se tomó — si lo hiciéramos, la consecuencia real sería que la gente dejara de usar esas categorías para evitar el castigo, y perderíamos justo la información que necesitamos.

3. De número a letra

Nota	Rango
A	90 – 100
B	80 – 89
C	70 – 79
D	60 – 69
F	0 – 59

4. Las reglas que no admiten excepción

Hay dos situaciones donde no dejamos que la aritmética decida sola, porque un promedio puede esconder un problema grave detrás de un buen número.

Un solo hallazgo crítico abierto: la nota nunca pasa de D

No importa qué tan bien salga el resto de la cuenta: si hay al menos un hallazgo de gravedad crítica sin resolver, en cualquier categoría, la calificación queda topada en D como máximo.

Por qué: una base de datos expuesta a internet no se compensa teniendo buenas cabeceras HTTP. Un score que dijera "A" con una base de datos abierta al público sería peor que no tener score, porque activamente ocultaría el riesgo más importante que tiene ese activo. Esta regla es la que hace que la nota sea confiable: nunca vas a ver una A que esconda un problema grave.

_(Nota técnica para quien quiera el detalle: esta regla topa la letra, no el número. El número interno de la categoría afectada sí puede quedar alto si el resto del sitio está bien — es intencional, y es justamente lo que hace evidente que la letra es una decisión de política, no solo un promedio.)_

Sin escaneos todavía: sin nota, no una F

Un activo que nunca se ha analizado no recibe una F — recibe "sin calificación". Un activo recién dado de alta que todavía no tuvo su primer análisis se ve, en el panel, como "pendiente", no como el peor alumno de la clase.

Por qué: "no sabemos" y "está mal" son cosas muy distintas, y confundirlas castigaría a un cliente nuevo por el simple hecho de acabar de registrarse. Apenas se completa el primer análisis, el activo recibe su primera nota real — que sí puede ser una F, si los datos así lo indican.

Verificación caducada: la nota se marca como desactualizada

Antes de analizar un activo, confirmamos que realmente te pertenece (por ejemplo, con un registro DNS). Esa verificación puede caducar con el tiempo. Cuando eso pasa, seguimos mostrando la última nota real que tuvimos, pero marcada como desactualizada, con la fecha del último dato confiable — para que quede claro que no es un número del día de hoy.

5. Lo que no medimos

Para que quede claro qué puedes prometerle a un cliente con este número, y qué no:

No es una auditoría de seguridad completa. Es un análisis continuo y

automatizado de la superficie expuesta a internet — no un pentest manual ni una revisión de código.

No sustituye un pentest. Un pentest prueba activamente si algo se

puede explotar; nosotros observamos configuración y exposición desde afuera, sin intentar comprometer nada.

No cubre lógica de negocio de la aplicación. No evaluamos si el

carrito de compras tiene un error que permite pagar de menos, ni si un usuario puede ver datos de otro dentro de la aplicación — ese tipo de problema requiere pruebas específicas de la aplicación, no un análisis externo.

No es una certificación ni un cumplimiento normativo. Una A en

securitymbt no equivale, por sí sola, a cumplir PCI-DSS, ISO 27001 ni ninguna norma similar.

Dicho en una frase: el score responde a "¿qué tan bien está configurada y protegida la puerta de entrada?", no a "¿es imposible entrar?". Nadie puede prometer lo segundo.

6. Cómo y cuándo cambia esta metodología

La metodología tiene un número de versión (hoy, 1.6.0) que queda guardado junto con cada nota que se calcula. Esto importa porque, sin este control, un cambio de criterio silencioso podría hacer que un cliente que era B pasara a D sin haber tocado nada — y eso, para un producto que se presume mide seguridad, sería inaceptable.

Qué garantizamos:

Todo cambio en los pesos, las penalizaciones, los cortes de calificación

o las reglas de esta página sube el número de versión.

Cada nota guardada conserva la versión de la metodología con la que se

calculó. Si tu nota cambia y no es por un problema nuevo o resuelto en tu sitio, la explicación siempre va a estar aquí: un cambio de versión documentado, nunca un ajuste silencioso.

Un cambio de versión se anuncia con anticipación en el panel antes de

entrar en vigor.

Si un cliente te pregunta por qué su nota cambió, esta página — con la versión correspondiente — es la respuesta que puedes darle.

Historial de versiones

Versión	Qué cambió
1.0.0	Versión inicial: las cinco categorías y sus pesos, las penalizaciones por gravedad, los cortes A–F y las reglas duras.
1.1.0	Se incorporan a la categoría de exposición los hallazgos de reputación (listas negras, dominios parecidos) y de huella tecnológica (versiones publicadas, CVE, paneles y archivos sensibles expuestos), y a la de DNS los de descubrimiento de superficie (subdominios e IPs abandonados). Los cinco pesos no cambian.
1.2.0	Se incorpora la superficie de IA a la categoría de exposición. Un servicio de IA alcanzable desde internet —un servidor MCP, un endpoint de inferencia, el panel de un agente— cuenta como una exposición más y penaliza esa sub-nota igual que cualquier otro servicio expuesto. Los cinco pesos no cambian. La nota de un activo que tenga un servicio de IA expuesto puede bajar tras el despliegue de esta versión: es intencional — antes ese riesgo no se estaba midiendo, y ahora sí. Un activo sin superficie de IA no se ve afectado.
1.3.0	Se incorporan a la categoría de exposición los hallazgos de las pruebas activas (DAST). Un XSS reflejado confirmado —una entrada de una página que vuelve al navegador sin escapar— cuenta como una exposición y penaliza esa sub-nota igual que cualquier otro servicio expuesto. Los cinco pesos no cambian. La nota de un activo con un reflejo confirmado sin resolver puede bajar tras esta versión: es intencional — antes ese riesgo no se estaba midiendo. Un activo sin hallazgos de pruebas activas no se ve afectado.
1.4.0	Se incorporan a la categoría de exposición los hallazgos de inyección de las pruebas activas (DAST): SQL y NoSQL. Una inyección confirmada —un parámetro que cambia la lógica de una consulta a la base de datos, comprobado por una firma de error inequívoca, por un diferencial verdadero/falso repetido, o por un retardo reproducido— cuenta como una exposición y penaliza esa sub-nota igual que cualquier otro servicio expuesto. Los cinco pesos no cambian. La nota de un activo con una inyección sin resolver puede bajar tras esta versión: es intencional — antes ese riesgo no se estaba midiendo. Un activo sin hallazgos de inyección no se ve afectado.
1.5.0	Se incorporan a la categoría de exposición los hallazgos de control de acceso y autenticación de las pruebas activas (DAST): IDOR/BOLA, ruta privilegiada abierta a bajo privilegio, y autenticación ausente o sesión expuesta en la URL. Un fallo de acceso confirmado cuenta como una exposición y penaliza esa sub-nota igual que cualquier otro servicio expuesto. Los cinco pesos no cambian. La nota de un activo con un fallo de acceso sin resolver puede bajar tras esta versión: es intencional — antes ese riesgo no se estaba midiendo. Un activo sin esos hallazgos no se ve afectado.
1.6.0	Se incorporan a la categoría de exposición los hallazgos de seguridad de API y resistencia de las pruebas activas (DAST). Un JSON que filtra campos internos (`api_exposure`) o una propiedad que A ve y B no (`bopla`) penalizan esa sub-nota igual que un IDOR. Un resultado no capado (`resource`) entra como baja (resta poco). La ausencia de límite de tasa (`rate_limit`) es informativa: se registra como exposición, no mueve la nota (es una observación sobre una ráfaga acotada, no una vulnerabilidad crítica). Los cinco pesos no cambian.