Skip to content

Security & Compliance page for core users - Technical design

Why

This issue tracks the technical design for &4787 which exposes a Security & Compliance page fore Core users.

References:

  1. https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/finders/security/security_jobs_finder.rb
    • Lists scanners to query job status
  2. https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/presenters/projects/security/configuration_presenter.rb
    • Meta data for scanners
    • Custom logic to override license compliance and inject DAST Profiles lines

Problems with the current configuration page code design

  1. The code is very rigid. It is difficult to add static content that isn't pipeline driven. (eg. adding DAST Profiles)
  2. The current configuration page has an issue where the status is incorrectly reported if the last pipeline run didn't contain security scans (eg. docs only pipeline)

Questions

  1. Should we follow the jobs_finder pattern or can we build more elegant APIs to run this page?
  2. For MVC should we build this page completely static?

Proposals

Option Level of Effort Complexity Desire Pros Cons
Fully static Low/Medium Low Medium
  • Requires the least amount of backend work: just moving the existing Mutation.configureSast GraphQL API to FOSS
  • Quickest way to make this page available to non-Ultimate users
  • A lot of the frontend work to achieve this will probably need to be rewritten when the page is later made dynamic
  • It's feasible the Ultimate and non-Ultimate versions of this page diverge if left static for too long
Using existing pipeline driven backend Medium Medium Medium
  • Keeps the implementations of Ultimate and non-Ultimate versions in sync, making it easier in future to extend/enhance both together
  • The existing backend/frontend contract is awkward, since different scanners are managed in different ways
  • Requires more backend to be moved to FOSS (or at least to plans lower than Ultimate)
Augmenting pipeline status with ci.yml parsing/JSON API High High Short-term low, long-term, high
  • Probably requires more investigation of its own - for instance, how expensive is it to get the .gitlab-ci.yml as JSON; do the current limitations of that JSON API block us from getting the information we need; should we instead be displaying two statuses: whether a scanner is configured, and whether or not it ran
  • Requires the most backend and frontend work to implement

Relevant links

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing:

Implementation plan

Edited by Neil McCorrison