Discovery: Apply compliance controls to projects
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 cannot apply company policies to GitLab projects, which makes managing their compliance difficult and introduces risk to their business.
Intended users
- Delaney (Development Team Lead)
- Sam (Security Analyst)
- Dana (Data Analyst)
- All management stakeholders who adhere to any auditing process. For example in a finance institution (Security, Quality, Development department heads)
Further details
Compliance-minded organizations require a certain level of control of their GitLab environments to manage risk (non-compliance). When a group is configured with a specific compliance framework, that framework may or may not apply equally across all projects.
Customers necessarily need project-level features like this to customize their environments to address the more (or less) strict requirements of any particular project.
Use Cases
- I want to configure merge request approvals and know that this setting cannot be changed by individuals without the proper authority to do so.
- I want all merge requests to pass certain "compliance checks" before they can be approved.
- I need to know when Low and Medium vulnerabilities are accepted and see an issue detailing the risk assessment and acceptance criteria.
- I need all actions and activity to generate evidence artifacts, especially for merge requests that deploy code to production.
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 simply add a default: on
state to a new admin setting that restricts changes to MR approval settings since this is a core pain point for many of our customers.
Prototype
Examples of Controls
These are examples of sensible defaults GitLab could provide for projects on creation. Iteration on these controls could be a mapping to specific group-level compliance frameworks, which would programmatically modify settings throughout a project to meet those requirements.
Many of these features already exist within GitLab and may require only an enforcement element to empower customers to maintain compliance.
Separation of Duties (e.g. PCI-DSS 6.4)
- 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, based on these Additional Thoughts, so as not to make this issue too complex or confusing.
GitLab's Security Compliance team has built the GitLab Control Framework (GCF). Our approach to Compliance Controls should begin with a single framework to validate our assumptions and solutions. 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.