Discovery: Apply compliance framework sensible defaults to projects

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Compliance-minded organizations do not have the necessary controls of their GitLab environment to ensure their projects are meeting compliance program requirements. Currently, customers do not have a way to define compliance controls at an elevated level (above projects) and then programmatically apply these controls to their GitLab projects, which makes managing their compliance difficult and introduces risk to their business.

Intended users

Further details

Compliance-minded organizations require a certain level of control of their GitLab environments to manage risk (non-compliance). When a project is configured with a specific compliance framework, it should apply certain pre-defined, sensible defaults that align with the compliance framework's controls.

For example, if an organization applies the SOX label, we should be able to prompt the user to "Apply recommended SOX settings to your project?" This should automatically take actions such as:

  • Enable Prevent approval of merge requests by merge request author
  • Enable Prevent approval of merge requests by merge request committers
  • Add an approval rule for the Security Group with a minimum of 2 required approvers
  • Add an approval rule for the Compliance Group with a minimum of 2 required approvers

Eventually, we should provide insight into how these settings map to specific compliance controls to be able to provide guidance and insight about a project's compliance posture and not an attestation of compliance.

This would enable customers to quickly see if a project is out of compliance and why, while equipping them to decisively act in a very specific, actionable way (e.g. "Project allows MR authors to approve their own MR. You should consider preventing this to strengthen your SOX compliance posture")

We do not yet have a broad coverage of controls for customers and will need to continue implementing these features to then utilize with compliance labels in a more efficient and effective way.

Use Cases

  • I want to apply a compliance framework to my projects and know that sensible default settings that most closely align with that framework's controls will be applied.

Proposal

Map specific compliance controls, starting with SOX, to be leveraged by the compliance framework project labels. Specifically, creating a SOX compliance label should have the ability to link to these internal SOX mappings.

Applying this label to a project should prompt the user to modify the predefined settings to certain values.

Upon confirming this change, the project should automatically adjust these settings for the user.

Original proposal Leverage GitLab's @gitlab-com/gl-security/compliance team's work on the GitLab Control Framework (GCF) to create an initial standard for newly created projects.

Described in this vision issue, we can create an MVC using the GCF to apply sensible defaults to new projects.

This proposal should allow customers to apply the GCF compliance controls to new projects. The use of his template could be defined in Admin -> Settings -> Templates.

The GCF will provide predefined, "sensible defaults" that will apply to new projects. For example, creating a new project with the GCF framework selected could use the following defaults:

  • All merge requests have at least one linked issue
  • All MRs are reviewed by someone besides the author
  • All MRs conduct DAST, SAST, and dependency scanning
  • All pipelines must pass before an MR can be approved
  • Remediation issues are automatically generated for all identified scan outcomes
  • The build process checks if there's a code freeze and continues if not
  • A CSV "download" option is available as an evidence artifact for the deploy activity

MVC

The MVC for this feature could be to add a hyper-focused default setting around separation of duties for MRs. We could define a profile for Merge request approvals that closely aligns with the requirements of SOX.

Prototype workflows

compliance_controls_prototype

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
comp1 comp2 comp3 comp4 comp5 comp6
View projects Enter a project Select compliance controls in project settings See projects with compliance controls Check a merge request Notified of compliance controls issue

Examples of Controls

These are examples of sensible defaults GitLab could provide for projects on creation.

Some of these features already exist within GitLab and may require only an enforcement element to empower customers to maintain compliance. There are many features that do not yet exist that would support this experience of:

  1. Create a SOX label for projects
  2. Map specific requirements to that SOX label that align with the SOX framework
  3. Apply the SOX label to a project
  4. Prompt the user to apply these sensible default controls
  5. Programmatically make the project changes on behalf of the user

Separation of Duties (e.g. SOX)

  • A merge request cannot be reviewed by someone who has committed code to it
  • A merge request cannot be approved by someone who has committed code to it
  • A merge request cannot be approved without at least X number of approvers
  • An author cannot disable required approvers
  • An author cannot disable code reviews

Risk Assessment (e.g. SOC 2 Risk Assessment)

  • Code reviews must pass DAST, SAST, dependency, and license scanning
  • Vulnerabilities with a Low or Medium impact identified during a merge request should be remediated or accepted with justification
  • Vulnerabilities with a High or Critical impact identified during a merge request must be remediated
  • Merge requests that impact critical systems must undergo a Risk Assessment
  • Merge requests containing code that processes sensitive data (store, transmit, or process) must undergo security testing

Audit And Accountability (e.g. NIST SP 800-53 - AU-10)

  • All activities performed within GitLab must be traceable to a specific individual
  • Authorized users must be able to view the producer of information
  • Remediation issues should be created in the event of a validation error
  • Audit log retention must meet internal company standards
  • Audit events should include specific detail for internal company auditing purposes

Permissions and Security

This should be limited to administrators or group owners.

Additional Thoughts

*Following a discussion with @jburrows001, I've created a separate vision issue that explores using our internal GitLab Control Framework (GCF) as a way to simplify the number of frameworks we have to track and manage.

Given the somewhat universal nature of many compliance controls (e.g. separation of duties, access control, risk assessment), it makes sense to leverage the GCF since it has already roughly translated three compliance frameworks (e.g. SOC 2, PCI, ISO) into a single source of truth.

Leveraging our own internal framework has several benefits:

  • GitLab can maintain a single, standard framework despite the constantly changing compliance space
  • The GCF will inherently continue to evolve due to GitLab's own internal needs for a common framework
  • A single framework can simplify, and more more efficient, the process of extending flexibility to customers who already employ - and prefer to keep - their own in-house solutions for compliance

Applying the GCF to projects also creates an opportunity to provide valuable reporting to customers. Future iterations could incorporate reporting to the group-level compliance dashboard. This reporting could manifest in a way similar to #40600 (closed) by mapping the GCF controls to other compliance frameworks "at a glance" for projects. This could be an exportable (csv) evidence artifact in addition to UI reporting.

Edited by 🤖 GitLab Bot 🤖