Kulkan's checklist for Self-hosted GitLab instances

Category	OWASP CI/CD Risk	Required Privileges	Description	How to test it?	References
Authentication	CICD-SEC-7	None / Administrator	Self Registration status Self registration should be disabled for secured environments. By default, in self-hosted instances users can create their own accounts.	Blackbox: 1. Access the GitLab instance and go to "/users/sign_up". 2. Try to create a new account. Whitebox: 1. Go to the menu in the left, select Admin. 2. Select Settings > General. 3. Click Sign-up restrictions and check the value of the "Sign-up enabled checkbox".	GitLab Sign-up restrictions documentation
Authentication	CICD-SEC-2	None / Administrator	Domains allowed to register a new account If self-registration is possible, it is recommended to only whitelist trusted domains. Otherwise users can register with personal e-mail addreses not compliant with the accepted security policy.	Blackbox 1. Attempt to register with a non-trusted (e.g. gmail) e-mail account. Whitebox 1. Go to the menu in the left, select Admin. 2. Settings -> General. 3. Sign-up restrictions. 4. Check if the allowlist is enabled.	GitLab E-mail allowlist / denylist documentation
Authentication	CICD-SEC-7	None / Administrator	E-mail confirmation status E-mail addresses using during sign-up must be confirmed. E-mail confirmation must be set in hard.	Blackbox 1. After account creation verify if e-mail verification is mandatory and has to be performed right after account creation (hard confirmation). Whitebox 1. Go to the menu in the left, select Admin. 2. Settings > General. 3. Expand Sign-up restrictions. 4. Under Email confirmation settings, select Hard.	GitLab E-mail confirmation documentation
Authentication	CICD-SEC-2	None / Administrator	2FA/MFA enforcement Multifactor-Authentication should be enforced for all accounts. Additionally, the window to delay the configuration of MFA should be as lower as possible.	Blackbox During the account creation process verify that MFA/2FA is mandatory. Whitebox: 1. Go to the menu in the left, select Admin. 2. Select Settings > General. 3. Expand Sign-up restrictions. 4. Check that Ensure that Two-factor authentication (2FA) is selected.	GitLab 2FA documentation
Authentication	CICD-SEC-2	None / Administrator	Strong password policy Enforcing strong passwords make bruteforcing attacks less efective. The password policy should be in compliance with the company's guidelines.	Blackbox: 1. When creating a password attempt to use a weak one. Whitebox: 1. Go to the menu in the left, select Admin. 2. Select Settings > General. 3. Expand Sign-up restrictions. 4. Review requirements under "Minimum password length (number of characters)" 5. Review requrements under "additional password complexity requirements".	GitLab Password complexity documentation
CI/CD (runners)	CICD-SEC-5	Developer	Available Instance runners Having instance runners is not a vulnerability per-se, but it opens up the posibility for further testing and potential exploitation. For ideas check the articles in the references. Ideas to consider: - Shared runners should not be used for different levels of security. - Depending on the runner configuration, malicious users could be able to poison it and access any file/secret that is stored during the pipline's execution.	Low privileged account (Developer user): 1. Create a new project. 2. Go to Settings -> Pipelines. 3. Go to Runners. 4. Check if there is available runners on "Assigned project runners".	Breaking Into GitLab: Attacking and Defending Self-Hosted CI/CD Environments OMGCICD - Attacking GitLab CI/CD via Shared Runners
CI/CD (runners)	CICD-SEC-5	Developer	Gitlab Runner OS user It is important to check what OS user is being used to run Gitlab's Runner. Highly priiveleged users or 'root' are discouraged.	Low privileged account (Developer user): 1. Create a new pipeline with a job that executes whoami and id. 2. Validate the result afte job execution, user should not be root. 3. Check what groups the user has assigned.	Security for self-managed Runners
CI/CD (runners)	CICD-SEC-5	Developer	Runner Executor being used Executors allow the creation of builds in different environments (Locally, Docker, and so on). Depending on the executor being used, different tests and post-exploitation techniques can be performed.	Low privileged account (Developer user): 1. Create a new project and check what preconditions apply to execute jobs in any available instance runner (tags, branch names, etc). 2. Create a new pipeline that, at least, executes: - whoami - uname -a - ip a / ifconfig 3. Review results to determine the executor being used (Docker, Shell, etc)	Security risks for each type of executor
CI/CD (runners)	CICD-SEC-5	Developer	Runners network connectivity and isolation It is important to determine how the Runner's host is connected to the rest of the environment. It is recommended that Runners are as isolated as possible from the rest of the network, with limited connectivity, following the principle of least privilege.	Low privileged account (Developer user): The easiest way to perform this test is to first obtain an interactive shell in the runner (direct or reverse) and attempt to connect to an external host or perform a network scan to find other targets. If this is not possible, try to establish network connections whitin the workflow to controlled hosts, for example using curl. The idea here is confirming that the Runner has outbout connectivity. Consider that the Runner can be able to access some hosts to pull dependencies and other artifacts, but these hosts should be whitelisted.	Runners network segmentation
CI/CD (runners)	CICD-SEC-5	Developer	Network connectivity from Runner's host Outbound connection from hosts running the GitLab Runners should be evaluated depending on the use case. Runners used for production environments should have whitelisted outbound connectivity unless strictly required (e.g. dependencies of the deployment tool).	Low privileged account (Developer user): 1. Create a job that attempts to make a connection to an external host (such as www.google.com). 2. Verify if the connection is successful. 3. If it is, attempt to make a connection to other sites such as pastebin, discord, ngrok, etc.	Security for the Docker Executor
CI/CD (Variables)	CICD-SEC-3	Developer	CI/CD Variables permissions and visibility Secrets and CI/CD variables visibility should be reviewed on a per-project level. In a more granular approach on a per-envaronment level.	Low privileged account (Developer user): 1. Go to the project Settings > CI/CD. 2. Expand the Variables section. 3. Check the Variables table and review: - If Variables are protected and to what branch. - If Variables are masked. - If Variables have envionment scope limitations.	Post Exploitation: Triaging secrets Feature Flag FF_ENABLE_JOB_CLEANUP
CI/CD (Variables)	CICD-SEC-3	Developer	Accessing CI/CD Variables from a Job Variables used within CI/CD jobs can be sometimes be exposed or leaked through different mechanisms.	Low privileged account (Developer user): 1. Create or modify a pipeline/job that prints the environment variables. Try things like: - env - export - set - printenv 2. Execute the job and review the output in the Job's log.	CI/CD Variables
Projects	CICD-SEC-8	Developer	Public projects Public projects allow anonymous access to the project's repository and code.	Low privileged account (Developer user): 1. Browse the GitLab instance to determine if there are any Public projects. 2. Click "Explore projects" or access the "/-/explore" URL to browse them. 3. Review if there are projects that should not be public (e.g. if they have company information, credentials, secrets, proprietary code).	Visibility and control access