### 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 1. create a patch for existing files (e.g.: `package-lock.json`) 1. 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": * [x] @fcatteau (~backend go): * [x] Update output format to include the API version: https://gitlab.com/gitlab-org/gitlab-ee/issues/8747 * [x] Define the new fields for auto-remediate: https://gitlab.com/gitlab-org/gitlab-ee/issues/8833#report-syntax * [x] Update dependency scanning to generate the auto-remediate data: https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/merge_requests/5 * [x] @ayufan (~backend rails): * [x] Update reports to support the new format !8701 * [x] ~~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) * [x] @leipert (~frontend): * [x] Support the new ~"dependency scanning" format: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8869 * [x] Support the new ~"dependency scanning" fields: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9009 * [x] Update the modal to display the new solutions box : https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9030 * [x] Document how to create a patch https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9056 * [x] 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. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->