The GNU strip backdoor is the case AI code review can't see

A new paper (arxiv 2607.24888) demonstrates that Ken Thompson's trusting-trust attack can be executed using GNU strip, a build utility that neither reads nor generates source code, by tampering with finished ELF binaries. The authors show that in the NixOS bootstrap, a single malicious strip in the binary seed can propagate a payload to subsequent generations and persist into the final standard environment. The paper highlights a critical limitation of AI code review tools, which analyze source diffs but cannot detect malicious code embedded in binary dependencies, emphasizing that artifact provenance and build reproducibility are separate from code review.

This paper arxiv 2607.24888 is worth a stop if you evaluate AI code review. It shows Ken Thompson's trusting-trust attack is not compiler-specific: the authors pull it off with GNU strip, a build utility that neither reads nor generates source, using only tampered finished ELF binaries. In the NixOS bootstrap, one malicious strip in the binary seed implants a payload that propagates to the next strip generation and survives into the final standard environment after the seed is gone. The uncomfortable part for anyone building or buying AI review: these tools read the patch text and the source, and none of them reads the build path or the binary seed. And that is not a limitation a bigger model fixes. Put the strongest reasoning model in the world on that source diff and it sees a clean PR, because the malicious code is not in the source at all. It arrived as a finished strip binary in the dependency closure. I keep bumping into the same split and this paper is the cleanest example yet. Two jobs get lumped together. One is "did this source diff introduce a bug or flaw", and AI is genuinely, surprisingly good at that. The other is "does the artifact your users run match the source you reviewed", and no diff-based review, human or model, can answer yes to that. That is an artifact provenance and build reproducibility job, not a code review job. So the rule for teams adopting AI review: use it for the first job, and do not let its approval make you feel covered on the second. If your acceptance criterion becomes "the model said the diff is fine", you have traded the compiler-trust problem for a strip-trust problem and called it a win.