How to ensure separation of duties and enforce compliance with GitLab

In this article, you'll learn the different ways to ensure separation of duties and continuous compliance with the GitLab DevSecOps platform. But first, let's level-set on two key concepts:

Compliance means being in accordance with guidelines and specifications that have been defined either by your corporation or a regulatory agency. Compliance helps maintain corporate ethics, appropriate user policies, security standards, and much more for the safety of consumers.

Non-compliance may result in a bundle of legal fees and fines, so it is very important to maintain compliance. While maintaining compliance, DevSecOps teams must also ensure sustained development velocity, providing necessary simplicity, visibility, and control.

Separation of duties requires multiple actors to complete a task to increase protection from error as well as prevent malicious activity. Separation of duties ensures roles best-suited for the job are the only ones that can perform it. As an example, some of the following actors are observed, each with a specific purpose:

• a developer will be responsible for developing new features
• a compliance officer will be responsible for creating and enforcing the usage of a pipeline
• an application security engineer will be responsible for approving merge requests with vulnerabilities

Considering the above roles, we can ensure that a developer cannot change a running pipeline. This is a task that can only be performed by a compliance officer, ensuring only compliant code can be pushed without approval.

An application security engineer is responsible for reviewing and approving code with vulnerabilities, ensuring proper mitigation can be performed, and that nothing comes as a surprise in the future. In this scenario, developers can't merge code until compliance and security requirements are met.

Security policies

GitLab provides Security Policies, which enable security teams to require security scans to run according to a configuration. This gives security teams confidence that the configured scans have not been changed or disabled.

Security policies can be scoped to meet certain Compliance Frameworks. This means that your project has certain compliance requirements and needs additional oversight. This label can be created in Secure > Compliance Center > Frameworks under your top-level group.

Note: Compliance labels can only be assigned to projects within the top-level group in which we create the label.

There are three types of policies, Scan Execution Policies, Merge Request Approval Policies, and Pipeline Execution Policies.

• Scan Execution Policies: Require that security scans run on a specified schedule or with the project pipeline.
• Merge Request Approval Policies: Take action based on scan results, such as requiring approval from the security team before a merge can occur.
• Pipeline Execution Policies: Enforce CI/CD jobs for applicable projects.

These policies can be configured via the Policy Editor in a few simple steps.

Scan execution

1. Go to Security & Compliance > Policies.

2. Create a new policy by pressing the New Policy button.

3. Select Scan Execution.

4. Create the rule. I'm creating a rule that requires SAST to be configured in order for a pipeline to run.

name: force_sast
description: 'require sast to run'
enabled: true
rules:
- type: pipeline
  branches:
  - main
actions:
- scan: sast

5. Submit the policy by creating a merge request and then merge.

All scan execution policy changes are applied through a background job that runs once every 10 minutes. Allow up to 10 minutes for any policy changes committed to this project to take effect.

6. Try and run a pipeline. It will not be run unless SAST is defined in the YAML.

Note: You can also force SAST to run on a timer. For more information, see the scan execution policies documentation.

Merge Request Approval

1. Go to Secure > Policies.

2. Create a new policy by pressing the New Policy button.

3. Select Merge Request Approval Policy.

4. Define policy scope.

5. Create the rule.

6. Add action to take.

Note: The policy is evaluated according to the rules you set. This means that, if the rules are invalid, or can’t be evaluated, approval is required. To prevent this, the default Fallback behavior field can be changed to open.

1. Submit the policy by creating a merge request and then merging

2. Create a separate merge request with vulnerabilities

You can see how to add vulnerabilities by checking out the Developer Workflow section of the GitLab DevSecOps Workshop.

3. Verify Merge Request Approval Policy is being used by viewing merge request.

Pipeline Execution Policy

To set up a pipeline execution policy, you need to first create a project containing the CI files you would like to run. Make sure that only the security team and/or administrator has access to ensure separation of duties. I created the "Compliance and Deploy" project, which contains the YAML I wish to enforce.

1. Go to Secure > Policies.

2. Create a new policy by pressing the New Policy button.

3. Select Pipeline Execution Policy.

4. Define policy scope.

5. Add action to take.

6. Add conditions.

7. Submit the policy by creating a merge request and then merging.

8. Try and run a pipeline. You will see the policy specific jobs and stages in your pipeline.

Audit Management and Compliance Dashboard

Another important part of compliance is knowing it is actually happening in your groups/projects. GitLab has Audit Events and Compliance Reports to assist with audits.

Audit Events allows GitLab owners and administrators to track important events such as who performed certain actions and the time they occurred.

Audit Events records different events per group and per project, which can be seen in the audit events documentation. Audit Events can be accessed by going to Security & Compliance > Audit Events. Some examples include:

• user was added to project and their permissions
• permission changes of a user assigned to a project
• project CI/CD variable added, removed, or protected status changed
• user was added to group and their permissions
• group name or path changed

Audit Events can also be sent to an HTTP endpoint using Audit Event Streaming. Learn how to implement Audit Event Streaming in this video.

Standards Adherence gives you the ability to see a group's merge request activity. It provides a high-level view for all projects in the group.

You can use the report to:

• get an overview of the latest merge request for each project
• see if merge requests were approved and by whom
• see merge request authors
• see the latest CI/CD pipeline result for each merge request

The Standards Adherence report can be accessed in the top-level group by going to Secure > Compliance Center, and choosing the Standards Adherence tab.

---

Thanks for reading! For more information on separation of duties within GitLab, check out Continous Software Compliance with GitLab