Log4j와 Java 보안: ‘패치’되었다고 해서 안전하다는 뜻은 아니다

이 블로그 글의 AI 요약으로 바로 가기

패치가 배포되었고, 티켓은 종결되었으며, 사후 분석 보고서도 제출되었습니다. 그런데도 4년이 넘게 지난 지금도 스캐너들은 계속해서 이 문제를 지적하고 있습니다. 이 글은 ‘패치됨’과 ‘입증 가능한 안전성’ 사이의 간극, 그리고 Log4j가 그 이면의 시스템에 대해 실제로 무엇을 드러냈는지에 관한 이야기입니다.

중대한 보안 사고가 발생한 후에는 특유의 피로감이 찾아옵니다. 패치를 적용하기 위한 분주한 작업, 전 사원 대상 회의, 영향을 받은 시스템을 허둥지둥 파악하는 과정, 그리고 마침내 누군가가 추적 티켓을 닫고 상태란에 ‘해결됨’이라고 적는 순간. 그 마무리가 된 듯한 느낌은 실재합니다. 하지만 많은 경우, 이는 다소 성급한 판단이기도 합니다.

Log4Shell—2021년 12월 아파치 Log4j 라이브러리에서 공개된 치명적인 원격 코드 실행 취약점—은 자바 생태계의 깊숙이 뿌리내린 구성 요소가 보편적으로 존재하며 보편적인 위험 요소로 드러났을 때 어떤 일이 벌어지는지를 보여주는, 최근 기억에 남는 가장 극명한 사례로 남아 있습니다. 이에 대한 대응은 엄청났습니다. 수천 개의 기관이 며칠 만에 패치를 적용했습니다. 정부 기관들은 긴급 지침을 발표했습니다. 보안 팀들은 주말 내내 업무를 처리했습니다.

그럼에도 불구하고 Log4j가 드러낸 자바 보안 문제는 여전히 해결되지 않은 상태입니다. 특정 CVE 자체의 문제가 아니라, 그 문제를 가능하게 했던 조건들과 패치를 적용한 후에도 여전히 남아 있는 불확실성이 문제인 것입니다. 이러한 불확실성을 이해하는 것이야말로 진정한 교훈이며, 이는 어떤 특정 라이브러리를 넘어 훨씬 더 광범위한 영역에 적용되는 교훈입니다.

“패치된”이 실제로 의미하는 바

어떤 조직이 Log4j에 대한 패치를 적용했다고 발표할 때, 그 발표에는 취약한 라이브러리의 모든 인스턴스가 식별되어 업데이트되었다는 암묵적인 가정이 내포되어 있습니다. 실제로는 복잡한 Java 환경에서 이러한 가정을 검증하기가 매우 어렵습니다.

자바 애플리케이션은 JAR 파일, WAR 파일, Maven Shade나 Spring Boot의 내장 패키징과 같은 도구를 통해 생성된 팻 JAR(fat JAR)와 같은 패키지 형태로 배포됩니다. 이러한 패키지는 빌드 시점에 의존성을 함께 묶어 포함합니다. 취약점이 있는 Log4j 버전은 단순히 의존성 매니페스트에 나타나는 것뿐만 아니라, 다른 JAR 파일에 물리적으로 내장되어 있을 수도 있으며, 이 JAR 파일은 다시 WAR 파일 내에 포함되어 있을 수 있습니다. 그리고 이 WAR 파일은 보안 팀이 해당 애플리케이션 서버에서 자바가 실행되고 있다는 사실조차 인지하지 못한 채 배포된 서버에 배포될 수 있습니다.

이러한 깊숙이 뿌리내린 종속성을 체계적으로 파악하고 해결하는 방법을 알아보려면, Log4j 취약점 수정 적용에 관한 당사의 종합 가이드를 참조하십시오.

이는 드문 사례가 아닙니다. Log4Shell 대응 과정에서 보안 연구원들은 해당 라이브러리의 존재 자체를 인지하지 못했던 벤더들의 기업용 소프트웨어 내부에 4~5단계나 중첩된 취약한 Log4j 인스턴스를 발견했습니다. 당시 CISA의 지침은 영향을 받은 모든 자산을 파악할 것을 강조했으며, 초기 스캔만으로는 전체 자산을 완전히 파악하기에 충분하지 않다고 경고했습니다. 이는 구조적인 문제였습니다.

의존성 매니페스트에 선언된 내용과 런타임 시 실제로 실행되는 내용 사이의 차이는 사소한 불일치가 아닙니다. 이는 자바 의존성 관리에서 발생하는 근본적인 가시성 문제이며, Log4Shell 사태로 인해 더 이상 이를 무시할 수 없게 되었습니다.

중대 사고의 장기적인 여파

Log4j와 같은 대규모 보안 사고는 깔끔하게 해결되지 않습니다. 이러한 사고는 ‘긴 꼬리’ 현상을 보입니다. 즉, 누군가가 점검할 것이라고 생각했던 시스템에서는 기술적으로 패치 작업이 완료된 지 오래되었음에도 불구하고, 아무도 기억하지 못한 시스템에는 여전히 취약한 인스턴스가 남아 있는 상황이 장기간 지속되는 것입니다.

Log4j의 장기적인 영향은 유례없이 끈질기게 이어지고 있습니다. 이는 부분적으로 자바가 유난히 고착화된 런타임 환경이기 때문입니다. 자바 애플리케이션은 빈번한 업데이트를 염두에 두고 설계되지 않은 환경에 배포됩니다. 예를 들어 임베디드 산업용 시스템, 레거시 금융 플랫폼, 의료 기기 소프트웨어, 고객이 빌드 과정을 통제할 수 없는 벤더 제공 엔터프라이즈 애플리케이션 등이 이에 해당합니다. 이러한 환경들은 결코 드문 사례가 아닙니다. 오히려 자바 설치 기반의 상당 부분을 차지하고 있습니다.

2021년 12월

CVE-2021-44228이 공개되었습니다. 전 세계적으로 긴급 패치 대응이 시작되었습니다. Log4j 2.15.0이 출시되었으나, 이후 특정 구성 환경에서는 이 패치가 불완전한 것으로 밝혀졌습니다.

2021년 12월 – 2022년 1월

다음은 2021년 12월에 공개된 세 가지 추가 CVE입니다: CVE-2021-45046, CVE-2021-45105, CVE-2021-44832. 2.15.0 버전으로 패치를 적용한 팀은 다시 한 번 패치를 적용해야 합니다. 자산 현황 조사 결과, 벤더 소프트웨어 및 임베디드 시스템에서 예상치 못한 사례가 발견되었습니다.

2022

CISA는 ‘Log4Shell’을 ‘알려진 악용 취약점’ 목록에 추가했으며, 위협 행위자들은 이를 새로운 CVE와 함께 표준 툴킷에 계속해서 포함시켰습니다. 패치가 적용되지 않은 구형 시스템에 대한 악용은 계속되었습니다.

2023년 – 현재

Log4Shell에 대한 스캐닝 및 악용 활동은 공개된 지 수년이 지난 지금도 여전히 발견되고 있으며, 2026년에 실시된 한 종단적 추적 연구에 따르면 관련 트래픽이 2025년 10월까지 지속된 것으로 나타났습니다. 임베디드 및 벤더 제공 Java 애플리케이션은 여전히 지속적인 취약점으로 남아 있습니다. 이 사건은 대부분의 조직의 공식 추적 시스템에서는 ‘해결’된 것으로 기록되어 있지만, 실제 환경에서는 그렇지 않습니다.

이 타임라인은 중요한 사실을 보여줍니다. 주요 취약점은 인시던트 티켓이 종결되었다고 해서 사라지지 않습니다. 이러한 취약점은 초기 대응 과정에서 가장 소홀히 다뤄졌던 인프라의 일부, 즉 IT 부서가 잊고 있던 레거시 시스템, 제조사가 패치를 출시하는 데 6개월이나 걸린 벤더 어플라이언스, 그리고 오래된 베이스 이미지에서 재구축된 컨테이너화된 서비스 등에 여전히 남아 있습니다.

Log4j가 내부 보안 논의에 어떤 변화를 가져왔는가

Log4Shell이 패치 적용을 넘어 조직에 남긴 지속적인 영향이 있다면, 바로 이것이었습니다. 즉, 대부분의 엔지니어링 조직이 자사 소프트웨어에 대해 실제로 얼마나 아는 바가 없는지 냉철하게 직시하게 만들었다는 점입니다.

“Log4j를 사용하고 있는가?”라는 질문에 답하는 일은 누구도 예상했던 것보다 훨씬 어려웠으며, 그 어려움은 생산적인 의미에서 다소 당혹스러웠습니다. 보안 아키텍트들은 대개 사후에 같은 깨달음을 털어놓곤 합니다. 그들은 매니페스트가 있으니 자산 목록이 잘 정리되어 있다고 생각했지만, 매니페스트는 자신이 설치했다고 생각하는 것들의 목록일 뿐, 실제로 실행 중인 것들의 목록은 아니기 때문입니다.

Log4Shell 사태 이전에는 소프트웨어 부품 명세서(SBOM)가 틈새 관심사에 불과했습니다. 즉, 규정 준수 팀에서 논의할 뿐 엔지니어링 팀이 우선순위를 두지 않는 분야였죠. Log4Shell 사태 이후, SBOM에 대한 논의는 주류 보안 관행으로 자리 잡았습니다. Log4j 취약점이 공개되기 몇 달 전인 2021년 5월에 서명된 미국 정부의 소프트웨어 보안 관련 행정 명령은 이미 SBOM을 기본적인 요구 사항으로 제시하고 있었습니다. Log4Shell은 그러한 기대가 왜 타당한지 여실히 보여주었습니다.

대화의 초점은 소유권 문제로 옮겨가기도 했습니다. 대규모 조직에서는 “이 애플리케이션의 종속성을 누가 관리하는가?”라는 질문에 명확한 답을 내리기 어려운 경우가 많습니다. 애플리케이션을 개발한 엔지니어링 팀은 이미 다른 업무로 이동했을 수도 있습니다. 플랫폼 팀은 인프라를 운영합니다. 보안 팀은 취약점을 지적할 수는 있지만 수정 패치를 병합할 수는 없습니다. Log4j 사태는 세 개의 서로 다른 팀이 각기 상대방이 먼저 조치를 취하기를 기다리는 동안, 시간은 계속 흘러가는 상황을 초래했습니다.

신뢰와 공급자 문제

Log4Shell은 또한 정량화하기 어려운 또 다른 측면, 즉 공급업체가 제공하는 소프트웨어에 대한 신뢰까지 훼손했습니다. 많은 조직은 자사가 구매하고 지원 계약 비용을 지불하고 있던 상용 애플리케이션과 어플라이언스에, 공급업체가 공개하지 않았고 합리적인 기간 내에 패치를 적용할 수도 없었던 취약한 Log4j 인스턴스가 포함되어 있음을 발견했습니다. 해당 조직들은 해당 제품에 무엇이 포함되어 있는지 파악할 수 없었을 뿐만 아니라, 공급업체의 대응을 서두르게 할 수 있는 영향력도 전혀 가지고 있지 않았습니다.

이것이 바로 벤더 종속성 문제가 가장 극명하게 드러나는 사례입니다. 타사 애플리케이션을 배포하면, 사용자가 볼 수도 없고, 업데이트할 수도 없으며, 대체할 수도 없는 구성 요소를 포함해 해당 애플리케이션의 전체 종속성 그래프를 그대로 물려받게 됩니다. 보안 팀의 입장에서 보면, 이는 공격 표면이 엔지니어가 작성한 코드를 넘어 벤더가 작성한 코드, 그리고 그 벤더의 벤더가 작성한 코드 등으로까지 확대된다는 것을 의미합니다.

‘가시성 문제’, 간단히 설명하면

대부분의 조직은 자사 환경에서 어떤 것들이 실행되고 있는지 모두 파악하지 못합니다. 조직은 무엇을 배포했는지는 알고 있지만, 배포한 것 안에 무엇이 들어 있었는지는 항상 알지 못합니다. Log4j는 이러한 정보의 공백을 되돌리기 어려운 수준으로 심각한 문제로 만들었습니다.

더 넓은 교훈: Log4j 사태는 단발성 사건이 아니었다

Log4j를 일회성 이상 현상, 즉 유난히 널리 쓰이는 라이브러리의 유난히 위험한 기능으로 인해 발생한 ‘10년에 한 번 있을 법한’ 대재앙으로 치부해 버리는 것이 편할 수도 있다. 이러한 해석은 정도 면에서는 정확하지만, 본질적으로는 오해의 소지가 있다. Log4Shell을 그토록 파괴적으로 만든 요인들은 자바 생태계 전반에 존재하며, 앞으로도 유사한 성격의 사고를 일으킬 것이다.

자바 생태계에는 방대한 레거시 코드가 존재합니다. 보안 관행이 달랐고 위협 모델이 더 좁았던 15년 전에 작성된 라이브러리들이 오늘날에도 여전히 운영 환경에서 실행되고 있습니다. 그중 일부는 수년 동안 손도 대지 않은 애플리케이션의 직접적인 의존성입니다. 또 다른 일부는 오래전에 해당 라이브러리를 흡수한 프레임워크의 전이적 의존성으로, 이를 제거할 이유를 찾지 못한 채 남아 있습니다.

보다 현대적인 패키지 생태계와 달리, 자바의 빌드 도구를 사용하면 모든 것을 단일 배포 가능한 아티팩트로 쉽게 패키징할 수 있습니다. 즉, 스캐너나 보안 사고가 발생하기 전까지는 오래되고 취약한 코드가 새로운 코드와 함께 눈에 띄지 않게 배포되는 것입니다. 이 생태계의 강점(하위 호환성, 안정성, 광범위한 라이브러리 이용 가능성)은 동시에 보안상의 취약점이기도 합니다.

다음 Log4j급 사태를 일으킬 후보는 부족하지 않습니다. Apache Commons Text의 StringSubstitutor 클래스(CVE-2022-42889, 2022년 10월 공개)는 안전하지 않은 변수 삽입을 통해 원격 코드 실행을 가능하게 할 수 있다는 점에서 Log4Shell과 비슷한 수준의 경각심을 불러일으켰으나, 실제 악용 가능성은 Log4Shell보다 훨씬 제한적인 것으로 드러났다. 광범위한 아파치 커먼스 생태계, 다양한 XML 파싱 라이브러리, JNDI 및 RMI 관련 유틸리티 등은 오랫동안 자바 애플리케이션에 사용되어 왔으며, 최신 라이브러리보다 보안 검토가 덜 이루어지고 있어, 다음 중대한 CVE가 발견될 가능성이 높은 구성 요소들입니다.

팀들은 어떻게 적응하고 있는가

Log4j가 드러낸 불확실성에 대한 대응으로, 의존성 위험을 심각하게 여기는 조직들에서 표준으로 자리 잡아가고 있는 일련의 관행들이 마련되었습니다. 이 중 어느 것도 문제를 완전히 해결해 주지는 못합니다. 하지만 이 관행들이 종합적으로 작용함으로써 불확실성을 상당히 줄여주고 있습니다.

01 소프트웨어 자재 명세서(SBOM)

각 팀은 빌드 프로세스의 일환으로 기계가 읽을 수 있는 SBOM을 생성하고 있습니다. Syft, CycloneDX 또는 Maven SBOM 플러그인과 같은 도구를 사용하면 전이적 종속성을 포함하여 배포 아티팩트에 포함된 모든 구성 요소에 대한 감사 가능한 기록을 생성할 수 있습니다. SBOM은 취약점을 방지하지는 않지만, 구성 요소 목록을 파악할 수 있게 해줍니다. 향후 Log4j와 같은 문제가 발생할 경우, 최신 SBOM을 보유하고 있는 조직은 며칠이 아닌 몇 시간 내에 “우리 조직이 영향을 받았는가?”라는 질문에 답할 수 있습니다.

02 CI/CD 환경에서의 지속적인 종속성 스캔

또한 취약점 스캔을 정기적인 감사에서 지속적인 통합 점검으로 전환하고 있습니다. Grype, OWASP Dependency-Check, Snyk와 같은 도구를 활용하면 대응 중심의 태세에서 예방 중심의 태세로 전환할 수 있습니다. 기존 의존성에서 발견된 새로운 취약점은 다음 분기 검토 시점이 아니라 즉시 드러나게 됩니다. 여기서 문제는 ‘경고 피로감’을 관리하는 것입니다. 표시된 모든 CVE가 해당 상황에서 실제로 악용될 수 있는 것은 아니며, 구분 없이 쏟아지는 스캐너 결과물은 금세 무시되기 마련입니다.

03 런타임 모니터링 및 행동 탐지

정적 스캔은 알려진 구성 요소에서 알려진 취약점을 탐지합니다. 스캔 시점에 아직 알려지지 않은 취약점을 악용하려는 시도는 탐지하지 못합니다. 아직 JDK 17부터 23까지를 실행 중인 레거시 환경에서는 Java Security Manager가 제한적인 제어 기능을 제공할 수 있지만, 이 기능은 Java 17에서 제거 예정으로 지정되었으며 JDK 24에서는 영구적으로 비활성화되었으므로, 최신 런타임 보호는 이제 RASP 에이전트와 의심스러운 JNDI 조회 패턴에 대한 네트워크 수준 모니터링에 의존합니다. 이는 빌드 시점이 아닌 런타임 시점에 작동하는 탐지 계층입니다.이는 정적 스캔을 사후 적용하기 어려운 레거시 시스템에서 특히 유용합니다.

04 명시적 소유권 및 문제 해결 SLA

많은 조직에서 Log4j 대응을 지연시킨 책임 소재의 불명확성은 기술적 문제가 아니라 프로세스상의 문제였습니다. 레거시 서비스를 포함한 모든 배포된 애플리케이션에 대해 명확한 책임 소재를 확립하고, 중대한 취약점 시정에 대한 구체적인 SLA를 정의함으로써(책임 소재가 불분명한 경우의 에스컬레이션 절차 포함), “누가 이 문제를 해결해야 하나?”라는 질문이 반복적으로 발생하는 장애 요인에서 체계적으로 관리되는 프로세스로 전환됩니다.

05 표준 지원 범위를 넘어선 도서관용 보안 지원 확대

더 이상 적극적으로 유지보수되지 않는 구버전 라이브러리를 사용하는 자바 애플리케이션의 경우, 일반적인 해결책은 “업그레이드”입니다. 공급업체의 제약, 규제 동결, 또는 취약한 레거시 시스템 등으로 인해 업그레이드가 현실적으로 어려운 경우, 팀은 새로운 메이저 버전으로 전환하지 않고도 보안 패치를 적용할 수 있는 방법이 필요합니다. 다음과 같은 서비스들, 예를 들어 TuxCare의 ‘라이브러리용 엔드리스 라이프사이클 지원(ELS)’ 와 같은 서비스는 지원 대상 라이브러리 버전에 대해 역포트된 보안 수정 사항을 제공하여, 팀이 장기적인 마이그레이션을 계획하는 동안에도 안정성이 검증된 구성을 유지하면서 현재의 취약점으로부터 보호받을 수 있도록 돕습니다. 이는 최종 목표가 아닌 과도기적인 조치이지만, 업그레이드가 수개월이나 남았다는 이유로 패치를 적용하지 않은 상태로 운영해야 하는 상황에서는 매우 의미 있는 해결책입니다.

잔여 불확실성 수용

이 대화에는 체크리스트로 끝나는 버전이 하나 있습니다. SBOM을 구현하고, 스캐닝을 배포하며, 책임 소재를 명확히 하고, 지원 기간을 관리하는 것입니다. 이 단계들을 따르기만 하면 문제가 해결됩니다. 하지만 그 버전은 현실보다 훨씬 단순화되어 있습니다.

솔직히 말해, 복잡한 소프트웨어 시스템에는 완전히 제거할 수 없고 단지 관리만 할 수 있는 잔여 불확실성이 내재되어 있습니다. 환경 내의 모든 종속성을 완벽하게 파악할 수는 없을 것입니다. 다음 중대한 CVE가 공개되기 전에 모든 취약한 라이브러리에 패치를 적용할 수도 없을 것입니다. 공급업체가 제공하는 소프트웨어에는 앞으로도 여러분이 볼 수도 없고 통제할 수도 없는 구성 요소들이 계속 포함될 것입니다.

여러분이 할 수 있는 일은, 사고가 발생해 어쩔 수 없이 논의하게 될 때까지 불확실성이 눈에 띄지 않게 쌓이게 내버려 두는 대신, 그 불확실성을 줄이기 위해 어디에 투자할지 신중하게 결정하는 것입니다. Log4j 사태는 여러 가지 의미에서 ‘촉매제’였으며, 눈에 보이지 않던 의존성 리스크의 대가가 더 이상 부정할 수 없을 정도로 분명해진 순간이었습니다.

Log4Shell 대응을 통해 보안 태세를 강화한 팀들은 패치를 가장 빨리 적용한 팀들이 아니었습니다. 이들은 해당 사고를 자사 시스템에 대한 정보로 삼았습니다. 즉, 자신들이 알지 못했던 점, 프로세스상 어떤 취약점이 있었는지, 인프라 중 어느 부분에 명확한 책임자가 없는지 등을 파악한 것입니다. 이들은 이번 사고로 인한 혼란을 기회로 삼아, 단순히 패치된 JAR 파일보다 훨씬 더 견고한 체계를 구축했습니다.

이 질문은 Log4j 사태 이후 진행되는 모든 보안 검토의 핵심이 되어야 합니다. 문제는 단순히 패치를 적용했는지 여부가 아니라, 그 답변에 대해 얼마나 확신을 가지고 있는지, 그리고 그 취약점에 대해 어떤 조치를 취하고 있는지에 있습니다.

TuxCare의 라이브러리용 ‘무한 라이프사이클 지원(ELS)’을 확인해 보세요 →

요약