Discovery: improve user awareness of when/what security scans are configured
Problem
There is no clear awareness provided to the user of what branches have security scans configured (and what scans are configured and when). Examples: this affects the experience on the dashboard (the data being displayed) and the experience in the merge request (ex. when a feature branch does not have configured scans, but is in a project that has scans configured on the default branch)
Related context: In &1784 (closed) study, only 1 of 5 users were able to properly configure a security scan when given the task. We found that users navigated to the left nav security section with ease; however were disappointed when arriving to this section and not finding a "on/off" switch. This discovery: #13646 (closed) produced a workflow to enable a user to configure security scans directly from the UI. This workflow was validated in ux-research#359 (closed) (closed), where we saw 5 of 5 participants successfully configure a scan. This implementation issue #34771 (closed) allows the user to configure a security scan directly form the UI, but only to the default branch.
Solution ideation
Provide the user with the awareness of what branches have security jobs in the pipeline/configured. Clarify when security scans are not being performed, for example in a feature branch that is not configured with a security scan, but exists in a project that has scans on the default branch.
Related: the security dashboard only shows results from the default branch. This issue #33160 looks to improve this by allowing user to view data from feature branches. These two issues are closely related and should aim to align in iterations.
We'll consider the following:
A. It shouldn't be possible to merge an MR if the target branch has security scans but the source branch has no similar security scans, otherwise, it would be possible to work around the scans by not enabling them, which is a serious security flaw. For instance, the merge should be blocked if it has no SAST scans, but the target branch has SAST scans. The same goes for Dependency Scanning, DAST, etc.
B. If there's a mismatch in the scans, such as the one described in A, the UI should give instructions to remediate the problem. Two solutions are 1. to rebase the source branch on top of the target branch and 2. merge the target branch into the source branch. These solutions are generic (nothing specific to the security scans) and they ensure consistency in the scans, which is really important, as explained in A.
C. Large software usually has many contributors who submit MRs, to be merged into the master branch (or some other "default branch"). It's not realistic to enable the scans on all the branches corresponding to all the open MRs; not only this would be too much work for the maintainers (a burden really), but also they would be contributing to the MRs where they should be reviewers, not contributors. Maintainers should focus on configuring the security scan for the master/default branch(es), knowing that no MR can be merged into this branch (or these branches) unless it has similar scans (A), and that the UI will help contributors with configuring the scans (B).
D. Given all that, there's no need for a configuration screen where maintainers would enable the security scans for multiple branches. There may have to configure the scans for multiple stable branches (like v1 and v2, corresponding to 2 major versions of the software), but projects have no more than a few of these branches, and it seems acceptable to have maintainers repeat the configuration steps for each of them.
E. Right now the security dashboard only show the status of the default branch and doesn't fit projects where they are multiple stable branches corresponding to major versions of the project, as described in D.
Designs under review
A. Context: current rebase functionality | B. Solution ideation |
---|---|
![]() |
![]() |
Baseline UX: this shows when a rebase could be set to be shown in the UI (settings). It would then be seen in the MR as an option. There is ongoing work for a "rebase and merge" solution. (#895) | Ideation on solutions for improved UX in the MR when the source branch (that has not been configured with scans) is targeting branch with configured scans. |
Issue conclusion
1. MVC implementation issue: #198496 (closed). This issue will bring awareness to developers in the MR when a source branch, that isn't configured with scans, is targeting the default branch (with scans). Additionally, it will provide a solution to remediate the issue. Additionally, will need to ensure the UI display is aligned/consistent with this issue: #4913 (closed).
2. Follow up issue: #198497 (closed). This issue considers how an approval rule and/or setting to further enforce the remediation (and dissallowing the MR). This way the system can ensure that no changes will be merged to default without a scan (aligning with user expectation).