Allow owners to define custom compliance framework labels (discovery)

Problem to solve

We introduced compliance framework project labels in %12.10 to help users identify projects as having compliance requirements specific to a framework. As an MVC, this has served well to identify these projects at a basic level, but does not provide sufficient flexibility.

In many cases, compliance-minded organizations need to identify projects such as the type of environment (Linux, Windows, AWS, GCP, etc) or other characteristics to build automation into their workflows. The current feature for labeling projects with compliance frameworks cannot properly scale and provide necessary value for organizations in its current form.

Intended users

• Cameron (Compliance Manager)
• Sidney (Systems Administrator)

JTBD

• When my GitLab project is subject to specific compliance requirements or regulations, I want to apply sensible default settings and behaviors, so I can ensure we're adequately meeting those requirements without having to constantly monitor or enforce the required settings and behaviors.

Proposal

Add a group level setting section to Settings -> General -> Compliance frameworks

Allow group owners to add or modify a compliance framework with the following fields:

• Title: [ e.g. HIPAA, SOX, Internal, Tech Risk, otherCustomLabelName ]
  • The labels should allow the use of labels that look scoped (use of ::) but should not implement or leverage any scoped label behavior for now.
• Description: [ e.g. "This label should be applied to projects which are regulated by HIPAA" ]
• Background color:
• Regulated: A checkbox indicating if this label should be considered regulated by law. (This attribute was introduced under #273098 (closed).)

Show a line item for each label that is created in this section.

This issue is complete when:

• Refactor Compliance Frameworks model
• Create/edit/assign compliance labels

Figma

Labels at Group Level	Edit	New	Display defaults/custom compliance frameworks at project level

Note: To prevent a breaking change, we could convert the existing compliance framework labels (GDPR, HIPAA, PCI-DSS, SOC 2, and SOX) to standard, default labels.

Pricing Tier: The default labels that exist today (cited just above) should be available in GitLab Premium as is currently the case today. The ability to add & customize additional labels should be in GitLab Ultimate.

Further details

It's possible this issue is redundant with Project Topics, but we'll need to ensure this feature set can achieve the following:

• This first MVC would support only a single project label of this type, per project
• Customers can specify attributes (compliance framework(s), environment, language, etc) within these labels
• Can be controlled to prevent changes to these attributes since automation/services will be built based on this feature
• Reliable as a scoping mechanism for features like #231246 (closed)

Currently, Project Topics can accept virtually any word or set of words to describe a project, e.g. "Ruby", "Windows", "Kittens", "Pillows". There's no way to pre-define these, enforce the use of specific topics, prevent changes to these topics, or trigger any actions off of these topics.

Compliance framework project labels are a limited number of pre-defined (by GitLab) values that are informative, but do not provide any flexibility or additional functionality (yet).

Links

• 📺 Required Pipeline Alternative

Add to a new issue

• Add a field, Custom CI configuration path: [ e.g. /group/compliance-project/hipaa-include.gitlab-ci.yml ]

Adding additional, custom project labels and using the "custom CI configuration path" feature should be in GitLab Ultimate.

Early customer feedback

Some experience by which you could define a list of pre-defined labels (using this term ambiguously for now) that any project could pull from to describe characteristics of it. For example:

Pre-defined list, created by admin or group owner:

• Regulated
• Linux::Internal
• Finance
• Regulated
• Regulated::EU

You could then configure Project A to use/be labeled with: Regulated::EU. You could then configure Project B to use/be labeled with: Linux::Internal

• Nobody except for Owners or Admins could modify these labels
• Additional labels couldn't be added unless added to the list of labels
• These labels could be used to trigger certain actions or behaviors (e.g. "Run pipeline configuration A for all projects labeled with Regulated", "Run pipeline configuration B for all projects labeled with Regulated::EU")