Remediación automatizada de vulnerabilidades, del hallazgo a la corrección

Qué significa la remediación automatizada de vulnerabilidades

La remediación de vulnerabilidades consiste en eliminar una vulnerabilidad conocida de su software: actualizar el paquete afectado, aplicar un parche o sustituir el componente. La remediación automatizada encarga a un software la parte mecánica de ese trabajo. Lee un hallazgo, determina qué versión lo corrige, cambia el manifiesto, el lockfile o el código y propone el cambio, por lo general como una pull request.

Para las dependencias de terceros, donde se encuentran la mayoría de las vulnerabilidades conocidas de una base de código moderna, el ciclo es el mismo en todas las herramientas:

1. Inventariar. Saber qué paquetes, y en qué versiones, hay en cada cosa que distribuye.
2. Cotejar. Comprobar ese inventario con los avisos, y seguir comprobándolo a medida que se publican otros nuevos.
3. Priorizar. Decidir qué corregir primero, según la gravedad, la explotación y la exposición.
4. Corregir. Elegir la versión corregida, actualizarla y adaptar el código si la actualización rompe algo.
5. Verificar. Compilar y probar el cambio, y después confirmar que la versión corregida es la que se distribuyó realmente.
6. Registrar. Conservar un rastro de qué estaba afectado, cuándo se corrigió y en qué versión.

La automatización es más fuerte en los pasos 2, 4 y 6, donde el trabajo es repetitivo. Es más débil cuando las entradas son erróneas, y la entrada de todo lo demás es el paso 1.

Cuatro tipos de remediación automatizada

Enfoque	Qué hace	Ejemplos	Dónde se detiene
Bots de actualización de dependencias	Abren pull requests que suben una dependencia vulnerable a una versión corregida	Actualizaciones de seguridad de Dependabot, Renovate	Trabajan a partir de los manifiestos y lockfiles del repositorio; una actualización incompatible sigue necesitando que una persona adapte el código
Pull requests de corrección de SCA	Abren pull requests de actualización para los hallazgos que genera una herramienta de SCA comercial	Snyk, Black Duck, Aikido, Endor Labs	La cobertura varía: algunas herramientas solo corrigen dependencias directas, otras añaden parches o backports
Correcciones de código con IA	Generan un cambio de código para un hallazgo, a menudo una alerta de análisis estático	GitHub Copilot Autofix	Sugerencias no deterministas que requieren revisión; consulte la remediación con IA
Autorremediación de infraestructura	Revierte una configuración errónea o parchea un host cuando se activa una regla	Herramientas de postura de seguridad en la nube y de endpoints	Cubre la infraestructura en ejecución, no las dependencias del software que usted distribuye

Los tres primeros corrigen código que usted distribuye, y todos comparten una suposición: que la lista de paquetes vulnerables que corrigen es la lista correcta.

Toda corrección depende del inventario

Una herramienta de remediación solo puede corregir las vulnerabilidades que conoce, y conoce las que contiene su inventario. La mayoría de los inventarios se reconstruyen a partir de archivos: manifiestos, lockfiles, paquetes instalados o una imagen de contenedor terminada. Esa reconstrucción pasa cosas por alto de formas previsibles.

• Paquetes que los archivos no declaran. Las herramientas que descarga el build, las imágenes base, los plugins y todo lo que instala un script nunca aparecen en un lockfile, así que nunca se abre una pull request de corrección para ellos.
• Versiones distintas de las del lockfile. El build puede resolver una versión distinta de la que lee un escáner, sobre todo si no hay un lockfile en el repositorio. Una corrección basada en la versión equivocada es una respuesta errónea dada con total convicción.
• Paquetes restaurados desde cachés. Una dependencia en caché nunca vuelve a pasar por el registro, de modo que lo que usó el build puede ir por detrás de lo que dice el repositorio.

La solución es partir de lo que el build utilizó realmente. Una SBOM del build se registra mientras se ejecuta el build, por lo que enumera los paquetes que el job descargó, incluidos los transitivos, en lugar de lo que un manifiesto dice que debería necesitar. La remediación que parte de ahí corrige lo que se distribuye.

Qué automatizar y qué reservar

La mayoría de los equipos que consiguen que la remediación funcione la dividen así:

• Automatice la búsqueda y el cotejo. Cada día se publican nuevos avisos. Volver a comprobar a mano cada build distribuido frente a ellos no escala, y es exactamente el tipo de trabajo que el software hace bien.
• Automatice la propuesta. Elegir la versión corregida y abrir el cambio es mecánico. Agrupe las actualizaciones relacionadas para que los revisores vean una pull request en lugar de veinte.
• Condicione la fusión a las pruebas. Fusione automáticamente las actualizaciones de seguridad a nivel de parche que cubra el conjunto de pruebas. Reserve para una persona las actualizaciones incompatibles y todo lo que no tenga cobertura de pruebas.
• Deje las decisiones de criterio en manos humanas. Si una vulnerabilidad afecta siquiera a su producto, y si merece la pena una actualización arriesgada esta semana, son decisiones. Regístrelas, por ejemplo como una declaración VEX, para que no se plantee dos veces la misma pregunta.

Cómo evaluar una herramienta de remediación

Antes de confiar en una herramienta para abrir pull requests en sus repositorios, pregunte:

1. ¿De dónde procede su lista de vulnerabilidades: de archivos del repositorio, de una imagen escaneada o del propio build?
2. ¿Corrige dependencias transitivas o solo las directas que usted declara?
3. ¿Cómo elige la versión corregida: la versión parcheada mínima, la más reciente o una versión que usted fija?
4. ¿La corrección se compila y se prueba antes de que usted la vea, o la pull request es la primera vez que se ejecuta?
5. ¿Puede agrupar las actualizaciones y programarlas para no saturar a los revisores?
6. ¿Registra qué versiones estaban afectadas y cuándo se distribuyó cada corrección?

Dónde encaja CRACI hoy

CRACI ejecuta sus jobs de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas y los paquetes restaurados desde cachés, con un estado de completitud para cada job. Ese registro es el inventario del que debería partir un workflow de remediación.

CRACI reevalúa continuamente las SBOM monitorizadas, de modo que, cuando se publica un nuevo aviso, usted ve a qué builds distribuidos afecta en todos sus repositorios. Los equipos de seguridad hacen el triaje de cada hallazgo y lo envían al equipo responsable de la corrección, y CRACI es compatible con VEX para registrar cómo afecta una vulnerabilidad a su producto. La SBOM del siguiente build muestra después si la versión corregida es la que el build utilizó realmente. La página de seguimiento de vulnerabilidades cubre la funcionalidad completa.

Con arreglo al Cyber Resilience Act de la UE, los fabricantes deben abordar y corregir las vulnerabilidades sin demora, también mediante actualizaciones de seguridad. Un registro de lo que contenía cada build y de cuándo se distribuyó cada corrección es la evidencia que necesita ese proceso.

Remediación automatizada de vulnerabilidades: preguntas frecuentes

¿Qué es la remediación automatizada de vulnerabilidades?

La remediación automatizada de vulnerabilidades es un software que convierte un hallazgo de vulnerabilidad en una corrección sin que una persona haga el trabajo pesado: determina la versión corregida, cambia el manifiesto, el lockfile o el código y propone el cambio, normalmente como una pull request. Una persona, o una política en la que confíe el equipo, sigue decidiendo qué se fusiona.

¿Cuál es la diferencia entre remediación y mitigación de vulnerabilidades?

La remediación elimina la vulnerabilidad, por ejemplo actualizando a una versión corregida o aplicando un parche. La mitigación reduce el riesgo mientras la vulnerabilidad sigue ahí, por ejemplo desactivando la función afectada o bloqueando la vía de ataque. La mitigación gana tiempo; la remediación cierra el hallazgo.

¿Se puede automatizar por completo la remediación de vulnerabilidades?

Solo en parte. Localizar los builds afectados, cotejar avisos y proponer una subida de versión son tareas mecánicas que se automatizan bien. Decidir si una actualización incompatible es segura, o si una vulnerabilidad afecta siquiera a su producto, sigue requiriendo criterio. La mayoría de los equipos automatizan la propuesta y dejan la fusión a una persona, respaldada por pruebas.

¿Dependabot hace remediación automatizada de vulnerabilidades?

Las actualizaciones de seguridad de Dependabot abren pull requests que actualizan una dependencia vulnerable a la versión parcheada mínima, para las alertas que GitHub genera sobre el grafo de dependencias de su repositorio. Eso es remediación automatizada para lo que declaran los manifiestos y lockfiles. CRACI frente a Dependabot explica dónde difieren lo declarado y lo distribuido.

¿Qué debo buscar en una herramienta de remediación de vulnerabilidades?

De dónde procede su lista de vulnerabilidades, si gestiona las dependencias transitivas, cómo elige la versión de la corrección, si la corrección se compila y se prueba antes de que usted la vea, y si registra qué se corrigió y cuándo. Esto último importa para las auditorías y para el CRA, que pide a los fabricantes corregir las vulnerabilidades sin demora.