Require the same checks for outside contributors as for your own team: build and tests, a dependency check for changed manifests, static code analysis, and one summary gate that fails if any of them did not truly run. Run them without secrets so they work for forks, and add maintainer review for workflow file changes.
Definition: required check
A required status check is a check that branch protection says must pass before a pull request can merge. On GitHub it must pass on the latest commit SHA, and a check from an earlier commit does not count.
The checklist
- Tests with no secrets. Run unit tests on pull_request. Anything that needs credentials runs later, after review.
- Dependency change check. If a pull request touches a manifest or lockfile, review what was added or updated and whether any version has known vulnerabilities. GitHub's dependency review shows added, removed and updated dependencies with vulnerability data, and its action can enforce a result on the pull request.
- Static analysis. Scan the changed code for common weakness patterns. It does not execute the contributor's code, so it suits untrusted input.
- Workflow file protection. Require review from designated owners for the workflows directory.
- Summary gate. One job, run with always(), that fails if any needed job failed or was skipped.
- Up to date requirement. Choose whether the branch must be current with the base before merge, so the checks ran against the real merge result.
Which checks run for first-time contributors
For public repositories, a first-time contributor's workflows may wait for maintainer approval. Until approved, the required checks stay pending, which is the intended behavior. Once a maintainer approves, they run. GitHub's guidance is to look at the changes first, especially anything touching workflow files.
For private repositories, fork pull request workflows run when enabled in repository settings.
Choosing blocking versus warning
Not every finding should block. A reasonable split:
| Finding type | Suggested action |
|---|---|
| Failing tests | Block |
| New dependency with a known critical vulnerability | Block |
| Style or low severity code issue | Warn |
| Workflow file change by an outsider | Block until owner review |
Tune this to your project. A strict gate that nobody trusts gets bypassed, and bypassed gates protect nothing.
Keep contributor experience in mind
Outside contributors give you time for free. Explain in CONTRIBUTING what checks run and how to fix common failures, and keep messages specific. A comment that names the file and the rule beats a red cross.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how each check feeds one decision on the pull request.
Where Safeguard fits
Safeguard combines dependency scanning, SBOM generation and policy gates on pull requests, and its reachability analysis helps separate vulnerable code that is called from code that is merely present. The free scan is a quick way to see results.
Quick check
Should outside contributors face different checks than staff?
The checks can be the same. What differs is trust: no secrets, approval before first runs, and owner review for workflow changes.
Can a check from an older commit satisfy a required check?
No. On GitHub, required checks must pass on the latest commit SHA.
Sources
- Troubleshooting required status checks, GitHub Docs
- About dependency review, GitHub Docs
- Approving workflow runs from forks, GitHub Docs
- Events that trigger workflows, GitHub Docs
Last reviewed: 19 October 2026.
