En la lección anterior documentamos cada hallazgo del engagement de TechNova y, en la plantilla de la SQLi, escribimos "Severidad: Crítica | CVSS 9.8" con una promesa: justificarlo aquí. Este es el momento. Cuando un informe recoge veinte, treinta o cincuenta hallazgos, TechNova no puede arreglarlos todos a la vez: necesita saber por dónde empezar. La clasificación de riesgos responde a esa pregunta con criterio objetivo, no con intuición ni con el hallazgo que a ti te pareció más vistoso.

Aquí desarrollamos en detalle el sistema estándar del sector para puntuar la severidad técnica —CVSS (Common Vulnerability Scoring System)— en sus versiones 3.1 y 4.0: qué mide cada métrica, cómo se lee un vector, cómo se traduce el score a un rating. Pero la lección no se queda ahí, porque la severidad técnica no es lo mismo que el riesgo de negocio. Un CVSS 9.8 en un servidor de pruebas aislado puede importar menos, para TechNova, que un 6.5 en la pasarela de pago. Aprenderás a combinar ambas visiones —la técnica y la de negocio— en una tabla de priorización real. La remediación concreta de cada hallazgo es la siguiente lección (06-03); aquí decidimos el orden.

1. Severidad técnica frente a riesgo de negocio
2. Qué es CVSS y para qué sirve
3. Las métricas base de CVSS v3.1
4. Leer y construir un vector CVSS
5. Del score al rating
6. CVSS v4.0: qué cambia
7. Métricas temporales y de entorno
8. Riesgo de negocio: probabilidad por impacto
9. Tabla de priorización de los hallazgos de TechNova
10. Alternativas: OWASP Risk Rating y DREAD
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

Antes de entrar en la mecánica, fija esta distinción porque gobierna toda la lección:

• Severidad técnica: cuán grave es la vulnerabilidad en sí misma, con independencia de dónde esté. La mide CVSS. Es objetiva y comparable entre organizaciones.
• Riesgo de negocio: cuánto le importa a TechNova que esa vulnerabilidad se explote. Combina la probabilidad de que ocurra con el impacto sobre su negocio concreto (ingresos, datos, reputación, cumplimiento). Depende del contexto.

Un pentester profesional entrega ambas: el CVSS da autoridad y comparabilidad ("esto es un 9.8, no es opinión mía"); el riesgo de negocio da relevancia ("y además está en tu tienda, que es de donde vienen tus ingresos"). Priorizar solo por CVSS es un error de junior; priorizar solo por intuición de negocio es poco riguroso. Se usan juntos.

CVSS es un estándar abierto, mantenido por FIRST, que asigna a una vulnerabilidad una puntuación numérica de 0.0 a 10.0 a partir de sus características técnicas. Su valor es que es reproducible y comparable: dos analistas que evalúan la misma vulnerabilidad con las mismas métricas obtienen el mismo score, y ese score significa lo mismo en TechNova que en cualquier otra empresa del mundo.

CVSS se organiza en tres grupos de métricas:

La mayoría de informes reportan el score base, y es lo que verás en las bases de datos de CVE. Las métricas temporales y de entorno ajustan ese base a la realidad de TechNova.

El grupo base se divide en explotabilidad (cuán fácil es abusar de la vulnerabilidad) e impacto (qué se rompe si se abusa). Estas son las ocho métricas base de la v3.1:

Las tres últimas (C, I, A) son la clásica tríada CIA. Cuanto más alto el impacto en cada una y más fácil la explotación, mayor el score.

CVSS se comunica como un vector: una cadena compacta que codifica cada métrica. Así se ve el de nuestra SQLi de TechNova:

Léelo métrica a métrica:

Con estos valores, la calculadora oficial de CVSS v3.1 da un score base de 9.8. No hace falta memorizar la fórmula: se usa la calculadora de FIRST. Lo importante es saber justificar cada métrica con la evidencia del test —por qué PR es None, por qué C/I/A son High— porque ahí está el rigor profesional.

El número de 0 a 10 se traduce a un rating cualitativo, que es lo que entiende quien no es técnico. La escala oficial de CVSS v3.1:

Nuestra SQLi, con 9.8, cae en Critical. Por eso en la plantilla de 06-01 escribimos "Severidad: Crítica": no era una etiqueta subjetiva, sino la traducción del score CVSS. En el informe se muestran ambos —el número y la etiqueta— para que técnicos y negocio lo entiendan cada uno a su nivel.

CVSS v4.0 (publicado por FIRST) refina el modelo para resolver críticas de la v3.1, sobre todo que casi todo acababa siendo "Critical". Cambios principales que debes conocer:

• Nueva granularidad de impacto: separa el impacto sobre el sistema vulnerable (VC/VI/VA) del impacto sobre sistemas posteriores (SC/SI/SA), sustituyendo el antiguo Scope por algo más expresivo.
• User Interaction con más matiz: ahora distingue None / Passive / Active en lugar de solo None/Required.
• El grupo "Temporal" se renombra a "Threat" y se centra en la madurez del exploit.
• Nomenclatura de score: un vector v4.0 puede reportarse como CVSS-B (solo base), CVSS-BT (base+threat) o CVSS-BTE (base+threat+environmental), dejando claro qué se puntuó.

Un vector v4.0 empieza por CVSS:4.0/.... En la práctica de 2026 convivirán ambas versiones; reporta con la que use tu cliente o herramienta e indica siempre la versión, porque un 8.0 en v3.1 no es exactamente comparable a un 8.0 en v4.0.

El score base es "de laboratorio". Las otras dos dimensiones lo acercan a la realidad:

• Temporales / de amenaza: ajustan según el estado actual de la amenaza. ¿Existe un exploit público y fiable? ¿Hay parche disponible? Una vulnerabilidad con exploit funcional circulando es más peligrosa hoy que la misma sin exploit conocido. Estas métricas suben o mantienen el score, nunca lo suben por encima del base.
• De entorno: ajustan según tu infraestructura. Aquí TechNova puede decir "en mi caso la confidencialidad de este activo es máxima porque guarda datos de pago" (elevando el impacto), o "este sistema está aislado y no expuesto" (reduciéndolo). Es el puente natural hacia el riesgo de negocio de la sección 8.

En informes de pentest suele reportarse el base como referencia común, y usarse el entorno para argumentar la priorización real ante el cliente.

Aquí damos el salto de lo técnico a lo que le quita el sueño a la dirección de TechNova. El riesgo se modela clásicamente como:

• Probabilidad: cuán fácil y atractivo es que esto se explote de verdad. El CVSS de explotabilidad (AV, AC, PR, UI) alimenta esta parte, más el contexto: ¿está expuesto a Internet?, ¿hay exploit público?, ¿es un objetivo apetecible?
• Impacto de negocio: qué pierde TechNova si ocurre. No en términos CIA abstractos, sino concretos: ingresos perdidos, datos de clientes filtrados, multas por incumplimiento, daño reputacional, parada de la tienda.

Esto se visualiza con la clásica matriz de riesgo:

La SQLi de TechNova es probabilidad alta (expuesta a Internet, sin autenticación, trivial de explotar) e impacto alto (toda la base de datos de la tienda, que es el corazón del negocio): riesgo crítico. Coincide con su CVSS, y por eso encabeza la lista.

Reunimos varios hallazgos del engagement y los priorizamos combinando CVSS y riesgo de negocio. Esta tabla es el corazón del informe para quien decide:

Observa el matiz profesional: TN-014 tiene menor CVSS que TN-001 pero comparte prioridad alta por su probabilidad y su impacto de negocio; TN-030, aun siendo un hallazgo real, es de prioridad baja y no debe consumir recursos antes que los críticos. Esa lectura es la que convierte una lista de scores en un plan.

CVSS es el estándar de facto, pero conviene conocer otros marcos que verás mencionados:

• OWASP Risk Rating Methodology: calcula el riesgo como Likelihood × Impact, pero desglosa cada factor con criterios pensados para aplicaciones web (habilidad del atacante, motivo, oportunidad, tamaño del grupo; impacto técnico y de negocio). Su fuerte es que integra el impacto de negocio de forma explícita.
• DREAD: modelo más antiguo (Damage, Reproducibility, Exploitability, Affected users, Discoverability) que puntúa cada factor y promedia. Es sencillo pero subjetivo; hoy se usa poco de forma formal.

En un informe profesional lo habitual es CVSS para la severidad técnica más una capa de riesgo de negocio al estilo OWASP. Menciónalos para dar contexto, pero mantén CVSS como columna vertebral por su comparabilidad.

• Priorizar solo por CVSS. Un 9.8 en un activo aislado puede ceder el paso a un 6.5 en la pasarela de pago. Combina siempre severidad técnica y riesgo de negocio.
• Inflar los scores. Poner todo en "Critical" para asustar destruye tu credibilidad y hace que el cliente no sepa qué es urgente de verdad. Justifica cada métrica con evidencia.
• No indicar la versión de CVSS. Un 8.0 en v3.1 no equivale a un 8.0 en v4.0. Especifica siempre CVSS:3.1/... o CVSS:4.0/....
• Confundir vulnerabilidad con riesgo. La vulnerabilidad es técnica; el riesgo depende del contexto de TechNova. Un mismo fallo tiene distinto riesgo en distintos activos.
• Olvidar el impacto de negocio. La dirección no prioriza por "C:H/I:H"; prioriza por "se filtran los datos de todos los clientes". Traduce.
• Consejo: aprende a justificar el vector, no a memorizar la fórmula. Usa la calculadora oficial de FIRST y dedica el esfuerzo a defender por qué cada métrica vale lo que vale.

Ejercicio 1. Durante el test confirmas un XSS almacenado en el formulario de reseñas de la tienda: cualquier visitante que vea la reseña ejecuta el script del atacante (robo de sesión). No requiere privilegios, se explota por red, pero sí necesita que la víctima cargue la página. Construye el vector CVSS v3.1 base razonando cada métrica (AV, AC, PR, UI, S, C, I, A).

Ejercicio 2. Tienes dos hallazgos: (A) SQLi con CVSS 9.8 en un servidor de staging sin datos reales y no accesible desde Internet; (B) fallo de control de acceso con CVSS 6.5 en la pasarela de pago en producción. Argumenta cuál prioriza TechNova y por qué, usando la distinción severidad técnica vs. riesgo de negocio.

Ejercicio 3. Explica, para el resumen ejecutivo, qué significa que la SQLi de TechNova tenga "CVSS 9.8, riesgo crítico" sin usar jerga técnica, en dos o tres frases que entendería un director financiero.

Solución 1. Vector razonado para el XSS almacenado:

• AV:N — se explota a través de la web (red).
• AC:L — no hacen falta condiciones especiales.
• PR:N — el atacante publica la reseña sin necesitar privilegios (o con una cuenta básica; aquí asumimos None por ser reseña pública).
• UI:R — Required: la víctima debe cargar la página de la reseña para que el script se ejecute.
• S:C — Changed: el script se ejecuta en el navegador de la víctima, un componente distinto del servidor vulnerable (el impacto cruza el ámbito).
• C:L / I:L / A:N — típico de XSS: robo de sesión/datos limitados (C:L), posible manipulación limitada del contenido visto (I:L), sin impacto directo en disponibilidad (A:N).

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (aprox. 6.1, Medium). Lo clave es el razonamiento, no clavar el decimal.

Solución 2. TechNova prioriza (B), el fallo en la pasarela de pago, pese a su menor CVSS. Motivo: la severidad técnica de (A) es mayor (9.8), pero su riesgo de negocio es bajo porque está en staging, sin datos reales y sin exposición a Internet: la probabilidad de explotación real y el impacto son mínimos. (B) tiene menor CVSS pero está en producción, en la pasarela de pago: alta probabilidad de ser un objetivo, e impacto directo sobre ingresos, datos de tarjetas y cumplimiento. El riesgo = probabilidad × impacto es mucho mayor en (B). Eso sí: (A) debe corregirse igualmente (y vigilar que ese staging no acabe expuesto), pero (B) va primero.

Solución 3. Ejemplo para dirección: "El catálogo de nuestra tienda online tiene un fallo que permite a cualquier persona en Internet, sin necesidad de contraseña, acceder a toda la base de datos: datos de clientes, pedidos y contraseñas. Es el nivel de gravedad más alto que existe y podría explotarse con muy poco esfuerzo, por lo que debe corregirse de forma urgente antes que cualquier otra cosa."

Hemos aprendido a priorizar, que es lo que convierte una lista de hallazgos en un plan de acción. Dominamos CVSS como estándar de severidad técnica: sus métricas base (AV, AC, PR, UI, Scope y la tríada CIA), cómo se lee y se construye un vector como CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, cómo el score se traduce a rating (de Low a Critical), qué añade CVSS v4.0 y para qué sirven las métricas temporales/de amenaza y de entorno. Y, sobre todo, aprendimos a no confundir la severidad técnica con el riesgo de negocio: la matriz probabilidad × impacto y la tabla de priorización de TechNova mostraron por qué a veces un hallazgo de menor CVSS va primero. Mencionamos también OWASP Risk Rating y DREAD como alternativas.

Ya tenemos los hallazgos documentados (06-01) y priorizados por riesgo (06-02). Sabemos qué está mal y en qué orden atacarlo. Falta lo que de verdad reduce el riesgo de TechNova: decir cómo arreglarlo, de forma accionable, realista y priorizada. Eso es la próxima lección, 06-03: Recomendaciones de Remediación, donde convertimos cada prioridad de esta tabla en una hoja de ruta que TechNova pueda ejecutar.