# External collaborator push access is restricted

- Source: https://support.icompaas.com/support/solutions/articles/a_178120159403873-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) › [GitHub](https://support.icompaas.com/support/solutions/folders/f_1781179116560328)
- Last updated: 2026-06-12
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This control ensures that external collaborators are restricted from directly pushing changes to protected branches within a GitHub repository. Changes to protected branches must be performed through approved workflows and authorized users, reducing the risk of unauthorized modifications to critical code.

  

Rationale:

Restricting push access for external collaborators enforces the principle of least privilege and helps protect repository integrity. This control reduces the risk of accidental, unauthorized, or malicious changes to protected branches and supports secure software development and change management practices.

  

Impact:

-   Prevents external collaborators from directly modifying protected branches.
    
-   Reduces the risk of unauthorized code changes.
    
-   Improves repository security and governance.
    
-   Supports compliance requirements related to access control and change management.
    
-   Ensures changes to protected branches are performed through approved workflows.
    

  

Default Value:

Disabled by default. Repository administrators must explicitly configure rulesets or branch protection settings to restrict direct updates to protected branches.

  

Remediation

Test Plan

1.  Navigate to the target GitHub repository.
    
2.  Verify that a ruleset is configured for the protected branch.
    
3.  Verify that Restrict updates is enabled.
    
4.  Attempt to push changes directly to the protected branch using an external collaborator account.
    
5.  Verify that the push attempt is denied.
    
6.  Verify that the external collaborator is not included in the ruleset bypass list.
    
7.  If direct pushes are permitted, follow the Implementation Steps to remediate the issue and repeat the test.
    

  

Implementation Steps:

1.  Sign in to GitHub with administrative access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Settings.
    

4.  Under Code and automation, select Rules → Rulesets.
    

5.  Create a new branch ruleset or edit an existing branch ruleset.
    

6.  Enter a name for the ruleset.
    
7.  Under Enforcement status, select Active.
    

8.  Under Target branches, specify the branch or branch pattern to protect (e.g., main).
    
9.  Enable Restrict updates.
    

10.  Review the Bypass list and ensure external collaborators are not included.
     
11.  Click Create or Save changes to apply the ruleset.
     

  

Backout Plan:

1.  Sign in to GitHub with administrative access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Settings.
    
4.  Under Code and automation, select Rules → Rulesets.
    
5.  Edit the applicable branch ruleset.
    
6.  Disable Restrict updates or modify the bypass permissions as required.
    
7.  Click Save changes.
    

  

References:

-   [GitHub Rulesets Documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)
    
-   [GitHub Protected Branches Documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches) 
    
-   [GitHub Repository Roles Documentation](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/repository-roles-for-an-organization) 
    
-   [GitHub Collaborators Documentation](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/inviting-collaborators-to-a-personal-repository)

## 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.