GitLab Configuration Best Practices
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.
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.
- Two-Factor Authentication Should Be Enforced For The Group
- Forking of Repositories to External Namespaces Should Be Disabled
- Group Should Enforce Branch Protection
- Webhooks Should Be Configured To Use SSL
Members, Access Control and Permissions
- Two Factor Authentication Should Be Enabled for Collaborators
- Two Factor Authentication Should Be Enabled for External Collaborators
- Admininistrators Should Have Activity in the Last 6 Months
- Project Should Be Updated At Least Quarterly
- Default Branch Should Require Code Review
- Project Should Require All Pipelines to Succeed
- Repository Should Not Allow Review Requester To Approve Their Own Request
- Default Branch Should Be Protected
- Default Branch Should Not Allow Force Pushes
- Default Branch Should Require Code Review By At Least Two Reviewers
- Merge Request Authors Should Not Be Able To Override the Approvers List
- Project Should Have Fewer Than Three Owners
- Webhook Configured Without SSL Verification
- Project Should Require All Conversations To Be Resolved Before Merge
- Default Branch Should Require All Commits To Be Signed
- Repository Should Not Allow Committer Approvals
- Default Branch Should Limit Code Review to Code-Owners
- Forking Should Not Be Allowed
- Default Branch Should Require New Code Changes After Approval To Be Re-Approved
- 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.