PR Review
Scope a run to a diff: changed trust boundaries and dataflows, new or weakened controls, and a verdict of verified blocker, known risk, or no evidence-backed regression.
The instruction
A pull-request review scopes the run to a diff. The evidence contract is unchanged: a changed line is a location, not a finding.
Use SecHelix to security-review the current pull request/diff.
Map changed trust boundaries and dataflows, identify new or weakened controls,
verify important candidates, and state whether the PR introduces a verified blocker,
known risk, or no evidence-backed security regression.Review this PR with SecHelix.
Identify newly introduced trust-boundary, authorization, injection, secrets, supply-chain,
state-machine, race, privacy, or release risks.
Verify important candidates against the changed dataflow and existing controls.
Do not report grep-only suspicions as vulnerabilities.What a diff review covers
The diff is the starting point, not the boundary. A changed function that removes an ownership check affects every caller, so the review has to follow the dataflow out of the diff and back into the existing controls.
- Trust boundaries the change crosses or moves.
- Dataflows that gain a new source or a new sink.
- Controls that were removed, weakened, or made conditional.
- New dependencies, new workflow steps, and new secrets usage.
- State-machine transitions that gained a new path or a new terminal state.
- Configuration and release changes that only take effect in a production build.
The three verdicts
| Verdict | What it means for the PR |
|---|---|
| Verified blocker | A candidate survived independent verification and reaches a release-blocking severity under the active policy. |
| Known risk | A real weakness with a documented owner, reason, and expiry, accepted under the risk-acceptance rules. |
| No evidence-backed regression | Candidates were raised and refuted, or none reached the evidence bar. This is not a claim that the PR is perfect. |
Diff-specific traps
- A moved file reads as a large diff and a small change, or the reverse. Revalidate the property rather than the line count.
- A refactor can preserve behaviour while relocating the enforcement point out of the canonical boundary.
- Source-text assertions are weak when the behaviour can be tested. If a refactor moves code, revalidate the property before updating a source assertion.
- A green typecheck on the diff says nothing about the production build or the browser bundle.
- Grep-only suspicions are the most common false positive in PR review. Establish reachability and attacker control first.
Running it in CI
Pull-request automation has its own safety rules. Private policies, provider credentials, and signing identity must never be exposed to forked pull request code, and external scanner artifacts are treated as untrusted input.