Branch protection requires a review before merge. Your audit evidence shows one on every pull request for the last year. What it does not show is whether any of those reviews involved a person reading the code, and for a meaningful share of pull requests at most companies, they did not.
A required approval and a reviewed change are not the same claim, and the gap between them is invisible to every tool that only checks whether the checkbox is ticked.
This post is what actually undermines the review control, separately from whether it exists. For whoever relies on "we require code review" as evidence that changes get checked.
The three ways the checkbox gets satisfied without a review happening
Reciprocal approval. Two engineers approve each other's changes as a matter of course, on a cadence that has nothing to do with reading the diff. This is not malicious; it emerges naturally on a small team where everyone trusts everyone, and it produces a required approval on every change with review actually happening on very few of them.
Approval on request, before the diff is even open. A message asking for a quick approval, sent and granted inside a minute, for a pull request with three hundred changed lines. The timestamp gap between the approval and the pull request's creation is the tell, and it is trivial to compute and almost nobody looks at it.
Self-approval through an alternate identity or a bypass path. A second account, a personal token with merge rights, or an administrator role that skips required reviews entirely. Platforms differ in whether administrators are included in required-review enforcement by default, and the default is frequently that they are not, which means the people with the most access are the ones for whom the control may not actually apply.
Why this matters more than it looks
The consequence is not merely that some bugs slip through. It is that your evidence of a working change control is fabricated by the process itself, which is a worse position than having no control, because an auditor, a customer's security team, or your own incident review will trust it.
A vulnerability introduced through a rubber-stamped review is, from the audit trail's perspective, a change that was reviewed and approved. When it is later found, the natural question, who approved this and what did they check, has an answer that looks complete and explains nothing, because the approval was real and the review was not.
Measure whether reviews are happening, not whether they are recorded
None of the following require asking anyone to change behaviour, and all of them can be computed from data you already have.
Time between pull request creation and approval, especially for large diffs. A three-hundred-line change approved in ninety seconds was not read at that speed by anyone. Set a threshold relative to diff size and flag outliers rather than trying to police every approval manually.
Reviewer comment rate. An approval with zero comments, on every pull request, from the same reviewer, over months, is a pattern worth looking at even though no single instance is damning. Real review produces occasional questions; its total absence is itself a signal.
Reciprocity graphs. Who approves whose changes, and how symmetric is it. A pair that approves each other at a rate far above what the team's overall pattern would predict is worth a conversation, not an accusation.
Administrator bypass events, if your platform logs them separately, which most do. Anyone merging via an override path is merging without the review the rest of the team is required to have, and that path deserves more scrutiny than the normal one, not less.
Why it happens, and it is rarely laziness
Deadline pressure makes a fast approval feel like helping a colleague rather than skipping a control. Team size means the reviewer pool is small enough that the same two or three people review everything, and familiarity breeds a lighter touch over time without anyone deciding to lighten it. No feedback loop means nobody ever learns that a rubber-stamped review missed something, because most changes are fine regardless of how carefully they were checked, so the absence of a bad outcome is read as confirmation the process works.
That last point is the important one. Rubber-stamping is not usually a moral failure. It is a rational response to a process that asks for a signal, an approval, with no cost attached to providing it thoughtlessly and no visible cost to providing it carelessly, until the one time it matters.
What actually helps
Make comment-free approvals on substantial changes visible, not forbidden. A dashboard showing review depth by reviewer and by pull request size, reviewed periodically by an engineering lead, changes behaviour more effectively than a policy nobody enforces, because visibility itself is a light form of accountability.
Require a second reviewer for higher-risk changes specifically, using the same trigger list that decides which changes need a security review: authentication, authorisation, external input, data handling. Concentrate the scrutiny where it earns its cost rather than spreading it evenly across every change including the trivial ones.
Remove the administrator bypass, or log and alert on every use of it. If the people with the most access can skip the control the rest of the team follows, that path is where the highest-consequence unreviewed changes will eventually land, whether through habit or through compromise.
Rotate reviewer pairs deliberately, so review is not consistently performed by the same familiar pair who have stopped genuinely reading each other's work. This is a small process change and it interrupts the exact pattern that produces reciprocal rubber-stamping.
Check yours
Pull your own repository's pull request history and compute the approval-to-creation time distribution for changes above a size threshold. A cluster near zero for large diffs is your answer, and it takes one query against data your source host already has.
The concession
Not every pull request needs deep scrutiny, and requiring the same depth of review for a one-line configuration change as for a new authentication path wastes the attention that the second one actually needs. Some fast approvals are entirely legitimate: a trivial change, reviewed accurately, in ten seconds, is not a rubber stamp, it is a correctly calibrated response to a small diff.
The distinction worth measuring is size-adjusted speed and comment rate together, not speed alone. A ten-second approval on a two-line change is fine. The same ten seconds on three hundred lines touching authorisation logic is the pattern worth investigating.
The implication
A required approval proves that a button was clicked. It does not prove that anyone read the change, and the tools your compliance programme relies on to demonstrate a working review control cannot see the difference, because they were never designed to measure attention, only presence.
Pull the timing data for your own repository this week. If the fast approvals cluster on your largest, most consequential changes, that is the finding your next audit will not catch on its own.
