# Required commit signatures enforced on default branch

- Source: https://support.icompaas.com/support/solutions/articles/a_1781201391394483-required-commit-signatures-enforced-on-default-branch
- 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 commits pushed or merged into the default branch are required to be cryptographically signed. Commit signatures help verify the authenticity of commits and ensure that code changes originate from trusted contributors.

  

Rationale:

Unsigned commits can make it difficult to verify the identity of contributors and the integrity of code changes. Requiring signed commits strengthens software supply chain security by ensuring that commits can be traced to authenticated users and have not been tampered with after creation.

  

Impact:

Enforcing signed commits may:

-   Require contributors to configure GPG, SSH, or X.509 commit signing.
    
-   Prevent unsigned commits from being pushed or merged.
    
-   Increase administrative effort during initial setup.
    
-   Improve traceability, accountability, and code integrity.
    

  

Default Value:

By default, GitLab does not enforce signed commits on protected branches or the default branch.

Default setting:

-   Reject unsigned commits: Disabled
    

  

Remediation:

Test Plan:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the target project.
    
3.  Select Settings → Repository.
    
4.  Locate the Push Rules section.
    
5.  Review the configured push rules.
    
6.  Verify that commit signature verification is enforced.
    
7.  Confirm that unsigned commits are rejected when pushed to the default branch.
    

  

Implementation:

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

5.  Enable the option to reject unsigned commits (if available in your GitLab edition).
    

6.  Save the configuration.
    

  

Backout Plan:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the target project.
    
3.  Select Settings → Repository.
    
4.  Expand the Push Rules section.
    
5.  Disable the commit signature enforcement rule.
    

6.  Save the changes.
    

  

References:

-   [https://docs.gitlab.com/ee/user/project/repository/push\_rules.html](https://docs.gitlab.com/ee/user/project/repository/push_rules.html)
    
-   [https://docs.gitlab.com/ee/user/project/repository/signed\_commits/](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)
    
-   [https://docs.gitlab.com/ee/user/project/repository/gpg\_signed\_commits/](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/)

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