Thompson’s work redefines the threat model: **the toolchain (e.g., C compiler) is a self-perpetuating attack surface** where Trojans in the bootstrap compiler (used to build the compiler itself) remain undetected even in clean source code. Source-level checks fail because the compiler *is* the verification mechanism, and Trojans (e.g., Figure 3.3’s dual self-replicating bugs) are embedded in all compiled binaries.  

**Defense strategy**: Enforce a *hand-verified bootstrap* using a minimal, non-compiled (e.g., machine code) assembler. First, build the C compiler from this clean, traceable base. Then, use *only* this verified compiler to produce all toolchain components (linker, OS, etc.). Each layer must be validated *before* use, ensuring no self-replicating Trojans. For example, compile the C compiler from a hand-written assembly "kernel" (no C dependencies), then use it to build all C code. This eliminates the "chicken-and-egg" problem of untrusted toolchains, as the bootstrap is independent of the system being verified.  

*Paranoid but rational*: Toolchain integrity is non-negotiable; source code is secondary to the bootstrap’s verified state.