Respuesta directa
En pocas palabras
Para priorizar vulnerabilidades de un sistema de IA, primero confirma que la vulnerabilidad aplica al release exacto. Después usa CVSS para entender severidad técnica, EPSS para estimar la probabilidad de explotación de un CVE en los próximos 30 días, CISA KEV para reconocer explotación observada y SSVC para convertir esas señales y el contexto del negocio en una acción. No promedies los cuatro valores: expresan cosas distintas. La decisión debe conservar componente, versión, evidencia, exposición, impacto, controles, responsable, plazo y condición de cierre.
Empieza por la decisión, no por una tabla ordenada por puntaje
Un backlog puede contener miles de coincidencias y aun así ocultar el caso más urgente. El orden por CVSS suele tratar igual una biblioteca expuesta a internet, un paquete no alcanzable y una herramienta ausente de producción. Antes de calcular nada, define qué decisión debe tomarse: contener hoy, corregir en el ciclo inmediato, programar, vigilar, aceptar temporalmente o documentar que no aplica.
Delimita producto, release, digest, ambiente, región, recorrido, datos, privilegios y consumidores afectados. La unidad de análisis no es el nombre genérico del paquete, sino su presencia concreta dentro de un sistema y una ventana operativa. Conserva la hora de las señales porque EPSS, KEV, exploit intelligence y exposición cambian. Una prioridad sin sujeto ni momento no puede auditarse ni reproducirse.
Confirma aplicabilidad antes de enriquecer el riesgo
Relaciona el advisory con el componente exacto mediante ecosistema, nombre, namespace, versión, digest, Package URL o CPE cuando corresponda. Comprueba presencia en AI/ML-BOM, imagen, lockfile, manifest, servicio administrado y runtime observado. Valida el rango con las reglas del ecosistema; una comparación alfabética de versiones puede producir una coincidencia falsa.
Después revisa alcanzabilidad y precondiciones: función vulnerable, configuración, formato de entrada, ruta de red, autenticación, privilegios e interacción. Un VEX puede registrar in triage, exploitable, not affected, false positive o resolved con justificación y evidencia. Si faltan versión o ruta, conserva desconocido. La ausencia de evidencia no demuestra que el componente sea seguro.
Usa CVSS 4.0 para describir severidad técnica
CVSS es un marco abierto para comunicar características y severidad de vulnerabilidades de software, hardware y firmware. En la versión 4.0, Base describe cualidades intrínsecas; Threat incorpora condiciones que cambian con el tiempo; Environmental ajusta el resultado al ambiente del consumidor; Supplemental agrega contexto sin modificar el puntaje final. Conserva siempre el vector y la nomenclatura, por ejemplo CVSS-B o CVSS-BTE, no solo un número.
El puntaje Base supone un escenario razonablemente adverso entre ambientes y no conoce clientes afectados, pérdidas, obligaciones, continuidad o reputación. Ajusta Threat y Environmental con inteligencia y controles comprobables cuando tengas autoridad para hacerlo. Aun así, CVSS sigue siendo una entrada a la evaluación de riesgo. No lo presentes como probabilidad de ataque ni como fecha automática de corrección.
Interpreta EPSS como probabilidad, no como impacto
EPSS es un modelo de machine learning mantenido por FIRST que estima, para un CVE publicado, la probabilidad de explotación en la práctica durante los siguientes 30 días. Publica diariamente un score entre cero y uno y un percentil. El score responde a probabilidad estimada; el percentil indica la posición relativa frente a otros CVE. Ninguno describe el daño que sufriría tu organización.
Guarda score, percentil, fecha del cálculo y versión o contexto de integración. Un valor puede cambiar cuando aparecen nuevas señales; por eso una exportación antigua no debe gobernar indefinidamente. EPSS no cubre una debilidad sin CVE y no sustituye el análisis de aplicabilidad. Define umbrales a partir de capacidad y apetito de riesgo, y revisa su rendimiento con tus propios resultados, en vez de copiar un corte universal.
Trata CISA KEV como evidencia fuerte de explotación observada
CISA mantiene Known Exploited Vulnerabilities como fuente autorizada de vulnerabilidades que han sido explotadas en la práctica y recomienda usar el catálogo dentro de la priorización. Una coincidencia aplicable cambia la conversación: ya no se discute solo si el exploit podría existir. Escala la revisión, busca indicadores, reduce exposición y decide corrección o retiro con urgencia acorde al sistema.
KEV no prueba que tu organización haya sido atacada, no sustituye una investigación y no contiene todas las vulnerabilidades explotables. Confirma producto, versión y ruta. Conserva fecha de incorporación, acción publicada y evidencia interna. Si el componente no aplica, documenta la conclusión; si aplica, la ausencia de un incidente visible no es motivo suficiente para posponer la respuesta.
Convierte evidencia en acción mediante un árbol SSVC adaptado
SSVC organiza decisiones según el papel del interesado. La guía de CISA propone un árbol para quienes despliegan tecnología y considera estado de explotación, posibilidad de automatización, impacto técnico y prevalencia de la misión o efecto en bienestar público. El valor práctico está en hacer explícitas las preguntas y producir una acción, no en obtener otro decimal.
Adapta nombres, resultados, autoridades y plazos a tu organización antes de automatizar. Por ejemplo: Track, Track*, Attend y Act pueden traducirse en vigilar, preparar, corregir con prioridad o actuar de inmediato, pero cada salida necesita una definición local. Versiona el árbol y conserva sus respuestas. Un cambio de explotación, exposición o misión debe permitir recalcular la decisión sin reescribir la historia.
| Criterio | Pregunta principal | Uso correcto |
|---|---|---|
| CVSS | ¿Qué tan severa es técnicamente? | Vector, severidad y contexto técnico |
| EPSS | ¿Qué probabilidad estimada tiene de explotarse pronto? | Score y percentil fechados |
| CISA KEV | ¿Existe evidencia de explotación en la práctica? | Escalamiento de casos aplicables |
| SSVC | ¿Qué acción corresponde a este interesado? | Árbol versionado y decisión trazable |
No promedies ni multipliques señales incompatibles
CVSS de 0 a 10 y EPSS de 0 a 1 no comparten escala ni significado. KEV es una clasificación sustentada en evidencia observada y SSVC produce una decisión categórica. Sumarlos, normalizarlos o multiplicarlos puede crear una precisión aparente que nadie puede explicar. También puede reducir la prioridad de explotación conocida porque otro campo está vacío o introducir dos veces la misma señal.
Mantén columnas separadas y usa reglas legibles. Por ejemplo: una coincidencia aplicable en KEV activa revisión inmediata; un EPSS alto eleva la cola de casos alcanzables; CVSS y el ambiente explican impacto técnico; el árbol decide la respuesta. Si necesitas un orden de trabajo, conserva razones, desempates y datos faltantes. La salida debe poder leerse sin conocer una fórmula secreta.
Añade el contexto propio del sistema de IA
Revisa dónde vive la pieza vulnerable: parser de documentos, cargador de modelos, servidor de inferencia, tokenizer, runtime, biblioteca numérica, notebook, plugin, herramienta, imagen base, driver o acelerador. Determina si procesa archivos externos, ejecuta código, accede a secretos, consulta datos personales, puede modificar el CRM o suministra artefactos a otros equipos. El mismo CVE puede tener consecuencias muy distintas en un build aislado y en un endpoint público.
No fuerces riesgos como prompt injection, alucinación, sesgo, extracción de datos o envenenamiento de modelos dentro de CVSS o EPSS si no corresponden a una vulnerabilidad publicada. Regístralos en threat model, evaluaciones e incidentes con taxonomía propia. Cuando una vulnerabilidad de software habilite una ruta de ataque a IA, relaciona ambos registros para conservar causa técnica, escenario y efecto sin confundirlos.
Evalúa impacto, alcance y reversibilidad del negocio
Registra confidencialidad, integridad y disponibilidad, pero también datos involucrados, privilegios, clientes, jurisdicciones, procesos comerciales, dependencia operativa y consumidores aguas abajo. Considera si el atacante podría alterar propuestas o precios, acceder a Buyer Rooms, usar credenciales, contaminar un índice RAG, distribuir un artefacto o detener un recorrido crítico. Separa impacto posible de impacto observado.
Valora alcance y reversibilidad: cuántos releases y tenants dependen del componente, si existe segmentación, si el efecto se detecta, si los datos pueden conciliarse y cuánto cuesta operar en modo limitado. Evita convertir dinero, reputación o seguridad humana en cifras sin sustento. Usa rangos y supuestos explícitos. Cuando no puedas estimar, registra incertidumbre y eleva la revisión, no inventes certeza.
Distingue control compensatorio, contención y corrección
Un WAF, sandbox, allowlist, segmentación, firma, mínimo privilegio o bloqueo de formatos puede reducir una ruta, pero solo cuenta si está activo en el ambiente y la prueba cubre el escenario. Documenta control, propietario, cobertura, evidencia y posibilidad de bypass. Un control externo no cambia el puntaje Base de CVSS; puede informar el contexto ambiental y la decisión local.
Registra si existe fix, workaround, versión soportada o sustituto, además del esfuerzo, ventana y riesgo del cambio. Contener hoy y corregir después son decisiones distintas. Si no hay parche, reduce exposición, deshabilita la función, aísla o retira. Una aceptación temporal necesita autoridad, vencimiento, monitoreo y condición de salida; no debe convertirse en cierre permanente por inercia.
Define niveles de acción con criterios y autoridad
Crea pocas salidas operativas. Actuar ahora puede exigir contención, investigación y cambio de emergencia; atender puede requerir corrección prioritaria y seguimiento ejecutivo; preparar puede reservar capacidad y validar el fix; vigilar puede mantener inteligencia y reevaluación. Describe qué evidencia activa cada nivel, quién puede asignarlo y quién autoriza excepciones.
Los plazos deben reflejar criticidad, exposición y capacidad de reducción, no una cifra universal copiada de otro sector. Distingue tiempo para triage, contención, corrección y verificación. Si un SLA vence, escala; no marques resuelto. Para componentes compartidos coordina un responsable técnico y propietarios de productos consumidores, porque reparar una imagen base no demuestra que todos los despliegues ya la usen.
Automatiza enriquecimiento sin automatizar decisiones irreversibles
El pipeline puede normalizar CVE, resolver aliases, consultar CVSS, ingerir EPSS diario, marcar KEV, relacionar BOM y calcular rutas del árbol. Cada dato conserva proveedor, timestamp, versión del esquema, resultado original y errores. Implementa idempotencia, límites, caché con vigencia y monitoreo de feeds. Una fuente detenida debe generar una alerta visible, no mantener un tablero verde con datos viejos.
Usa automatización para proponer prioridad y reunir evidencia; reserva revisión humana para datos incompletos, conflictos, excepciones y acciones de alto impacto. No permitas que una afirmación VEX externa, un score bajo o una consulta fallida cierre casos automáticamente. Prueba el motor con ejemplos límite y golden cases. Versiona reglas y reproduce la salida anterior antes de promover cambios.
Reevalúa a diario y cierra con estado efectivo
Vuelve a evaluar cuando cambien EPSS, KEV, advisory, exploit intelligence, release, exposición, controles, datos o importancia del proceso. Una cola puede actualizarse diariamente y también por eventos. Conserva transición, causa y responsable. Un aumento de EPSS no prueba ataque; una entrada nueva en KEV sí exige revisar con urgencia todos los componentes aplicables y buscar evidencia interna.
Para cerrar, verifica la respuesta en producción: digest corregido, ruta eliminada o control probado. Repite correlación y escaneo; confirma workers, notebooks, cachés y ambientes. Actualiza BOM, lineage, VEX, registro de riesgo y consumidores. Si hubo posible explotación, el parche no cierra la investigación ni concilia efectos. Mantén el registro resuelto para demostrar qué se sabía y qué se hizo.
Mide exposición reducida y calidad de decisión
Mide tiempo hasta confirmar aplicabilidad, contener, corregir y verificar; días de exposición por criticidad; casos KEV aplicables; cobertura de release; porcentaje con vector y fecha; datos EPSS vencidos; decisiones SSVC sin evidencia; excepciones vencidas; reaperturas y fallas de corrección. Segmenta por producto, ambiente y responsable con denominadores claros.
No premies volumen de tickets cerrados ni un CVSS promedio menor. Muestrea conclusiones not affected, controles y falsos positivos; revisa si los umbrales capturan los casos que después se explotan; y mide deuda en componentes sin soporte. Un sistema de prioridad mejora cuando explica decisiones, reduce exposición real y aprende de resultados, no cuando produce más colores.
Aplica el método a releases y límites comprobables de Cerravi
En Cerravi, la priorización de dependencias se vincula con el release y digest exactos, AI/ML-BOM, provenance, registro, lineage, admisión, pruebas y estado efectivo de producción. Una señal propone una revisión; no autoriza por sí sola un despliegue. Los cambios conservan backup, release anterior permitido, journal, verificación pública y rollback. La evidencia se mantiene separada de secretos y datos personales.
Este proceso no amplía lo que el producto ofrece públicamente. Cerravi organiza contexto y sugiere siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios conocidos y solicitan revisión si falta un importe. Forecast usa reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado, y no garantiza cierres. CVSS, EPSS, KEV, SSVC, un VEX o un escaneo tampoco certifican seguridad ni cumplimiento.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre CVSS y EPSS?
CVSS describe características y severidad técnica de una vulnerabilidad. EPSS estima la probabilidad de que un CVE publicado sea explotado en la práctica durante los próximos 30 días. EPSS no mide impacto y CVSS no es una probabilidad de ataque; ambos necesitan aplicabilidad y contexto local.
¿Una vulnerabilidad incluida en CISA KEV debe corregirse primero?
Debe revisarse con urgencia porque existe evidencia de explotación en la práctica. Primero confirma que producto, versión y ruta aplican. Si aplica, prioriza contención y respuesta según exposición e impacto. KEV no demuestra que tu organización ya haya sido atacada ni sustituye investigación.
¿Qué aporta SSVC a la priorización de vulnerabilidades?
SSVC convierte evidencia técnica y contexto del interesado en una acción mediante un árbol de decisiones. Hace visibles las preguntas, evita depender de un puntaje único y permite versionar la política. Sus resultados, autoridades y plazos deben adaptarse a la organización.
¿Se pueden sumar CVSS, EPSS, KEV y SSVC en un puntaje?
No es recomendable. Usan escalas y significados distintos, y SSVC ya es un método de decisión. Sumarlos crea precisión aparente y puede duplicar señales. Es mejor conservar cada dato y aplicar reglas legibles con evidencia, contexto, incertidumbre y desempates explícitos.
¿Cada cuánto debe recalcularse la prioridad?
Como mínimo cuando cambien EPSS, KEV, el advisory, el release, la exposición, los controles o la criticidad. Los feeds pueden revisarse a diario y los cambios operativos deben disparar reevaluación por evento. Cada transición conserva fecha, motivo, política y responsable.