### Note: Future work of Vulnerability Management Automation will be tracked in https://gitlab.com/groups/gitlab-org/-/epics/16283, including open issues/use cases discussed within this epic. ## Description Security policies are not used in a vacuum, but are often playing a supporting role in a larger vulnerability management or triage workflow. Ensuring the proper level of detection and enforcement is a delicate balance, and it can vary from organization to organization. One of the most common workflows utilizes MRs to automatically detect new vulnerabilities and block changes if the risk is too high. If vulnerabilities are detected they may be surfaced in the MR widget, pipeline report, or vulnerability report, depending on the case. The intent of this epic is to understand the various use cases and consider cross-functional impacts and improvements. ## Key Themes After evaluating various scenarios that cause friction and confusion for users of scan result policies, we identified the following key themes, in order of priority: 1. **Aligning security policies and MR widget comparison logic** 2. **Improve accuracy of scan results related to timing of scans** 3. **Security Policy Automation in Vulnerability Report** ### 1\. Aligning security policies and MR widget comparison logic These use cases cause the most friction for our users as they rely heavily on the MR widgets to understand what is blocking an MR, and generally scan result policies are based on rules that evaluate the severity of a vulnerability to choose when to block merge requests. <details> <summary>Use cases</summary> <table> <tr> <th>Use case</th> <th>Current behavior</th> <th>Desired behavior</th> <th>Solution</th> </tr> <tr> <td> 1\. The Security MR Widget currently does not consider the same pipeline sources as security policies and should be aligned </td> <td>The Security MR Widget compares feature/main (source/target) branches and does not consider all pipeline source types. This results in possible findings identified in related pipelines affecting approvals, while they do not appear in the widget.</td> <td> Results in the Security widget should align with Security Policy approvals. If a vulnerability is identified from a `merge_request_event` pipeline source and causes a violation, it should appear in the Security Widget and block the MR. Additionally, it should be clear to users which violations require approval. </td> <td>The MR Widget comparison logic should align on pipeline sources used by Security Policies (latest completed pipeline for all sources except for parent/child pipelines).</td> </tr> <tr> <td> 2\. The Security MR Widget only accounts for findings from `Common base` on the main branch to the feature tip of the `feature` branch. However, Security Policies uses `Main tip` for the default/target branch. </td> <td> This can result in findings in commits on the default branch past `Common base` to be detected by a Security Policy and require approval (if it also matches policy criteria, such as `newly_detected`). </td> <td> Security Policies should align with the MR widget and only consider commits up to `Common base` in the default branch for `newly detected` findings. For `previously_existing` findings, however, we need to ignore the source branch results and only use the most recent data possible for the default branch (using the Vuln report db or the CVS db). </td> <td> 1. https://gitlab.com/gitlab-org/gitlab/-/issues/428518+ 2. https://gitlab.com/gitlab-org/gitlab/-/issues/425482+ [Workflow Diagram](https://gitlab.com/groups/gitlab-org/-/uploads/6cf295b4efdfe92a5ee943796180ad2d/Mis-match_cases.png) </td> </tr> </table> </details> ### 2\. Improve accuracy of scan results related to timing of scans The next priority involves the timing of scans. Stale pipelines, new commits, or inconsistent timing of scans can affect the results and cause MRs to be blocked when it's unexpected. <details> <summary>Use cases</summary> <table> <tr> <th> Resolved :white_check_mark: / Moved :fast_forward: </th> <th>Use case</th> <th>Current behavior</th> <th>Desired behavior</th> <th>Solution</th> </tr> <tr> <td></td> <td> 1\. An MR is raised and an existing dependency in the default branch has a new CVE </td> <td>The short summary is this is a timing issue.  If the last pipeline for the default branch is stale, and if a new advisory has been added to our advisory database since the time that pipeline last ran, we won’t detect that vulnerability on the default branch.  When a source branch pipeline runs, it will detect the vulnerability which incorrectly leads the widget to think a new vulnerability is being introduced when in fact the vulnerability is already in the default branch and just has not yet been detected there due to the stale default branch pipeline.</td> <td>As the newly detected vuln is not related to the MR and any commits within the MR, the MR would not be blocked and the vuln would not appear in the MR Widget</td> <td> 1. Most scenarios will be addressed by adding [continuous vulnerability scanning](https://gitlab.com/groups/gitlab-org/-/epics/7886 "Continuous vulnerability scans") for container and dependency scanning. 2. https://gitlab.com/gitlab-org/gitlab/-/issues/428518+ will also contribute to the solution by ignoring findings past `Common base` for policies scoped to `newly detected` . [Workflow Diagram](https://gitlab.com/groups/gitlab-org/-/uploads/93f829aaf6a35e1ee79fd5e3b69d6b97/MR_workflow_for_security2.png) </td> </tr> <tr> <td> :fast_forward: Carrying forward in https://gitlab.com/groups/gitlab-org/-/epics/14526 </td> <td> 2\. After an MR is created that includes a vulnerability, a separate MR is created that includes a fix for the vuln </td> <td>The vulnerability appears as new in the MR widget and the MR is blocked, requiring approval, as the pipeline is comparing all commits on the default branch tip, not just those from the common base.</td> <td>As the vulnerability is fixed in a subsequent MR, the approval is outdated and should not be required and the vulnerability should not appear in the MR Widget.</td> <td> Solution TBD [Workflow Diagram](https://gitlab.com/groups/gitlab-org/-/uploads/45c3b1ddf83caad2774ae352917b1aa9/Screenshot_2023-10-11_at_10.53.45.png) </td> </tr> <tr> <td> :fast_forward: Carrying forward in https://gitlab.com/groups/gitlab-org/-/epics/16285 </td> <td> 3\. Source branch is out of sync with the target branch when the security policies are evaluated </td> <td>Without rebasing, if a vulnerability has already been fixed in the target branch and the source branch has not been rebased, the vulnerability may still exist in the source branch. In this case, Security Policies may require approvals.</td> <td> 1. Approval logic could by synced without requiring a pipeline to run 2. Users could be notified in MR when their branch is out of sync / stale. </td> <td> Solution TBD [Workflow Diagram](https://gitlab.com/groups/gitlab-org/-/uploads/9e24844f9daecd55a20a8f5c35597750/Screenshot_2023-10-11_at_10.58.36.png) </td> </tr> </table> </details> ### 3\. Security Policy Automation in Vulnerability Report The last key them involves the interaction between using Security Policies along with other features, such as the Vulnerability report. Once an MR is approved with a vulnerability, there are additional steps that can be taken to automate vulnerability management. <details> <summary>Use cases</summary> <table> <tr> <th> Resolved :white_check_mark: / Moved :fast_forward: </th> <th>Use case</th> <th>Current behavior</th> <th>Desired behavior</th> <th>Solution</th> </tr> <tr> <td> :fast_forward: Carrying this forward in https://gitlab.com/groups/gitlab-org/-/epics/16284 </td> <td> 1\. A vulnerability is detected on the default branch and was detected as a violation in the MR, but was approved by the security team for `reason`. </td> <td>Today, users must update the status of such findings in the Vulnerability Report to dismiss the vuln again and choose a reason.</td> <td>By default, policies should set approved vulnerabilities to "Dismiss" and select a reason such as Acceptable Risk (or perhaps be able to do so in the policy step and have this carry into the Vuln report).</td> <td> Solution TBD [Workflow Diagram 1](https://gitlab.com/groups/gitlab-org/-/uploads/3518d624bd667a4eec9c1150028ee077/previously-existing-workflow.png) [Workflow Diagram 2](https://gitlab.com/groups/gitlab-org/-/uploads/70bebb0368a123fa261a405800480d1c/new-vuln-workflow.png) </td> </tr> <tr> <td> :fast_forward: Carrying forward in https://gitlab.com/groups/gitlab-org/-/epics/16286 </td> <td> 2\. Scan result policies that set an SLA based on severity do not translate details into the Vulnerability report. </td> <td>A vulnerability is ignored for 30 days based on the policy rules (e.g. ignore findings with severity High for 30 days). The next step would require security teams to create an issue and add a due date. If the finding is not resolved in 30 days, security policies would begin blocking the MR. This information wouldn't be transparent to teams triaging in the vuln report today.</td> <td>When a finding is automatically ignored by a Security policy, the vulnerability can be merged into the default branch. The finding could be set to Confirmed, and we could automate creation of an issue with the SLA based on the policy.</td> <td> Solution TBD [Workflow Diagram 1](https://gitlab.com/groups/gitlab-org/-/uploads/b54c295c0aa952de1573aae13de92f72/previously-existing-workflow.png) [Workflow Diagram 2](https://gitlab.com/groups/gitlab-org/-/uploads/f08347d9b6f1e7f4ee360dbfe3fc30b3/new-vuln-workflow.png) </td> </tr> <tr> <td> :fast_forward: Carrying forward in https://gitlab.com/groups/gitlab-org/-/epics/12867 </td> <td> 3. Customers would like to be able to set exceptions, such as by CVE, and have these ignored by scan result policies. </td> <td> * A particular CVE is not relevant due to the languages used in a given set of repos. Security teams would like to ignore all instances of the CVE. * A certain type of finding is identified and acknowledged by the security team, but they want to set a temporary exception for that CVE, for particular projects to give dev teams time to prioritize/address. * A particular set of issues related to a dependency is identified, but the particular project/dependency and associated risk is identified and accepted. It may be desired to ignore for some time (which the org agreed to have this addressed by) or indefinitely as it's agreed this project/repo is in maintenance mode and the particular risk is minimal. </td> <td> 1. Have a mechanism to create an exception for a CVE or dependency from the Vulnerability report (or initiate the flow there). 2. The exceptions are stored somewhere, perhaps created within a Vulnerability Management policy (planned, but does not exist today) and the data stored in a database. 3. Scan result policies could include a toggle to filter out exceptions set by these policies. Perhaps this is a state in the vulnerability that scan result policies are aware of. </td> <td></td> </tr> </table> </details> ### Other undefined/TBD cases <details> <summary>Use cases</summary> <table> <tr> <th> Resolved :white_check_mark: / Moving :fast_forward: </th> <th>Use case</th> <th>Current behavior</th> <th>Desired behavior</th> <th>Solution</th> </tr> <tr> <td> :white_check_mark: We now surface this data in security policy bot comments, work continued in https://gitlab.com/groups/gitlab-org/-/epics/10975. </td> <td> 1. It is not clear whether the vulns are found in the source branch or target branches? </td> <td>We only show newly detected and previously existing as status, but in some cases, previously existing can be on the source branch as well.</td> <td></td> <td> 1. In policy settings, we make it clear that users want to block MR when they are target branches or source branches. 2. In the MR widget, we also make clear the Blocker's status and location (No.2) [Workflow Diagram 1](https://gitlab.com/groups/gitlab-org/-/uploads/567e23e79159c2c05f517d8b24543097/new-vuln-workflow.png) [Workflow Diagram 2](https://gitlab.com/groups/gitlab-org/-/uploads/3421de3f903a62171aa75d0de2de7fd6/previously-existing-workflow.png) </td> </tr> <tr> <td> :fast_forward: Carrying forward in https://gitlab.com/groups/gitlab-org/-/epics/13808 </td> <td> 2. Actions about particular blocker vulnerability or </td> <td>Currently, when are vuln marked as a blocker for MR, we encourage the user to approve or disapprove it, but we don't encourage the user to act on particular blockers</td> <td></td> <td> 1. In policy settings, introduce actions about auto-resolve blockers 2. In MR page make the blocker's action more clear (No.3 and No.5) [Workflow Diagram 1](https://gitlab.com/groups/gitlab-org/-/uploads/9015195f3af3d3b0bd33a3527696cb9d/new-vuln-workflow.png) [Workflow Diagram 2](https://gitlab.com/groups/gitlab-org/-/uploads/fc2c9bf334475130a22ee27c8bca5993/previously-existing-workflow.png) </td> </tr> </table> </details> ### Intended users ### User experience goal ### Proposal Align the MR widget, vulnerability report, and security policies based on the use cases documented in this epic. ### Links / references