논문 정보
제목: Reflections on Trusting Trust
저자: Ken Thompson (Kenneth Lane Thompson, AT&T Bell Labs) — UNIX 공동 창시자, 1983년 튜링상 수상
발표: Communications of the ACM, 27(8): 761–763, 1984년 8월 (1983 Turing Award Lecture)
분야: 소프트웨어 신뢰, 컴파일러 보안, 공급망 공격, 백도어
Semantic Scholar 인용: 759회 (K. Thompson, 1984)
저자: Ken Thompson (Kenneth Lane Thompson, AT&T Bell Labs) — UNIX 공동 창시자, 1983년 튜링상 수상
발표: Communications of the ACM, 27(8): 761–763, 1984년 8월 (1983 Turing Award Lecture)
분야: 소프트웨어 신뢰, 컴파일러 보안, 공급망 공격, 백도어
Semantic Scholar 인용: 759회 (K. Thompson, 1984)
연구 배경 — "직접 완전히 만들지 않은 코드는 신뢰할 수 없다"
이 논문은 Ken Thompson이 1983년 튜링상 수상자로서 발표한 단 3페이지짜리 강연문이다. UNIX와 C 언어의 창시자가 던진 질문은 충격적으로 단순하다. 소스 코드를 아무리 철저히 검토해도, 그 소스를 기계어로 바꿔주는 컴파일러가 악의적이라면 우리는 무엇을 믿는 것일까? 소스 코드에 백도어를 직접 심는 방법은 코드 리뷰에 금방 걸린다. Thompson은 컴파일러라는 더 깊은 층위를 공격해 어느 소스 파일에서도 흔적을 찾을 수 없는 완전한 트로이 목마를 만드는 3단계 방법을 보여줬다. 이 한 편의 강연은 이후 40년간 이어지는 공급망 보안 논쟁의 원형(原型)이 되었다.
핵심 내용 — 3단계 컴파일러 백도어
- 1단계 — 소스 수정은 들킨다:
login프로그램의 소스에 백도어(특정 비밀번호로 항상 통과)를 추가하면, 소스를 읽는 사람에게 곧 노출된다. 코드 검토는 이 수준의 공격을 막는다. - 2단계 — 컴파일러를 수정한다: C 컴파일러를 두 가지 방식으로 변조한다. (a)
login소스를 컴파일할 때 백도어 객체 코드를 자동으로 삽입하고, (b) 컴파일러가 자기 자신의 소스를 컴파일하는 경우에는 백도어 삽입 코드를 스스로 다시 생성한다. 후자가 핵심인데, 이는 프로그램이 자신의 복사본을 출력하는 유명한 Quine(자기재생산 프로그램) 기법이다. - 3단계 — 흔적을 지운다: 이 변조된 컴파일러로 새 컴파일러를 컴파일하면, 새 컴파일러는 소스가 완전히 깨끗해도 백도어 삽입 능력을 그대로 이어받는다. 이제 백도어와 관련된 코드는 시스템의 어떤 소스 파일에도 존재하지 않는다. 공격자는 변조된 컴파일러 바이너리 하나만 배포하면 된다.
- 결론 — 신뢰의 기원(起源): "신뢰의 궁극적 근거는 코드가 아니라, 그 코드를 처음 만든 사람과 과정에 있다." 통제권이 소스 코드에 있지 않으므로, 소스 레벨 검증만으로는 이런 공격을 원천적으로 막을 수 없다.
"You can't trust code that you did not totally create yourself. (No amount of source-level verification or scrutiny will protect you from using untrusted code.)" — Ken Thompson
보안 시사점
- 공급망 공격의 원형: Thompson이 그린 시나리오는 2024년 xz-utils 백도어(CVE-2024-3094, sshd 원격 백도어), SolarWinds, 3CX 등 현대 공급망 공격의 이론적 청사진이다. "소스는 깨끗한데 바이너리는 악성"이라는 구조가 그대로 반복된다.
- 오픈소스도 예외가 아니다: 소스 공개는 컴파일 체인을 신뢰하는 문제를 없애주지 않는다. 실제로 누구나 읽을 수 있다는 점이 오히려 "소스를 보면 안전하다"는 거짓 안도감을 준다.
- 현대적 대응책의 기원: 이 논문이 제기한 문제에 대한 직계 후손이 바로 재현 가능한 빌드(Reproducible Builds), 부트스트래핑(bootstrapping — GCC를 자기 자신으로 처음부터 검증), 이중 컴파일 검증(Diverse Double-Compilation), SBOM·서명 검증(sigstore 등)이다. 어느 것도 완전한 해법이 아니라 "신뢰의 시작점"을 더 작고 검증 가능하게 만드는 장치다.
- 오늘날의 공격면: CI/CD 파이프라인, 패키지 매니저, 컴파일러·툴체인 업데이트 채널은 모두 "소스를 보지 않고 바이너리를 신뢰하는" 지점이다. 누가 그 바이너리를 만들었는지(출처 무결성)를 검증하는 습관이 소스 리뷰보다 중요할 수 있다.
결론
40년 전 발표된 3페이지 분량의 수상 강연은 오늘날까지 보안 분야에서 가장 많이 인용되는 고전 중 하나다. "컴파일러를 컴파일하는 컴파일러"라는 자기참조적 사고실험은 소프트웨어 공급망의 취약성이 코드 품질이 아니라 신뢰 체인(chain of trust)의 시작점에 있음을 보여준다. 코드를 만드는 도구가 코드를 배신할 수 있다는 사실을 처음으로 대중화한 논문으로, 소프트웨어를 신뢰한다는 것의 의미를 다시 묻게 만든다.
원문: ACM Digital Library — Reflections on Trusting Trust (DOI: 10.1145/358198.358210) · Wikipedia