A verdict about this change.
Findings on a pull request are marked against the base branch. The check tells you what the branch introduced, what it inherited and what it fixed - so review is about what you just wrote, and nobody is asked to fix main to merge a feature.
NEW, UNCHANGED, resolved.
One check run per pull request. Its summary line reads the same way every time: the verdict, how many findings would be introduced by merging, how many were already known on the base branch, and how many this branch fixes.
- NEW
Would be introduced by merging. These are the ones the check is about.
- UNCHANGED
Already on the base branch. Listed once, never raised again on this branch.
- Fixed by this PR
Findings the branch resolves, counted in its favour.
- FAILED when an invariant breaks
A guard removed, a tenant scope dropped, a signature check deleted: the check fails on its own, whatever else the diff did.
- CriticalAdd bulk refund endpoint14 commits · 32 files
- LowBump next to 15.5.71 commit · 2 files
- HighMove uploads to S36 commits · 11 files
- LowCopy changes on pricing page2 commits · 3 files
One push is one unit of work.
Rapid pushes to the same branch are coalesced: A, then B, then C, then D become one change from A to D. Files are classified by what they touch, and a push that only changed formatting is recognised as MINIMAL because the symbols it defines are fingerprinted, not its bytes.
- CLEAN Nothing that runs changed, or nothing the rules object to.
- MONITORED Worth knowing about; nothing to do right now.
- REVIEW A person should read this change before trusting it.
- ACTION_REQUIRED A finding was introduced or an invariant broke.
- MINIMAL
- LOW
- MODERATE
- HIGH
- CRITICAL_CHANGE_SURFACE
A dependency bump is not read with the seriousness of a rewritten auth middleware.
A protection that disappears is a finding.
Most tools only notice what a diff adds. The rule source.authorization.protection-removed notices what it takes away: a guard, a tenant filter, a signature verification that was there on the base branch and is not on this one.
Thirty days of pushes, by outcome.
The overview keeps the last month of change sets by outcome - analyzed, clean, monitored, review, action required - with the average risk and how many high-risk pushes were verified. It is deliberately not a code-quality score; it says how the last thirty days went, not how good the code is.
Off by default. 22 credits when you ask.
A risky push can be read by a model, over the changed files only. It may move an invariant and lift a change from MONITORED to REVIEW; it never creates a finding of its own, and it never runs unless the site has opted in.
- Runtime re-check
A push that touches authentication, authorization, tenancy, the API contract, a webhook, a security control or infrastructure triggers one bounded runtime re-scan.
- Catch-up
When a usage window ends in tracking-only mode, the pushes that were only recorded are analyzed when the next window opens.
- Non-default branches
Tracked, and analyzed when they open a pull request. Commits on them are stored, not scanned on every push.
- Written back to GitHub
The verdict lands where the team already reviews code: a check run on the pull request, with the same wording as the app.
Install it on one repository.
Connect the GitHub App to one site. The next pull request gets a check; the base branch is never held against it.