Incorporación de la gestión de vulnerabilidades en el ciclo de vida
Como cualquier software, Onesait Platform tiene múltiples dependencias de software de terceros, desde librerías utilizadas en tiempo de desarrollo hasta sistemas operativos utilizados en los contenedores a la hora de desplegar.
Por lo tanto, es vital analizar y actualizar dichas dependencias a medida que se van detectado amenazas de seguridad.
La Plataforma ha incorporado a partir de esta release 5.1.0-Survivor la gestión de vulnerabilidades dentro del ciclo de vida de producto, lo que garantiza el compromiso de la Plataforma con este tema.
¿Cómo funciona el proceso?
En cada release (trimestral) se analizará el software (tanto propio como de terceros) que compone Onesait Platform, detectando las vulnerabilidades críticas y graves y trazando un plan de corrección durante la release.
Los puntos de actuación serán:
- Se analizará el software en M-2 de la publicación de la release. Por ejemplo para la release de Q3 de la Plataforma que se publica después de septiembre, las vulnerabilidades analizadas serán las de M-2, es decir julio.
- Se priorizará la resolución de incidencias críticas, y siempre que sea posible, se intentará no tener incidencias críticas, y minimizar las incidencias graves.
- Como la Plataforma se compone de varios softwares Open Source (véase Kafka, Apache Zeppelin, Spring Boot, Keycloak), es posible que el producto base, por ejemplo Keycloak, en ese momento no tenga corrección para esas vulnerabilidades o que la corrección implique actualizar a una versión superior.
- Si el software no tiene corrección para esas vulnerabilidades, se indicará.
- Si el software tiene corrección en un Update Minor (por ejemplo Spring Boot, pasando de la 2.6.0 a la 2.7.0), se realizará durante la release.
- Si el software tiene corrección en una versión Major, entonces se planificará la migración a esta versión en el Roadmap de la Plataforma analizando las posibles repercusiones, como incompatibilidades, etc.
Importante
- Las vulnerabilidades no dejan de aparecer, lo que puede implicar que la Plataforma tenga cero vulnerabilidades críticas en el momento M-2, pero en M hayan aparecido nuevas. Por tanto, debe verse esta gestión de vulnerabilidades como un proceso continuo de mejora, y que debe entenderse como normal que existan vulnerabilidades, tanto en la Plataforma como en los proyectos que la usan.
- En algunos casos, los proyectos que usan la Plataforma no pueden actualizar de versión, bien porque la versión se ha certificado por cliente, porque el producto está en producción y debe planificarse, o por otras razones.
- Si un cliente de la Plataforma necesita una gestión diferente de vulnerabilidades (con más frecuencia o detalle), puede solicitarlo, en cuyo caso éste debe asumir el esfuerzo extra.
¿Cómo se ha implementado técnicamente?
En esta release se ha automatizado el proceso de detección de vulnerabilidades.
Obtención de vulnerabilidades
Mediante un DataFlow podremos descargar del registro de imágenes de la Plataforma (en GCP Registry) la vulnerabilidades, en formato JSON, de las imágenes de la Plataforma etiquetadas con la release a analizar.
Análisis de vulnerabilidades
Se filtran por criticidad (quedándonos con las CRITICAS y ALTAS) las vulnerabilidades y se agrupan por módulos. Se ha creado un Dashboard base de visualización.
Creación de issues en GitLab
A partir del análisis, se crean automáticamente las issues en el GitLab de la Plataforma. Una issue incluye imágenes afectadas con el link al registry de Google, y un enlace a la descripción de la issue donde se especifica qué librería y versiones hay que mejorar.
La seguridad es algo que nos tomamos muy en serio, y con esta mejora avanzamos un paso importante en este sentido.
Si estáis interesados en conocer más sobre esta nueva funcionalidad, dejadnos un comentario o poneos en contacto con nosotros vía canales de soporte, y estaremos encantaros de enseñaros su funcionamiento.
Imagen de cabecera: Scott Webb en Unsplash.
✍🏻 Author(s)
