Gitlab is an open-source power player in the SCM market, with the entire company working remotely across 65+ countries.
Over the last few years, GitLab’s feature set has expanded into numerous adjacent verticals ranging from code security analysis to application deployment automation. GitLab 13, the latest release that launched May 22nd, continues that expansion. Typically, when features sets expands, so do problems, so it’s always better to review and update security settings.
Authentication & Access
The default authentication method to Gitlab’s web platform is done with standard credentials, a username and password. Since the username is public, it is highly recommended that you implement a more secure authentication flow since once attackers, armed with your username, locate the password to an account (using social engineering, data from prior breaches ,etc.) they can login and gain user access to your SCM.
2-Factor Authentication:
If you haven’t already, the most basic option that should be a company de facto policy, is to require that all teams, employees and contractors use 2FA:
Go to: GroupName -> Settings – > General -> Permissions, LFS, 2FA
Read more about enforcing 2FA on Gitlab.
Limit Access to Specific IP Addresses:
You can restrict access to your organization’s assets by configuring a list of IP addresses that are allowed to connect by setting the “IP allow list” configuration.
Go to: GroupName -> Settings – > General – > Permissions, LFS, 2FA
SSO:
SAML authentication for your organization through an identity provider is available for Gitlab groups from the silver package.
GroupName -> Settings – > SAML SSO
Access Expiration:
Gitlab offers an option to set an expiration date for access permissions.
On the same form where the access is granted, you can specify an expiration date which will expire the permissions.
This is great for contracts that have specific timelines and saves you from needing to remember to go back and revoke the access later on.
Project Access
Base Permissions:
Access can be granted in Gitlab either through groups or specific projects. If a member is added to a group, the member will have the same access level to all the group’s projects.
There are five permission levels in Gitlab with a simplified abstraction:
- Guest – Can see public and internal project’s repositories code. Can see SDLC related data except code on all projects with access.
- Reporter – Have access to all the project’s data but can’t write to the repository.
- Developer – Have read/write access to all the project’s data.
- Maintainer – Adds some configuration and management functionality including adding members.
- Owner – Full configuration and management functionality.
If a user is both in a project’s group and the project itself, the highest permission level is used.
Group Member Lock:
Project -> Settings -> General -> Permissions, LFS, 2FA
This will disable the option for all users who previously had permissions to operate project memberships, so no new users can be added. Furthermore, any request to add a new user to a project through the API will be rendered impossible.
View Permissions:
To view a groups members and their permission, simply click the members section on the group page and you can see all the different permissions granted for the team
To view the permissions of a project, go to settings on the projects main page and then click the members sub menu.
Leak Prevention
Disable forking:
Forking is the act of creating a copy of the repository. Forking is meant to allow developers to create a copy where they can experiment on the code without affecting the original repository.
From a security perspective there are two main issues with forking. The first is that the more forks there are for a repository the harder it is to keep track of the security of each fork, and the problem of securing the repository grows exponentially the more forks a repository has. The second is that forking can be easily used to create a copy of a repository in a user’s private account.
Forking can be disabled at the project level. In the project settings under general -> Visibility, project features, permissions.
Group and Project Visibility:
Gitlab allows users to control the visibility of projects through two main mechanisms.
Group visibility can be either private or public.
If the group is private all the projects will remain projects, this is the recommended choice if you have no public repositories in that group, as it prevents making errors and creating public repositories.
If the group is a public group, the visibility of its internal projects can be set independently per project.
Gitlab allows for more granular control over the visibility of the project’s components which can be seen in the project’s visibility settings under the general settings section.
Tempering Protection
Protected Branches:
Gitlab allows configuration protected branches, where rules can be enforced to protect the source code under that branch.
The most basic control is requiring code review before allowing developers to commit code to the protected branch, which usually is the master branch.
This will enforce push and merge policy on the main branch.
Another setting related to this issue is the Merge request approvals under the project settings.
Here we can define the policy for approving merge requests. For example if we want 2 users to approve code changes in the master branch, and 1 user to approve code changes to the dev branch we can define something like:
Gitlab has many other controls you can adjust.
Code Security:
Gitlab comes with built-in support for many security related checks.
Under each project you can find the Security and Compliance section.
The Security Dashboard provides a high-level view of vulnerabilities detected in your projects, pipeline, and groups.
GitLab uses the following tools to scan and report known vulnerabilities:
- Container Scanning – Scan Docker containers for known vulnerabilities.
- Dependency List – View your project’s dependencies and their known vulnerabilities.
- Software Composition Analysis – Analyze dependencies for known vulnerabilities.
- Dynamic Application Security Testing (DAST) – Analyze running web applications for known vulnerabilities.
- Secret Detection – Analyze Git history for leaked secrets.
- Security Dashboard – View vulnerabilities in all your projects and groups.
- Static Application Security Testing (SAST) – Analyze source code for known vulnerabilities.
These controls can be configured under the configuration section:
Review Audit Events:
Under the organization settings you can access the audit events and view various events that happened in your gitlab organization.
Periodically review the audit events and make sure that there are no anomalous or suspicious activities.
How Cycode can help protect your source code on Gitlab
Cycode can help with all the above by automatically inspecting the security posture across Gitlab’s various settings. We analyze the actual usage and recommend tightening the access model to fit a least privileged approach. We monitor the SCM activity in real time allowing us to alert on various security related incidents based on the policy that suits your organization.
Bottom line, use this post as your guide to securing your Gitlab SCM and use Cycode to protect your organizations source code wherever it is sprawled
