Secure your Repository

Securing your repository is essential to maintain the integrity and confidentiality of your code base. This guide covers the practices for implementing robust access controls, enforcing branch protection, securing secrets, and using groups efficiently within GitLab.

Implement Access Controls

Establishing strong access controls is fundamental for repository security.

Properly configured permissions ensure only authorized individuals can perform sensitive actions like pushing code, merging changes, or altering project settings.

• Role-Based Access Controls (RBAC): Assign roles such as Guest, Reporter, Developer, Maintainer, or Owner based on the principle of least privilege.
• Least Privilege Principle: Limit user permissions so they have only what is necessary for their duties.
• Regular Reviews: Conduct periodic reviews of user access rights to align with shifting project requirements.
• Timely Deactivation: Promptly remove or deactivate accounts for users moving off the project or leaving the organization.
• Expiration Dates: For contractors or temporary access, set expiration dates to automatically revoke permissions when no longer needed.
• Avoid Owner Permission Proliferation: Minimize the number of users with Owner permissions to preserve project and group integrity.

Make use of GitLab’s visibility settings (Private, Internal, Public) appropriately.

• Public projects should be avoided to prevent unauthorized access;
• Internal use only for Inner Source initiatives shared within Thales;
• by default, all projects should be Private to maximize confidentiality and protect your assets.

Group Management

Group Hierarchy

Design your GitLab group hierarchy primarily around access control needs and project ownership, not organizational charts.

Create groups and subgroups only when they serve a clear purpose for permissions management.

Key Principles:

• Purpose-driven levels: Each hierarchy level should have a specific access control or ownership function.
• Avoid unnecessary nesting: Don’t replicate your entire org chart if it doesn’t serve permission management.
• Team-centric ownership: Group projects by who needs to maintain and access them.

Additionally, ensure that you use consistent and clear naming conventions for your groups and projects. This will facilitate easier navigation and collaboration across your organization.

project A/ 
├── Team 1
│    ├── component
├── Team 2
│    ├── component
project B/ 

User Groups

Instead of managing user access individually project by project, leverage GitLab’s groups to streamline and secure permission management at scale.

Enforce Branch Protection

Protect critical branches such as main, develop, and release branches to prevent accidental or unauthorized changes.

Enabling branch protection ensures that all changes go through the proper review and approval process.

• Allowed to Merge: Configure which roles, users, or groups can merge into protected branches—typically limited to Maintainers or specific teams.
• Allowed to Push: Restrict push access to only those who absolutely require it, such as Maintainers for hotfixes.
• Code Owner Approval: Require approvals from designated Code Owners for specified files or directories before merging.
• Enforce Signed Commits: In the repository settings, enable Signed commits for protected branches to help ensure all commits are verified and attributable.
• Branch Rules: Prevent force-pushes and deletion of protected branches.
• Require Merge Requests: Enforce that all changes go through Merge Requests and enable required approvals.

Code Owners and Approval Workflows

Assigning Code Owners to critical parts of your codebase ensures eyes on every change.

Code Owner approval can be made mandatory for Merge Requests that touch specific files or directories.

• Set up a CODEOWNERS file in your repository.
• Configure the project to require approval from Code Owners before merging.
• Combine this with review rules, so sensitive or high-impact code always gets the necessary oversight.

Secure Your Secrets

Secure your Source Code

❌ Never Store Secrets in Code:

• Hardcoded credentials in source files
• Configuration files committed to Git (.env, credentials.json, secrets.yml)
• API keys or passwords in comments or documentation
• Secrets in commit messages

✅ Repository Configuration Practice:

• Add .env, *.pem, *.key, credentials.* to .gitignore
• Never commit .env files—use .env.example with placeholder values instead
• Use .gitignore templates appropriate for your language and framework

Secure your Pipelines

Your CI/CD pipelines often require sensitive data, such as API keys, credentials, or tokens. Use GitLab’s masked and protected secret variables to securely manage these secrets.

Please follow these practices:

• Descriptive Naming: Use meaningful variable names to clarify purpose.
• Protect and Mask All Secrets: Set secret variables as protected and masked to prevent leaks.
• Use Environment Scopes: Apply environment scopes to restrict secrets to staging, production, or other environments as needed.
• Never Hardcode Secrets: Do not store secrets in code or configuration files. Always use secured environment variables or secret managers.
• Scan for Exposed Secrets: Regularly scan your codebase and commit history for accidental secret exposure using GitLab’s Secret Detection or third-party tools.
• Avoid echo or log secret values in pipeline output

Removing Exposed Secrets

If a secret has been accidentally committed:

• Revoke and Rotate the exposed secret immediately.
• Inform your Product Security Officer or designated security contact as soon as possible.
• Purge the Secret from History: Refer to the official guide for removing secrets from Git history.