Pull-request security checks vs full-codebase review: why diffs miss serious bugs

Key takeaways

• Pull-request security bots are optimised for speed on small diffs, which makes them useful for catching local mistakes before merge.
• Most high-severity application vulnerabilities emerge from interactions between unchanged files and new code, or from broken security assumptions across components.
• Diff-only tools rarely revisit untouched modules when a helper, middleware or trust boundary changes elsewhere in the repository.
• Running a continuous full-codebase reviewer alongside PR checks gives engineering teams both fast merge feedback and deep architectural coverage.

What are pull-request security bots actually designed for?

Pull-request review tools sit inside GitHub, GitLab or your CI pipeline and inspect the lines added or modified in a branch. Because developers are waiting to merge, a PR check has a strict time and attention budget: it needs to finish in a couple of minutes and leave a handful of inline comments on the changed files.

Within that constraint, PR bots do useful work. They catch hardcoded tokens accidentally committed in a config file, obvious SQL string concatenation in a new query, missing input checks inside the modified function, or a forgotten debug flag.

The problem starts when engineering leaders assume that because every pull request passes an automated check, the codebase as a whole has been reviewed for security vulnerabilities.

Why reviewing only the diff misses architectural vulnerabilities

A pull request is a slice of time, not a security boundary. Most serious vulnerabilities in production software do not live inside a single twenty-line diff. They live in the relationship between the code being changed and the rest of the repository that was not changed in that commit.

When a tool only reads the diff (or the diff plus a few surrounding lines), it lacks three pieces of information:

1. The system’s trust boundaries: Which callers can reach this code path, and what authentication or tenant isolation has already been enforced upstream?
2. Existing security assumptions: Did an older module elsewhere in the repository rely on an invariant that this harmless-looking refactor just relaxed?
3. Sibling consistency: Do twelve other endpoints in this service enforce an ownership check that the new thirteenth endpoint quietly omitted?

Three vulnerability classes that routinely slip past PR review

1. Broken assumptions in untouched callers

Suppose a developer updates a shared path-resolution helper so it follows symlinks or accepts relative segments needed by a new internal feature. The diff inside the helper looks clean and intentional. Meanwhile, an archive extraction handler written two years ago in another package calls that same helper assuming it strictly confines paths to a workspace root. A PR bot looking at the helper diff never reads the archive handler; the archive handler was not modified, so it never triggers a PR scan.

2. Multi-hop trust-boundary confusion

In modern backends, a request often passes through an edge proxy, an HTTP middleware layer, a service layer and a background job queue. A pull request that adds a header fallback in middleware or exposes a new field on an internal struct rarely looks dangerous in isolation. Discovering that an unauthenticated caller can spoof that header to impersonate an organisation owner requires tracing the data flow across all four layers.

3. Missing controls (“absence” bugs)

Diff tools excel at spotting bad code that is present in the diff. They are much weaker at spotting a security control that is absent, unless the requirement is explicitly known. Recognizing that a new state-mutating route forgot to check organisation membership requires knowing how organisation membership is modeled and enforced across the rest of the application.

How Dokima keeps the whole codebase in view as code changes

Dokima is not a pull-request comment bot. It runs as a persistent workspace reviewer on Linux or macOS, either interactively from the terminal dashboard or continuously in the background via a detached service worker.

Instead of treating every commit as an isolated diff, Dokima maintains durable state in .dokima/:

• Explicit security assumptions: Dokima records the security assumptions each component relies on and periodically runs the Component Assumption Verifier against current source to check whether recent commits have invalidated an older assumption.
• Rotated hunting lenses: Across scheduled passes, Dokima rotates specialized hunting lenses (trust boundaries, authz/isolation, injection, secrets, resource abuse) and coverage-improvement stages (such as Sink Completeness Hunter, which checks whether a bug class found in one place also exists in sibling code).
• Automatic Git synchronisation: When running continuously, Dokima can refresh your local Git checkout on a schedule and prioritise components affected by recent changes without losing its map of the wider system.

Using PR checks and full-codebase review together

You do not need to remove fast linters, SAST rules or PR bots to adopt Dokima. In fact, they work best as complementary layers:

• Keep fast checks in pull requests to catch obvious local mistakes before merge.
• Run Dokima continuously on your main or integration branches to uncover cross-file vulnerabilities, verify architectural assumptions, and maintain an up-to-date security report for your engineering team.

For a side-by-side breakdown, see Dokima vs pull-request review bots, or start a 21-day free trial to run a full sweep on your repositories.