Signed commits show that a commit was signed by a verified key, and required status checks show that named checks passed. Neither shows that the code is safe or the change is intended. Treat them as evidence about process and identity, and pair them with human review.
Myth versus fact
| Claim | Reality |
|---|---|
| Signed commits mean the code is safe | They show a signature verified, not that the content is correct or benign |
| Required checks mean the change is reviewed | Checks are automated. They do not replace a person reading the diff |
| Anyone can bypass checks, so they are pointless | Settings can restrict the source of a check and who bypasses rules |
| One approval from the author is fine | Approvals should come from someone else |
What signed commits do
GitHub's rules reference says that when required commit signing is enabled on a branch, every commit that contributors and bots push must be signed and verified. That helps with attribution: it is harder for someone to push a commit pretending to be a colleague.
What it does not do is judge the commit. A legitimate engineer with a verified key can sign a bad change. A compromised laptop with the signing key can sign a malicious one. The signature is a statement about who, not about what.
What required status checks do
GitHub states that required status checks ensure all required CI tests pass before collaborators can change the branch. They can be checks or statuses, and the commit status API lets external services set statuses.
The reference also includes a point that is easy to miss. Any person or integration with write permission to a repository can set the state of any status check, but you can choose to accept a check from one specific GitHub App. With that option, a status set by any other person or integration will not allow merging. If you leave the source as any source, you can still verify the author of each status in the merge box.
So a check is as trustworthy as its source and the people who can write to the repository.
Strict or loose checks
GitHub describes two kinds. Strict checks require the branch to be up to date with the base branch before merging, which is the default behavior, and may mean more builds. Loose checks do not require this. For a payments repository the stricter choice reduces the chance that two individually passing changes break each other after merging, at the price of more rebuilds. Decide deliberately.
Where each control sits in a release story
- Identity: signed commits, and multifactor authentication on accounts.
- Review: required approvals and code owner review.
- Automation: required status checks from a named app.
- Safety: force pushes blocked, so approved history stays approved.
- Approval to deploy: environment reviewers.
No single item carries the argument. The combination does.
What to say to a reviewer
Be precise. "All commits to the release branch are signed and verified, checks must pass from our CI app, and changes need approval from the owning team" is accurate. "Our code is verified secure" is not supported by any of these controls.
Practical setup tips
- Document how engineers set up signing and what happens when a key is lost or an engineer leaves.
- Pin the source of required checks to your CI app where your plan allows it.
- Review the list of people with write access regularly.
- Remember that signing does not scan for vulnerable dependencies, so add a dependency review check separately.
Where Safeguard fits
Safeguard adds vulnerability and dependency checks as policies and gates on pull requests, so a signed commit that adds a flawed library still gets flagged. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and see how signing, checks and approvals each appear as separate conditions.
Quick check
Do signed commits stop malicious code?
No. They help attribute a commit to a verified key. The content still needs review and checks.
Can a status check be faked?
Anyone with write permission can set a status, but you can restrict a required check to a specific GitHub App as its source.
Sources
Last reviewed: 19 October 2026.
