Skip to content

GitLab Next

You need to sign in or sign up before continuing.
Closed
Created by Fabio Busatto@bikebillyContributor13 of 13 tasks completed13/13 tasks

Create a code diff to fix Dependency Scanning vulnerabilities

Problem to solve

Security checks are performed on the codebase and vulnerabilities are shown in the MR widget and in the Security Dashboard. We also show suggestions on how to remediate specific problems, like vulnerable libraries. This information is great, but users still need to understand if the suggestion is compatible with their app, and which are the needed changes to implement it.

Auto remediate aims to automate the fix. In order to do that, GitLab needs to:

  1. find which is the best version of the library that fixes the problem, given all the version constraints of that app
  2. create a patch for existing files (e.g.: package-lock.json)
  3. include this information in the report, and send it to GitLab

Once GitLab has this information, it can be shown to users along with the suggestion text. It will be easier then to create a proper fix.

Further details

This issue aims to create a diff to fix the vulnerability, and to present it to the user. Further iterations will allow to automatically commit it, and create a MR.

This issue considers Dependency Scanning vulnerabilities only.

This issue supports Node.js projects only.

Proposal

Improve our dependency_scanning job definition to include another process that will be executed to identify which are the new library versions that need to be used to fix the vulnerability and still satisfy constraints defined in the dependency file. It will target Node.js only.

If the process is able to find a suitable change, it will be translated into a code diff. This information is then included in the gl-dependency-scanning-report.json.

If the information is not available (old report version, no remediation found, etc.) it will not be shown in the frontend.

The gl-dependency-scanning-report.json must be changed to use a hash instead of an array as the top element. The hash will contain a version field (to version the config), a vulnerabilities field (the "old" array), and a remediation field (with the code diffs, referenced array elements in vulnerabilities).

When the details modal window for the vulnerability is shown from the MR report or the Group Security Dashboard, the code diff will be displayed to the user.

We will ensure backward compatibility with "old" reports.

Design

Modal with solution & patch Modal with solution only
with-solution-and-patch with-solution-no-patch
No solution Solution, no patch Solution and patch
no-solution no-patch solution-and-patch

What does success look like, and how can we measure that?

We want to measure if users are looking at the code diff when they access details of the vulnerability.

We can add a snowplow even to the tab/button that shows the diff, so we can count the number of code diff views.

The solution section will not be shown if a solution is not available.

Execution

3 moving parts are involved in this issue, and we need to sync 3 "teams":

Timing

Many of us will be on Holidays in December, especially W52. We should aim to do all developments before the end of W51, and use Jan 2, 3, 4 (W1) for final reviews. Try to identify available reviewers during W51 already, so we don't waste time during W1 running after everyone's availability.

Edited by Fabien Catteau