A Verified badge means the commit carries a signature that GitHub could cryptographically check. It supports a claim about who signed the change, not that the change is good, reviewed, or free of malicious code. Use it as a small supporting signal alongside review and provenance.
What GitHub says it means
GitHub documents that you can sign commits and tags with GPG, SSH or S/MIME. If a commit or tag has a signature that is cryptographically verifiable, GitHub marks it Verified or Partially verified. The statuses listed include Verified, for a signed commit whose signature was successfully verified, Unverified, for a signed commit whose signature could not be verified, and no verification status, for an unsigned commit.
GitHub also describes persistent verification. Once a signature is verified on push, a record is stored with the commit and it remains verified within the repository network, even if keys later expire, are revoked, or a contributor leaves the organization. That is useful history, with one catch for consumers: a Verified badge reflects the state when verification happened, not today.
What it can tell you
- The commit was signed by a key associated with an account. That makes impersonation by someone with only a pushed email address harder.
- A project that signs consistently has some process discipline.
- If most commits are verified and one is not, that exception is worth a look.
What it cannot tell you
| Claim | Does Verified support it? |
|---|---|
| The author is honest | No |
| The change was reviewed | No. Review is a separate control |
| The account was not compromised | Not reliably. An attacker with the signing key can sign |
| The released package matches the commit | No. That needs provenance on the artifact |
| The key is still trusted today | Not necessarily, per the persistence note |
OpenSSF Scorecard separates these concerns. Its Signed-Releases check looks at release artifacts for signature files or provenance, and Code-Review looks at approvals. Those address different questions from commit signing.
How to use it
Treat signed commits as a bonus for projects you already trust on other grounds. Do not demand signed commits from every dependency, because many healthy projects do not sign. Put your effort into the signals that connect source to artifact: attestations on the published package and a visible, required review.
If you maintain a project, signing commits is cheap and helps readers. Pair it with branch protection that requires review and with a publishing path tied to your build workflow.
Try it yourself
Click through it at your own pace, or open it full screen. It shows checks on a pull request, where a signature would be one check among several.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for pull requests, with SBOM and dependency scanning. A free scan is at gold.safeguard.sh/scan.
Quick check
Is an Unverified commit a red flag?
Not on its own. It may be signed with a key GitHub does not know, or not signed at all. Look at the pattern across the project.
Does signing replace review?
No. Signing shows who made the change. Review checks the change.
Sources
Last reviewed: 19 October 2026.
