Pull request checks
Findings on a branch are compared with its base: NEW is what this change introduced, UNCHANGED is what it inherited.
A check that reports your whole backlog on every pull request gets muted within a fortnight. This one speaks only about the change in front of it.
- NEW
- Raised by this change. This is what the check asks you to look at.
- UNCHANGED
- Already present on the base branch. Listed for context, never used to block you.
- Resolved
- Something this change fixed, confirmed by re-running the rule that raised it.
- Security regression
- A protection that existed before and does not now - raised on its own, with the diff that removed it.
Where the verdict appears
As a GitHub check run on the pull request, where your team already reviews code, and inside the app on the site’s pull requests screen. Updating the branch re-runs the check against the new head.
When a code finding on a pull request matches something the browser pass already proved in production, the check says so. That is the difference between “this looks wrong” and “this is exploitable today”.
Questions
Will the check block my merge?
Only if you make it required in GitHub’s branch protection. By default it reports and lets you decide.
Do checks run on pull requests from forks?
They run with the permissions GitHub grants a fork pull request, which are deliberately narrow. Anything that cannot be read is reported as skipped rather than passed.
Does a pull request scan cost credits?
No. Continuous monitoring, including pull request checks, is included in the plan. Credits are for AI tasks and manual full scans.
Something here wrong, missing or out of date? Tell us and we will fix the page.