ELS를 통해 Apache Commons Collections의 EOL 버전을 안전하게 보호하기

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

주요 내용

Commons Collections는 대개 간접적으로 포함되는 경우가 많으므로, 아무도 추가하지 않았더라도 빌드에 포함되어 있을 수 있습니다.
이 패키지의 펑터(functors)는 자바에서 가장 잘 알려진 역직렬화 도구 체인을 구성하는 기본 요소를 제공했습니다.
3.x에서 4.x로 마이그레이션한다는 것은 새로운 좌표계, 새로운 패키지 네임스페이스, 그리고 의도적인 API 호환성 중단을 의미합니다.
Apache Commons Collections용 ELS는 사용자가 마이그레이션을 계획하는 동안 지원 종료(EOL) 버전과 해당 의존성 체인을 패치해 줍니다.

Apache Commons Collections가 자바 의존성 그래프 어딘가에 포함되어 있다면(엔터프라이즈 자바 환경에서는 흔히 그런 경우가 많습니다), 스캐너나 감사 담당자가 이 문제를 제기하기 전에 지원 종료(EOL) 문제를 미리 정리해 두는 것이 좋습니다.

이 라이브러리는 자바에서 가장 유명한 역직렬화 공격 체인의 배후에 있는 라이브러리입니다. 아파치가 백도어를 포함시켰기 때문이 아니라, functors 패키지에 있는 소수의 클래스가 직렬화 가능하고 리플렉션을 사용하기 때문에, 누군가가 결국 이를 이용해 무엇을 만들 수 있는지 알아차렸기 때문입니다. 2015년의 보안 취약점 공개로 인해, 평범한 유틸리티 JAR 파일이 보안 팀이 통제할 수 없는 애플리케이션 서버 전반에 걸쳐 추적해야 하는 의존성 문제로 변모했습니다. 이 글에서는 그 경위와, 여전히 구버전 아티팩트 라인을 운영 중인 팀에게 이것이 어떤 의미를 갖는지, 그리고 이번 분기 내에 마이그레이션이 이루어지지 않을 경우 확장 지원이 어떤 역할을 할 수 있는지에 대해 다룹니다.

두 가지 유물 계열과 그 중요성

Commons Collections는 2001년부터 사용되어 왔습니다. 이 라이브러리는 JDK에 포함되지 않았던 데이터 구조, 반복자, 비교기 및 변환 유틸리티를 통해 Java Collections Framework를 확장해 주며, 바로 그 덕분에 모든 곳에서 널리 사용되게 되었습니다. 그러나 이러한 보편성 때문에 보안 문제가 발생했을 때 그 여파가 특히 컸습니다.

아티팩트 계열은 두 가지가 있으며, 이 둘을 혼동하는 것이 잘못된 수정 조언이 나오는 가장 흔한 원인입니다.

기존 라인은 다음과 같습니다. commons-collections:commons-collections, 이는 3.x 시리즈 전체를 다루며 다음 위치에 있습니다. org.apache.commons.collections 패키지 네임스페이스. 아파치는 3.2와 3.2.1 버전을 Java 1.2와 호환되는 버전으로 설명하고 있으며, 3.2.1은 2008년 4월 15일에 출시되었습니다. 최종 릴리스인 3.2.2는 2015년 11월에 보안 및 버그 수정 릴리스로 출시되었으며, Java 1.3으로 전환되었습니다. 이 릴리스의 가장 큰 변경 사항은 기본적으로 안전하지 않은 펑터 클래스의 역직렬화를 비활성화한 것으로, 이를 시도하면 UnsupportedOperationException 누군가가 명시적으로 org.apache.commons.collections.enableUnsafeSerialization 시스템 속성을 true로 설정합니다. 그 이후로 3.x 계열에서는 새로운 버전이 출시되지 않았습니다.

현재 줄은 다음과 같습니다. org.apache.commons:commons-collections4, 그리고 패키지 네임스페이스가 다음으로 이동했습니다. org.apache.commons.collections4 이와 함께. 4.0은 애초에 하위 호환성을 보장할 의도가 없었기 때문에 새로운 groupId와 artifactId가 부여되었으며, 바로 이 네임스페이스 변경 덕분에 3.x와 4.x JAR 파일이 동일한 클래스패스에 존재해도 충돌이 발생하지 않습니다. 4.0은 2013년 11월 27일에 출시되었으며, 전반적으로 제네릭이 적용되었고 최소 지원 버전은 Java 5입니다. 이어 2015년 11월 28일에 4.1이 출시되어, 3.2.2에서 시작한 작업을 마무리하며, 안전하지 않은 펑터 클래스에 대한 제한을 단순히 두는 데 그치지 않고 Serializable을 완전히 제거했습니다. 그 후 2018년 7월 11일에 4.2, 2018년 12월 21일에 4.3, 2019년 7월 5일에 4.4, 2025년 4월 19일에 4.5.0, 그리고 2026년 8월 6일에 현재 버전인 4.6.0이 출시되었습니다. 이에 따라 Java의 최저 버전도 함께 상승하여, Java 5에서는 4.0, Java 6에서는 4.1, Java 7에서는 4.2를 기록했으며, 이후 Java 8부터는 4.3부터 시작하여 4.6.0까지 이어졌습니다.

아파치는 3.x 버전에 대한 공식적인 지원 종료(EOL) 공지를 발표하지 않으므로, 티켓에 붙여넣을 수 있는 날짜가 명시된 공지문을 누구도 제공해 주지 않을 것입니다. 분명히 밝힐 수 있는 사실은 다음과 같습니다. 2015년 11월 이후로 3.x 버전의 릴리스가 없었으며, 모든 개발은 4.x에서 진행되고 있습니다. 또한 3.2.2가 해당 계열의 마지막 버전이었던 만큼, 새로 발견된 문제에 대해 업스트림 3.x 버전의 백포트를 기대해서는 안 됩니다.

여기서 ‘생명의 끝’이 실제로 무엇을 의미하는가

더 이상 상류 단계에서의 수정 없음

다음에서 실행되는 모든 것에 대해 commons-collections:commons-collections, 실질적인 상황은 간단합니다. 3.2.2 이후로 3.x 버전의 새로운 릴리스는 없었으며, 아파치는 10년 넘게 4.x 계열에 주력해 왔습니다.

이전 4.x 릴리스들은 이와 비슷한 상황이지만 그 정도가 다소 완화된 상태입니다. 아파치에서 공개한 수정 사항은 최신 4.x 릴리스에 반영되므로, 이전 4.x 버전에 영향을 미치는 문제의 경우 일반적인 업스트림 수정 절차는 최신 릴리스로 전환하는 것입니다.

많은 사람들이 약간 오해하고 있는 CVE 이야기

이 부분에서는 정확히 짚어둘 필요가 있습니다. 스캐너 출력물과 CVE 제목이 일치하지 않기 때문이며, 이러한 불일치로 인해 불필요한 회의가 많이 열렸기 때문입니다.

아파치(Apache)는 자체 보안 페이지에서 2015년 역직렬화 문제와 관련해 Commons Collections 라이브러리에 CVE ID가 할당되지 않았다고 밝혔습니다. 모두가 인용하는 식별자들은 하류 제품에 속하는 것입니다. CVE-2015-7501은 Red Hat JBoss 제품에, CVE-2015-6420은 수많은 Cisco 제품에 대해 등록된 것으로, 둘 다 CVSS v3 기준 9.8의 ‘치명적(critical)’ 등급을 받았으며, 아파치 Commons Collections 라이브러리의 결함이라기보다는 이 라이브러리와 관련된 문제로 설명되고 있습니다. 아파치(Apache)의 공식 페이지에서는 오라클 웹로직 서버(Oracle WebLogic Server)와 관련된 세 번째 취약점인 CVE-2015-4852를 언급하고 있습니다.

이 모든 것의 작동 원리는 동일합니다. functors 패키지의 여러 클래스는 직렬화 가능하며, 반사적으로 메서드를 호출하며, InvokerTransformer 리플렉션을 통해 지정된 메서드를 호출하기 때문에 공격자에게 특히 유용합니다. 필요한 가젯들을 연쇄적으로 연결한 뒤, 해당 클래스들이 클래스패스에 존재하는 상태에서 신뢰할 수 없는 입력을 검증 없이 역직렬화하는 애플리케이션에 결과 객체를 전달하면, JVM 프로세스의 권한으로 임의의 명령을 실행할 수 있게 됩니다. 아파치(Apache)는 영향을 받는 버전을 3.0부터 4.0까지로 명시하고 있으며, 이 문제는 3.2.2 및 4.1 버전에서 수정되었습니다.

이 타임라인은 왜 이 문제가 그렇게 큰 파장을 일으켰는지 설명해 줍니다. 가브리엘 로렌스와 크리스 프로호프는 2015년 1월 28일 AppSecCali에서 이 기법을 발표했습니다. 스티븐 브린은 2015년 11월 6일, WebSphere, JBoss, Jenkins, WebLogic 및 OpenNMS를 대상으로 한 실제 작동하는 공격 시나리오를 공개했습니다. 아파치 측은 이 내용이 공개되기 전 보안팀에 사전 통보되지 않았다고 밝혔으며, 그 결과 익스플로잇이 완전히 공개된 지 불과 몇 주 만에 패치가 적용되었습니다. 또한 각 팀은 직접 수정할 수 없는 의존성 트리 내 여러 단계 깊숙한 곳에 위치한 해당 라이브러리를 발견했습니다.

따라서 스캐너가 제목에 Cisco가 언급된 CVE에 해당하는 3.2.1 JAR 파일을 탐지하더라도, 이는 스캐너의 오탐이 아닙니다. 이러한 보안 권고 기록은 취약한 Commons Collections 버전을 이를 포함해 출시한 하위 제품들과 연결해 주며, GitHub 보안 권고 데이터베이스(GitHub Advisory Database)에는 Maven 아티팩트에 대해 GHSA-6hgm-866r-3cjv라는 동일한 문제가 등록되어 있습니다. CVE에 다른 회사의 제품명이 기재되어 있더라도 이 발견 사항은 사실입니다.

규정 준수 및 감사 관련 위험

PCI DSS v4.0.1 요구사항 6.3.3에 따르면, 조직이 ‘중대’ 등급으로 분류한 취약점에 대한 패치는 공개 후 1개월 이내에 설치해야 하며, 그 외 모든 취약점에 대해서는 요구사항 6.3.1에 명시된 동일한 위험 등급 평가 절차를 통해 설정한 일정에 따라 처리해야 합니다. PCI DSS는 모든 CVSS 7.0 평가 결과를 자동으로 ‘중대’ 등급으로 취급하지 않으므로, Commons Collections에서 발견된 취약점이 얼마나 심각한 문제로 간주될지는 조직이 문서화한 등급 평가와 실제 노출 정도에 따라 달라집니다. HIPAA 보안 규칙은 다르게 적용되는데, 적용 대상 기관 및 비즈니스 파트너에게 합리적으로 예상되는 위협으로부터 전자 보호 건강 정보(ePHI)를 보호할 의무를 부과합니다. 이는 패치가 적용되지 않은 EOL(지원 종료) 구성 요소로 인해 방어하기 까다로운, 바로 그와 같은 개방형 의무입니다.

지원되지 않는 구성 요소는 SOC 2 Type II 감사 과정에서 취약점 관리 통제 사항에 대한 의문을 제기할 수도 있으며, FedRAMP 인증은 그 자체로 지속적인 모니터링과 결함 시정에 대한 기대치를 수반합니다. 지원 기간 연장이 그 자체로 조직의 규정 준수를 보장해 주지는 않지만, 마이그레이션 계획이 진행 중인 동안에도 패치 공급이 원활하게 이루어지도록 하여 취약점 관리 의무를 지속적으로 이행할 수 있게 해줍니다.

의존성 트리 문제

커먼즈 컬렉션 자체는 탱글이 아닙니다. 4.6.0 아티팩트는 메모리 점유량이 매우 적으며, commons-codec 1.22.1을 유일한 선택적 컴파일 종속성으로 두고, 그 외 모든 것은 테스트 범위로 제한되므로, 이 라이브러리가 소비자의 런타임 종속성 그래프에 미치는 영향은 미미합니다.

문제는 소비자 측에 있습니다. 애플리케이션 서버는 이를 번들로 제공하고, 빌드 도구는 이를 포함하며, 레거시 프레임워크는 이를 필수로 요구합니다. 실행 mvn dependency:tree 성숙한 엔터프라이즈 자바 애플리케이션을 대상으로 스캔해 보면, 유지보수 담당자가 의존성 선언을 마지막으로 수정한 지 아주 오래전인 어떤 구성 요소에 의해 끌려 들어온 오래된 3.x 버전의 commons-collections JAR 파일이 출력 결과에 나타날 가능성이 높습니다. 스캐너는 사용자가 선언한 범위에서 멈추지 않고 전체 그래프를 샅샅이 조사하기 때문에, 그 그래프상에 있는 모든 취약한 사본이 발견 항목으로 기록될 수 있습니다. 특정 사본이 취약점으로 간주될지는 버전에 따라 달라집니다. 3.0부터 3.2.1까지는 취약한 범위에 속하지만, 3.2.2부터는 이미 아파치 측의 취약점 완화 조치가 적용되어 있기 때문입니다.

바로 이 점이 Apache Commons Collections의 EOL(지원 종료)을 까다롭게 만드는 이유입니다. 이는 라이브러리 버전 문제라기보다는 적용 범위와 가시성 문제이며, 오래된 JAR 파일을 불러오는 프로젝트 자체가 더 이상 유지보수되지 않는 경우, 해당 라이브러리가 실제로 사용되고 있는 위치에서 패치를 적용하는 것이, 아무도 유지보수하지 않는 의존성 체인에 더 새로운 전이적 버전을 강제로 도입함으로써 발생할 수 있는 호환성 위험을 피할 수 있는 방법입니다.

(현실적인) 선택지는 무엇일까요?

commons-collections4 4.6.0으로 마이그레이션

장기적으로 볼 때 확실한 해결책은 ~에서 벗어나는 것입니다. commons-collections:commons-collections 에 org.apache.commons:commons-collections4 4.6.0 버전으로, 이는 현재 활발히 유지보수 중인 브랜치에 해당합니다.

하지만 이번 업데이트는 단순한 버전 업그레이드가 아닙니다. API가 변경되면서 의존성이 교체되었기 때문에, 해당 라이브러리를 사용하는 모든 클래스를 검토해야 합니다. 제네릭이 전반적으로 도입되었고, 3.x 버전에서 사용이 중단된 클래스들은 제거되었으며, Buffer 인터페이스가 다음으로 대체되었습니다. java.util.Queue, 그리고 유틸리티 시그니처가 이동되었습니다. 모든 import 문은 collections4 네임스페이스로 옮겨야 하며, 3.x 버전의 동작에 의존하는 모든 요소(특히 functors 패키지 내의 요소)는 컴파일되기 전에 실제 코드 수정이 필요합니다.

이미 4.x 버전을 사용 중인 팀의 경우 작업량이 다소 적지만, 그래도 무턱대고 버전을 올리기보다는 각 중간 릴리스의 변경 내역을 꼼꼼히 확인하고 업그레이드 경로를 테스트해야 합니다.

Commons Collections가 직접적으로가 아니라 전이적으로 도입되는 경우, 마이그레이션 경로는 이를 불러오는 요소를 거치게 됩니다. 만약 해당 라이브러리들이 더 이상 유지보수되지 않는다면, 사용자는 전이적인 버전을 재정의하고 호환성을 직접 검증해야 하는데, 이는 가능은 하지만 비용이 들 뿐만 아니라 항상 안전한 방법도 아닙니다.

커먼즈 컬렉션을 완전히 대체하기

일부 팀은 EOL(지원 종료) 발표를 계기로, 해당 라이브러리가 여전히 필요한지 재고해 보는 좋은 구실로 삼기도 합니다. 현재 Eclipse Collections, Guava의 컬렉션 유틸리티, 그리고 애초에 사람들이 Commons Collections을 사용하게 만들었던 기능의 상당 부분을 흡수한 표준 라이브러리 등, 대안들이 상당히 훌륭해졌습니다.

이를 전면적으로 교체하는 것은 업그레이드하는 것보다 훨씬 더 큰 작업입니다. 모든 사용처에 이에 상응하는 대안을 마련해야 하고, 동작상의 차이점은 테스트를 거쳐야 하며, 펑터나 변환 파이프라인을 기반으로 구축된 모든 요소는 개별적으로 검토해야 합니다. 수년에 걸쳐 축적된 사용 이력이 있는 코드베이스의 경우, 이는 지난 화요일에 발견된 문제에 대한 즉각적인 해결책이 아니라 여러 스프린트에 걸쳐 진행해야 할 프로젝트입니다.

TuxCare의 끝없는 라이프사이클 지원

Apache Commons Collections용 ELS는 지원 대상인 EOL(지원 종료) 버전에 대해, 팀이 아직 계획하지 않은 마이그레이션을 수행하도록 요구하지 않으면서도 보안 패치를 지속적으로 제공합니다. 현재 지원 범위는 3.2 및 3.2.1 버전이며, 그 외 버전에 대해서는 문의해 보시는 것이 좋습니다. 지원 대상 버전을 사용 중이라면 해당 버전을 그대로 유지하며, 기존 워크플로에는 아무런 변화가 없으며, 새로운 문제가 발생할 때마다 패치가 계속 제공됩니다.

바로 그 간극을 메우기 위해 이 제품이 존재합니다. 즉, EOL 버전이 보고서상 부담 요소가 되는 시점과, 계획되고 테스트를 거친 마이그레이션이 실제로 완료되는 시점 사이의 공백을 메우는 것입니다.

업그레이드를 서두르면 왜 역효과가 나는가

부담은 실재합니다. 스캐너가 이를 드러내고, 감사관은 대응 계획을 묻고, 규정 준수 기한은 결코 유예되지 않습니다. 이 상황을 잘 처리하는 팀은 기존 위험에 대응하는 것과 새로운 위험을 만들어내는 것을 명확히 구분하는 팀입니다.

이주가 실제로 무엇을 수반하는지

3.x 버전에서 벗어나려면, 의존성이 선언되거나 중앙에서 관리되는 모든 곳에서 아티팩트 좌표를 업데이트하고, 새로운 패키지 네임스페이스에 맞게 임포트 문장을 재작성한 다음, 제너릭화된 4.x API와 함께 도입된 타입 안전성 및 API 변경 사항을 고려하여 컬렉션 사용처를 검토해야 합니다. 제거된 클래스는 대체하거나 재작성해야 합니다. 3.x functors 패키지를 사용하는 코드는 경우에 따라 개별적으로 검토해야 합니다. 일부는 Java 8 함수형 인터페이스로 매핑이 원활하지만, 일부는 설계에 따라 재작성이 필요하기 때문입니다.

직렬화된 Java 데이터를 처리하는 모든 경우, 시스템 속성을 통해 활성화하지 않는 한 안전하지 않은 펑터 역직렬화가 비활성화되는 3.2.2 모델과, 해당 클래스가 아예 직렬화될 수 없는 4.1 모델 간의 차이점을 이해하고, 실제 운영 환경에 적용하기 전에 반드시 테스트해야 합니다.

압축될 때 어떤 문제가 발생하는가

컴파일 오류는 비교적 다루기 쉬운 편입니다. 이름이 변경되거나 제거된 API는 즉시 드러나기 때문입니다. 흥미로운 오류는 좀 더 은근하게 나타납니다. 바이너리 호환성 문제는 다음과 같이 드러날 수 있습니다. NoSuchMethodError 실행 시, 반사 조회 실패 시 다음이 발생할 수 있습니다. NoSuchMethodException 대신, 이 둘 중 어느 것도 컴파일만으로는 반드시 포착된다고 보장할 수 없습니다.

행동 변화는 더 심각합니다. MultiValueMap 4.1 버전에서 더 새로운 기능으로 대체되어 사용이 권장되지 않게 되었습니다. MultiValuedMap 인터페이스, BeanMap 4.0 버전에서 출시되었으며, 이에 상응하는 기능은 Commons BeanUtils로 이전되었고, 4.6.0 버전에서는 전체 기능이 더 이상 사용되지 않게 되었습니다. Bag ~을 지지하는 가족 MultiSet. 기존 의미 체계에 의존하는 코드는 테스트 스위트를 통과할 수는 있지만, 실제 운영 환경에서 특정 데이터 형식이 적용될 경우 오류가 발생할 수 있습니다.

게다가 잔여 문제들도 남습니다. 기한을 맞추기 위해 작성된 호환성 시임은 영구적으로 남게 되고, “나중에 정리하자”는 말은 결국 다른 누군가의 처리 과제로 넘겨집니다. 긴급 엔지니어링 작업 시간, 지연된 로드맵 작업, 그리고 제품 출시 대신 운영 환경 디버깅에 매달리는 선임 엔지니어들의 상황을 더하면, 서둘러 진행한 마이그레이션은 원래 맞추려 했던 마감 기한을 지키는 데 드는 비용보다 훨씬 더 많은 비용을 초래하기 쉽습니다. 이런 식으로는 문제가 해결되지 않습니다. 단지 추가 비용을 치르며 문제를 미루는 것뿐입니다.

Apache Commons Collections용 TuxCare ELS의 작동 방식

TuxCare는 지난 15년 동안 오픈소스 패치 개발 경험을 쌓아왔으며, 운영 체제, 런타임, 프레임워크, 라이브러리 등 다양한 분야에서 42만 개 이상의 패치를 제공해 왔습니다. Apache Commons Collections용 ELS도 동일한 프로세스를 따릅니다.

의존성 체인 커버리지 포함

추가 비용 없이 직접 의존성과 전이적 의존성 모두를 포괄합니다. 스캐너는 최상위 아티팩트에서 멈추지 않으므로, 패치 작업도 마찬가지입니다.

패치가 만들어지는 과정

CVE 추적은 NVD, 벤더 권고 사항, GitHub 보안 권고 사항 및 기타 출처를 대상으로 지속적으로 수행됩니다. 새로운 내용이 반영되면, 알고리즘 기반 도구와 AI 지원 자동화 시스템이 엔지니어들의 백포트 작업을 지원하며, 보안 엔지니어들이 결과를 검증하고, 모든 빌드는 리포지토리에 반영되기 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 패치는 TuxCare가 호스팅하는 리포지토리에서 서명된 상태로 배포되며, 해당 파이프라인을 자세히 확인하시려면 ‘오픈 소스 패치 프로세스(Open Source Patching Process )’ 백서를 참조하시기 바랍니다.

자신의 체형에 맞게 입기

Maven이나 Gradle을 통해 Commons Collections를 가져오든 간에, 주요 변경 사항은 빌드 경로를 TuxCare의 저장소로 지정하고, 의존성 해결 과정에서 패치된 아티팩트가 제대로 반영되는지 확인하는 것입니다. 파이프라인, CI/CD, 그리고 팀의 업무 방식은 모두 기존과 동일하게 유지됩니다.

패치가 적용되는 속도

지원 대상인 EOL 버전에 영향을 미치는 고위험 및 중대 위험 취약점(즉, CVSS 7.0 이상)의 경우, 공개 후 14일 이내에 대응을 완료하는 것을 목표로 하며, 중위험 취약점은 60일, 저위험 취약점은 90일 이내에 대응합니다. 취약점 분류 및 문제 해결 지원은 연중무휴 24시간 운영됩니다.

감사인의 가시성

TuxCare의 CVE 추적 도구는 지원 대상 제품 및 해당 의존성 체인 전반에 걸쳐 어떤 취약점이 식별되고 해결되었는지 보여줍니다. 이를 통해 보안 및 규정 준수 팀은 특정 시점의 스캐너 결과만 보는 것보다 실제로 어떤 취약점이 해결되었는지에 대한 더 명확한 근거를 확보할 수 있습니다.

EOL 판정이 사고로 이어지지 않도록 하십시오

EOL Commons Collections 버전은 그 자체로는 아무런 문제를 일으키지 않습니다. 다만, 해당 릴리스에 영향을 미치는 새로운 취약점이 발견되거나, 클래스패스에 여전히 남아 있는 클래스가 새로 공개된 역직렬화 체인 공격에 악용될 경우, 의존할 수 있는 유지보수되는 업스트림 3.x 릴리스가 없어지게 됩니다.

이전을 계획하는 동안 구버전의 Commons Collections 릴리스를 안전하게 유지하는 것이 당면한 문제라면, TuxCare의 ‘오픈 소스 소프트웨어를 위한 무한 수명 주기 지원(Endless Lifecycle Support ) ’ 이 귀사의 나머지 스택 전반에 걸쳐 어떤 내용을 포함하는지 살펴보시기 바랍니다.

요약