Requiring signed commits from contractors is worth it when you want a cryptographic link between each commit and a key its author controls. It does not prove the code is safe or that the person is who they claim to be. Treat it as an attribution control that sits beside review.
What a signature proves
GitHub says that if a commit or tag has a GPG, SSH or S/MIME signature that can be cryptographically verified, it is marked "Verified" or "Partially verified". If a signature cannot be verified, the commit is marked "Unverified". When a signature is verified at push time, GitHub stores a verification record alongside the commit. That record cannot be edited, and it persists so signatures stay verified even if keys are rotated or revoked, or contributors leave the organization.
So a verified commit tells you the commit was signed by a key registered to that account. It supports attribution: who authored this, and was it pushed by someone holding that key. It says nothing about intent or quality.
The three outcomes you care about
| Outcome | Signed commits help | Signed commits do not help |
|---|---|---|
| Spoofed author name in git history | Yes | |
| Review of what the code does | Right, you still need review | |
| A malicious but legitimate contractor | Right, signatures are valid for bad code too | |
| Investigation after an incident | Yes, clearer attribution | |
| Stolen contractor laptop with key loaded | Partly, key is theirs | Attacker can sign as them |
How to require them
GitHub lets you enable required commit signing on a protected branch. Once on, contributors and bots can only push commits that are signed and verified. If someone pushes an unsigned commit to such a branch, they must rebase to add a verified signature and force push the rewritten commit.
For contractors, the practical steps are:
- Choose a signing method. GitHub notes SSH signatures are the simplest to generate and that you can reuse an existing authentication key as the signing key. GPG offers keys that can expire or be revoked.
- Give contractors a short setup guide with commands for their operating system.
- Test with one contractor before enforcing for everyone.
- Turn on the rule for protected branches, not every personal branch.
- Decide what happens with bots, such as a dependency update tool. They need signatures too, or an agreed exception.
Friction you should expect
Agencies often work from several machines and share CI users. Signing keys then multiply, and the first week produces support tickets. Budget for that. Also test how your merge strategy interacts with the rule on a throwaway repository before you enforce it.
When it is not worth it
For a one week task on a low risk repository, the setup cost can exceed the benefit. Required review, branch protection and a clean offboarding matter more. If you must choose one control for contractors, choose review.
Use it with the rest
- Require pull request review so that signed commits are also reviewed, as in branch protection rules worth enabling.
- Dismiss stale approvals when new commits are pushed.
- Keep a list of which key belongs to which contractor, and delete the key from the account at exit.
- Add attribution evidence to your offboarding checklist.
Safeguard's policies and gates apply checks to every pull request regardless of whether commits are signed, and its compliance and evidence automation can hold the records. Try the free scan.
Quick check
Does a Verified badge mean the code is safe?
No. It means the signature checked out. A contractor, or an attacker holding their key, can sign harmful code.
What if a contractor pushes an unsigned commit?
On a branch that requires signatures, the push is rejected. GitHub says they must rebase the commit to include a verified signature and force push it.
Sources
Last reviewed: 19 October 2026.
