Motivation
The Garden Linux Vulnerability Database (GLVD) should inform users of Garden Linux (GL) about CVEs that affect our GL releases. Moreover, it should help the maintainer team to identify CVEs, which must be fixed to ensure the security of our users, and assist the maintainers with handling those CVEs during major and minor releases. For compliance reasons we should also have a clear trace how CVEs are detected and handled.
Prototype
We identified that we can improve several aspects of the current GLVD solution. Especially how it is integrated into the different workflows of the team and its traceablity. Because of the amount of changes which will be required, we also decided to take the opportunity to redesign the solution as a whole and simplify the tech stack to ease operation and maintenance.
This epic collects the different tasks required to create a first prototype of the new GLVD2 solution. This prototype should focus on the core requirement of identifying relevant CVEs for our GL releases and provide the triage meeting with useful information for the release decision. Once the usefulness of the prototype has been proven, we will extend this prototype to cover more requirements.
Architecture
The following diagram shows the basic features and process we want to implement and test with the prototype.
Our main source for CVEs will be the CVEListV5, which provides all CVEs in CVE JSON V5 format. We will enrich these CVEs with information from the Debian Security Tracker like their triage or which CPEs are related to which Debian package. Moreover, we create SBOMs for our GL releases and parse our package-* repos to identify how our GL packages are build.
With this information we will decide if a CVE is relevant for us or not. If possible, we then decide automatically if we are affected by these potential CVEs. If an automatic decision is not possible, we bring the maintainers into the loop to decide if a CVE affects our GL releases.
The filtered list of current CVEs for our GL releases is then presented to the triage meeting, such that they can use it to decide if a new release of GL is required to fix these CVEs.
Motivation
The Garden Linux Vulnerability Database (GLVD) should inform users of Garden Linux (GL) about CVEs that affect our GL releases. Moreover, it should help the maintainer team to identify CVEs, which must be fixed to ensure the security of our users, and assist the maintainers with handling those CVEs during major and minor releases. For compliance reasons we should also have a clear trace how CVEs are detected and handled.
Prototype
We identified that we can improve several aspects of the current GLVD solution. Especially how it is integrated into the different workflows of the team and its traceablity. Because of the amount of changes which will be required, we also decided to take the opportunity to redesign the solution as a whole and simplify the tech stack to ease operation and maintenance.
This epic collects the different tasks required to create a first prototype of the new GLVD2 solution. This prototype should focus on the core requirement of identifying relevant CVEs for our GL releases and provide the triage meeting with useful information for the release decision. Once the usefulness of the prototype has been proven, we will extend this prototype to cover more requirements.
Architecture
The following diagram shows the basic features and process we want to implement and test with the prototype.
Our main source for CVEs will be the CVEListV5, which provides all CVEs in CVE JSON V5 format. We will enrich these CVEs with information from the Debian Security Tracker like their triage or which CPEs are related to which Debian package. Moreover, we create SBOMs for our GL releases and parse our package-* repos to identify how our GL packages are build.
With this information we will decide if a CVE is relevant for us or not. If possible, we then decide automatically if we are affected by these potential CVEs. If an automatic decision is not possible, we bring the maintainers into the loop to decide if a CVE affects our GL releases.
The filtered list of current CVEs for our GL releases is then presented to the triage meeting, such that they can use it to decide if a new release of GL is required to fix these CVEs.