PAPERS-12-002 · Paper — Reflections on Trusting Trust

The paper

The paper “Reflections on Trusting Trust” was presented by Ken Thompson in 1984 at the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). It is a landmark because it revealed a fundamental weakness in trusting software tools, showing that even clean source code can hide malicious behavior.

Before this paper

Before this work, security reviews assumed that reading clean‑looking source code was enough to trust a program. The compiler that turned that source into an executable was taken on faith, and no one questioned whether the compilation tool itself could be compromised. This created a hidden trust gap in the software supply chain.

The key idea

Thompson’s key insight is that you cannot fully trust any code you did not build yourself, because a compiler can be taught to insert a backdoor into a target program and also to embed that same teaching into any future compiler it builds. The malicious behavior therefore survives even after every trace is removed from the source.

How it works

He described a three‑stage trick. First, a modified compiler recognizes when it is compiling the login program and silently adds a backdoor. Second, the compiler is taught to recognize when it is compiling its own source code and to re‑insert both the login‑backdoor trick and the self‑replicating trick. Third, the modified compiler is used once to produce a clean‑looking binary, and then the added source code is deleted. The resulting compiler binary looks innocent but continues to propagate the backdoor forever, with nothing visible in any source file.

See it — the self-hiding backdoor

flowchart TD
  A["Clean source<br/>looks safe"] --> B["Compiler binary<br/>(already trojaned)"]
  B --> C["Inserts backdoor<br/>+ re-inserts itself"]
  C --> D["Backdoor invisible<br/>in all source"]

What they showed

The lecture proved that trust must extend below the source code to every tool in the build chain – the compiler, the linker, and even the hardware. Inspecting source alone is not enough, and the result was a clear demonstration that a self‑replicating compiler can hide malicious behavior indefinitely.

What it changed

The paper introduced the concept of a trusted computing base and became the founding argument for supply‑chain security, reproducible builds, and diverse double‑compilation. It reshaped how the community thinks about trust in software tools and sparked decades of research into verifying the entire build process. Next: The Byzantine Generals Problem.

The one-line takeaway

Even a perfectly clean source can be compromised by an untrusted compiler.

Read it / meet it

Reading the original lecture is a short but eye‑opening experience that shows why supply‑chain security matters. Its legacy lives on in modern reproducible‑build efforts and in every discussion of SolarWinds‑style attacks.

Related evidence

• SolarWinds: Poisoning the Well — the trusted build pipeline itself was compromised, exactly the fear Thompson described.
• Kaseya: One Vendor, 1,500 Victims — trust in a vendor's software cascaded to everyone downstream.