# External collaborator push access is restricted

- Source: https://support.icompaas.com/support/solutions/articles/a_1781201409443641-external-collaborator-push-access-is-restricted
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Version Control System (VCS)](https://support.icompaas.com/support/solutions/c_1781179095087930) › [Gitlab](https://support.icompaas.com/support/solutions/folders/f_178117912544158)
- Last updated: 2026-06-12
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This check verifies that external users, contractors, guests, or non-project members are not permitted to directly push changes to the repository's default branch. Access should be restricted so that code changes are submitted through merge requests and reviewed before being merged.

  

Rationale:

Allowing external collaborators to push directly to critical branches increases the risk of unauthorized changes, accidental modifications, and bypassing established review processes. Restricting push access helps enforce change management controls, maintain code integrity, and reduce security risks.

  

Impact:

Restricting push access may:

-   Prevent external users from directly committing to protected branches.
    
-   Require contributors to submit merge requests for code changes.
    
-   Improve code quality through peer review.
    
-   Reduce the risk of unauthorized or unreviewed modifications.
    

  

Default Value:

Depends on project configuration.

In GitLab, external collaborator push access is controlled through:

-   Project membership roles.
    
-   Protected Branch settings.
    
-   Group-level permissions.
    

By default, users with sufficient project permissions may be able to push unless branch protections are configured.

  

Remediation:

Test Plan:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the project.
    
3.  Select Settings → Repository.
    
4.  Locate the Protected Branches section.
    
5.  Identify the default branch (for example, main).
    
6.  Verify the following:
    

-   The branch is protected.
    
-   Allowed to push and merge is set to No one or Maintainers only.
    
-   Developers, Guests, and external users are not allowed to push directly.
    

8.  Navigate to Manage → Members.
    
9.  Review project members and their assigned roles.
    
10.  Verify that external collaborators do not have Maintainer or Owner privileges.
     

  

Implementation:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the project.
    
3.  Select Settings → Repository.
    
4.  Expand the Protected Branches section.
    

5.  Configure the default branch:
    

-   Allowed to push and merge: No one (recommended).
    
-   Allowed to merge: Maintainers.
    

6.  Save the configuration.
    
7.  Navigate to Manage → Members.
    
8.  Review external users and contractors.
    
9.  Assign the minimum required role (Guest, Reporter, or Developer as appropriate).
    
10.  Ensure external collaborators are not assigned Maintainer or Owner roles.
     

  

Backout Plan:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to Settings → Repository.
    
3.  Expand the Protected Branches section.
    
4.  Modify the push permissions to their previous values.
    
5.  Navigate to Manage → Members.
    
6.  Restore previous user roles if approved.
    
7.  Save the changes.
    

  

References:

-   [https://docs.gitlab.com/user/project/members/](https://docs.gitlab.com/user/project/members/)
    
-   [https://docs.gitlab.com/user/project/protected\_branches/](https://docs.gitlab.com/user/project/protected_branches/)
    
-   [https://docs.gitlab.com/user/permissions/](https://docs.gitlab.com/user/permissions/)
    
-   [https://docs.gitlab.com/user/project/repository/branches/protected/](https://docs.gitlab.com/user/project/repository/branches/protected/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.