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:
- find which is the best version of the library that fixes the problem, given all the version constraints of that app
- create a patch for existing files (e.g.:
- 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.
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.
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
If the information is not available (old report version, no remediation found, etc.) it will not be shown in the frontend.
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
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.
|Modal with solution & patch||Modal with solution only|
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.
3 moving parts are involved in this issue, and we need to sync 3 "teams":
@fcatteau (backend go):
- Update output format to include the API version
- Define the new fields for auto-remediate (ASAP, so frontend knows what to expect)
- Update dependency scanning to generate the auto-remediate data.
@ayufan (backend rails):
- Update reports to support the new format
- Update reports to support the new fields
- @leipert and @samdbeckham (frontend) (correct me if I'm wrong):
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.