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.
- 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)
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.
- 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'd like my internal auditing or security team to have access to audit data so I don't have to provide that to them.
This is not yet refined for an MVC
Allow customers to specify what compliance controls should apply to a specific project. This can be achieved by creating predefined, "sensible defaults" that can be selected at project creation. For example, creating a new project and selecting
SOC 2, could set the appropriate defaults for a project so that:
- 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
- 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
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
Xnumber 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.
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