Vulnerability Management in the Life Cycle of Platform

Owned by Onesait Platform
Last updated: 24/04/24
3 min read

Available since Release 5.1.0 (Survivor)

Introduction

Like any other software, Onesait Platform 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), 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.

    • 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 to 2.7.0), it will be done during the release.

    • 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.

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.

Â