Full Pentest vs PR Security Review: What Each One Actually Answers

A full pentest and a PR security review get compared as if one is a lighter version of the other. They are not. They answer different questions, and a team that buys one expecting the other ends up with a blind spot it cannot see.

The question each one asks

A full pentest asks what an attacker can do to this system as it stands. The scope is the agreed target: the application, APIs, authenticated surfaces, infrastructure, or other assets included in the engagement. Its findings are properties of the system as tested.

A PR security review asks something much narrower. Does this change introduce a reachable weakness? The scope is the diff plus whatever the diff touches. Its findings are properties of a change.

Every other difference follows from that one.

What a pentest sees that a PR review cannot

Some flaws do not exist in any single diff. Service A starts trusting a field that service B quietly stopped validating a quarter earlier. Both changes may have been correct in isolation. A narrowly scoped PR review can miss the interaction. Testing the running system across those service boundaries gives you a way to uncover that class of bug.

The same goes for weaknesses that exist outside the repository. A staging environment left reachable, an old API version still answering, a subdomain pointing at infrastructure nobody owns any more. No diff introduced those, so no diff review will surface them.

And some attack paths need sustained effort. Enumerating identifiers across two tenants for a day, chaining a weak redirect into a token leak into privilege escalation. That is deliberate work against a live system, not a judgement about a changeset.

What a PR review sees that a pentest cannot

Everything you ship after the pentest is outside the scope of that specific assessment. If you deploy daily and assess annually, the version tested by the pentest may have been live for only a small fraction of the year. Every subsequent change creates an opportunity for a regression or a new vulnerability that the original assessment could not have evaluated. This is the gap behind most of what startups get wrong about application security.

Regressions on fixes, too. A permission check gets restored during remediation, then refactored back out six weeks later by someone tidying a controller. The original finding is marked resolved. The vulnerability is back.

Then there is cost. Caught on the diff, the fix can often happen before the code ships. Caught in an assessment later, the same issue may require a ticket, a new release, and a retest.y.

Why it matters where the feedback lands

A finding on an open pull request reaches the person who wrote the line, while they still remember why they wrote it that way. The same finding in a report months later reaches whoever owns that service now, with no context and a backlog already full. The technical content is identical. The odds of it being fixed properly are not.

That is the argument for treating security findings as engineering work rather than a document, and for pushing them into Linear, Jira or GitHub where the rest of the work already lives.

Neither one is a scanner

Automated scanners are useful for finding potential weaknesses at scale. SAST identifies insecure code patterns and data flows, dependency scanners flag known vulnerable components, and DAST probes running applications for common weaknesses.

But a potential weakness is not the same as an exploitable one. A missing authorization check, for example, is different from proving that one user can actually access another user's data.

That is where offensive testing adds value. Pentests test the running system from an attacker's perspective, while code-aware PR reviews use the context of a change to focus testing on exploitability before it reaches production. That is why a scanner can pass a codebase that an actual assessment does not.

How they actually fit together

Depth and cadence are different axes, and you need both. A deep periodic assessment reasons about architecture, chains attack paths, and looks at the parts of your system no changeset has touched in a year. A change-triggered review keeps the gap between deploying code and testing it down to hours rather than months.

That is the split in how Borg is built. Mjolnir runs continuous application pentesting against the running system. Gungnir does code-aware review on changes, running targeted micropentests against the diff and surfacing findings in GitHub. They are separate jobs because they answer separate questions.

The failure mode to avoid

Do not use either one as a reason to skip the other. Shipping PR review and dropping deep assessment leaves you blind to everything cross-service and everything outside the repository. Running the annual assessment and nothing else leaves you blind for eleven months of merges. Both are real gaps. They are just different gaps.

The useful question to ask a vendor is not which one they do. It is what happens to your coverage in the weeks between. If you want to see what that looks like against your own application and your own pull requests, book a walkthrough with Borg.