Skip to content

Latest commit

 

History

History
81 lines (64 loc) · 4.7 KB

README.md

File metadata and controls

81 lines (64 loc) · 4.7 KB
Raw

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: