Signing code commits
Last updated: 26 November 2024
Signing code commits means that each developer has a private/public key pair assigned to them, usually this is generated by the developer on their local machine using a key generation tool. The private key is kept secret on the developers machine and the public key is deployed to their account with the source code management system (e.g. GitHub, GitLab or Bitbucket). When commits are pushed, they are digitally signed using the private key, and then verified by the source code management system. Subsequently, anyone viewing the commit in the repository will be able to cryptographically verify that the commit they are looking at was authored and signed by the developer that committed the change.
When commit signing is not enforced, it is feasible for code to be committed with author information other than that of the developer committing the change. It is essential that all code changes can be correctly attributed to the developer that made the change, i.e. that they are traceable, auditable and enable accountability.
Requirement(s)
- All code commits MUST be cryptographically signed by the author of that commit
- All Source code repositories MUST require all commits be signed
All code commits MUST be cryptographically signed by the author of that commit
Guidance on configuring git commit signing with common source code management systems is available as below.
- Git tools - Signing your work
- GitLab - Signed commits
- GitHub - Signing commits
- Bitbucket - Using GPG keys
All source code repositories MUST require all commits be signed
While commit signing can often be enforced in the global configuration of source code management systems, this is not always implemented. Engineering teams must ensure that all of their repositories are configured to require commits be signed. Guidance on configuration for common source code management systems is available as below.
- GitHub - requiring commit signing with branch protection rules - generally, this should be configured for the main branch at minimum. Dependent on your branching and release strategies it may need to be configured more widely, to ensure that only signed commits are promoted to higher environments
- Bitbucket - using repository hooks - Bitbucket has default hooks for verifying committers and commit signatures
- GitLab - push rules - the ‘Reject unsigned commits’ rule should be enabled. Be sure to understand how this rule behaves with the GitLab UI and Web IDE