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.:
package-lock.json
) - 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 |
---|---|
No solution | 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":
-
@fcatteau (backend go): -
Update output format to include the API version: https://gitlab.com/gitlab-org/gitlab-ee/issues/8747 -
Define the new fields for auto-remediate: https://gitlab.com/gitlab-org/gitlab-ee/issues/8833#report-syntax -
Update dependency scanning to generate the auto-remediate data: gitlab-org/security-products/analyzers/gemnasium!5 (merged)
-
-
@ayufan (backend rails): -
Update reports to support the new format !8701 (merged) -
Update reports to support the new fields(update: as we don't store the remediation data yet, we don't have anything to do here)
-
-
@leipert (frontend): -
Support the new ~"dependency scanning" format: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8869 -
Support the new ~"dependency scanning" fields: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9009 -
Update the modal to display the new solutions box : https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9030 -
Document how to create a patch https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9056 -
Document the new feature https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9056
-
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.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.