Qué significa el puntaje CVSS de un hallazgo

Cuando recibes un informe de pentest, cada hallazgo trae un número: CVSS (Common Vulnerability Scoring System), de 0 a 10. Es el estándar que usamos para calificar severidad de forma consistente, en vez de dejarlo a criterio subjetivo de quién escribió el hallazgo ese día. Pero un número solo no dice nada si no entiendes qué mide — y, como vas a ver más abajo, tampoco es toda la historia.

Qué mide realmente el puntaje

CVSS 3.1 se arma con ocho métricas divididas en dos grupos:

• Qué tan fácil es explotarlo: si necesita estar en la misma red o alcanza con internet (Attack Vector), si requiere condiciones especiales fuera del control del atacante como una race condition (Attack Complexity), si hay que estar autenticado y con qué rol (Privileges Required), y si la víctima tiene que hacer algo como hacer clic en un enlace (User Interaction).
• Qué se rompe si lo explotan: si expone datos (Confidentiality), si permite modificarlos o alterar el comportamiento del sistema (Integrity), y si puede tumbar el servicio (Availability) — cada una calificada como Ninguno, Bajo o Alto.

Con esas ocho respuestas, la fórmula entrega un número. De 9.0 a 10.0 es crítica, de 7.0 a 8.9 alta, de 4.0 a 6.9 media, y de 0.1 a 3.9 baja. Puedes calcular el de cualquier hallazgo propio con nuestra calculadora CVSS gratuita — corre 100% en tu navegador, no manda nada a ningún servidor.

La métrica que más se subestima: Scope

Hay una novena pieza que no es una métrica de exploitabilidad ni de impacto, sino que decide si el impacto se queda contenido en el mismo componente vulnerable o se escapa a otro. El ejemplo clásico: un XSS reflejado que termina robando la sesión de un administrador no afecta solo a "la aplicación" — afecta al navegador de la víctima, que es un componente de seguridad distinto. Eso es Scope Changed, y sube el puntaje bastante más de lo que la intuición sugiere para "solo un XSS". Si un informe te llega con un XSS calificado como severidad media y después otro con el mismo tipo de falla calificado como alta, esto suele ser la razón.

Errores comunes al calificar (y que un buen retest debería atrapar)

• Sobre-calificar exposición de información sin impacto directo: que se vea la versión de un software en un header HTTP es información, no una vulnerabilidad por sí sola — a menos que esa versión tenga un CVE conocido asociado, en cuyo caso el CVE es el hallazgo real, con su propio puntaje.
• Sub-calificar un puerto abierto "porque no hay exploit hoy": un servicio expuesto que no debería estarlo, con historial de vulnerabilidades graves, merece severidad real aunque hoy no haya un exploit público confirmado contra esa instancia puntual.
• Confundir "requiere varios pasos manuales" con Attack Complexity alta: AC alta es para condiciones que el atacante no controla — una ventana de tiempo angosta, tener que estar exactamente en la ruta de red correcta. Que un ataque tome varios pasos no lo hace automáticamente más difícil en términos de CVSS.

Por qué CVSS no alcanza por sí solo

Un CVSS 9.8 sin ningún exploit público ni explotación activa conocida representa, en términos de riesgo real hoy, algo distinto de un CVSS 7.5 que ya está en el catálogo CISA KEV (vulnerabilidades con explotación activa confirmada). Por eso además de CVSS miramos EPSS (la probabilidad estimada de que se explote en los próximos 30 días) y si el CVE asociado aparece en KEV. Priorizar remediación mirando solo el número de CVSS, sin ese contexto, es una de las formas más comunes de gastar el tiempo de un equipo técnico arreglando lo que suena más grave en vez de lo que realmente representa más riesgo esta semana.