Versions Compared

Version Old Version 1 New Version 2
Changes made by

Onesait Platform

Onesait Platform

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Introducción

...

Introduction

Like any other 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.

Plataforma ha incorporado a partir de esta release (Q2 de 2023) la gestión de vulnerabilidades dentro del ciclo de vida de producto, lo que garantiza el compromiso de 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.

Se tendrá en cuenta esto: :

...

Se analizará el software en M-2 de la publicación de la release, por ejemplo para la release de Q3 de plataforma que se publica pasado 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.

...

has multiple dependencies on third-party software, from libraries used during development time, to operating systems used in containers at deployment time.

It is thus vital to analyze and update these dependencies as security threats are detected.

Starting with this release (2023, Q2), the Platform has incorporated vulnerability management within the product life cycle, which guarantees the Platform's commitment to this issue.

How does the process work?

In each (quarterly) release, we analyze the software (both proprietary and third-party) that makes up the Onesait Platform, detecting critical and serious vulnerabilities, and drawing up a correction plan during the release.

The action points will be:

  • The software will be analyzed in M-2 of the release post. For example, for the Q3 release of the Platform that is published after September, the vulnerabilities analyzed will be those of M-2, that is to say, July.

  • The resolution of critical incidents will be prioritized, and whenever possible, an attempt will be made to not have critical incidents, and to minimize serious incidents.

  • As the Platform is made up of several Open Source software (like 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

    it is possible that the base product, for example Keycloak, does not currently have a fix for those vulnerabilities or that the fix may involve updating to a higher version.

  • Creación de issues en Gitlab : automáticamente a partir del análisis se han creado las issues en el Gitlab de Plataforma. Esta issue incluye imágenes afectadas con el link al registry de google y link a la descripción de la issue donde viene qué librería y versiones hay que mejorar

    • If the software does not have a fix for those vulnerabilities, that will be indicated.

    • If the software has a correction in a Minor Update (for example Spring Boot, going from 2.6.0 a la to 2.7.0) se realizará durante la , it will be done during the 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 plataforma analizando las posibles repercusiones, como incompatibilidades,…

Info

IMPORTANTE

  • Las vulnerabilidades no dejan de aparecer, lo que puede implicar que la plataforma tenga 0 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 Plataforma como en los proyectos que la usan.

  • En algunos casos, los proyectos que usan 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,…

  • Si un cliente de plataforma necesita una gestión diferente de vulnerabilidades (con más frecuencia o detalle) puede solicitarlo, en cuyo caso este 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: con un dataflow nos descargarmos del Registro de imágenes de Plataforma (en GCP Registry) la vulnerabilidades en JSON de las imágenes de 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:

...

    • If the software has a correction in a Major version, then the migration to this version will be planned in the Platform Roadmap, analyzing the possible repercussions, such as incompatibilities, etc.

Info

IMPORTANT

  • Vulnerabilities do not stop appearing, which may mean that the Platform has zero critical vulnerabilities at the time M-2, but new ones have appeared in M. Therefore, this vulnerability management must be seen as a continuous improvement process, and the existence of vulnerabilities, both in the Platform and in the projects that use it, must be understood as normal.

  • In some cases, the version of the projects that use the Platform cannot updated, either because the version has been certified by the client, because the product is in production and must be planned, or for other reasons.

  • If a Platform client needs different vulnerability management (with more frequency or detail), they can request it, in which case they must assume the extra effort.

How has it been technically implemented?

In this release, the vulnerability detection process has been automated.

  • Obtaining vulnerabilities: Through a DataFlow, you can download the vulnerabilities of the Platform images, in JSON format, tagged with the release to be analyzed, from the Platform's image registry (in GCP Registry).

...

  • Vulnerability analysis: The vulnerabilities are filtered by criticality (retaining the CRITICAL and HIGH) and grouped by modules. We have created a display base Dashboard.

...

  • Creating issues in GitLab: From the analysis, issues are automatically created in the Platform's GitLab. An issue includes affected images with a link to the Google registry, and a link to the issue description where the libraries and versions to be improved are specified.

...