Skip to content

Design | Post-MVC | Group-level Security Dashboard widget: Security scanner status

Problem to solve

Design | Group-level Security Dashboard widget: Security control status was originally opened to show which scanners are enabled across projects in a group. However, due to the BE restrictions in place (see #241309 (closed) and #215373 (closed)), we are moving forward with an MVC of showing the latest pipeline run to the default branch across projects in the group instead. This is an improvement to the current experience (where customers have to go to the Security & Compliance > Configuration page of each project in the group), but still doesn't satisfy their primary job of showing which scanners have been enabled. Both the security control status widget and the Configuration page only show whether or not the scan was run successfully on the latest pipeline to the default branch, so, for example, if there was an error in the SAST job, it would show SAST as not enabled. The next steps would be for the user to troubleshoot the error rather than trying to enable SAST, but this isn't clear.

JTBD

When I am verifying that projects are compliant with our organization's security policies, I want to easily see the status of security scanners across all projects in a group so that I can make sure we're preventing business-critical vulnerabilities from getting into production.

Proposal

Once we have the ability to show whether or not the scan type has been enabled, we should replace the information in the status widget from the latest pipeline run to whether it's been enabled or not.

MVC Future (this issue)
image image

Considerations

  • It's possible that a scanner has been configured in a way that has an affect on when and if the security control runs at all. Therefore, we may want to consider including configuration information, should it differ from the defaults that GitLab provides, in future iterations.

  • Per this conversation in the MVC issue, consider doing solution validation on whether or not it makes sense to separate out links to more jobs; one link for failed jobs (which would go to the Failed jobs tab of the pipeline page), and another link for the other states (success/ passed with warnings/ skipped) which go to the main pipeline page. The latter link would say something like +5 more or +5 others.

Edited by Becka Lippert