xz 유틸리티 백도어 — 몇 해에 걸쳐 쌓은 신뢰, 느려진 로그인에 들키다

0.3초가 0.8초가 된 로그인

2024년 3월 29일 금요일, 미국 태평양 시간으로 오전 8시 51분에 앤드레스 프로인트가 보안 메일링 리스트 oss-security에 글 한 통을 올렸습니다 (발견자 앤드레스 프로인트의 공개 글). 그는 지난 몇 주 동안 자기가 쓰던 데비안 개발판 리눅스에서 이상한 증상을 봤습니다. 원격 로그인이 처리 능력을 많이 잡아먹었고, 메모리 검사 도구가 오류를 냈습니다. 원인을 쫓은 끝에 그가 적은 결론은, xz를 만드는 원본 프로젝트 쪽에 백도어가 심겼다는 것이었습니다 (발견자 앤드레스 프로인트의 공개 글). 백도어(backdoor)는 정상적인 확인 절차를 거치지 않고 시스템에 들어올 수 있게 몰래 만들어 둔 출입 경로입니다. 열쇠공이 집주인 모르게 여분의 열쇠를 깎아 둔 것과 비슷해서, 문과 자물쇠는 겉으로 멀쩡해 보입니다.

xz는 범용 데이터 압축 형식으로, 공동체가 만드는 것이든 회사가 파는 것이든 거의 모든 리눅스 배포판에 들어 있습니다 (레드햇 보안 공지). 리눅스 배포판은 리눅스를 여러 프로그램과 한데 묶어 설치할 수 있게 내놓는 꾸러미입니다. 미국 국토안보부 산하 사이버보안·인프라보안청(CISA)은 같은 날 낸 경보에서 XZ Utils, 곧 xz 유틸리티를 리눅스 배포판에 들어 있을 수 있는 데이터 압축 소프트웨어라고 설명했습니다 (CISA 경보).

이 일은 인터넷 위에서 벌어졌습니다. xz는 메일링 리스트와 코드 공유 사이트 GitHub에서 만들어지고 고쳐지는 오픈소스, 곧 「Log4j 취약점 — 벽 속에 묻힌 부품은 누가 찾아내나」에서 다룬 대로 코드를 누구나 보고 고칠 수 있게 공개해 둔 소프트웨어입니다. 등장하는 사람은 셋입니다. 이 프로젝트를 원래 맡아 온 라세 콜린, 2022년의 기록에 이미 그를 돕고 있던 Jia Tan이라는 이름을 쓴 기여자, 그리고 발견자 프로인트입니다. 프로인트는 스스로 보안 연구자도, 프로그램을 거꾸로 뜯어 분석하는 역공학 전문가도 아니라고 밝혔습니다 (발견자 앤드레스 프로인트의 공개 글).

이 글이 따라가는 1차 문서는 여덟입니다. 발견자의 공개 글, 당사자인 라세 콜린의 공식 페이지와 사건 뒤 검토 노트, 사건 2년 전 xz 개발 메일링 리스트의 메일들, CISA의 경보, 배포판을 내는 레드햇과 데비안의 공지와 기록, 그리고 두 오픈소스 재단 OpenSSF·OpenJS의 공동 경보입니다. 이 글은 몇 해에 걸쳐 쌓인 신뢰가 어떻게 새 판 속 코드가 됐는지, 그리고 서명과 검토 같은 방어가 그 앞에서 무엇을 할 수 있었는지를 이 문서들과 연구로 따라갑니다.

보수 없는 취미 프로젝트

2022년 5월 19일, 라세 콜린은 xz 개발 메일링 리스트에 자기 자원이 너무 부족해 답하지 못한 메일이 쌓여 있고, 장기적으로 무언가 바뀌어야 한다고 적었습니다 (xz 개발 메일링 리스트, 2022년). 그는 이 프로젝트의 유지보수자였습니다. 유지보수자(maintainer)는 프로젝트에 들어오는 수정 제안을 검토해 받아들일지 정하고, 새 판을 내보내는 책임을 맡은 사람입니다.

같은 메일에 이름 하나가 나옵니다. Jia Tan이 메일링 리스트 밖에서 XZ Utils 일을 도와 왔고, 앞으로 적어도 XZ Utils에서는 더 큰 역할을 맡을 수 있다는 것입니다 (xz 개발 메일링 리스트, 2022년).

6월 7일, 유지보수자가 아닌 다른 참가자 계정 하나가 새 관리자가 생기기 전에는 진전이 없을 것이고 지금 관리자는 관심을 잃었다고 썼습니다. 이튿날 콜린은 이것이 보수 없는 취미 프로젝트라는 점을 상기시키고, 관심을 잃은 것이 아니라 본인이 메일에서 밝힌 개인 사정으로 돌볼 여력이 제한돼 왔다고 적었습니다. 같은 스레드에서 그는 공동 관리자를 찾거나 프로젝트를 통째로 넘기는 일은 오래 생각해 왔지만, 기술과 시간과 이 프로젝트에 대한 장기적 관심을 모두 갖춘 사람이 필요해 쉽지 않다고도 적었습니다. 6월 14일에는 같은 계정이 관리자 교체를 왜 5.4.0판까지 미루느냐고 다그쳤습니다 (xz 개발 메일링 리스트, 2022년).

6월 29일, 콜린은 Jia Tan이 리스트 밖에서 많이 도와 왔고 사실상 이미 공동 관리자이며, 적어도 XZ Utils는 관리자 교체가 진행 중이라고 적었습니다 (xz 개발 메일링 리스트, 2022년). Jia Tan은 문제의 판 이전에도 판을 냈습니다. 사건 뒤 콜린은 Jia Tan이 만들고 서명한 이전 판들, 곧 5.2.12와 5.4.3~5.4.6으로 내놓은 파일을 다시 확인해 악성 내용이 없었다고 적었습니다. 코드 변경 기록 하나하나에는 서명이 없었지만, 그는 변경한 사람을 사칭한 흔적도 찾지 못했습니다 (유지보수자 라세 콜린의 검토 노트).

백도어가 나오기 2년 전의 기록에 남은 것은 자원이 모자란 채 보수 없이 이어 온 일, 교체를 재촉하는 목소리, 그리고 실제로 일을 도우며 「사실상 공동 관리자」가 된 기여자입니다.

몇 주의 의심, 하루의 공개

프로인트가 처음 붙잡은 것은 속도였습니다. 문제의 판이 설치된 컴퓨터에서 원격 로그인이 눈에 띄게 느려졌고, 그의 측정에서 약 0.3초 걸리던 로그인이 약 0.8초 걸렸습니다 (발견자 앤드레스 프로인트의 공개 글). 원격 로그인에 쓰인 것은 SSH입니다. SSH는 원격으로 시스템에 접속할 때 흔히 쓰는 방식이고, 그 접속을 받아 주는 서비스가 sshd입니다 (레드햇 보안 공지).

그는 처음에 이것을 데비안이 꾸려 내놓은 xz 꾸러미만의 문제로 생각했지만, 원본 쪽 문제로 드러났습니다 (발견자 앤드레스 프로인트의 공개 글). 그래서 신고도 그 순서를 따랐습니다. 먼저 데비안 보안팀에 예비 보고를 했고, 이어 여러 배포판의 보안 담당자가 함께 보는 목록에 알렸습니다. CISA에는 한 배포판이 알렸습니다. 원본 쪽이 관여한 것으로 보였기 때문에, 원본 프로젝트에는 버그로 보고하지 않았습니다. 「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」에서 다룬 대로 취약점은 공격자가 파고들어 만든 사람이 뜻하지 않은 일을 일으킬 수 있는, 시스템의 약한 자리입니다. 취약점마다 붙는 공개 번호인 CVE는 레드햇이 부여했고, 이 사건의 번호는 CVE-2024-3094입니다 (발견자 앤드레스 프로인트의 공개 글).

그는 자기 글의 한계도 함께 적었습니다. 관찰한 것 대부분은 코드를 철저히 분석한 결과가 아니라 관찰에서 나왔다는 것입니다 (발견자 앤드레스 프로인트의 공개 글).

발견은 보안 연구자가 아니라고 스스로 밝힌 사람이, 약 0.3초에서 약 0.8초로 느려진 로그인과 검사 도구의 오류를 지나치지 않은 데서 나왔습니다.

저장소에는 없던 코드

오픈소스 프로그램은 대개 두 모습으로 있습니다. 저장소(repository)는 개발자들이 코드를 함께 고치며 그 변경 기록을 모두 쌓아 두는 곳입니다. 공개 저장소라면 누가 언제 무엇을 바꿨는지 누구나 들여다볼 수 있습니다.

배포 파일(release tarball)은 프로젝트가 새 판을 낼 때 소스 코드를 한 덩어리로 묶어 내놓는 파일입니다. 그리고 빌드(build)는 사람이 읽고 쓰는 코드를 컴퓨터가 실행하는 프로그램으로 만드는 과정입니다.

xz 유틸리티 5.6.0과 5.6.1의 배포 파일에 백도어가 들어 있었고, 그 배포 파일은 Jia Tan이 만들고 서명했습니다 (유지보수자 라세 콜린의 공식 페이지).

백도어의 일부는 배포 파일에만 있었고, 공개 저장소의 코드와 배포 파일이 달랐습니다 (발견자 앤드레스 프로인트의 공개 글). 콜린도 같은 취지로, 백도어를 작동시키는 코드는 Git 저장소에 들어간 적이 없다고 적었습니다 (유지보수자 라세 콜린의 공식 페이지). 공개 저장소를 아무리 꼼꼼히 읽어도 그 부분은 보이지 않았다는 뜻입니다.

권한의 범위도 당사자가 적어 두었습니다. 콜린의 설명으로는 주 웹사이트와 tukaani.org의 저장소에는 자신만 접근했고, Jia Tan은 xz.tukaani.org라는 하위 주소를 포함해 GitHub에 올린 것들에만 접근했습니다 (유지보수자 라세 콜린의 공식 페이지). 이것은 당사자의 설명이고, 이 글의 근거 가운데 따로 확인한 문서는 없습니다.

압축 도구가 원격 로그인에 닿은 길은 간접적이었습니다. SSH 서버 프로그램은 xz의 압축 부품을 직접 쓰지 않습니다. 그러나 데비안을 비롯한 여러 배포판이 SSH 서버에 덧붙인 수정 때문에, 시스템을 관리하는 프로그램 systemd를 거쳐 그 부품과 이어져 있었습니다 (발견자 앤드레스 프로인트의 공개 글). 직접 쓰지 않는 부품도 이어진 사슬을 따라 닿을 수 있었습니다.

이런 공격에는 이름이 있습니다. 공급망 공격(software supply chain attack)은 목표를 직접 뚫는 대신, 목표가 가져다 쓰는 소프트웨어를 만들고 나르는 과정 어딘가에 해로운 코드를 끼워 넣어, 그것을 받아 쓰는 쪽까지 닿게 하는 공격입니다. 오픈소스 공급망에서 공격자가 끼어들 수 있는 자리를 코드 기여부터 꾸러미 배포까지 한 그림으로 정리하면 107가지 경로가 나오고, 그 경로들은 실제 사건들과 이어집니다 (DOI: 10.1109/sp46215.2023.10179304). 공격자가 끼어들 자리는 코드 한 줄보다 훨씬 많습니다.

이 사건을 GitHub 기록과 개발 산출물로 직접 다시 짠 연구는 여기서 한 걸음 더 갑니다. 저자들은 공격자가 코드만이 아니라 공동체 운영부터 자동 빌드 설정까지 개발 과정 전체를 이용해 정당성을 얻고 오래 통제권을 쥐려 했다고 보고, 겉보기에 유익한 기반 작업과 유지보수 기여가 전통적인 보안 장치를 비켜 가는 데 쓰였다고 결론지었습니다 (DOI: 10.1109/msr66628.2025.00026).

세 문서, 세 가지 말투

무엇이 위험했는지를 말할 때 문서들은 모두 단서를 답니다. 발견자는 끼워 넣은 코드가 무엇을 확인하는지 아직 정확히 분석하지 못했다고 먼저 밝히고, 인증 전 단계에서 돌아가므로 어떤 형태의 접근이나 원격 코드 실행을 허용할 가능성이 커 보인다고 적었습니다 (발견자 앤드레스 프로인트의 공개 글). 여기서 인증은 「비밀번호와 패스키 — 내가 나라는 걸 어떻게 증명하나」에서 다룬 대로, 지금 들어오려는 사람이 정말 그 사람인지 확인하는 일입니다.

CISA 경보는 이것을 악성 코드라고 불렀습니다. 「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」에서 다룬 대로 악성코드는 사용자 몰래 해를 끼치려고 만든 프로그램입니다. 경보는 이 코드가 영향받은 시스템에 무단 접근을 허용할 수 있다고 했습니다 (CISA 경보). 레드햇은 이 코드가 무단 접근을 노린 것으로 보인다고 했고, 악성 빌드가 systemd를 거쳐 sshd의 인증에 끼어들며, 조건이 맞으면 공격자가 인증을 깨고 원격으로 시스템 전체에 무단 접근하는 것도 가능할 수 있었다고 적었습니다 (레드햇 보안 공지).

가능성이 커 보인다, 할 수 있다, 조건이 맞으면 가능할 수 있었다. 세 표현은 서로 모순되지 않지만, 모두 가능성의 말입니다. 문서들은 위험을 원격 접속을 통한 무단 접근이나 원격 실행 쪽으로 보면서도, 그 세기는 모두 가능성의 말로 적었습니다.

어디까지 들어갔나

발견자는 다행히 5.6.0과 5.6.1이 아직 리눅스 배포판에 널리 들어가지 않았고, 들어간 곳도 대부분 정식 출시 전 판이라고 적었습니다 (발견자 앤드레스 프로인트의 공개 글). 배포판 쪽 문서들은 그 「출시 전 판」 가운데 몇 곳을 적었습니다.

레드햇에 따르면 Fedora 40 사용자는 업데이트 시점에 따라 5.6.0을, 개발판 Fedora Rawhide 사용자는 5.6.0이나 5.6.1을 받았을 수 있습니다. Rawhide는 앞으로 나올 판, 이번에는 아직 출시 전인 Fedora 41의 바탕이 되는 개발용 배포판이고, 레드햇은 Rawhide 사용을 즉시 멈추라고 했습니다 (레드햇 보안 공지). 레드햇은 또 데비안 개발판용으로 빌드된 5.6.x에서 백도어가 실제로 빌드됐다는 보고와 증거가 있고, 다른 배포판도 영향받았을 수 있다고 적었습니다 (레드햇 보안 공지). 자사 상용 배포판 RHEL은 어떤 판도 영향이 없다고 밝혔는데, 이것은 공급자의 자기 평가입니다 (레드햇 보안 공지).

데비안의 기록에서 안정판들은 영향이 없었습니다. 취약한 코드가 들어 있지 않았습니다. 개발판은 이름은 5.6.1이지만 내용은 5.4.5로 되돌린 판으로 고쳐졌습니다 (데비안 보안 추적기).

레드햇 공지 안에서는 판단이 하루 사이에 바뀌었습니다. 3월 29일 판은 Fedora 40 빌드에서 침해가 확인되지 않았고 주입이 작동하지 않은 것으로 본다고 했고, 3월 30일 갱신은 Fedora 40 베타에 영향받는 판 두 개가 들어 있지만 실제 악성 코드 작동에는 영향받지 않은 것으로 보인다고 했습니다 (레드햇 보안 공지). 판 번호 표기도 문서마다 다릅니다. CISA 경보는 이 공지를 「Fedora 41과 Rawhide」 사용자 대상 공지로 링크했지만, 지금의 레드햇 공지 제목은 「Fedora Linux 40과 Fedora Rawhide」이고, 레드햇은 영향받는 판을 더 분명히 하려고 고쳤다는 편집자 주를 달았습니다 (CISA 경보; 레드햇 보안 공지).

실제로 침입당한 시스템이 있었는지, 없었는지를 적은 문서도 이 글의 근거 가운데 없습니다. 문서들이 이름을 든 곳은 Fedora 40 베타와 Rawhide, 데비안 개발판 같은 개발판과 출시 전 판이고, 레드햇은 다른 배포판도 영향받았을 수 있다고 덧붙였으며, 몇 대에 들어갔는지 센 문서는 이 글의 근거 가운데 없습니다.

되돌리고 다시 읽은 두 달

CISA 경보는 개발자와 사용자에게 오염되지 않은 판, 예를 들어 5.4.6 안정판으로 되돌리고, 악성 활동이 있었는지 찾아보고, 발견하면 알려 달라고 권고했습니다 (CISA 경보).

프로젝트 쪽 정리는 당사자 페이지에 날짜와 함께 남아 있습니다. 콜린과 Jia Tan의 GitHub 계정이 모두 정지됐고, 콜린의 계정은 2024년 4월 2일에 복구됐습니다. 3월 30일에는 프로젝트 메일 주소가 더는 Jia Tan에게 전달되지 않게 바꿨습니다. 저장소의 기록은 고쳐 쓰지 않기로 했고, 다른 두 저장소인 xz-embedded와 xz-java에는 악성이거나 의심스러운 내용이 없었습니다 (유지보수자 라세 콜린의 공식 페이지).

콜린은 Jia Tan 계정이 남긴 변경과 배포 파일을 하나하나 다시 읽었습니다 (유지보수자 라세 콜린의 검토 노트). 그 검토 노트의 첫 작업판은 2024년 4월 15일에, 1.0판은 5월 29일에 나왔고, 같은 날 깨끗한 새 판들이 나왔습니다 (유지보수자 라세 콜린의 공식 페이지).

복구는 옛 판으로 되돌리기, 계정과 주소 정리, 남긴 것 전부를 다시 읽기, 그리고 깨끗한 새 판의 순서였습니다.

이름만 남은 기여자

Jia Tan은 누구였을까요. 문서가 확인한 것은 계정이 한 일까지입니다. 백도어가 든 배포 파일을 Jia Tan이 만들고 서명했다는 것은 당사자가 적었습니다 (유지보수자 라세 콜린의 공식 페이지). 변경 기록에서 사칭 흔적을 찾지 못했다는 것도 당사자의 검토입니다 (유지보수자 라세 콜린의 검토 노트).

발견자는 추정으로 한 걸음 더 갔습니다. 몇 주에 걸친 활동으로 보아 변경을 올린 사람이 직접 관여했거나 그 사람의 시스템이 심하게 뚫렸거나 둘 중 하나인데, 그 사람이 여러 메일링 리스트에서 「수정」을 두고 소통했기 때문에 뚫렸다는 쪽은 가능성이 덜해 보인다는 것입니다 (발견자 앤드레스 프로인트의 공개 글). 두 재단은 이 이름을 따옴표로 묶어 「Jia Tan」이라고 불렀습니다 (OpenSSF·OpenJS 재단 공동 경보).

사건 뒤 연구는 다른 길로 그 계정을 봤습니다. GitHub에 공개된 기여 기록을 그래프로 엮으면, 그 계정이 다른 오픈소스 프로젝트들에서 보인 이상 행동을 효율적으로 찾아낼 수 있었습니다 (arXiv:2508.13453, 프리프린트). 이미 알려진 계정을 놓고 한 분석이고, 저자들은 이런 기여 계정을 지켜보는 도구가 아직 없다고 지적했습니다.

문서가 확인한 것은 「Jia Tan」이라는 계정이 무엇을 만들고 서명했는가까지이고, 그 뒤의 실제 사람이나 집단, 나라를 지목한 문서는 이 글의 근거 가운데 없습니다.

열쇠를 넘기는 일은 원래 필요하다

GitHub에서 인기 있는 프로젝트 1,932개 가운데 315개(16%)가 버려졌고, 그 가운데 128개(41%)는 새 핵심 개발자가 개발을 이어받아 살아남았습니다. 이어받은 사람들이 꼽은 주된 장벽은 시간 부족과, 저장소에 직접 변경을 올릴 권한을 얻기 어렵다는 점이었습니다 (DOI: 10.1109/esem.2019.8870181). xz 사건 전에 GitHub 인기 프로젝트들을 잰 이 결과에서 권한 넘기기는 버려질 프로젝트를 살리는 길이기도 합니다.

그만큼 한 사람에 기대는 부품도 많습니다. 여러 언어의 공개 부품 저장소에서 간접적으로 기대는 프로그램이 가장 많은 축에 드는 부품 가운데, 핵심 개발자 한 사람만 빠져도 멈출 수 있는 것들이 나왔습니다 (DOI: 10.1109/msr52588.2021.00017). 데비안 소스 꾸러미 21,902개의 자료에서는, 널리 설치된 여러 부품에서 일손의 공급이 그 소프트웨어에 기대는 사람들의 수요에 못 미치는 「과소생산」이 넓게 나타났습니다 (DOI: 10.1109/saner50967.2021.00043). 두 연구 모두 xz 사건 이전에 생태계를 넓게 잰 것으로, xz를 따로 들여다본 연구는 아닙니다.

사건 뒤 두 재단의 경보는 넘기는 쪽에 일반 기준을 이렇게 적었습니다. 누군가에게 관리자로서 소스 코드 관리 권한을 주는 일은 더 높은 수준의 쌓인 신뢰가 필요하고, 어떤 문제의 「빠른 해결책」으로 내줄 것이 아니라는 것입니다 (OpenSSF·OpenJS 재단 공동 경보). 콜린 자신도 2022년에 적합한 사람을 찾는 일이 쉽지 않다고 적었고, 그 판단은 자원이 모자란 자리에서 내려야 했습니다 (xz 개발 메일링 리스트, 2022년).

권한 넘기기는 버려질 프로젝트를 살리는 정상적인 길이고, 쌓인 신뢰는 바로 그 문을 여는 열쇠입니다.

책임감을 파고드는 사회공학

2024년 4월 15일, 두 재단은 xz 백도어 시도가 고립된 사건이 아닐 수 있다는 경보를 냈습니다. OpenJS 재단이 비슷한, 신빙성 있는 탈취 시도를 가로챘다는 것입니다 (OpenSSF·OpenJS 재단 공동 경보). 이름은 다르지만 GitHub에 연결된 메일 주소가 겹치는 여러 이메일이, 구체적인 근거 없이 「심각한 취약점」을 고쳐야 한다며 이전 관여가 거의 없는 자신들을 새 관리자로 지정해 달라고 했습니다. 그 누구도 권한을 받지 않았습니다. 재단 팀은 재단 밖의 인기 자바스크립트 프로젝트 두 곳에서도 비슷한 의심 패턴을 알아보고 CISA 등에 알렸습니다 (OpenSSF·OpenJS 재단 공동 경보).

이것은 사회공학입니다. 「피싱과 사회공학 — 문을 부수는 대신 초인종을 누른다」에서 다룬 대로, 사회공학은 기계의 빈틈 대신 사람의 마음과 판단을 파고들어, 그 사람이 스스로 정보를 내주거나 위험한 일을 하게 만드는 공격입니다. 재단이 꼽은 의심 징후에는 비교적 알려지지 않은 사람들이 다정하지만 공격적이고 끈질기게 관리자를 쫓는 것, 새롭거나 모르는 사람이 관리자 권한을 요구하는 것, 가짜 신분을 쓰고 있을 수 있는 다른 모르는 사람들의 추천, 검토를 대충 하게 만드는 거짓 긴급함이 들어 있습니다. 재단은 이런 공격이 유지보수자가 프로젝트와 공동체에 느끼는 책임감을 이용한다고 봤습니다 (OpenSSF·OpenJS 재단 공동 경보).

2022년 xz 메일링 리스트에도 관리자 교체를 재촉하는 메일이 있었습니다 (xz 개발 메일링 리스트, 2022년). 다만 그 메일을 보낸 계정들이 가짜 신분이었는지 확인한 문서는 이 글의 근거에 없습니다. 재단의 목록은 일반 징후이고, 2022년의 메일은 그 자체의 기록입니다.

그 책임감이 놓인 자리는 연구가 거듭 보고해 온 부담입니다. 오픈소스 개발자들은 기능과 버그 수정을 끊임없이 요구받고 그 요구가 때로 공격적인 말투로 오는 데서 큰 스트레스를 보고해 왔고, 그런 대화가 개발자의 의욕을 꺾고 소진시킬 수 있습니다. 같은 논문이 GitHub 이슈의 유해한 대화를 분류해 보니, 그 정도는 공동체마다 달랐고 2012~2018년 사이 줄었습니다 (DOI: 10.1145/3377816.3381732, 4쪽 짧은 논문). 유지보수자 면담에서는 일과 삶의 균형, 사회적 압력을 미리 관리하는 일 같은 사람의 요인이 중요하게 꼽혔고, 자금이 중요한 조건으로 나왔습니다 (arXiv:2408.06723, 유지보수자 10명 면담 프리프린트). 두 재단도 자바스크립트 생태계의 많은 프로젝트가 소수 팀이나 개발자 한 명이 유지하며, 거기 기대면서 거의 보태지 않는 상용 기업들에 짓눌린다고 적었습니다 (OpenSSF·OpenJS 재단 공동 경보).

재단은 이런 사회공학이 유지보수자의 책임감을 이용한다고 봤고, 그 책임감을 짓누르는 부담은 한 사람의 사정을 넘어 연구가 거듭 보고해 온 구조입니다.

서명이 확인해 주는 것

공급망을 지키는 장치 가운데 하나가 서명입니다. 「열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가」에서 다룬 대로, 디지털 서명은 개인키를 쥔 사람만 만들 수 있고 그 짝인 공개키만 있으면 누구나 확인할 수 있는 표식입니다. 서명을 확인하면 파일이 어느 열쇠에서 나왔는지, 서명한 뒤에 바뀌지 않았는지를 알 수 있습니다. 많은 공급망 공격은 서명으로 완화할 수 있지만, 공개 꾸러미 저장소들에서 서명이 얼마나 쓰이는지는 공격이 널리 알려진 것보다 저장소의 정책에 주로 좌우됐습니다 (DOI: 10.1109/sp54263.2024.00215).

이번 배포 파일에는 서명이 있었고, 그 서명은 파일을 만든 Jia Tan의 것이었습니다 (유지보수자 라세 콜린의 공식 페이지). 서명은 그 파일이 어느 계정의 열쇠에서 나왔는지는 알려 주지만, 그 계정을 믿어도 되는지도, 그 뒤에 누가 있는지도 알려 주지 않습니다. 파일을 만든 쪽이 처음부터 넣어 둔 것은 서명이 걸러 내지 못합니다. 두 재단이 권한 것도 서명 하나에 그치지 않습니다. 변경에 서명하게 하고, 관리자가 올린 변경이라도 합치기 전에 다른 개발자가 검토하게 하고, 변경을 올리는 사람과 관리자를 알고 주기적으로 점검하라는 것입니다 (OpenSSF·OpenJS 재단 공동 경보).

빌드 쪽에도 확인 장치가 있습니다. 재현 가능한 빌드(reproducible builds)는 같은 소스 코드로 누가 다시 빌드해도 비트 하나까지 똑같은 결과물이 나오게 만드는 방식입니다. 소스 코드를 검토해 믿는 것과 실제로 받아 쓰는 실행 파일을 믿는 것은 같지 않고, 재현 가능한 빌드는 만들어진 실행 파일이 원래 소스와 맞는지 가려낼 수 있습니다 (DOI: 10.1109/ms.2021.3073045). 이 장치가 확인하는 것은 결과물이 넣은 소스와 맞는가까지입니다.

재현 가능한 빌드는 큰 꾸러미 모음에서도 높은 비율로 해낼 수 있지만, 생태계에 따라 품이 듭니다. 꾸러미 관리 도구 Nix의 꾸러미 709,816개를 다시 빌드하자 비트 하나까지 똑같이 나온 비율이 69~91%였고 갈수록 올랐습니다. 똑같이 나오지 않은 경우의 약 15%는 결과물에 빌드한 날짜가 박혀 들어간 탓이었습니다 (DOI: 10.1109/msr66628.2025.00115). 자바에서는 특히 어렵다고 저자들은 봤습니다. 이미 똑같이 나오지 않던 결과물만 모아 새 도구를 써 보니, 그 가운데 똑같이 나오게 된 비율이 9.48%에서 26.60%로 올랐습니다 (DOI: 10.1109/tse.2025.3627891).

배포판들이 주로 힘을 쏟아 온 것도 이 장치였습니다. 주요 리눅스 배포판 여러 곳의 유지보수자들은 면담에서 그때까지 주로 재현 가능한 빌드에 집중해 왔다고 답했고, 악성코드 검사를 적극적으로 하는 곳은 면담한 배포판 가운데 하나뿐이었습니다. 공개 검사 도구 여섯 개는 대부분 멀쩡한 꾸러미를 의심하는 오탐을 쏟아 내면서 진짜 악성코드는 드물게만 잡았습니다 (arXiv:2411.11017, 프리프린트).

두 재단은 이 한계를 이렇게 적었습니다. 이런 공격은 사회공학으로 신뢰를 깨는 것이라 프로그램으로 탐지하거나 막기 어렵고, 자신들의 권고도 끈질긴 사회공학 공격을 막지는 못한다는 것입니다 (OpenSSF·OpenJS 재단 공동 경보).

서명은 파일이 어느 열쇠에서 왔는지를, 재현 가능한 빌드는 결과물이 넣은 소스와 맞는지를 확인해 줄 뿐, 서명한 계정을 믿어도 되는지는 알려 주지 않습니다.

아직 모르는 것

첫째는 누가 했는가입니다. 앞에서 본 대로 문서들은 계정이 한 일과 발견자의 추정까지만 적었습니다. 둘째는 백도어가 어떻게 배포판까지 들어갔고 무엇을 배울 수 있는가에 대한 당사자의 설명입니다. 콜린은 그 글을 쓰고 있지만 생각보다 오래 걸리고 있다고 적었고, 페이지의 마지막 갱신인 2025년 1월 17일까지 그 글은 나오지 않았습니다 (유지보수자 라세 콜린의 공식 페이지).

셋째는 범위입니다. 앞에서 본 대로 몇 대의 시스템이 문제의 판을 받았는지 센 문서는 이 글의 근거 가운데 없습니다. 넷째는 이것이 한 번뿐이었는가입니다. 두 재단은 xz 시도가 고립된 사건이 아닐 수 있다고 했고, 다른 프로젝트들에서 비슷한 패턴을 보고했습니다 (OpenSSF·OpenJS 재단 공동 경보). 그 시도들이 xz와 같은 손에서 나왔는지는 경보가 말하지 않습니다. 재단은 그 방식이 「Jia Tan」이 자리 잡은 방식과 매우 닮았다고만 적었습니다 (OpenSSF·OpenJS 재단 공동 경보).

문지기 곁에 누가 서 있었나

이 하루를 다시 걸으면, 기술의 빈틈보다 사람의 자리가 먼저 보입니다. 자원이 모자란 채 보수 없이 이어 온 프로젝트가 있었고, 도움이 들어왔고, 도운 사람은 사실상 공동 관리자가 됐습니다. 서명은 파일을 만든 계정의 이름을 가리켰고, 백도어의 일부는 공개 저장소 밖에 있었습니다. 그리고 그것을 찾아낸 것은 느려진 로그인을 이상하게 여긴 한 사람의 의심이었습니다.

두 재단의 결론은 장치보다 사람 쪽에 있습니다. 유지보수자를 잘 지원하는 것이 이런 사회공학 공격에 맞서 가진 가장 주요한 억지책이라는 것입니다 (OpenSSF·OpenJS 재단 공동 경보). 산업계 개발자와 설계자 25명을 면담한 연구의 저자들도 기업들에 오픈소스 생태계를 공짜 공급망으로 대하지 말고, 자신들이 덕을 보는 그 생태계를 튼튼하고 안전하게 지키는 데 기여하라고 호소했습니다 (DOI: 10.1109/sp46215.2023.10179378).

기반 소프트웨어를 지키는 일은 코드를 검사하는 데서 끝나지 않고, 그 코드를 몇 안 되는 손으로 지키는 사람들 곁에 누가 시간과 돈을 보태는가에도 달려 있습니다.

사람을 노리는 공격의 기본은 「피싱과 사회공학 — 문을 부수는 대신 초인종을 누른다」에, 소수의 자원봉사자에 기대던 기반 소프트웨어가 무너진 다른 날은 「하트블리드와 OpenSSL — 경계 검사 하나가 빠졌을 때」에, 부품 사슬 속에 숨은 약점이 오래 남는 이야기는 「Log4j 취약점 — 벽 속에 묻힌 부품은 누가 찾아내나」에 이어집니다.

사건 자료

• "backdoor in upstream xz/liblzma leading to ssh server compromise" (2024-03-29) — https://www.openwall.com/lists/oss-security/2024/03/29/4 — 발견자 앤드레스 프로인트의 공개 글. 증상·측정, 처음의 오해, 신고 경로, 위험에 대한 단서 달린 추정, 자신의 한계 고지.
• "XZ Utils backdoor" (사건 뒤 계속 갱신, 마지막 갱신 2025-01-17) — https://tukaani.org/xz-backdoor/ — 당사자인 원 유지보수자 라세 콜린의 공식 페이지. 문제 판본, 만들고 서명한 계정, 접근 권한 범위, 계정 정지·주소 변경·새 판 등 사건 뒤 조치.
• "Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094" (2024-03-29) — https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094 — 미국 사이버보안·인프라보안청(CISA) 경보. 영향 판본, 위험, 이전 판으로 되돌리기 권고.
• "Urgent security alert for Fedora Linux 40 and Fedora Rawhide users" (2024-03-29, 2024-03-30 갱신) — https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users — 레드햇 보안 공지. 영향받은 배포판과 단계, 하루 사이 바뀐 Fedora 40 판단, RHEL에 대한 자기 평가.
• "Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects" (2024-04-15) — https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/ — OpenSSF·OpenJS 재단 공동 경보. 다른 프로젝트의 비슷한 탈취 시도, 의심 징후, 권고와 그 한계.
• "CVE-2024-3094" (조회 2026-10-18) — https://security-tracker.debian.org/tracker/CVE-2024-3094 — 데비안 보안 추적기. 데비안 판별 영향 여부와 개발판의 수정 판.
• "XZ Utils review notes" version 1.0 (2024-05-29) — https://tukaani.org/xz-backdoor/review.html — 유지보수자 라세 콜린의 검토 노트. 공동 관리자 계정의 변경과 배포 파일을 다시 본 결론.
• "Re: [xz-devel] XZ for Java" 스레드 중 다섯 통 (2022-05-19 ~ 2022-06-29) — https://www.mail-archive.com/xz-devel@tukaani.org/msg00563.html — xz 개발 메일링 리스트, 2022년. 유지보수 부담과 관리자 교체 재촉이 오간 기록.

근거 논문

• "SoK: Taxonomy of Attacks on Open-Source Software Supply Chains" (2023) — DOI: 10.1109/sp46215.2023.10179304 — 코드 기여부터 꾸러미 배포까지 공격 나무로 107개 경로, 실제 사건 94건, 막는 장치 33가지.
• "Wolves in the Repository: A Software Engineering Analysis of the XZ Utils Supply Chain Attack" (2025) — DOI: 10.1109/msr66628.2025.00026 — GitHub 기록으로 xz 공격 시간표를 다시 짜, 공동체 운영부터 자동 빌드 설정까지 개발 과정 전체가 정당성 확보와 장기 통제에 쓰였다고 분석.
• "Beneath the Mask: Can Contribution Data Unveil Malicious Personas in Open-Source Projects?" (2025) — arXiv:2508.13453 (프리프린트) — 기여 계정 감시 도구는 없다고 지적하고, 공개 기여 기록 그래프 분석으로 그 계정의 다른 프로젝트 이상 행동을 찾아낼 수 있음을 보임.
• "On the abandonment and survival of open source projects: An empirical investigation" (2019) — DOI: 10.1109/esem.2019.8870181 — 인기 프로젝트 1,932개 중 315개(16%) 버려짐, 그중 128개(41%)는 새 핵심 개발자로 생존. 장벽은 시간 부족과 권한 얻기의 어려움.
• "Identifying Critical Projects via PageRank and Truck Factor" (2021) — DOI: 10.1109/msr52588.2021.00017 — 간접 의존이 가장 많은 부품 가운데 핵심 개발자 한 명에 기대는 것들을 찾아냄.
• "Underproduction: An Approach for Measuring Risk in Open Source Software" (2021) — DOI: 10.1109/saner50967.2021.00043 — 데비안 소스 꾸러미 21,902개·버그 461,656건으로 일손 공급이 수요에 못 미치는 과소생산이 널리 설치된 부품에 넓게 나타남을 보임.
• "Stress and burnout in open source" (2020) — DOI: 10.1145/3377816.3381732 (4쪽 짧은 논문) — 잦은 요구와 공격적 말투에서 오는 높은 스트레스, 유해한 대화가 개발자를 소진시킬 수 있음.
• "Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective" (2024) — arXiv:2408.06723 (프리프린트) — 유지보수자 10명 면담. 일과 삶의 균형·사회적 압력 관리 등 인간 요인과, 핵심 조건으로서의 자금.
• "Signing in Four Public Software Package Registries: Quantity, Quality, and Influencing Factors" (2024) — DOI: 10.1109/sp54263.2024.00215 — 서명 채택은 저장소 정책이 좌우하고 공격이 알려진 것으로는 늘지 않음. 많은 공급망 공격은 서명으로 완화 가능.
• "Reproducible Builds: Increasing the Integrity of Software Supply Chains" (2021) — DOI: 10.1109/ms.2021.3073045 — 코드를 믿는 것과 실행 파일을 믿는 것은 다르며, 재현 가능한 빌드는 실행 파일이 원래 소스와 맞는지 가려낼 수 있음.
• "Does Functional Package Management Enable Reproducible Builds at Scale? Yes." (2025) — DOI: 10.1109/msr66628.2025.00115 — Nix 꾸러미 709,816개 재빌드에서 비트 단위 재현율 69~91%(상승), 재빌드 가능률 99% 이상, 실패의 약 15%는 박혀 들어간 빌드 날짜 탓.
• "Causes and Canonicalization of Unreproducible Builds in Java" (2025) — DOI: 10.1109/tse.2025.3627891 — 재현되지 않던 결과물 12,803개에서 새 도구로 성공률 9.48% → 26.60%.
• "A Study of Malware Prevention in Linux Distributions" (2024) — arXiv:2411.11017 (프리프린트) — 배포판들은 주로 재현 가능한 빌드에 집중, 적극적 악성코드 검사는 한 곳뿐. 공개 검사 도구 여섯 개는 오탐이 많고 진짜 악성코드는 드물게 잡음.
• "“Always Contribute Back”: A Qualitative Study on Security Challenges of the Open Source Supply Chain" (2023) — DOI: 10.1109/sp46215.2023.10179378 — 산업계 25명 면담. 기업들에 오픈소스를 공짜 공급망으로 대하지 말고 생태계의 건강과 보안에 기여하라고 호소.