Respuesta directa
En pocas palabras
La gestión de vulnerabilidades de un sistema de IA empieza con un inventario versionado y el release que realmente opera. Cada advisory se normaliza, se relaciona con componentes exactos y se analiza en el contexto de rutas alcanzables, configuración, exposición, autoridad, datos e impacto. VEX documenta si el caso está en análisis, es explotable, no afecta, es un falso positivo o quedó resuelto, junto con justificación y evidencia. La prioridad no depende solo de CVSS: combina aplicabilidad, explotación conocida, exposición, criticidad, controles, disponibilidad de corrección y alcance aguas abajo.
Define el sujeto y la decisión antes de revisar alertas
Una alerta de vulnerabilidad describe una condición asociada con un producto, paquete o rango. No demuestra que el release de tu sistema contenga esa pieza, que el código vulnerable sea alcanzable ni que exista explotación en tu contexto. Empieza con una pregunta operativa: qué releases están afectados, qué recorrido puede exponerse, qué debe contenerse y qué evidencia autoriza cerrar el caso.
Fija producto, release, digest, ambiente, región, organización, periodo y recorridos incluidos. Distingue producción, staging, notebooks, pipelines de entrenamiento, imágenes de build, servicios administrados y equipos de desarrollo. Una biblioteca ausente de producción puede seguir siendo relevante si firma artefactos, prepara datasets o tiene acceso a secretos durante el build. El sujeto debe abarcar el camino donde puede ocurrir el daño, no solo el contenedor final.
Conecta AI/ML-BOM, lineage y runtime
El AI/ML-BOM aporta modelos, datasets, paquetes, imágenes, servicios y relaciones del release. El lineage permite recorrer desde un componente hacia builds, evaluaciones, despliegues y resultados. La observación de runtime confirma qué digest, imagen, modelo, librería o endpoint estuvo activo. Las tres vistas se reconcilian porque un inventario declarado puede omitir una dependencia transitiva y un alias puede cambiar después del despliegue.
Incluye componentes de aplicación, runtimes de inferencia, parsers, tokenizers, bibliotecas de serialización, drivers, CUDA, sistemas operativos, servidores de modelos, bases vectoriales, plugins, herramientas, imágenes base y servicios externos. Para APIs administradas registra proveedor, producto, versión o fecha observable, región y avisos recibidos. No inventes un paquete o digest cuando el proveedor no lo expone; conserva el límite y los controles compensatorios.
Normaliza advisories, aliases y rangos sin perder la fuente
La misma vulnerabilidad puede aparecer como CVE, GHSA, OSV u otro identificador. Conserva el registro original, fuente, fecha de publicación, modificación, aliases, paquete, ecosistema y referencias. Deduplica por relaciones confirmadas, no por títulos parecidos. Una alerta actualizada puede corregir rangos, severidad o disponibilidad del fix; guarda la versión del advisory usada para decidir.
OSV representa paquetes y rangos con eventos introduced, fixed y, en casos limitados, last_affected. El orden de versiones depende del ecosistema; comparar cadenas alfabéticamente produce falsos resultados. Usa el resolvedor correspondiente y prefiere el evento fixed cuando la fuente lo ofrece. Un rango desconocido queda en análisis. No conviertas ausencia de datos en no afectado.
Relaciona la alerta con el componente exacto del release
El matching empieza por identidad: ecosistema, nombre, namespace, versión, digest y procedencia. Después verifica si la dependencia está incluida en el artefacto o servicio efectivo. Un nombre parecido, un paquete de otro ecosistema o una versión normalizada incorrectamente puede crear un falso positivo. Una dependencia vendorizada o renombrada puede producir el error contrario y quedar fuera del escáner.
Conserva evidencia reproducible: BOM del release, consulta del escáner, manifest, lockfile, capa de imagen, lista observada o declaración del proveedor. Si el componente aparece en una imagen pero se elimina antes del runtime, registra dónde existió y quién confirmó la etapa. Si forma parte de una herramienta de build con acceso privilegiado, no lo descartes solo porque no llega al contenedor final.
| Criterio | Evidencia | Estado inicial |
|---|---|---|
| Match exacto | Paquete y versión dentro del rango | Analizar explotabilidad |
| Identidad incorrecta | Otro paquete, producto o ecosistema | Falso positivo con evidencia |
| Versión sin resolver | Alias, fork o rango ambiguo | En análisis; ampliar evidencia |
| Componente ausente | BOM y observación consistentes | No afectado con justificación |
Usa VEX como afirmación versionada, no como etiqueta final
CycloneDX VEX representa el estado de una vulnerabilidad en el contexto de un producto. Sus estados de análisis incluyen in_triage, exploitable, false_positive, not_affected, resolved y resolved_with_pedigree. La afirmación apunta al producto o componente exacto, identifica la vulnerabilidad, declara respuesta y conserva detalle. Not affected necesita una justificación comprobable; in triage necesita dueño y fecha.
VEX no elimina el advisory ni modifica su severidad. Comunica la conclusión contextual de una organización en un momento. Si cambia el release, configuración, exposición, ruta de código, control o advisory, reabre o reemplaza la afirmación. Firma o protege su integridad y conserva el documento anterior. Consumir automáticamente cualquier VEX externo sin validar emisor, sujeto, vigencia y política convierte una ayuda de priorización en una vía de bypass.
Analiza alcanzabilidad, precondiciones y controles
Revisa si el código vulnerable está presente y puede ejecutarse desde una entrada real. Documenta función o ruta alcanzable, configuración requerida, privilegios, autenticación, red, formato de archivo, interacción, datos controlables y efecto posible. En IA incluye carga de modelos, deserialización, parsers de documentos, notebooks, endpoints de herramientas, plugins y artefactos obtenidos de terceros.
Un control puede reducir probabilidad o impacto sin volver falsa la vulnerabilidad. Segmentación, sandbox, mínimo privilegio, allowlist, firma, bloqueo de formatos, egress restringido o validación pueden justificar una mitigación mientras se corrige. Prueba el control en la ruta relevante y registra cobertura. Protegido por perímetro no significa no afectado si existe otra ruta interna o el perímetro puede cambiar.
Prioriza con contexto y explotación conocida, no solo con CVSS
CVSS describe severidad técnica bajo supuestos publicados; no conoce por sí solo tus activos, exposición, datos, controles ni consecuencias. Combínalo con certeza del match, alcance de consumidores, presencia en internet, privilegios, sensibilidad, criticidad del recorrido, facilidad de detección, exploit disponible, señales internas y tiempo de exposición. Mantén cada factor visible para que la prioridad pueda revisarse.
CISA mantiene KEV como fuente autoritativa de vulnerabilidades con evidencia de explotación en la práctica y recomienda utilizarla como entrada de priorización. Una coincidencia con KEV eleva urgencia, pero sigue necesitando confirmar que el producto y versión aplican. Tampoco ignores una vulnerabilidad fuera de KEV cuando el componente es crítico o la explotación sería grave. KEV es una señal fuerte, no una lista completa de todo riesgo posible.
Elige una respuesta con autoridad, fecha y condición de salida
Las opciones incluyen actualizar, reconstruir, reemplazar, retirar, aislar, desactivar una función, limitar entradas, aplicar workaround, aumentar revisión, aceptar temporalmente o detener. Registra la decisión, responsable, autoridad, versión, alcance, vencimiento, evidencia, riesgo residual y señal de cierre. Will not fix o can not fix no significan que el riesgo desapareció: requieren una decisión explícita sobre uso y controles.
Separa contención de corrección. Deshabilitar uploads puede cortar una ruta hoy; actualizar el parser y repetir pruebas corrige la causa técnica. Una aceptación temporal debe tener límite y seguimiento. Si no existe fix, reduce exposición o sustituye el componente. Si el cambio produce una incompatibilidad mayor, decide con seguridad, operación y negocio; la presión por disponibilidad no autoriza mantener silenciosamente una ruta explotable.
Incluye superficies propias de AI y ML sin mezclar categorías
Un sistema de IA combina software tradicional y artefactos con comportamientos particulares. Busca vulnerabilidades en runtimes, frameworks, formatos de modelos, operadores nativos, bibliotecas numéricas, tokenizers, parsers, servidores de inferencia, notebooks, drivers, aceleradores, plugins y cadenas de datos. Evalúa además si un modelo o dataset se distribuye mediante una herramienta que ejecuta código al cargarlo.
No etiquetes automáticamente como CVE un problema de calidad, prompt injection, sesgo, alucinación, datos contaminados o acceso indebido. Pueden ser riesgos graves y entrar en threat model, evaluación o incidente, pero necesitan taxonomía y evidencia propias. Cuando una vulnerabilidad de software habilita un escenario de IA —por ejemplo, un parser vulnerable antes del RAG— vincula ambos registros sin fusionarlos.
Construye una afirmación VEX que otra persona pueda revisar
Una afirmación útil incluye emisor, momento, versión del esquema, producto y release, identificador del componente, vulnerabilidad, estado, justificación, respuesta, detalle, referencias y vigencia. Para not affected explica por qué: código no presente, no alcanzable, configuración ausente, dependencia requerida ausente, ambiente no presente o control comprobado, según el vocabulario adoptado. Adjunta referencias, no secretos ni datos personales.
Registra quién preparó el análisis, quién lo revisó y qué prueba sostiene la conclusión. Una captura de pantalla sin consulta, versión o fecha envejece rápido. La evidencia puede ser un test de alcanzabilidad, manifest, diff, configuración, regla de red, inventario observado o confirmación del proveedor. Marca incertidumbre. Unknown o in triage son más honestos que una justificación improvisada para reducir el backlog.
Reevalúa cuando cambien advisories, releases o exposición
Ingiere fuentes con identificador, modified time y procedencia; deduplica; relaciona contra cada release soportado; y vuelve a procesar cuando cambian rangos, aliases, severidad, exploit, KEV o fix. Una alerta cerrada puede reabrirse si el advisory amplía el rango o si un servicio antes interno se publica. Conserva la última revisión y el motivo de cada transición.
Los escaneos ocurren en código, dependencias, imágenes, artefactos, registro y runtime. Programa conciliación para detectar componentes fuera del BOM y releases que ya no reciben feeds. Controla fallas del propio pipeline: fuente vencida, credencial rota, cola detenida, parser incompatible y cobertura perdida. Un tablero verde basado en datos que dejaron de actualizarse es una señal engañosa.
Integra vulnerabilidades en admisión y cambios de emergencia
El gate de release comprueba políticas por ambiente y nivel de riesgo: vulnerabilidades bloqueantes, estados sin revisar, VEX aceptable, excepciones vigentes y evidencia requerida. La regla usa el digest candidato y un snapshot de intelligence; no consulta un alias móvil después de decidir. Conserva decision ID, policy version y fuentes. Un bypass necesita autoridad, alcance, vencimiento y monitoreo.
Para una corrección urgente prepara una ruta corta, no una ruta sin controles. Fija el componente, reproduce el build, verifica provenance, ejecuta pruebas de seguridad y regresión relevantes, aprueba, despliega por etapas y observa. Si el parche cambia un runtime de IA, vuelve a evaluar formatos, rendimiento, calidad, permisos y compatibilidad. La urgencia puede reducir espera, pero no debe borrar identidad, evidencia ni rollback.
Prueba corrección, regresión y estado efectivo antes de cerrar
Cerrar requiere demostrar que la versión corregida contiene el fix o elimina la ruta, que pasó pruebas relevantes y que producción resolvió el nuevo digest. Repite el escaneo y la prueba de aplicabilidad. Confirma que no quedó un worker, notebook, imagen, caché o ambiente con la versión anterior. Si el cambio produjo datos o acciones durante la exposición, corregir el paquete no concilia automáticamente esos efectos.
Actualiza BOM, provenance, lineage, VEX, release notes y registro de riesgo. Conserva el estado resolved y, cuando aplique, pedigree del cambio. Prueba rollback sin reinstalar la versión vulnerable; el punto de retorno debe cumplir la política actual. Si no existe rollback seguro, prepara modo limitado o pausa. La reversión técnica no sustituye investigación cuando hay indicios de explotación.
Mide exposición y calidad de decisión, no volumen de tickets
Mide tiempo desde publicación o detección hasta correlación, triage, contención y corrección; releases sin BOM vigente; matches sin estado; VEX vencidos; excepciones activas; casos KEV; reaperturas; fallas de fix; componentes fuera de soporte y exposición acumulada por criticidad. Segmenta por ambiente, producto y dueño. Usa denominadores y conserva la definición.
No premies cerrar muchas alertas como no afectadas. Muestrea justificaciones, pruebas y vigencia; mide falsos positivos y falsos negativos conocidos; y revisa si los plazos reflejan riesgo real. Un SLA único puede hacer que el equipo atienda primero lo fácil. La cola debe mostrar casos críticos, bloqueos, dependencias y edad sin convertir una puntuación en certeza de seguridad.
Aplica el proceso al release y los límites de Cerravi
En Cerravi, cada release se relaciona con imagen, dependencias, migraciones, AI/ML-BOM, provenance, admisión, registro, lineage, pruebas y evidencia de producción. Los análisis de vulnerabilidad apuntan al digest exacto y la verificación posterior confirma runtime, readiness y artefactos públicos. La corrección conserva backup, release anterior permitido y journal; no se promueve una reconstrucción sin identidad o pruebas.
El proceso no amplía las capacidades públicas del producto. Cerravi organiza contexto y propone 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 piden confirmación cuando falta un importe. Forecast aplica reglas transparentes del CRM, no es un modelo predictivo entrenado o calibrado y no garantiza cierres. Un VEX o un escaneo aprobado tampoco certifican seguridad, cumplimiento ni ausencia de vulnerabilidades desconocidas.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es VEX en gestión de vulnerabilidades?
VEX es una forma legible por máquinas de comunicar el estado de una vulnerabilidad para un producto o componente concreto. Puede indicar que está en análisis, es explotable, no afecta, es un falso positivo o quedó resuelta, junto con justificación, respuesta y evidencia contextual.
¿Una dependencia con CVE significa que el sistema es vulnerable?
No automáticamente. Primero debe confirmarse identidad y versión, presencia en el release, alcanzabilidad, configuración, exposición y controles. El CVE inicia el análisis. Si el componente no aplica, la conclusión debe documentarse con evidencia y revisarse cuando cambie el advisory o el release.
¿Se puede priorizar solo con la puntuación CVSS?
No. CVSS aporta severidad técnica, pero la prioridad también depende de aplicabilidad, explotación conocida, exposición, privilegios, datos, criticidad, alcance aguas abajo, controles, fix disponible y capacidad de detectar o contener el efecto.
¿Qué significa not affected en un VEX?
Significa que el emisor concluyó que la vulnerabilidad no afecta al producto identificado bajo el contexto analizado. Debe incluir una justificación comprobable, como código ausente o no alcanzable. No significa que el advisory sea falso ni que futuras versiones estén cubiertas.
¿Cuándo se cierra una vulnerabilidad de un sistema de IA?
Cuando la respuesta aprobada está implementada, la corrección o mitigación fue probada, producción resolvió el release esperado, se revisaron efectos previos y se actualizaron BOM, lineage, VEX y evidencia. Un ticket cerrado o un escaneo sin match no bastan por sí solos.