El ciclo de vida de la gestión de vulnerabilidades para proveedores de software

¿Qué es el ciclo de vida de la gestión de vulnerabilidades?

El ciclo de vida de la gestión de vulnerabilidades es el proceso repetible que sigue un proveedor de producto para gestionar una vulnerabilidad en el software que distribuye: recibirla o encontrarla, verificarla, determinar qué está afectado, corregirla, publicar la corrección e informar a los clientes. En una organización proveedora suele encargarse de ello un equipo de respuesta a incidentes de seguridad de productos (PSIRT), y los equipos de ingeniería hacen las correcciones.

Esta página trata del lado del proveedor. La gestión de vulnerabilidades de TI, que escanea y parchea los servidores y portátiles que utiliza una organización, comparte el vocabulario pero no las partes difíciles. Un proveedor tiene que responder por cada versión con soporte que esté en manos de sus clientes, y tiene que publicar lo que ha encontrado.

Las etapas del ciclo de vida

1. Recibir o descubrir. Las vulnerabilidades llegan de investigadores externos a través de su programa de divulgación, de clientes, de coordinadores como los CSIRT nacionales y de su propia monitorización: una nueva CVE en una dependencia de código abierto, un hallazgo de un escáner o una prueba interna. Registre cada una con un identificador de seguimiento y acuse recibo a quienes informan desde fuera.
2. Verificar y hacer el triaje. Reproduzca el problema o confirme la coincidencia de la dependencia, decida si es una vulnerabilidad de su producto y califique su gravedad y su urgencia. Cierre lo que no sea aplicable, con un motivo que pueda mostrar más adelante. Señales de priorización como EPSS y el catálogo KEV de CISA ayudan a clasificar lo que queda.
3. Evaluar los productos y las versiones afectados. Encuentre cada producto, versión y rama con soporte que contenga el código o el componente vulnerable, y cada despliegue de cliente que ejecute alguno de ellos. Este paso decide el alcance de la corrección y del aviso.
4. Corregir. El equipo responsable desarrolla y prueba una corrección: una dependencia actualizada, un cambio de código o una mitigación, como un cambio de configuración, cuando todavía no es posible una corrección.
5. Publicar la corrección. Distribuya versiones actualizadas para cada rama con soporte afectada, a través de un canal en el que los clientes puedan confiar.
6. Avisar y divulgar. Publique un aviso que indique qué está afectado, qué gravedad tiene y qué hacer, asigne o cite un identificador CVE y reconozca el mérito de quien informó. Los formatos legibles por máquina como CSAF y VEX permiten a los clientes procesar los avisos automáticamente.
7. Monitorizar y aprender. Vigile la explotación y la información nueva, actualice el aviso y traslade la causa raíz al desarrollo, para que no se vuelva a distribuir la misma clase de fallo.

ISO/IEC 30111 e ISO/IEC 29147

Dos estándares internacionales describen este ciclo de vida para los proveedores. Lo dividen en el límite de la organización:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Título	Vulnerability handling processes	Vulnerability disclosure
Cubre	Lo que ocurre dentro: verificar, investigar, priorizar y corregir	Las interfaces: recibir informes y publicar avisos
Contenido clave	Política y organización, responsabilidades del PSIRT, fases de gestión, consideraciones sobre la cadena de suministro	Funciones de las partes interesadas, gestión de informes, contenido de los avisos, coordinación, política de divulgación
Destinatarios	Proveedores que gestionan vulnerabilidades notificadas	Proveedores que reciben informes y divulgan vulnerabilidades

Los estándares están pensados para usarse juntos. ISO/IEC 30111 nombra seis fases de gestión: preparación, recepción, verificación, desarrollo de la corrección, publicación y fase posterior a la publicación. También pide monitorización del proceso, confidencialidad de la información sobre vulnerabilidades y atención a la cadena de suministro, ya que muchas vulnerabilidades están en componentes que usted no escribió. Ambos estándares son ediciones vigentes, confirmadas en sus últimas revisiones de ISO, y constan como pendientes de revisión.

Otros marcos siguen el mismo esquema. El FIRST PSIRT Services Framework agrupa el trabajo en descubrimiento de vulnerabilidades, triaje y análisis, corrección y divulgación, e IEC 62443-4-1 incluye la gestión de actualizaciones de seguridad y de defectos en su ciclo de vida de desarrollo seguro para productos industriales.

Funciones

• PSIRT o equipo de seguridad de producto: es responsable del proceso, recibe los informes, hace el triaje, coordina las correcciones y publica los avisos. Consulte CRACI para equipos PSIRT y en qué se diferencia un PSIRT de un CSIRT.
• Equipos de producto e ingeniería: son responsables del código, desarrollan y prueban las correcciones y distribuyen las versiones.
• Gestión de versiones: decide qué ramas con soporte reciben una corrección y cuándo.
• Atención al cliente y comunicación: gestionan las preguntas de los clientes y el público del aviso.
• Departamento jurídico: asesora sobre divulgación, contratos y notificaciones regulatorias.
• Partes externas: quienes informan, coordinadores como CERT/CC o un CSIRT nacional, mantenedores upstream de los componentes afectados y clientes que deben desplegar la corrección.

Plazos y SLA

No hay un plazo único obligatorio. La mayoría de los proveedores fijan objetivos internos según la gravedad y publican los externos en su política de divulgación. Una estructura típica:

• Acusar recibo de un informe externo en unos pocos días hábiles.
• Hacer el triaje en cuestión de días, para que quien informó y el equipo responsable sepan en qué punto está.
• Corregir en un plazo fijado por la gravedad y la explotación, el más corto para los hallazgos críticos y todo lo que se sepa que se está explotando.
• Divulgar cuando la corrección esté disponible, o en una fecha límite acordada si la corrección se retrasa.

La presión externa marca el límite. Los investigadores suelen fijar una fecha límite de divulgación (Google Project Zero da 90 días a los proveedores), y la regulación añade las suyas: el Cyber Resilience Act de la UE exige a los fabricantes corregir las vulnerabilidades «sin demora» y fija plazos de notificación para las explotadas activamente (consulte qué exige el CRA). Cuando una vulnerabilidad ya se está explotando, como en el caso de una vulnerabilidad de día cero, todas las etapas se rigen por el plazo más corto.

Dónde se rompe el ciclo de vida

La mayoría de los retrasos no están en escribir la corrección. Vienen de no saber qué se distribuyó.

• No saber qué versiones contienen un componente. Aparece una nueva CVE en una biblioteca. ¿Cuáles de las versiones del año pasado la incluyen y qué clientes las ejecutan? Sin un registro por versión, los equipos vuelven a compilar etiquetas antiguas o buscan en los repositorios a mano, y la lista de versiones afectadas del aviso es una suposición.
• Dependencias transitivas. Muchos paquetes vulnerables no son paquetes que usted eligiera. Llegan como dependencias transitivas varios niveles más abajo, de modo que una búsqueda en sus manifiestos no los encuentra.
• Ruido de las dependencias de desarrollo. Los escáneres que leen lockfiles indican frameworks de pruebas y herramientas de build que nunca se distribuyen. Cada uno cuesta tiempo de triaje y entierra los hallazgos que importan.
• Componentes fuera del gestor de paquetes. Los binarios descargados por scripts de build, las imágenes base y los componentes de proveedores no aparecen en ningún lockfile.
• Responsabilidad poco clara. Un hallazgo sin equipo responsable se queda esperando. El triaje solo termina cuando la corrección tiene un responsable.
• Correcciones que no duran. Una versión vulnerable vuelve a través de otra dependencia o de una rama antigua, porque nada le impide entrar en el siguiente build.

Métricas

Métrica	Qué muestra
Tiempo hasta el acuse de recibo	Si quienes informan reciben respuesta cuando su política dice que la recibirán
Tiempo hasta el triaje	Cuánto espera un hallazgo antes de que alguien sepa si importa
Tiempo hasta la corrección, por gravedad	Con qué rapidez se distribuyen las correcciones, desde la recepción hasta una versión disponible
Tiempo hasta el aviso	Cuánto esperan los clientes la información después de la corrección
Proporción dentro del objetivo	Si se cumplen los SLA internos, sobre todo para los hallazgos críticos y explotados
Backlog por antigüedad	Los hallazgos atascados y dónde lo están
Tasa de no afectados	Cuánto esfuerzo de triaje se dedica a hallazgos que no son aplicables

Mida cada etapa por separado. Un tiempo de corrección largo suele deberse en realidad a lo mucho que se tarda en encontrar las versiones afectadas.

Gestione el ciclo de vida a partir de un registro de lo distribuido

Todas las etapas posteriores al triaje dependen de saber qué hay en cada versión. CRACI ejecuta sus builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés de CI y las dependencias que ningún lockfile enumera. Cada SBOM lleva un estado de completitud y se exporta como CycloneDX o SPDX.

CRACI reevalúa de forma continua las SBOM monitorizadas y las agrega en todos los builds y repositorios, y se pueden añadir SBOM de proveedores para que los componentes comprados se monitoricen junto a los suyos. Cuando aparece una nueva CVE, el historial de builds muestra qué builds anteriores contenían la dependencia vulnerable, directa o transitiva, de modo que usted conoce el periodo en que estuvo afectado, y la vista de inventario muestra qué versiones de software están desplegadas en qué productos. Los equipos de seguridad hacen el triaje de los hallazgos en CRACI y los envían a los equipos responsables de la corrección, CRACI es compatible con VEX, y los controles de política pueden bloquear los builds que contienen una CVE concreta, para que una vulnerabilidad corregida no vuelva a entrar. Consulte el seguimiento de vulnerabilidades.

Ciclo de vida de la gestión de vulnerabilidades: preguntas frecuentes

¿Cuáles son las etapas del ciclo de vida de la gestión de vulnerabilidades?

Para un proveedor de producto: recibir o descubrir la vulnerabilidad, verificarla y hacer el triaje, encontrar los productos y las versiones afectados, desarrollar la corrección, publicar la corrección, publicar el aviso y, por último, monitorizar y aprender. ISO/IEC 30111 nombra las fases de preparación, recepción, verificación, desarrollo de la corrección, publicación y fase posterior a la publicación.

¿Qué es ISO/IEC 30111?

ISO/IEC 30111:2019 es el estándar internacional para los procesos de gestión de vulnerabilidades. Ofrece a los proveedores requisitos y recomendaciones para procesar y corregir las vulnerabilidades notificadas en sus productos y servicios, desde la política y la función del PSIRT hasta las fases de gestión y las consideraciones sobre la cadena de suministro.

¿Cuál es la diferencia entre ISO/IEC 30111 e ISO/IEC 29147?

ISO/IEC 29147 cubre la parte externa: recibir informes y publicar avisos. ISO/IEC 30111 cubre la gestión interna entre ambos: verificar, investigar, priorizar y corregir. Están pensados para usarse juntos. Consulte divulgación coordinada de vulnerabilidades para el lado de 29147.

¿Qué es el triaje de vulnerabilidades?

El triaje es el paso en el que un equipo de seguridad confirma que una vulnerabilidad notificada o descubierta es real, valora su gravedad y su urgencia para su producto, y la envía al equipo responsable de la corrección. Un buen triaje también cierra los hallazgos que no son aplicables, con un motivo registrado.

¿En qué se diferencia la gestión de vulnerabilidades de producto de la gestión de vulnerabilidades de TI?

La gestión de vulnerabilidades de TI parchea los sistemas que utiliza una organización. La gestión de vulnerabilidades de producto se ocupa de los fallos del software que la organización compila y distribuye a terceros, de modo que añade pasos que los equipos de TI no tienen: determinar qué versiones publicadas están afectadas, distribuir una corrección a los clientes e informarles en un aviso.

¿Qué métricas debe seguir un proceso de gestión de vulnerabilidades?

El tiempo hasta el acuse de recibo de un informe, hasta el triaje, hasta la corrección y hasta el aviso, cada uno por gravedad, además de la proporción de hallazgos que cumplen sus objetivos internos, el backlog abierto por antigüedad y cuántos hallazgos se cerraron como no afectados.