Log4j 취약점 — 벽 속에 묻힌 부품은 누가 찾아내나

기록 부품 하나

2021년 11월 24일, 중국 알리바바 클라우드 보안팀의 한 보안 엔지니어가 비영리 법인 Apache 소프트웨어 재단(ASF)에 이메일을 보냈습니다. 재단이 돌보는 소프트웨어 Log4j에서 취약점을 찾았다는 보고였습니다 (미국 사이버안전검토위원회 보고서). 당사자인 Apache 로깅 프로젝트의 보안 페이지는 발견자를 이 팀의 천자오쥔(Chen Zhaojun)으로 밝힙니다 (Apache 로깅 프로젝트 보안 페이지). 취약점은 「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」에서 말한 대로, 공격자가 파고들어 만든 사람이 뜻하지 않은 일을 일으킬 수 있는 시스템의 약한 자리입니다. 이 보고는 몇 주 뒤, 전 세계 수천 명의 보안 전문가가 한꺼번에 매달린 사건이 됩니다 (미국 사이버안전검토위원회 보고서).

Log4j는 자바라는 프로그래밍 언어로 짠 기록 프레임워크로, 시스템에서 일어난 활동 정보를 모으고 관리합니다 (미국 사이버안전검토위원회 보고서). 프로그램이 돌아가는 동안 무슨 일이 있었는지 적어 두는 일, 곧 기록을 맡는 부품입니다. 오픈소스(open source)는 만든 사람이 코드를 공개해 누구나 읽고 가져다 쓰고 고칠 수 있게 한 소프트웨어입니다. Log4j도 오픈소스입니다. Log4j는 쓰기 쉽고, 무료로 내려받을 수 있고, 맡은 일을 잘해 자바 개발자들에게 인기를 얻었습니다. 개발자들은 이것을 수천 개의 다른 소프트웨어 패키지 안에 박아 넣었습니다 (미국 사이버안전검토위원회 보고서).

라이브러리(library)는 여러 프로그램이 같은 기능을 저마다 짜지 않고 가져다 끼워 쓰도록 만들어 둔 코드 묶음입니다. Log4j가 그런 부품입니다. 집을 지을 때 경첩을 직접 깎지 않고 규격 부품을 사다 다는 것과 비슷합니다. 의존성(dependency)은 한 프로그램이 제대로 돌아가려고 안에 함께 넣어 쓰는 다른 소프트웨어 부품입니다. 라이브러리를 끼워 넣으면 그 라이브러리는 그 프로그램의 의존성이 됩니다. 보안 기업 Sonatype의 집계를 옮긴 위원회 보고서에 따르면, Log4j는 2021년 8월부터 11월까지 석 달 동안 2,860만 번 내려받혔고, 2021년 12월 14일까지 7,000개 가까운 오픈소스 프로젝트가 Log4j를 의존성으로 쓰고 있었습니다 (미국 사이버안전검토위원회 보고서).

이 부품을 돌본 것은 자원봉사자 한 무리였습니다. 그들은 재단 산하 프로젝트로 Log4j를 유지보수했고, 재단은 그 프로젝트를 지원하는 비영리 법인입니다 (미국 사이버안전검토위원회 보고서). Log4j 2판은 2012년에 처음 나왔습니다. 2013년, 정식판이 나오기 전에 프로젝트 팀은 표준 절차를 거쳐 데이터 저장과 조회를 쉽게 하려는 커뮤니티의 제안 기능을 받아들였고, 7월 18일 그 기능을 검토해 코드에 반영했습니다 (미국 사이버안전검토위원회 보고서).

이 글이 따르는 공개 문서는 여섯입니다. 중심 문서는 미국 사이버안전검토위원회(CSRB)가 2022년 7월에 낸 보고서입니다. 이 위원회는 바이든 대통령의 행정명령으로 세운 정부 산하 위원회로 국토안보부 장관에게 권고하며, 이 첫 검토의 위원 15명 가운데 8명이 연방 기관 소속이고 7명이 민간 기업과 비영리 단체에서 왔습니다. 위원회는 스스로 「독립 검토」라 밝히고, 집행·규제 기관이 아니며 책임 소재를 가리지 않는다고 적습니다. 검토를 의뢰한 것은 미국 사이버보안·인프라보안청(CISA)의 국장이고, 위원 가운데 CISA 소속도 있습니다 (미국 사이버안전검토위원회 보고서). CISA는 미국 정부의 사이버보안 기관이고, 그 대응 지침이 둘째 문서입니다. 나머지 넷은 당사자 Apache 쪽 문서로, 재단 공지(2021년 12월 14일), 재단 회장 데이비드 낼리의 2022년 2월 미국 상원 증언, 재단 보안 부회장 마크 콕스의 2021년 보안 보고서, 그리고 지금도 고쳐 쓰는 로깅 프로젝트 보안 페이지입니다. 이 글은 미국 정부와 Apache의 문서를 따라 해외에서 일어난 사건을 걷습니다.

작고, 공짜이고, 맡은 일을 잘하는 부품이었기에 Log4j는 셀 수 없이 많은 프로그램의 벽 속으로 들어갔습니다.

보고에서 공개까지 열엿새

재단은 Log4j가 워낙 널리 쓰여 취약점 정보의 공개를 미뤄 두는 것은 비현실적이라고 판단했습니다 (미국 사이버안전검토위원회 보고서). 재단은 이르면 11월 29일부터 누구나 볼 수 있는 공개 저장소에서 수정 코드를 검토했고, 12월 5일 수정을 반영했으며, 12월 6일 출시 후보판을 냈습니다. 그때 보안 공지는 내지 않았습니다 (미국 사이버안전검토위원회 보고서). 위원회는 여기서 오픈소스의 한 성질을 짚습니다. Log4j 같은 프로젝트는 코드를 공개된 곳에서 개발하기 때문에, 보안 수정도 만들어지는 도중에 남의 눈에 보입니다 (미국 사이버안전검토위원회 보고서). 위원회의 관찰대로라면 오픈소스 프로젝트는 공지와 대응을 수정과 동시에 시작해야 할 수도 있습니다.

12월 9일, 알리바바 엔지니어가 재단에 다시 이메일을 보냈습니다. 이 취약점이 중국 메신저 위챗에서 논의되고 있다는 내용이었습니다. 그 글을 올린 중국 보안 업체는 어디서 알았는지 묻는 위원회에 답하지 않았습니다. 위원회는 그들이나 관련된 누군가가 출시 후보판에서 취약점을 알아냈다는 가설을 「합리적」이라 하면서도 확인하지 못했다고 적었습니다 (미국 사이버안전검토위원회 보고서).

재단은 원래 계획보다 앞당겨 12월 10일 고친 판 2.15.0을 공개했고, 같은 날 취약점의 공용 번호인 CVE-2021-44228도 공개됐습니다 (미국 사이버안전검토위원회 보고서). 고친 판, 곧 「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」에서 말한 패치는 이미 내놓은 프로그램의 취약점을 고쳐 다시 내보내는 수정본입니다. 위원회 보고서는 취약점이 세상에 드러난 날을 12월 9일로, 고친 판이 공식으로 나온 날을 12월 10일로 따로 적습니다. 아래에 나오는 측정 연구 하나는 공개일을 12월 10일로 잡고, 이 취약점을 Log4Shell이라 부릅니다 (DOI: 10.1109/tnsm.2024.3440188).

미국 국립표준기술연구소(NIST)의 취약점 데이터베이스는 이 취약점에 심각도 점수 최고점인 10.0을 매겼습니다. 공격이 복잡하지 않고, 권한도 필요 없고, 사용자가 무엇을 누를 필요도 없다는 뜻입니다 (미국 사이버안전검토위원회 보고서). CISA는 인증을 거치지 않은 원격 행위자가 이 취약점으로 영향받은 시스템을 장악할 수 있다고 적었습니다 (CISA 대응 지침). 재단 회장은 2013년에 Log4j에 더한 기능이 자바 실행 환경의 한 부분과 맞물려 이 결함을 드러냈고, 결함은 여러 해 동안 잠복해 있었다고 증언했습니다 (Apache 재단 회장 상원 증언). 그 결과 프로그램이 기록하라고 넘겨받은 글자 속에 특정한 지시가 숨어 있으면, 그 지시를 따라 바깥에서 코드를 불러와 실행해 버릴 수 있었습니다 (arXiv:2407.00246, 프리프린트). 이 라이브러리를 쓰면서 인터넷 쪽으로 창구를 열어 둔 서비스는 어느 것이든 잠재적으로 취약했습니다 (DOI: 10.1109/tnsm.2024.3440188). 취약한 판의 부품 하나가, 그것을 쓴 서비스에 바깥으로 난 창문이 될 수 있었던 것입니다.

고친 판이 세 번 더 나온 18일

12월 10일의 판으로 끝나지 않았습니다. 공개 뒤 연구자들이 추가 취약점을 잇달아 찾았고 재단은 판을 거듭 냈습니다 (미국 사이버안전검토위원회 보고서). 12월 13일 2.16.0이 나왔고 (Apache 재단 공지), 이튿날 공개된 두 번째 취약점(CVE-2021-45046)은 이 판에서 고쳐졌습니다. 12월 18일에는 서비스를 멈추게 할 수 있는 취약점이 2.17.0에서, 12월 28일 공개분은 2.17.1에서 고쳐졌습니다 (미국 사이버안전검토위원회 보고서).

두 번째 취약점의 무게는 같은 당사자의 문서 안에서 달라졌습니다. 12월 14일 재단 공지는 2.15.0이 가장 심각한 취약점은 고쳤지만 일부 기본값이 아닌 설정에서 수정이 불완전해, 공격자가 서비스 거부 공격, 곧 서비스를 멈추게 하는 공격을 할 수 있었다고 적었습니다 (Apache 재단 공지). 지금의 로깅 프로젝트 보안 페이지는 같은 취약점을 원격 코드 실행으로, 심각도를 「9.0 CRITICAL」로 적습니다 (Apache 로깅 프로젝트 보안 페이지). 위원회도 이것을 원격 코드 실행 취약점으로 적었습니다 (미국 사이버안전검토위원회 보고서). 첫 공지의 평가가 나중에 올라간 것입니다.

고친 판은 자바 버전마다 갈래가 나뉘기도 했습니다. 첫 취약점은 자바 6용, 자바 7용, 자바 8 이상용 판에서 따로 고쳐졌습니다 (Apache 로깅 프로젝트 보안 페이지). 12월 14일 재단 공지가 자바 7용으로 적은 판은 2.12.2였는데 (Apache 재단 공지), 12월 28일 CISA는 자바 8용 2.17.1, 자바 7용 2.12.4, 자바 6용 2.3.2로 올리라고 촉구했습니다 (CISA 대응 지침). 같은 자바 7을 쓰는 곳이라도 2주 사이에 올려야 할 판이 바뀐 것입니다. 위원회는 추가 취약점이 빠르게 이어지며 혼란과 「패치 피로」가 커졌고, 기관들은 어느 판으로 올려야 하는지 새 정보를 실시간으로 따라가야 했다고 적었습니다 (미국 사이버안전검토위원회 보고서).

재단 회장은 상원에서 완전한 해결책이 보고 약 2주 뒤에 나왔다고 말했습니다 (Apache 재단 회장 상원 증언). 같은 시기를 위원회 보고서와 CISA 지침의 날짜로 따라가면, 마지막 판이 나온 12월 28일은 보고일인 11월 24일부터 약 5주 뒤입니다. 두 셈은 「완전한 해결」을 어느 판에 두느냐에 따라 갈립니다. 판을 하나씩 따라가야 했던 쪽에게 고친 판은 한 번에 오지 않았습니다.

공격은 언제 시작됐나

알려진 가장 이른 악용은 한 기술 서비스 기업이 12월 1일부터 이틀 동안 관측한 활동입니다. 개념 증명(proof of concept)은 취약점이 실제로 통한다는 것을 보이려고 만든 시험용 코드입니다. 그 기업은 이 활동이 알리바바 엔지니어의 개념 증명을 시험한 것과 일치한다고 평가했습니다 (미국 사이버안전검토위원회 보고서). 위원회는 기밀·비기밀 정부 정보와 업계 자료를 검토하고도, 12월 9일 공개 이전에 중국·이란·북한·러시아 행위자를 포함해 누군가 실제로 더 악용했다는 증거를 찾지 못했습니다 (미국 사이버안전검토위원회 보고서).

당사자 쪽 기록은 다르게 들립니다. 재단 보안 보고서는 이 취약점이 고친 판이 나오기 전날부터 널리 악용됐다고 적었습니다 (Apache 재단 2021 보안 보고서). 12월 10일 판을 기준으로 하면 그 전날은 12월 9일이고, 위원회가 공개일로 적은 날과 같습니다. 그래서 두 문서는 날짜로는 부딪히지 않습니다. 다만 그림이 다릅니다. 위원회 기록에서 공개 전 활동으로 확인된 것은 시험과 일치한다는 그 이틀뿐입니다. 12월 1일을 「공격이 시작된 날」로 옮기면, 시험 활동과 일치한다는 위원회의 단서가 떨어져 나갑니다.

공개 뒤에는 빨랐습니다. 한 기술 서비스 기업은 공개 2시간도 안 돼 이 취약점을 찾는 탐색이 급증하는 것을 보았고, 공개 5일 뒤 인터넷 기업 Cloudflare는 초당 400건의 악용 시도를 관측했습니다. 둘 다 위원회 보고서가 옮긴 기업들의 관측입니다 (미국 사이버안전검토위원회 보고서). 탐색하는 쪽에는 공격자만 있지 않았습니다. 연구자와 보안팀도 많은 탐색을 만들어 악의적 활동과 구별하기 어려웠고, 보안 기업 Akamai는 공개 첫 주에 관측된 악용 활동의 약 57%가 알려진 악성 행위자에게서 왔다고 평가했습니다. 이것도 위원회 보고서가 옮긴 평가입니다 (미국 사이버안전검토위원회 보고서).

여러 관측 지점에서 공개 뒤 두 달을 자세히, 그 뒤 한 해를 이어서 잰 측정에서도 같은 흐름이 보였습니다. 공개 직후 몰려든 탐색은 빨리 잦아들었지만 2022년 내내 물결처럼 다시 일었고, 해가 없는 탐색자는 처음 며칠만 관심을 보였으며 악의적 탐색자는 계속 이 취약점을 겨눴습니다. 그 관측 지점들에서 악의적 활동의 대부분은 한 주체에게서 나온 것으로 보였습니다 (DOI: 10.1109/tnsm.2024.3440188). 인도에 둔 관측망으로 2025년 10월까지 잰 결과에서도 이 취약점을 노리는 활동은 몇 해 동안 이어졌고, 점점 적은 수의 되풀이되는 시설로 모였습니다. 이 결과는 앞선 한 연구와 시간 흐름은 맞지만, 관측 지점의 위치와 범위 때문에 체계적인 차이도 있습니다 (arXiv:2601.04281, 프리프린트). 두 연구의 관측망에서 공개 첫 주의 소란은 지키는 쪽과 공격하는 쪽이 함께 만들었고, 소란이 가라앉은 뒤까지 남은 쪽은 공격하는 쪽이었습니다.

그 뒤의 일은 위원회가 보안 기업의 관측을 옮겨 적었습니다. 한 사이버보안 기업은 2022년 1월부터 3월까지 이 취약점을 이용한 랜섬웨어 사건 여럿을 조사했습니다. 랜섬웨어는 「피싱과 사회공학 — 문을 부수는 대신 초인종을 누른다」에서 말한, 파일을 암호화하는 등으로 못 쓰게 만든 뒤 풀어 주는 대가로 돈을 요구하는 악성코드입니다. 보안 기업 Check Point의 연구자들은 국가 배후 행위자가 이 취약점을 악용하는 것을 관측했고, 사물인터넷 기기를 노리는 봇넷 Mirai의 악용도 보고됐습니다 (미국 사이버안전검토위원회 보고서). 위원회는 특정 행위자가 이 사건을 일으켰다고 귀속하지 않았습니다.

어디에 들어 있는지 알려 줄 목록이 없었다

12월 13일, CISA 국장 젠 이스털리는 이 취약점이 「내 경력에서 본 가장 심각한 것 중 하나, 어쩌면 가장 심각한 것」이라고 말했습니다. 전 세계 수천 명의 보안 전문가가 영향을 받았을 수 있는 수억 대의 기기를 찾아 막으려고 동시에 움직였습니다 (미국 사이버안전검토위원회 보고서). 수억 대는 잠재적으로 영향받은 기기의 수입니다.

찾는 일이 먼저 막혔습니다. 위원회는 Log4j의 포괄적인 「고객 명단」도, 어디에 하위 시스템으로 들어갔는지의 목록도 없다는 사실이 방어를 가로막았다고 판단했습니다. 기업과 공급업체는 자기들이 Log4j를 어디서 쓰는지 찾느라 허둥댔습니다 (미국 사이버안전검토위원회 보고서). 위원회가 든 이유는 둘입니다. Log4j는 다른 소프트웨어 부품 안에 일상적으로 박혀 있어서 그 위에 쌓인 단계나 시스템을 돌리는 쪽에서는 흔히 존재조차 모르고, 흔한 탐색 방식으로는 찾기 어렵습니다. 그리고 업계 관행대로 Log4j 팀과 재단은 누가 그 소프트웨어를 쓰는지, 결국 어떻게 쓰이는지 관리하지도 알지도 않습니다 (미국 사이버안전검토위원회 보고서). 위원회가 방어를 가로막았다고 짚은 것은, 그 부품이 어디에 들어 있는지 알려 줄 목록이 어디에도 없었다는 사실이었습니다.

찾아도 사용자가 혼자 고칠 수 없는 경우가 많았습니다. CISA는 Log4j가 든 제품과 서비스의 취약점은 그 제품을 만든 쪽이 보안 업데이트를 반영해야 고쳐지고, 사용자는 공급업체의 보안 업데이트를 봐야 한다고 안내했습니다 (CISA 대응 지침). 위원회는 많은 기관이 공급업체의 대응에 기대 취약점을 이해하고 고쳤으며, 업체가 고쳤다고 알린 뒤에도 프로그램과 부품 사이의 상호 의존 때문에 걱정을 놓지 못한 곳이 있다고 적었습니다. 고친 판을 까는 일 자체도 위험을 저울질하는 결정이었습니다. 운영이 멈출 수 있는 위험과, 빨리·빠짐없이 고치는 일, 그동안 쓸 보완 조치 사이에서 골라야 했기 때문입니다 (미국 사이버안전검토위원회 보고서).

값은 시간으로 치렀습니다. 한 연방 부처는 자기 네트워크를 지키려고 Log4j 대응에 33,000시간을 썼다고 보고했습니다. 몇 주, 몇 달 이어진 대응은 다른 취약점 대응을 포함한 중요한 일을 늦췄고, 방어 인력의 번아웃을 불러 장기적으로 인력 이탈에 영향을 줄 수 있다고 위원회는 적었습니다 (미국 사이버안전검토위원회 보고서).

CISA는 12월 10일 성명을 내고 같은 날 이 취약점을 「알려진 악용 취약점」 목록에 넣었습니다. 12월 13일에는 웹페이지와 함께 취약한 제품과 부품의 목록을 모으는 공개 저장소를 열어, 대응하는 사람들이 자기 환경 어디에 Log4j가 있는지 파악하도록 도왔습니다. 12월 17일에는 긴급 지시로 연방 민간 기관에 2주 안에 대응하라고 요구했습니다 (미국 사이버안전검토위원회 보고서). 위원회는 많은 일이 「제대로」 됐다고 평가했습니다. 재단의 정립된 개발 절차, 조율된 공개, 빠른 수정, 정부와 업체의 빠른 지침입니다. 그런데도 기관들은 고전했고, 많은 기관이 아직 취약한 Log4j를 다 고치지 못했다고 위원회는 적었습니다 (미국 사이버안전검토위원회 보고서). 정부 대응에 대한 이 평가는 CISA 국장이 의뢰하고 CISA 소속 위원이 참여한 위원회의 평가입니다.

결함이 들어온 2013년에 대해서도 위원회의 해석이 있습니다. 그 기능을 더할 때 보안 영향을 잘 아는 사람이 집중 검토했다면 뜻하지 않은 기능, 곧 취약점을 찾아낼 수 있었겠지만, 2013년 이 프로젝트를 이끈 자원봉사 개발자들에게는 그런 검토를 할 자원이 없었다고 위원회는 판단했습니다. 재단 개발자들은 자동 보안 테스트로는 이 취약점을 잡지 못했을 것이고, 광범위한 코드 감사라면 찾았을지도 모른다고 위원회에 말했습니다 (미국 사이버안전검토위원회 보고서). 위원회는 오픈소스 개발자가 대개 유지보수에 돈을 받지 않고, 특히 깊고 넓게 깔린 옛 판은 더 그렇다며 Log4j를 그 극단적 사례로 꼽았습니다. 자원봉사 기반의 이 공동체가 업계 표준의 안전한 코딩과 전문가 감사를 해내려면 지속적인 재정 지원과 전문성이 필요하다는 것이 위원회의 결론입니다 (미국 사이버안전검토위원회 보고서).

당사자 쪽도 자기 사정을 적었습니다. 재단 보안 보고서에 따르면 재단의 보안팀과 프로젝트 관리팀은 모두 자원봉사자여서 문제 처리에 공식 기한을 약속하지 않고, 보안 신고 창구는 여러 프로젝트에서 뽑힌 아주 적은 수의 자원봉사자가 맡습니다. 같은 보고서는 재단이 치명적인 문제의 수정판은 대개 빨리 내지만, 사용자들은 여러 해 업데이트하지 않은 옛 문제로 공격받고, 업체들은 알려진 취약점이 고쳐지지 않은 옛 판을 지원이 끝난 뒤에도 쓴다고 적었습니다 (Apache 재단 2021 보안 보고서). 위원회는 책임 소재를 가리지 않는다고 밝힌 기관이고, 원인을 한 사람의 실수보다 검토 자원과 쓰는 쪽의 구조로 적었습니다.

부품 속의 부품

2022년의 평균적인 자바 애플리케이션은 외부 라이브러리 40개에 의존한다는 집계가 있습니다 (DOI: 10.1109/saner56733.2023.00028). 부품이 어디에 들어 있는지 모르게 되는 구조가 여기서 시작됩니다. 간접 의존성(transitive dependency)은 내가 직접 골라 넣은 부품이 제 안에 다시 넣어 데려온 부품입니다. 개발자는 자기가 고른 부품과 그 판은 직접 정하지만, 간접 의존성은 직접 고르지 않으며 바꾸려면 따로 손을 써야 합니다. 그런 간접 의존성은 흔히 직접 고른 것보다 수가 많습니다 (arXiv:2310.07847, 프리프린트 — 자바스크립트 생태계 연구).

취약점도 그 길로 들어옵니다. 자바 부품 저장소 Maven Central의 판 약 400만 개 가운데 취약점을 직접 가진 판은 약 1%였지만, 간접 의존성을 거쳐 취약점의 영향을 받는 판은 약 46.8%였습니다 (DOI: 10.1109/msr66628.2025.00063). 이 수치는 Log4j만이 아니라 알려진 취약점 전반을 센 것입니다. 소수의 취약한 부품이 많이 쓰이면 생태계의 넓은 부분이 영향을 받는다는 것이 저자들의 해석입니다.

반대쪽 근거도 같은 생태계에서 나왔습니다. Maven 패키지 300만 개를 본 다른 연구에서는 간접 의존성까지 다 따져야만 취약한 것으로 잡히는 패키지가 약 3분의 1이었습니다. 그런데 의존성 속 취약한 코드까지 실제로 호출이 닿는 길이 있는 패키지는 전체의 1% 미만으로, 의존성 목록만 보고 센 것보다 훨씬 적었습니다 (DOI: 10.1109/saner56733.2023.00028). 취약한 부품이 집 안에 있다는 것과 그 부품의 약한 자리가 바깥에서 닿는다는 것은 다른 문제입니다. 다만 그것을 가리려면 부품이 어디 있는지부터 알아야 합니다.

이 구조를 한 회사의 자리에서 따라가 봅니다. 그 회사는 Log4j를 고른 적이 없고, 업체에서 산 제품을 썼을 뿐입니다. 그 제품 안의 한 부품에 Log4j가 들어 있다면, 회사는 위원회가 말한 「나중 단계」에 있어 그 존재를 모르기 쉽습니다 (미국 사이버안전검토위원회 보고서). 12월 10일 Log4j의 고친 판이 나와도 그 회사의 시스템 속 Log4j는 그대로입니다. 그 제품을 만든 쪽이 업데이트를 반영해야 고쳐지기 때문입니다 (CISA 대응 지침). 고친 판은 벽 속의 부품에서 시작해, 부품을 감싼 부품과 제품을 거쳐 한 칸씩 바깥으로 나와야 그 회사에 닿습니다.

고친 판이 나와도 남는 이유

그 한 칸 한 칸에서 고친 판이 멈출 수 있습니다. 업체 제품 쪽에서는 위원회가 기관들의 업체 의존을 적었고, 오픈소스 부품 사이에서는 한 프리프린트가 그 막힘을 수치로 보였습니다. 그 프리프린트에 따르면 취약점이 공개된 뒤 고친 판이 곧바로 나와도 Maven 생태계의 라이브러리와 애플리케이션은 취약한 판을 계속 쓰고, 저자들은 2023년 시점에도 Log4Shell이 Maven 생태계에 크게 영향을 미치고 있다고 적었습니다. 저자들은 위쪽 라이브러리에 막힌 고친 판이 이 지속의 원인이라는 것을 보였고, 막힌 판 범위를 자동으로 풀어 주는 도구도 제안했습니다 (arXiv:2308.03419, 프리프린트). 위쪽 부품이 판을 올리지 않으면 그 아래 프로젝트는 고친 판으로 옮기기 어렵다는 뜻입니다.

자바 프로젝트들이 Log4j를 갱신하는 데에도 지연이 있었고, 판을 자주 내는 프로젝트일수록 심각한 보안 문제를 더 빨리 고치는 경향이 있었습니다 (arXiv:2504.09834, 프리프린트). 더 오래된 판도 남아 있습니다. Log4j 1판은 2015년에 지원이 끝났고, 2015년 8월 이후 보고된 1판 취약점은 확인도 수정도 하지 않습니다 (Apache 로깅 프로젝트 보안 페이지). 재단은 그런데도 1판이 일부 애플리케이션의 의존성으로 아직 쓰인다는 것을 안다고 밝혔고 (Apache 재단 공지), 지원이 끝난 1판이 여전히 쓰인다는 분석도 있습니다 (arXiv:2504.03167, 프리프린트). 1판에 대해서는 문서마다 무게가 다릅니다. 위원회는 1.2판에 영향을 주는 원격 코드 실행 취약점을 따로 적었고 (미국 사이버안전검토위원회 보고서), 당사자 로깅 프로젝트는 1판에는 2판의 한 기능이 없어 위험이 더 낮다고 적습니다 (Apache 로깅 프로젝트 보안 페이지). 다만 지원이 끝난 1판은 그 밖의 취약점도 더는 고쳐지지 않습니다.

Log4j만이 아닌 취약점 전반을 잰 연구들에서도 지연은 흔합니다. 앞의 Maven Central 연구에서 심각도가 높거나 치명적인 취약점까지 포함해 고치는 데 걸린 시간은 흔히 몇 해에 걸쳤습니다 (DOI: 10.1109/msr66628.2025.00063). 여러 언어의 오픈소스 프로젝트에서는 대부분의 언어에서 취약한 의존성이 간접 의존성이었고, 치명적인 취약점은 고쳐지기 전까지 평균 1년 넘게 남았습니다 (DOI: 10.1109/issre62328.2024.00020). 판을 올리는 일에는 부담도 따릅니다. 일곱 생태계의 보안 수정판 가운데 13.2%는 판 번호로 이전 판과 호환되지 않을 수 있다고 표시했습니다 (DOI: 10.1109/tse.2022.3181010). Log4j에서는 고친 판이 18일 사이에 세 번 더 나왔고, 위원회는 고친 판을 까는 일 자체가 운영 중단과 신속성 사이의 위험 결정이었다고 적었습니다 (미국 사이버안전검토위원회 보고서).

풍토병 같은 취약점(endemic vulnerability)은 고친 판이 나온 뒤에도 한꺼번에 사라지지 않고 시스템 곳곳에 오래 머무는 취약점입니다. 위원회는 Log4j를 바로 그런 취약점으로 판정했고, 취약한 Log4j가 앞으로 여러 해, 어쩌면 10년 이상 시스템에 남을 것이라고 내다봤습니다 (미국 사이버안전검토위원회 보고서). 당사자 재단 회장도 Log4j가 거의 어디에나 쓰여서, 배포된 취약한 사례가 다 없어지기까지 몇 달 또는 몇 년이 걸릴 수 있다고 증언했습니다 (Apache 재단 회장 상원 증언). CISA는 2022년 4월 8일 지침을 고쳐, 기관들이 취약한 Log4j를 계속 찾아 고치고 장기적인 취약점 관리를 계획해야 한다고 적었습니다. 초기 정보가 부족해 일부 자산만 살폈을 수 있으니 자체 개발 소프트웨어와 인터넷에 노출되지 않은 시스템까지 포함하라는 권고였습니다 (CISA 대응 지침). 고친 판이 나와도 취약점이 남는 까닭으로 문서와 연구가 가리키는 것은, 부품의 사슬과 판을 올리는 일의 부담입니다.

자재 명세서는 어디 있었나

Log4j 사건 반년여 전인 2021년 5월, 미국 백악관이 소프트웨어 공급망 보안을 높이려는 행정명령을 내면서 한 대책이 널리 알려졌습니다 (DOI: 10.1145/3664476.3669975). 집을 지을 때 쓴 자재의 목록을 남기듯, 소프트웨어도 부품 목록을 남기자는 생각입니다. 소프트웨어 자재 명세서(SBOM)는 한 소프트웨어 안에 어떤 부품이 어떤 판으로 들어 있는지 적은 목록입니다. 위원회는 SBOM이 이론상 기관이 자기 환경의 취약한 부품을 찾게 해 줘야 한다고 보면서도, 위원회가 들은 SBOM 사용 기관 대표들 가운데 누구도 취약한 Log4j를 찾는 데 SBOM을 활용했다고 보고하지 않았다고 적었습니다. 지금의 SBOM은 항목 표기가 제각각이고 부품의 판 정보가 빠지는 등 한계가 있다는 것이 위원회의 판단입니다 (미국 사이버안전검토위원회 보고서).

당사자 재단 회장은 상원에서 SBOM 같은 생각이 취약점을 막지는 못하지만 취약한 소프트웨어를 찾는 속도를 높여 영향을 줄일 수 있다고 말했습니다. 그러면서 최신 판으로 빨리 올리는 능력이 여전히 소프트웨어 업계의 큰 걸림돌이라고 덧붙였습니다 (Apache 재단 회장 상원 증언).

연구는 이 목록이 아직 드물고 불완전하다는 쪽을 가리킵니다. 깃허브의 공개 저장소에서 SBOM 채택은 낮지만 늘어나는 추세였고, SBOM 파일을 실제로 구할 수 있는 곳은 그 가운데 절반이 안 됐습니다 (DOI: 10.1109/icsme58846.2023.00016). 네 언어의 작은 시험 프로젝트에 SBOM 도구들을 돌려 보니 모든 요건을 채운 도구가 없었고, 많은 도구가 부품과 의존성을 빠짐없이 적지 못했습니다 (DOI: 10.1145/3664476.3670926). Log4j를 시험 사례로 오픈소스 SBOM 도구 넷을 평가한 결과, 도구들은 그 부품이 들어 있다는 것과 그런 종류의 취약점이 있다는 것까지는 알려 주지만, 그 코드에 실제로 닿는지는 판단하지 못했습니다 (arXiv:2609.05380, 프리프린트).

위원회는 권고 가운데 하나로 SBOM 도구와 채택 가능성을 개선하라고 적었습니다 (미국 사이버안전검토위원회 보고서). 자재 명세서는 찾는 일을 빠르게 할 수는 있어도, 고치는 일을 대신하지는 않습니다.

얼마나 당했는지는 아직 모른다

CISA는 이 취약점의 「활발하고 광범위한 악용」에 대응하고 있다고 적었고 (CISA 대응 지침), 당사자 재단 보안 보고서는 「널리 악용됐다」고 적었습니다 (Apache 재단 2021 보안 보고서). 피해의 크기를 두고 위원회는 다른 말을 합니다. 위원회는 2022년 7월 작성 시점에 Log4j를 이용한 주요 기반시설 대상의 중대한 공격을 알지 못한다고 적었습니다. 그리고 다소 놀랍게도, 대체로 악용은 취약점의 심각도에 비해 많은 전문가가 예상한 것보다 낮은 수준이었다고 판단하면서, 이 결론에 이르기가 어려웠다고 덧붙였습니다 (미국 사이버안전검토위원회 보고서).

위원회는 이런 사정도 함께 적었습니다. 지역과 산업, 생태계 전반의 악용 추세를 알려 줄 권위 있는 출처가 없고, 많은 기관이 Log4j 악용 정보를 따로 모으지도 않으며, 보고는 대체로 자발적입니다. Log4j 관련 침해 정보를 모은 중앙 저장소도 없습니다 (미국 사이버안전검토위원회 보고서). 몇 개 시스템이 영향을 받았느냐는 질문에 당사자 재단은 재단의 프로젝트와 다른 오픈소스, 여러 제품에 들어 있다는 것만 안다며, 그 이상의 숫자는 추측일 뿐이고 크게 틀릴 것이라고 답했습니다 (Apache 재단 공지).

위원회는 자기 검토의 한계도 밝혔습니다. 90일 동안 모든 분야에 닿지 못했고, 의료기기·사물인터넷·가정용 네트워크 장비는 다른 경험을 했을 수 있으며, 미국 밖의 기관도 이 사건을 다르게 겪었을 수 있습니다. 그리고 위원회는 이 사건이 끝나지 않았다고 적었습니다 (미국 사이버안전검토위원회 보고서). 앞의 초당 400건과 측정 연구의 물결은 시도를 센 것이고, 그 시도 가운데 얼마가 실제 침해가 됐는지는 이 글이 따른 어느 문서도 세지 못했습니다. 공격 시도는 셀 수 있었지만, 실제 피해는 권위 있게 센 곳이 없습니다.

의의

고친 판이 나온 날은, 그 부품이 어디 있는지 찾는 일이 시작된 날이었습니다. 위원회가 가장 먼저 둔 권고도 같은 방향입니다. 기관들은 앞으로 여러 해 Log4j 취약점에 대비해야 한다는 것입니다. 위원회는 오픈소스 보안 투자를 늘리고, 핵심 서비스에 쓰이는 오픈소스의 유지보수 지원을 시범으로 해 보라는 권고도 냈습니다 (미국 사이버안전검토위원회 보고서).

연구 쪽에도 같은 빈자리가 보입니다. 저자들이 공급망 공격으로 묶은 SolarWinds·Log4j·xz 세 사건의 위협 정보 보고서를 소프트웨어 공급망 보안 프레임워크 열 개의 과제에 맞대 보니, 지속 가능한 오픈소스 소프트웨어라는 과제가 열 프레임워크 모두에 빠져 있었습니다. 저자들은 기관이 권고된 과제를 모두 따라도 소프트웨어 제품은 여전히 이런 공격에 취약할 것이라고 결론지었습니다 (arXiv:2503.12192, 프리프린트).

기반 소프트웨어를 누가 돈과 사람을 대어 지키느냐, 알려진 취약점을 고치지 못한 뒤에 무엇이 오느냐는 물음은 「하트블리드와 OpenSSL — 경계 검사 하나가 빠졌을 때」와 「Equifax 유출 — 맡긴 적 없는 정보가 털린 다음」에서 이어집니다. 아직 모르는 것은 분명합니다. 이 하루가 실제로 얼마나 많은 집의 문을 열었는지, 그리고 벽 속에 남은 취약한 부품이 몇 해 뒤에 몇 개나 남을지입니다. 패치와 다층 방어의 기본은 「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」에 있습니다.

사건 자료

• "Review of the December 2021 Log4j Event" (2022-07-11) — https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf — 미국 사이버안전검토위원회(대통령 행정명령으로 설치된 정부 산하 위원회, 연방 8명·민간 7명, CISA 국장 의뢰)의 사후 검토. 경과, 공격 관측(보안 기업 자료 인용), 원인 해석, SBOM, 피해 규모 판단과 한계, 권고.
• "Security :: Apache Logging Services" (계속 갱신, 2026-10-18 받은 판) — https://logging.apache.org/log4j/2.x/security.html — 당사자 Apache 로깅 프로젝트의 CVE별 영향 판본·수정 판본·심각도·발견자. 날짜 없음.
• "Apache Log4j Vulnerability Guidance" (2022-04-08 표기, 2021-12-28·2022-04-08 갱신) — https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance — CISA 대응 지침. 광범위한 악용, 권고 판본, 제품을 만든 쪽의 업데이트 반영, 장기 관리.
• "Apache Log4j CVEs" (2021-12-14) — https://news.apache.org/foundation/entry/apache-log4j-cves — 당사자 Apache 재단 공지. 당시 CVE 목록, 2.15.0 수정의 불완전함, 1판 사용, 영향 규모에 대한 답.
• "Foundation Statement at 8 February 2022 Senate Committee hearing on Homeland Security and Government Affairs" (2022-02-08) — https://news.apache.org/foundation/entry/foundation-statement-at-8-february — 당사자 재단 회장 데이비드 낼리의 상원 증언. 2013년 기능과 잠복, 약 2주 뒤 해결책, 몇 달·몇 년, SBOM.
• "Apache Software Foundation Security Report: 2021" (2022-01-10) — https://blogsarchive.apache.org/foundation/entry/apache-software-foundation-security-report2 — 당사자 재단 보안 부회장 마크 콕스의 연간 보고. 수정판 전날부터 널리 악용, 자원봉사 운영 실태, 지원 끝난 옛 판 사용.

근거 논문

• "The Log4j Incident: A Comprehensive Measurement Study of a Critical Vulnerability" (2024) — DOI: 10.1109/tnsm.2024.3440188 — 공개일(12월 10일)부터 여러 관측 지점에서 측정. 첫 탐색 러시는 빨리 잦아들었으나 2022년 내내 물결, 해 없는 탐색자는 처음 며칠만, 악의적 탐색은 지속, 악의적 활동 대부분이 한 주체.
• "A Longitudinal Measurement Study of Log4Shell Exploitation from a Reactive Network Telescope" (2026) — arXiv:2601.04281 (프리프린트) — 인도 관측망, 2021년 12월~2025년 10월. 악용 활동이 몇 해 지속되며 적은 수의 되풀이되는 시설로 집중. 관측 지점에 따른 체계적 차이.
• "SBOM.EXE: Countering Dynamic Code Injection based on Software Bill of Materials in Java" (2024) — arXiv:2407.00246 (프리프린트) — Log4Shell은 실행 중 악의적 입력을 처리해 원격 코드 실행으로 이어진 사례. 허용 목록 기반 방어 제안.
• "On the Effect of Transitivity and Granularity on Vulnerability Propagation in the Maven Ecosystem" (2023) — DOI: 10.1109/saner56733.2023.00028 — 2022년 자바 앱 평균 외부 라이브러리 40개. Maven 300만 패키지 중 약 3분의 1은 간접 의존성까지 봐야 취약으로 잡히고, 취약 코드까지 호출이 닿는 것은 1% 미만.
• "Dependency Practices for Vulnerability Mitigation" (2023) — arXiv:2310.07847 (프리프린트) — 개발자는 의존성의 의존성을 통제하지 못하며, 간접 의존성이 흔히 직접 의존성보다 많다(npm).
• "The Ripple Effect of Vulnerabilities in Maven Central: Prevalence, Propagation, and Mitigation Challenges" (2025) — DOI: 10.1109/msr66628.2025.00063 — 약 400만 판 중 직접 취약 약 1%, 간접 취약 약 46.8%. 고치는 데 흔히 몇 해, 일부는 취약 판을 계속 씀.
• "Mitigating Persistence of Open-Source Vulnerabilities in Maven Ecosystem" (2023) — arXiv:2308.03419 (프리프린트) — 고친 판이 빨리 나와도 취약 판이 지속(Log4Shell 예시), 위쪽 라이브러리에 막힌 패치가 원인임을 정량화. 자동 판 범위 복원 도구 제안.
• "Mining for Lags in Updating Critical Security Threats: A Case Study of Log4j Library" (2025) — arXiv:2504.09834 (프리프린트) — Maven의 Log4j 갱신에 지연이 있고, 판을 자주 내는 프로젝트가 심각한 보안 문제를 더 빨리 해결.
• "Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j" (2025) — arXiv:2504.03167 (프리프린트) — 지원이 끝난 Log4j 1판이 여전히 쓰임.
• "A Comprehensive Study on the Impact of Vulnerable Dependencies on Open-Source Software" (2024) — DOI: 10.1109/issre62328.2024.00020 — 여러 언어 1,000여 프로젝트. 취약 의존성은 대부분 간접, 치명적 취약점은 평균 1년 넘게 남음.
• "Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages" (2022) — DOI: 10.1109/tse.2022.3181010 — 일곱 생태계 보안 공지 4,377건. 보안 수정판은 중앙값 4일, 13.2%가 판 번호로 호환 깨짐 표시.
• "SBOM Ouverture: What We Need and What We Have" (2024) — DOI: 10.1145/3664476.3669975 — SBOM의 인기는 2021년 5월 백악관의 소프트웨어 공급망 보안 행정명령으로 커짐. 생성 도구는 아직 완전 자동화·성숙에 이르지 못함.
• "Software Bill of Materials Adoption: A Mining Study from GitHub" (2023) — DOI: 10.1109/icsme58846.2023.00016 — SBOM 도구를 쓰는 공개 저장소 186개. 채택은 낮지만 증가, 46%에서만 SBOM 파일 이용 가능.
• "Accuracy Evaluation of SBOM Tools for Web Applications and System-Level Software" (2024) — DOI: 10.1145/3664476.3670926 — 모든 요건을 채운 도구 없음, 많은 도구가 불완전한 SBOM.
• "Propagation Model for SSC attacks: Why SBOM (tools) don't tell the whole truth" (2026) — arXiv:2609.05380 (프리프린트) — Log4j를 시험 사례로 SBOM 도구 넷 평가. 구조적 노출·취약점 종류 존재까지만 지원, 코드 도달성·오염 경로는 지원 못 함.
• "Closing the Chain: How to reduce your risk of being SolarWinds, Log4j, or XZ Utils" (2025) — arXiv:2503.12192 (프리프린트) — 위협 정보 보고서 106건을 10개 프레임워크 73개 과제에 대응. 지속 가능한 오픈소스 등 세 과제가 모든 프레임워크에서 빠짐. 모두 따라도 여전히 취약.