GitLab Configuration Best Practices

Intro

GitLab is a collaborative source code management platform that plays a critical role in modern software development, providing a central repository for storing, managing, and versioning source code as well as collaborating with a community of developers. However, it also represent a potential security risk if not properly configured. In this guide, we will explore the best practices for securing GitLab, covering topics that include user authentication, access control, permissions, monitoring, logging, and integrating security tools.

Audience

This guide has been written for the:

• Maintainer who wants to improve the security posture for one or more GitLab projects they support.
• Owner who wants to improve the security posture for one or more GitLab groups they manage.
• Open Source Program Office (OSPO) who is typically responsible for multiple groups and projects.
• Operations team tasked with applying policies as part of their work managing assets on GitLab.
• GitLab enterprise admin who wants to improve the security posture for their server.

Recommendations

Enterprise

1. Two-Factor Authentication Should Be Enforced For The Group
2. Forking of Repositories to External Namespaces Should Be Disabled
3. Group Should Enforce Branch Protection
4. Webhooks Should Be Configured To Use SSL

Members, Access Control and Permissions

1. Two Factor Authentication Should Be Enabled for Collaborators
2. Two Factor Authentication Should Be Enabled for External Collaborators
3. Admininistrators Should Have Activity in the Last 6 Months

Repository

1. Project Should Be Updated At Least Quarterly
2. Default Branch Should Require Code Review
3. Project Should Require All Pipelines to Succeed
4. Repository Should Not Allow Review Requester To Approve Their Own Request
5. Default Branch Should Be Protected
6. Default Branch Should Not Allow Force Pushes
7. Default Branch Should Require Code Review By At Least Two Reviewers
8. Merge Request Authors Should Not Be Able To Override the Approvers List
9. Project Should Have Fewer Than Three Owners
10. Webhook Configured Without SSL Verification
11. Project Should Require All Conversations To Be Resolved Before Merge
12. Default Branch Should Require All Commits To Be Signed
13. Repository Should Not Allow Committer Approvals
14. Default Branch Should Limit Code Review to Code-Owners
15. Forking Should Not Be Allowed
16. Default Branch Should Require New Code Changes After Approval To Be Re-Approved

Operations

General Recommendations:

• Group Membership Should Be Limited to Organization Staff When Relevant.
• Review Security Policies and Procedures At Least Annually.
• Establish a Clear Communication and Incident Response Plan.
• Conduct Regular Security Audits and Vulnerability Assessments.
• Use Tools Built On APIs to Automate Tasks and Avoid Needing Elevated Privileges.
• Review the Configuration Settings Before Making a Repository Public.
• Review the Configuration Settings After Transferring a Repository into the Organization.
• Provide Automated Alerts and Tooling to Ensure Ongoing Compliance.
• Review Audit Events to Track Activity and Changes in Projects and Groups.

Specific Recommendations:

• Two-Factor Authentication Should Be Enforced For The Group
• Group Should Use Single-Sign-On
• Only Admins Should Be Able To Create Public Projects and Groups.
• Webhooks Should Be Configured To Use SSL

This site is open source. Improve this page.