Code review and security review used to live on different teams and different queues. A reviewer watched logic and architecture; a scanner watched injection sinks and unsafe deserialization; a security engineer watched the dependency tree and the SCA dashboard. The pipelines were separate, the dashboards were separate, and the diffs reached them through different paths. That split made sense when most teams reviewed every day and audited once a quarter — but it stops making sense when every PR is the cadence and the same diff is the surface where both signals have to fire. Shift-left AI security review treats them as one pass: the same webhook, the same model context, the same review, and the same follow-up commit on the same branch.
Why code review and security review are collapsing into the same pass
For most of the last decade, code review and security review sat on different teams, with different tools and different review queues. A reviewer watched logic, style, and architecture; a SAST scanner watched injection sinks and unsafe deserialization; a security engineer watched the SCA dashboard and the dependency tree. The packages were different, the pipelines were different, and the diffs landed in different dashboards. That split made sense when security was a quarterly audit and code review was a daily exercise — but it falls apart when the same diff is the surface where both signals have to fire. Shift-left AI security review treats them as the same pass: a single webhook reads the diff, the same diff context flows into both prompts, and the security comment lands on the same line as the style comment, in the same review, under the same app install.
What automated PR vulnerability detection looks like at the webhook surface
Automated PR vulnerability detection has the same plumbing problem as code review: anyone who can hit the webhook endpoint can post a security finding on any repo the app is installed on. The mistake is treating that as a concern for security tools, when it is really the same cheating surface anyone shipping a GitHub App has to defend. We verify every delivery by re-computing the HMAC the GitHub App sent and rejecting mismatches in the route handler — no exception path, no replay tolerance — and every Connection is scoped per user, not per org-wide token. That is the boring half. The interesting half is per-language review config: review.yml lets you turn language-specific security keys on or off per repo, the same way it already turns language-specific lint keys on or off, so the same install runs as a TypeScript reviewer on a TS PR and as a Python reviewer on a Python PR. The webhooks stay the same; the prompt changes with the file extension, and the security findings land on the same lines the lint findings already live on.
Where VeriFlow's PR-level vulnerability detection diverges from sonarqube
Run the same vulnerable PR past VeriFlow and a sonarqube scan and the comparison is no longer about whether one is better than the other — sonarqube's CFG and rule database catch deterministic taint paths VeriFlow does not optimize for, and that is its job. The job VeriFlow's PR-level review does is read the diff in context: a one-line config change that opens an unauthenticated admin route in front of an existing endpoint is the kind of cross-file logic gap a rule-bot scores low and a reviewer scores high. The PR-level review also carries the fix — when an inline comment says the env var is now publicly readable, the same review opens the follow-up commit that narrows the grant, reads the labelled scope in review.yml, and ships the change to the same branch. That is the surface where the two reviews diverge, and where a single review-cycle extracts the most signal for a team that already trusts SAST as a background check.
Related → How VeriFlow compares to sonarqube
Where security review fits in the code-review budget
Running a security pass on every PR is not free; it is a budget line. Most teams today pay for a CI-time SAST scan separately, a separate SCA tool separately, and a separate manual security review as part of release readiness. Bundling the security pass into PR review changes the line item: instead of three tools firing on three schedules, one pass fires on the pull request, the comment lands in the same queue the engineer is already reading, and the follow-up commit can carry both code-quality and security fixes in the same branch. The math is what most teams work through first, and the trade — what kind of reviews you want every PR to get, and which ones you want only on a flagged schedule — is what the Free and Team plans are organized around.
Related → See plans and pricing
Read the full security posture before you install
The full posture — what scopes the GitHub App requests, how redelivered webhooks are handled, what the model never sees outside the PR, how we rotate HMAC secrets, and what audit log we keep — lives on the security page. We document it the same way we ship code: a single source of truth that updates when the integration does, not a quarterly whitepaper with stale claims. Reading it before installing is the fastest way to know whether VeriFlow is a fit for the kind of data your repositories already hold, and the review surface is shaped around that same answer.
Related → Read our security posture