SSVC explicado: de la puntuación a la decisión (Track, Attend, Act)

Una puntuación CVSS responde una sola pregunta: ¿qué tan grave podría ser esta vulnerabilidad? No te dice qué hacer el lunes por la mañana. Un 9,8 en un servidor de laboratorio y un 9,8 en tu portal de clientes reciben el mismo número, y tu equipo igual tiene que decidir cuál se lleva una ventana de cambio de emergencia.

SSVC, siglas de Stakeholder-Specific Vulnerability Categorization (categorización de vulnerabilidades específica para cada parte interesada), parte del extremo opuesto. En lugar de un número, entrega una decisión: Track, Track*, Attend o Act. En este artículo explicamos cómo funciona la versión de CISA, por qué el mismo CVE puede terminar en decisiones distintas según la organización y cómo empezar a usarla sin rehacer tu programa de vulnerabilidades.

De dónde sale SSVC

SSVC nació en 2019 en el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. En 2020 CISA trabajó con el SEI para crear su propio árbol de decisión y, en noviembre de 2022, publicó la CISA SSVC Guide, que describe el árbol con el que CISA comunica sus prioridades de parcheo.

La guía está pensada primero para agencias del gobierno de EE. UU. e infraestructura crítica, pero aclara que "cualquier persona u organización puede usar SSVC para mejorar sus propias prácticas de gestión de vulnerabilidades". Y su objetivo es directo: priorizar la remediación según el impacto que la explotación tendría en esa organización en particular.

Esa es la idea clave. CVSS califica la vulnerabilidad. SSVC califica la vulnerabilidad en tu entorno.

Las cuatro decisiones

Cada camino del árbol de CISA termina en una de cuatro decisiones:

• Track (seguir): la vulnerabilidad no requiere acción por ahora. Se monitorea y se corrige dentro de los plazos normales de actualización.
• Track* (seguir de cerca): tiene características que pueden requerir un monitoreo más atento por si cambia. También se corrige en los plazos normales.
• Attend (atender): requiere la atención de los supervisores. CISA recomienda corregir antes de los plazos normales.
• Act (actuar): requiere la atención de supervisores y de la dirección. CISA recomienda corregir lo antes posible.

Fíjate en lo que describen: quién tiene que enterarse y qué tan rápido hay que moverse. Eso es justo lo que un equipo de seguridad tiene que decidir, y encaja directamente con los SLA de remediación que casi todas las organizaciones ya tienen. Si aún no los definiste, empieza por nuestra guía de SLA de remediación y MTTR.

Los puntos de decisión

El árbol de CISA recorre cuatro preguntas, en este orden.

1. Explotación

¿Cuál es el estado actual de explotación?

• None (ninguna): no hay evidencia de explotación activa ni prueba de concepto pública.
• Public PoC: existe una prueba de concepto pública típica, por ejemplo en Metasploit o Exploit-DB.
• Active (activa): hay evidencia compartida, observable y confiable de que atacantes usaron el exploit en el mundo real.

El catálogo Known Exploited Vulnerabilities de CISA es la evidencia más común para el valor Active.

2. Automatizable

¿Puede un atacante automatizar de forma confiable los pasos 1 a 4 de la cadena de ataque (reconocimiento, preparación del arma, entrega y explotación) para esta vulnerabilidad? Sí o No. Esta pregunta separa un fallo que un script puede disparar contra todo internet de uno que exige un atacante paciente y manual.

3. Impacto técnico

Si se explota, ¿cuánto control obtiene el atacante sobre el software vulnerable?

• Partial (parcial): control limitado sobre el comportamiento del software o exposición de información sobre él.
• Total: control total sobre el comportamiento del software.

4. Misión y bienestar

Es la única pregunta que la vulnerabilidad no puede responder por ti. Combina dos datos:

• Prevalencia en la misión: ¿el componente afectado es Minimal (mínimo), Support (da soporte a tus funciones esenciales) o Essential (esencial para al menos una de ellas)?
• Impacto en el bienestar público: daño Minimal, Material o Irreversible (físico, ambiental, financiero o psicológico).

Juntos dan Low, Medium o High. En la tabla de CISA, un componente esencial para la misión da High sin importar el valor de bienestar.

Mismo CVE, otra decisión

Aquí es donde SSVC demuestra su valor. Estos caminos salen directamente de la tabla de decisión de la guía de CISA:

Explotación	Automatizable	Impacto técnico	Misión y bienestar	Decisión
Active	Sí	Total	High	Act
Active	Sí	Total	Low	Attend
None	Sí	Total	High	Attend
Active	No	Partial	Low	Track

Dos conclusiones que sorprenden a casi todos los equipos:

• "Explotada" no significa automáticamente "deja todo". Un fallo explotado activamente que no es automatizable, tiene impacto parcial y está en un sistema de baja importancia termina en Track.
• Tu contexto puede mover una vulnerabilidad un nivel entero. El mismo fallo explotado, automatizable y de impacto total es Act en un sistema esencial y Attend en uno mínimo.

Es la misma intuición detrás de la exposición a internet y de EPSS: la puntuación de una vulnerabilidad no es el riesgo para tu negocio.

No tienes que responder todo tú

Los tres primeros puntos de decisión describen la vulnerabilidad, así que son iguales para todos. Con su programa Vulnrichment, CISA agrega puntos de decisión SSVC (Exploitation, Automatable y Technical Impact) a los registros CVE en su contenedor de Authorized Data Publisher (ADP), y publica los datos en el repositorio público cisagov/vulnrichment de GitHub.

A tu equipo le queda la pregunta que solo tú puedes responder: ¿qué tan importante es este activo para la misión? En la práctica, el trabajo de verdad de SSVC no es puntuar CVE. Es mantener un inventario de activos con contexto de negocio: qué sistemas son esenciales, cuáles les dan soporte y cuáles son mínimos.

Cómo empezar a usar SSVC

1. Clasifica tus activos primero. Marca los sistemas como esenciales, de soporte o mínimos. Empieza por los obvios: servicios de cara al cliente, identidad, pagos y todo lo que esté regulado.
2. Asocia cada decisión a tus SLA. Por ejemplo: Act es un cambio de emergencia con aviso a la dirección; Attend es corregir antes del ciclo normal; Track y Track* siguen el ciclo estándar. Déjalo por escrito para que nadie lo discuta en medio de un incidente.
3. Automatiza las entradas. Toma el estado de explotación de KEV y de la inteligencia de amenazas, los puntos de decisión de la vulnerabilidad del enriquecimiento de CISA cuando existan, y el contexto de misión de tu inventario.
4. Reevalúa cuando cambian los hechos. Un Track puede volverse Act de un día para otro cuando una prueba de concepto pública pasa a explotación activa. Track* existe justamente para marcar las que vale la pena vigilar.
5. Conserva CVSS, pero como un dato más. CVSS sigue ayudando a estimar la gravedad técnica. Solo que no debería tener la última palabra.

Preguntas frecuentes

¿SSVC reemplaza a CVSS? No. SSVC es un marco de decisión y CVSS es una puntuación de gravedad. CVSS, EPSS y KEV pueden servir como evidencia para una decisión al estilo SSVC.

¿El árbol de CISA es la única versión? No. SSVC nació en el SEI como una metodología más amplia, y CISA construyó su propio árbol sobre ella en 2020. Es un buen punto de partida porque CISA lo publica con una guía y lo usa para sus propios avisos.

¿Y si no sabemos qué tan importante es un activo? Es la brecha más común y vale la pena cerrarla por sí sola. Sin contexto de negocio, cualquier método de priorización termina tratando a todos los sistemas por igual.

Cómo ayuda priorIQ.ai

ScannerIQ enriquece los hallazgos de cada host con NVD, CISA KEV y EPSS, y CloudIQ clasifica qué recursos cloud están realmente expuestos a internet. PriorIQ Core combina esas señales con CVSS, disponibilidad de exploits, amenazas activas y tu contexto de negocio, el mismo tipo de evidencia que pide SSVC, agrupa los hallazgos en acciones de remediación y las envía a Jira, ServiceNow o Freshservice. El resultado es una cola corta de decisiones en lugar de una lista larga de puntuaciones. Solicita una demo.