Remediación de CVE: del aviso a un build corregido y distribuido

El proceso de remediación de CVE

La remediación de CVE elimina una vulnerabilidad divulgada públicamente del software que usted ejecuta o distribuye. Para su propio código, eso significa un parche. Para las dependencias de código abierto, de donde procede la mayoría de los CVE de un producto típico, significa llegar a una versión en la que la vulnerabilidad esté corregida. En ambos casos, los pasos son los mismos:

1. Localizar cada producto, build y lanzamiento que contenga el paquete y la versión afectados.
2. Evaluar si la vulnerabilidad le afecta, y en qué medida.
3. Priorizar frente a todo lo demás que esté abierto.
4. Corregir actualizando, parcheando, sustituyendo o, si no existe corrección, mitigando.
5. Verificar que el nuevo build contiene realmente la versión corregida.
6. Registrar qué estaba afectado, qué decidió usted y cuándo se distribuyó la corrección.

Paso 1: localice cada build afectado

La primera pregunta tras un aviso es dónde está el paquete. Responderla a partir de los repositorios de código fuente es lento y a menudo erróneo: la versión de un lockfile, la versión que resolvió un build y la versión de una imagen de contenedor publicada pueden ser distintas. Las dependencias transitivas y los paquetes que un build descarga fuera del gestor de paquetes no aparecen en absoluto en los manifiestos.

La respuesta fiable procede de una SBOM de cada versión, cotejada continuamente con los avisos. Si esa SBOM se registra durante el build, enumera lo que el build utilizó realmente, de modo que el cotejo le indica qué builds distribuidos contienen la versión vulnerable, no qué repositorios la mencionan.

Paso 2: priorice según la gravedad y la explotación

La gravedad por sí sola clasifica demasiadas vulnerabilidades como urgentes. La mayoría de los equipos combinan tres señales:

Señal	Qué le indica	Quién la publica
CVSS	La gravedad de la vulnerabilidad si se explota, con una puntuación de 0 a 10	FIRST (el estándar); NVD y los proveedores publican las puntuaciones
EPSS	La probabilidad estimada de explotación en los próximos 30 días	FIRST
KEV	Si se sabe que la vulnerabilidad se está explotando en entornos reales	El catálogo Known Exploited Vulnerabilities de CISA

Después añada su propio contexto: si el paquete afectado llega a los clientes o solo se ejecuta en un job de pruebas, y si la función vulnerable llega a utilizarse. Una vulnerabilidad con explotación conocida en un paquete que se distribuye pasa al primer puesto de la lista. La priorización de vulnerabilidades convierte estas señales en un método.

Plazos de remediación

• CISA BOD 26-04. Desde el 10 de junio de 2026, las agencias federales de Estados Unidos fijan cada plazo a partir de cuatro preguntas: si el activo está expuesto públicamente, si la vulnerabilidad figura en el catálogo KEV, si la explotación se puede automatizar y si otorga un control parcial o total. Las respuestas van desde 3 días, con triaje forense en los peores casos, hasta corregir en la siguiente actualización del sistema. Sustituyó a la BOD 22-01, que daba dos semanas para la mayoría de las entradas de KEV.
• Cyber Resilience Act de la UE. Los fabricantes deben abordar y corregir las vulnerabilidades sin demora, también mediante actualizaciones de seguridad (anexo I, parte II). Desde el 11 de septiembre de 2026, una vulnerabilidad explotada activamente en un producto también activa un plazo de notificación: una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final en un plazo de 14 días desde que haya una corrección disponible.
• Su propia política. La mayoría de los programas de seguridad fijan objetivos internos según la gravedad. Sean cuales sean, solo podrá cumplirlos si el paso 1 es rápido.

Paso 3: elija la corrección

Opción	Cuándo usarla
Actualizar	Existe una versión corregida. Prefiera la actualización más pequeña que incluya la corrección, para limitar los cambios incompatibles.
Actualizar el paquete padre	El paquete vulnerable es transitivo. Una versión más reciente de la dependencia directa suele incorporar la corrección.
Forzar la versión	El paquete padre no ha publicado una corrección. Fuerce la versión transitiva con overrides de npm, resolutions de Yarn o pnpm.overrides, y pruébela.
Parchear o aplicar un backport	Aún no puede pasar a la versión mayor corregida. Aplique la corrección de upstream a la versión que utiliza.
Sustituir	El paquete no tiene mantenimiento o sigue generando CVE. Cambie a una alternativa.
Mitigar y documentar	Aún no existe corrección, o su producto no está afectado. Reduzca la exposición y registre la evaluación, por ejemplo como una declaración VEX.

La mayor parte de este paso se puede automatizar, desde elegir la versión hasta abrir el pull request. La remediación automatizada de vulnerabilidades explica qué automatizar y qué reservar para una persona.

Paso 4: una corrección fusionada no es una corrección distribuida

El pull request se ha fusionado, así que el CVE está cerrado. No necesariamente. La corrección está en el repositorio, pero un build restaura una caché obsoleta, una imagen base sigue llevando el paquete antiguo o una rama de lanzamiento nunca incorporó el cambio. El ticket dice que está corregido mientras el producto sigue distribuyendo la versión vulnerable.

Cierre el círculo desde el otro extremo: revise la SBOM del siguiente build y confirme que la versión vulnerable ha desaparecido. Cuando esa SBOM registra lo que el build descargó realmente, incluidos los paquetes restaurados desde cachés, la comprobación responde a lo que de verdad preguntan el cliente, el auditor y el regulador.

Cómo apoya CRACI la remediación de CVE

• Localizar. CRACI registra los paquetes que descargó cada job de GitHub Actions, incluidas las dependencias transitivas y los paquetes restaurados desde cachés, y reevalúa continuamente las SBOM monitorizadas. Las vistas de organización agregan los hallazgos de todos los builds y repositorios, para que vea a qué builds afecta un nuevo CVE.
• Asignar. Los equipos de seguridad hacen el triaje de cada hallazgo y lo envían al equipo responsable de la corrección. CRACI es compatible con VEX para registrar cómo afecta una vulnerabilidad a su producto.
• Verificar. Cada nuevo build obtiene su propia SBOM con un estado de completitud, para que pueda confirmar que el build utilizó la versión corregida.
• Notificar. Para las vulnerabilidades explotadas activamente conforme al CRA, CRACI presenta las notificaciones a las autoridades en nombre del fabricante.

Consulte el seguimiento de vulnerabilidades para conocer la funcionalidad completa.

Remediación de CVE: preguntas frecuentes

¿Qué es la remediación de CVE?

La remediación de CVE consiste en eliminar una vulnerabilidad divulgada públicamente, identificada por su ID de CVE, del software que usted ejecuta o distribuye. Para una dependencia, eso suele significar actualizar a una versión en la que la vulnerabilidad esté corregida. Para su propio código, significa parchearlo.

¿Cómo decido qué CVE corregir primero?

Combine la gravedad con las pruebas de explotación. CVSS describe lo grave que es una vulnerabilidad, EPSS estima la probabilidad de que se explote en los próximos 30 días y el catálogo Known Exploited Vulnerabilities de CISA enumera las que ya se están explotando. Una vulnerabilidad con explotación conocida en un paquete que usted distribuye pasa al primer puesto.

¿Con qué rapidez hay que remediar los CVE?

Depende de quién lo pregunte. La Binding Operational Directive 26-04 de CISA da a las agencias federales de Estados Unidos entre 3 días y la siguiente actualización del sistema, según si la vulnerabilidad figura en el catálogo KEV, si el activo está expuesto públicamente, si la explotación se puede automatizar y cuánto control otorga a un atacante. El Cyber Resilience Act de la UE pide a los fabricantes corregir las vulnerabilidades sin demora y, desde el 11 de septiembre de 2026, una vulnerabilidad explotada activamente en un producto activa un plazo de notificación de 24 horas.

¿Qué ocurre si aún no hay una versión corregida?

Mitigue y documente. Desactive la función afectada, bloquee la vía de ataque o cambie el componente si puede, y registre su evaluación, por ejemplo como una declaración VEX. Después esté atento a la versión corregida y aplíquela cuando llegue.

¿Cómo corrijo un CVE en una dependencia transitiva?

Pruebe primero a actualizar la dependencia directa que la incorpora, ya que una versión más reciente suele incluir la corrección. Si aún no existe ninguna, la mayoría de los gestores de paquetes le permiten forzar la versión de un paquete transitivo: overrides en npm, resolutions en Yarn, pnpm.overrides en pnpm. Pruebe el resultado, porque el paquete padre no se compiló con esa versión.