The ultimate guide to securing your code on

May 31, 2023 · 6 min read
Steve Grossman GitLab profile

A critical aspect of a DevSecOps methodology is to apply best practices to secure your development environment. Your software should be protected from malicious and accidental exposure or modification. This blog explains how to control and manage access to and, in turn, source code, build pipelines, dependency and package repositories, and deployment keys involved in the software supply chain. The best practices specifically address the capabilities for end users on multi-tenant and are written for the Ultimate license tier. Not all of these capabilities are available at the Premium tier.

1. Group settings

Many security-related settings can be set on the top-level group and will cascade down into all subgroups and projects. They are the easiest and most important in securing your instance.

General settings

In the top-level group, the following settings should be applied to provide the best security for the code within that group:

Make the group visibility level private

This is likely the most important setting among general settings. By marking the group “private", anyone who is not explicitly a member of the group will not be able to access it. Additionally, by making the top-level group private, all subgroups and projects will also be private and cannot be exposed.

Permissions and group features

Under permissions:

Merge request approvals

Merge request approvals help prevent injection of malicious code into the repository by having people other than the author review them. Enable merge request approvals for all projects in your group to:


To more tightly control who can access your code in, set up SAML SSO. This will ensure that everyone who accesses it is approved by someone in authority.

To configure SAML SSO:

2. Group auditing and compliance

Regularly and periodically review the compliance reports to verify who is approving merge requests and what MRs are getting approved.

Set up streaming group audit events to your corporate security information and event management (SIEM) system and monitor them for unusual activity. This needs to be repeated for each group and project in the hierarchy to get the maximum number of audit events.

3. Group-level push rules

Setting restrictive push rules at the group level will help ensure malicious code is not injected into the repository:


The following settings can help insure the integrity of CI/CD pipelines and reduce the opportunities for abuse and malice:

4. Project settings

Some settings do not cascade down from the group or are not available at the group level and must be set on individual projects instead. These include some repo-specific settings.


Set up protected branches and protected tags to go along with the protected runners and protected variables defined above.



Protected environments

Use protected environments and tightly limit who can deploy and require approvals for deploying.

Token access

Restrict access to this project’s CI_JOB_TOKEN to only individual projects to ensure malicious projects to not retrieve the token and use it to access the API.

Secure files

Store keystores, provisioning profiles and signing certificates in the Secure Files storage rather than the repository.

5. Project-level security testing and compliance


Security testing


As an alternative to the security testing section above, you may choose to enable scan execution policies. Enable test scan result policies to prevent merging code with critical vulnerabilities.

Following these best practices will help ensure that your code hosted on is safe from tampering and public exposure and that your software supply chain is secure and only authorized users are accessing your software assets.

More resources

“This in-depth tutorial, complete with best practices, walks you through step-by-step how to secure your development environment.” – Steve Grossman

Click to tweet

Edit this page View source