In code review, which changed files get skimmed rather than read, and why does that matter?

## The premise Code review is the only control in most organisations that inspects the *content* of a change. Authentication tells you who pushed it, branch policy tells you that somebody approved it, and CI tells you the tests passed. None of those read the change. So the practical security question is not whether a repository requires review, but which parts of a change set are actually read by a human — and every real repository has categories that are not. ## The classes that get skimmed **Dependency lockfiles.** A resolved lockfile change can be thousands of lines for a one-line manifest edit. Reviewers approve on the manifest and assume the lockfile is its consequence. It is not — a lockfile can name packages and resolved sources that the manifest never asked for, and it will be the file the installer actually obeys. **Generated files.** Protobuf or API clients, ORM schemas, compiled templates, bundled assets. The social contract is that a machine wrote them, so reading them is pointless — which is precisely why an edit to one survives review. **Vendored trees.** A committed copy of a third-party library. The first commit is huge and unread; every later edit is read as an upgrade rather than as source. **Binary fixtures.** Golden capture files, reference images, sample archives, recorded HTTP transcripts, model-weight blobs. The interface offers no diff at all. A reviewer literally cannot read the change without deliberately extracting and inspecting the file. **Test and tooling code.** Read fast, if at all, because it does not run in production — but it *does* run on a build machine that usually holds credentials. ## Why this is a supply chain problem, not a hygiene problem An attacker who already holds legitimate commit rights — a contributor, a contractor, a stolen session belonging to a real teammate — has no need to defeat identity controls. Every authentication control has already granted them what it can grant: proof that the actor is who they claim to be. The remaining control between them and your artifact is a human reading a diff. They therefore aim the payload at the part of the diff that is not read, and the change looks routine: a refreshed fixture, a regenerated client, a lockfile update alongside a genuine dependency bump. This is also why the usual reassurances do not apply here. A signed commit binds the change to an identity; it says nothing about whether the change is safe, and the identity in question is authorised. Provenance and build attestations describe how the artifact was produced from this source; when the source itself is hostile, the build is honest and the attestation is truthful. Reproducible builds reproduce the payload byte for byte. All of these controls close a different gap — tampering between the reviewed source and the shipped artifact — and this attack is upstream of all of them. ## What to do about it The wrong response is to demand that reviewers read everything. Reviewer attention is finite, and a rule people cannot follow produces approvals that mean even less. Make each class safe by construction instead: - **Generated files:** regenerate them in CI from the committed source and fail the build if the result differs from the checked-in copy. The file is then a function of reviewed input, and a hand-edit is a build failure rather than a review problem. - **Lockfiles:** review the *semantic* change — which package names and sources were added, removed or repointed — rather than the raw diff. Tooling can render this; the reviewer's job is to confirm the added names are the ones the manifest change implies. - **Binary fixtures:** prefer fixtures generated at test time from committed source. Where a real binary must be committed, require that it be reproducible from a script in the repository, and record its hash and who produced it so a later swap is visible as a hash change with no accompanying source change. - **Vendored code:** treat an update as a dependency upgrade with a stated upstream version and a verifiable source, not as an ordinary diff. - **Blast radius:** assume some change will get through unread, and reduce what an unread change can reach — builds and tests that run without production credentials and without unrestricted network egress limit what a payload accomplishes even when review misses it. ## Interview framing The answer an interviewer wants is the honest one: review is a real control, it has known blind spots, the blind spots are predictable by file type, and the durable fix is to move those file types out of the class of things a human must read.