트러스팅 트러스트, 컴파일러 밖으로 번졌다

공격 표면이 컴파일러 밖으로 이동했다

arXiv 논문은 켄 톰프슨의 trusting-trust 공격을 GNU strip으로 확장했다. strip은 실행 파일에서 심볼과 부가 정보를 제거하는 평범한 빌드 유틸리티다. 연구진은 NixOS 부트스트랩 seed에 변조된 strip 하나를 넣고, 깨끗한 소스에서 strip이 다시 빌드되는 과정에서도 payload가 다음 세대로 복제되게 만들었다.

핵심은 공격이 소스 코드를 읽거나 고치지 않는다는 점이다. 논문은 ELF 바이너리 조작만으로 최종 standard environment까지 악성 동작이 살아남고, 그래픽 설치 이미지를 실패 없이 빌드했다고 설명한다. 이는 소스 저장소, 코드 리뷰, 의존성 잠금 파일만 보는 방어가 얼마나 좁은지를 보여준다. VM 하나로는 사이버 에이전트를 가두기 어렵다가 실행 환경 격리를 다뤘다면, 이번 논문은 빌드 도구 자체의 신뢰를 묻는다.

AI 빌드 자동화에는 더 큰 경고다

AI 코딩 에이전트는 테스트, 패키징, 릴리스 스크립트까지 자동으로 만진다. 그래서 공급망 공격은 더 이상 사람이 낯선 diff를 놓치는 문제만이 아니다. 에이전트가 정상적인 빌드 로그를 보고 다음 작업을 이어가면, 오염된 도구가 만든 산출물을 신뢰 체인의 일부로 받아들일 수 있다.

SLSA와 OpenSSF Scorecard는 provenance와 프로젝트 위생을 강조한다. 그러나 이번 사례는 provenance가 있어도 부트스트랩 seed와 중간 바이너리의 의미를 검증하지 않으면 부족하다는 점을 찌른다. Codex가 LibreOffice를 품은 이유에서 말한 로컬 런타임 신뢰 문제와도 맞닿아 있다.

재현 빌드는 필요하지만 충분하지 않다

Reproducible Builds 운동은 같은 소스에서 같은 바이너리가 나오는지를 확인한다. 이 방향은 여전히 중요하다. 다만 trusting-trust류 공격은 어떤 도구가 그 바이너리를 만들었는지, 부트스트랩 초기 seed가 어떻게 검증됐는지까지 질문을 밀어붙인다. 특히 Linux 배포판처럼 수천 개 패키지가 여러 단계로 재빌드되는 시스템에서는 작은 도구 하나가 넓게 퍼질 수 있다.

한국 기업이 오픈소스 기반 AI 서비스를 운영한다면, 컨테이너 이미지 스캔만으로는 부족하다. 베이스 이미지, 빌드러너, 패키지 미러, 릴리스 서명, SBOM, 재현 빌드 정책이 같이 움직여야 한다. AI 검색 최적화, 가짜 권위의 새 공급망이 정보 공급망을 다뤘다면, 여기서는 실행 파일 공급망이 같은 문제를 드러낸다.

한국 팀의 실무 체크리스트

첫째, 빌드 seed와 베이스 이미지를 고정하고 갱신 이력을 남겨야 한다. 둘째, 핵심 릴리스는 다른 빌드 환경에서 한 번 더 재생산해 산출물을 비교해야 한다. 셋째, AI 에이전트에게 배포 권한을 줄 때는 패키지 설치와 빌드 도구 변경을 별도 승인 대상으로 분리해야 한다. 넷째, NixOS나 Bazel 같은 선언형 빌드 체계를 쓰더라도 seed 신뢰는 별도 관리해야 한다.

자주 묻는 질문

Q1: 이 공격은 NixOS만의 문제인가요?

A: 아닙니다. 논문은 NixOS를 실험 대상으로 삼았지만, 부트스트랩 seed와 중간 빌드 도구를 신뢰하는 모든 배포 및 빌드 체계에 시사점이 있습니다.

Q2: 왜 GNU strip이 중요합니까?

A: strip은 많은 실행 파일을 후처리합니다. 컴파일러처럼 눈에 띄지 않지만, 넓은 범위의 바이너리를 만진다는 점에서 전파 지점이 될 수 있습니다.

Q3: 소스 코드가 깨끗하면 안전하지 않나요?

A: 이번 공격은 소스를 수정하지 않습니다. 깨끗한 소스에서 빌드해도 오염된 도구가 산출물을 바꿀 수 있다는 것이 핵심입니다.

Q4: AI 에이전트와 직접 관련이 있나요?

A: 에이전트가 빌드와 배포를 자동 실행할수록 도구 체인 무결성이 더 중요해집니다. 잘못된 산출물을 정상 결과로 받아들일 수 있기 때문입니다.

Q5: 당장 할 수 있는 방어는 무엇인가요?

A: SBOM, provenance, 재현 빌드, 서명 검증, 독립 빌드 환경 비교를 함께 적용하는 것이 현실적인 출발점입니다.