Apache Velocity용 ELS: 지원 종료(EOL) 이후에도 보안을 유지하세요

주요 내용

• 의존성은 취약점 노출 범위를 확대합니다: 지원 종료된 Velocity로 인한 위험은 Engine 및 Tools JAR 파일을 넘어 commons-collections 3.2.1과, 사용된 경우 Log4j 1.x와 같은 취약한 런타임 종속성까지 확대될 수 있습니다.
• 서둘러 진행하는 마이그레이션은 비용이 많이 들고 위험합니다: 규정 준수 기한 압박 속에서 Engine 1.7에서 2.x 계열로의 마이그레이션을 서두르면, 보안 위험을 감수하는 대신 새로운 회귀 오류 위험이 발생하게 됩니다.
• Apache Velocity의 지원 종료(EOL)가 반드시 보안의 종말을 의미하는 것은 아닙니다: TuxCare ELS는 지원 종료된 Velocity 버전에 대해 지속적인 보안 패치 지원을 제공하므로, 고객은 자신의 일정에 맞춰 체계적인 마이그레이션을 계획할 수 있습니다.

Java 애플리케이션의 의존성 그래프 어딘가에 Apache Velocity가 포함되어 있다면(구형 엔터프라이즈 Java 환경에서는 여전히 흔히 볼 수 있습니다), 보안 스캐너나 규정 준수 감사로 인해 이 문제가 불가피하게 대두되기 전에 해당 라이브러리의 지원 종료(EOL) 상태를 미리 파악해 두는 것이 좋습니다.

1.x 계열의 최종 릴리스인 Velocity Engine 1.7은 2010년 11월 이후로 새로운 업스트림 릴리스가 나오지 않았습니다. Velocity Tools 2.0 역시 2010년 5월 이후로 새로운 릴리스가 없는 반면, Apache 개발은 Engine 2.x 및 Tools 3.x 계열에서 계속되고 있습니다. 이 두 구형 구성 요소에 대한 CVE 기록은 보안 취약점을 명확히 보여주며, 패치가 적용되지 않은 상태로 프로덕션 환경에서 이를 실행할 경우 규정 준수 측면에서 실질적인 문제가 발생할 수 있습니다.

이 글에서는 Apache Velocity EOL이 실제로 무엇을 의미하는지, 보안 현황은 어떠한지, 그리고 TuxCare ELS for Apache Velocity가 귀사의 팀이 아직 준비되지 않은 마이그레이션을 강요하지 않으면서도 보안을 유지할 수 있는 방법을 제시합니다.

아파치 벨로시티란 무엇이며, 왜 여전히 이렇게 널리 사용되고 있을까요?

Apache Velocity는 Velocity 템플릿 언어(VTL)를 사용하는 자바 기반 템플릿 엔진으로, 개발자가 일반 텍스트 템플릿에 동적 지시문을 삽입할 수 있게 해줍니다. 실행 시 Velocity 엔진은 템플릿을 자바 데이터 모델과 병합하여 렌더링된 출력을 생성합니다. 표현 논리와 애플리케이션 로직을 분리했다는 점 덕분에 Velocity는 2000년대부터 2010년대까지 기업용 자바 애플리케이션에서 널리 채택된 템플릿 솔루션이 되었습니다.

Apache Velocity 프로젝트는 별도의 버전 라인과 릴리스 이력을 가진 두 가지 주요 구성 요소를 포함하고 있습니다:

• Velocity Engine: VTL 구문 분석, 지시문 실행, 매크로 확장 및 컨텍스트 변수 해결을 처리하는 핵심 템플릿 런타임입니다.
• Velocity 도구: 엔진을 기반으로 구축된 웹 프레임워크 통합 기능으로, 서블릿 기반 애플리케이션을 위한 VelocityViewServlet을 비롯해 날짜 서식 지정, URL 생성 및 일반적인 뷰 계층 유틸리티를 위한 도구 모음이 포함됩니다.

Velocity는 Apache Struts, 구형 Spring MVC 구성, Apache Turbine 및 Java CMS 플랫폼에 깊이 내장되어 있었으며, 종종 여러 단계에 걸친 전이적 의존성으로 애플리케이션에 포함되곤 했습니다. 또한, 현대화가 거의 이루어지지 않는 이메일 템플릿 시스템이나 보고서 생성기에서도 흔히 선택되는 기술이 되었습니다. 이러한 신뢰성 때문에 EOL(지원 종료)에 대한 사각지대가 발생할 수 있습니다. Velocity는 계속해서 정상적으로 작동하기 때문에 수명이 긴 애플리케이션에 여전히 내장된 채로 남아 있는 경우가 많으며, 이로 인해 취약점 스캐너가 이를 식별하기 전까지는 간과되기 쉽습니다.

Apache Velocity 지원 종료: 버전 수명 주기

Apache Velocity는 새로운 릴리스를 통해 수정 사항을 공개하며, 이전 릴리스는 Apache 아카이브로 이동됩니다. 따라서 스택 전반에 걸친 위험을 평가하기 위해서는 구성 요소의 타임라인을 파악하는 것이 필수적입니다.

Velocity Engine 1.7은 1.x 계열의 마지막 릴리스였으며, 한 세대의 자바 프레임워크에 기본으로 내장된 Velocity 버전이 되었습니다. Engine 2.x 계열은 1.x와 호환되지 않는 API 변경 사항을 도입했으며, 많은 업스트림 프레임워크들이 고정된 Velocity 의존성을 수년 동안 업데이트하지 않아 2020년대까지 1.7 버전이 널리 사용되었습니다. Velocity Tools 2.0 역시 2010년 이후 새로운 릴리스가 없었습니다. 두 구성 요소 모두 더 새로운 주요 버전으로 대체되었으며, 각 버전 라인에서는 더 이상 릴리스가 이루어지지 않고 있습니다.

Apache는 사용자에게 최신 릴리스를 안내하고 이전 버전을 아카이브로 보관하고 있으나, Engine 1.x 및 Tools 2.x 제품군에 대해서는 공식적인 보안 유지 관리 프로그램이나 패치 백포트 프로그램이 제공되지 않습니다. 이로 인해 해당 버전을 사용하는 조직들은 새로운 보안 수정 사항에 대한 문서화된 업스트림 출처를 확보하지 못한 상태이며, 바로 이러한 공백을 메우기 위해 TuxCare ELS for Apache Velocity가 개발되었습니다.

아파치 벨로시티의 서비스 종료(EOL) 위험을 결정짓는 CVE 이력

아파치 벨로시티(Apache Velocity)의 EOL(지원 종료)은 지원이 종료된 릴리스에서 더 이상 취약점이 발견되지 않는다는 의미가 아니라, 해당 릴리스에 대해 업스트림에서 더 이상 수정 패치를 제공하지 않는다는 것을 의미합니다. 템플릿 엔진은 애플리케이션 실행 컨텍스트 내에서 사용자의 영향을 받는 템플릿이나 데이터를 처리하는 경우가 많기 때문에, 공격자에게 매력적인 표적이 될 수 있습니다. 취약한 구성 환경에서 템플릿 로직과 애플리케이션 런타임 간의 경계에 결함이 있을 경우, 원격 코드 실행과 같은 심각한 결과를 초래할 수 있으며, 지원 종료 상태는 바로 이러한 유형의 공격에 대비한 업스트림 패치라는 안전망을 제거하게 됩니다.

CVE-2020-13936: 샌드박스 우회 및 원격 코드 실행

CVE-2020-13936 (NVD CVSS 3.1: 8.8, 고위험)은 2.2 버전까지(2.2 포함)의 Velocity Engine에 영향을 미치며, 이로 인해 1.x 계열 전체가 해당 취약점의 적용 범위에 포함됩니다. Velocity 템플릿을 수정할 수 있는 공격자는 서블릿 컨테이너를 실행하는 계정의 권한으로 임의의 Java 코드나 시스템 명령을 실행할 수 있습니다. 이 서버 측 템플릿 주입 취약점은 GitHub Security Lab에서 GHSL-2020-048로 보고되었으며, 이후 여러 다운스트림 벤더 및 배포판의 보안 권고문을 통해 해결되었습니다.

CVE-2020-13936은 2010년 11월에 출시된 1.x 시리즈의 마지막 버전 이후 10년 이상이 지난 2021년 2월에 출시된 Velocity Engine 2.3에서 패치되었습니다. 2021년 3월 이 취약점이 공개되었을 당시, Engine 1.7은 업스트림 릴리스가 없는 상태로 10년 넘게 지났으며, 1.x 계열에 대한 수정 패치는 단 한 번도 배포된 적이 없었습니다.

지원 종료된 Engine 1.7을 운영 중인 조직의 경우, 가장 직접적인 대응 방안은 수정 및 지원이 완료된 릴리스로 업그레이드하거나 TuxCare와 같은 공급업체가 제공하는 백포트 패치를 적용하는 것입니다. Velocity 템플릿을 업로드하거나 수정할 수 있는 사용자를 제한하면 취약점을 노출될 위험을 줄일 수 있지만, 취약한 기능에 대한 접근 권한이 여전히 허용되는 상황에서는 이러한 통제 조치만으로는 패치 적용을 대체할 수 없습니다.

숨겨진 위험: Velocity의 의존성 범위

Velocity Engine 1.7은 일반적인 런타임 기능을 위해 commons-collections 3.2.1 및 commons-lang 2.4에 의존합니다. Jakarta ORO 2.0.8은 자동 참조 이스케이프와 같은 특정 기능에만 필요합니다. Log4j 1.x는 애플리케이션에서 Velocity를 Log4j를 통해 로깅하도록 구성한 경우에만 사용되는 선택적 로깅 백엔드입니다. 이 생태계 내의 두 구성 요소에는 CVSS 9.8 등급의 ‘Critical’ CVE가 포함되어 있습니다:

commons-collections 3.2.1: CVE-2015-7501 (CVSS 9.8, 치명적). 이 버전은 애플리케이션이 취약한 코드 경로를 통해 신뢰할 수 없는 데이터를 역직렬화할 때 Java 역직렬화 가젯 체인에 연루될 수 있습니다. 이는 2015년 공개 당시 WebSphere, JBoss, WebLogic 및 Jenkins를 휩쓸었던 것과 동일한 유형의 공격입니다. Velocity Engine 1.7은 해당 취약점이 있는 버전을 사용하지만, 실제 악용 가능 여부는 주변 애플리케이션이 직렬화된 객체를 어떻게 처리하는지에 따라 달라집니다.

Log4j 1.x: CVE-2019-17571 (CVSS 9.8, 치명적). Log4j 1.x는 2015년 8월에 지원 종료되었으며, 1.x 브랜치 전체는 이후 공개된 CVE에 대한 패치를 제공받지 않습니다. Velocity와 함께 Log4j 1.x를 사용하는 애플리케이션은, 취약한 SocketServer 구성 요소를 활성화하고 노출할 경우 원격 코드 실행 취약점인 CVE-2019-17571에 노출될 수 있습니다.

취약점 스캐너는 이 종속성 트리 전반에 걸쳐 공식적인 업스트림 수정 사항이 없는 취약점을 탐지합니다. Apache Velocity용 TuxCare ELS는 최상위 Velocity 아티팩트를 넘어, 전이적 종속성 트리 내의 지원 대상 구성 요소까지 커버리지를 확장합니다.

규정 준수 및 규제 노출

PCI DSS v4.0의 요구사항 6.3.3에 따르면, 조직의 환경에서 ‘중대’ 등급으로 분류된 취약점에 대한 패치 및 업데이트는 출시 후 1개월 이내에 설치해야 하며, 그 외 적용 대상인 보안 업데이트는 조직의 위험 평가를 통해 정해진 기간 내에 설치해야 합니다(요구사항 6.3.1 참조).

PCI DSS는 CVSS 7.0 이상의 모든 취약점을 자동으로 ‘중대(critical)’ 등급으로 분류하지 않기 때문에, 2021년 3월부터 공개된 CVE-2020-13936이 규정 준수 측면에서 미치는 영향은 해당 조직이 문서화한 위험 등급, 노출 정도 및 통제 조치에 따라 달라집니다. HIPAA, SOC 2 Type II, FedRAMP를 비롯한 다른 프레임워크 및 보증 프로그램 역시 조직이 해당 취약점을 식별, 평가 및 조치할 것을 요구할 수 있으나, 이러한 요구사항은 별도로 평가되어야 합니다.

Apache Velocity용 ELS는 조직이 즉각적인 마이그레이션을 강요받지 않으면서도 예측 가능한 일정에 따라 해당 취약점을 해결할 수 있도록 지원합니다.

아파치 벨로시티 마이그레이션을 서두를 경우의 위험성

아파치 벨로시티(Apache Velocity)의 지원 종료(EOL) 관련 지적 사항에 대응해야 한다는 압박감은 실재합니다. SCA 도구가 지적 사항을 생성하고, 감사관들은 날카로운 질문을 던지며, 엔지니어링 역량 제약으로 인해 규정 준수 기한은 결코 연기되지 않습니다. 아파치 벨로시티의 지원 종료를 잘 처리하는 팀은 마이그레이션을 계획된 엔지니어링 프로젝트로 간주하며, 전체 템플릿 목록을 파악하고, 회귀 테스트를 수행하며, 명확한 롤백 경로를 마련합니다.

서두르면 어떻게 될까

팀들이 마이그레이션 일정을 비현실적으로 단축하려고 할 때, 예상 가능한 방식으로 일이 꼬이게 됩니다:

• 지원 업무량 증가: 압축된 테스트 과정에서 발견되지 못한 버그들이 운영 환경에 즉시 나타납니다. 지원 팀은 템플릿 렌더링 오류나 이메일 및 보고서 파이프라인의 동작 변경과 관련된 티켓으로 인해 업무에 압도당하고 있으며, 이러한 문제의 대부분은 촉박한 일정으로 인해 완전히 검증되지 못한 Engine 1.x와 2.x 간의 VTL 또는 API 차이에서 기인합니다.
• 시스템 불안정성: 일부 종속성 API 변경 사항은 실제 운영 환경의 부하가 가해졌을 때만 드러납니다. 간헐적으로 발생하는 템플릿 렌더링 오류, 업데이트된 Tools 툴박스와 다른 출력 서식, 변경된 VelocityViewServlet의 오류 처리 동작 등은 모두 재현하기 어렵고 진단하는 데 많은 비용이 드는 오류를 유발합니다.
• 기술 부채의 누적: 구성 차이가 라이브러리 계층에서 수정되지 않고 애플리케이션 초기화 코드에 반영됩니다. VTL의 1.x와 2.x 간 동작 차이는 문서화되지 않은 방식으로 로컬에서 우회 처리됩니다. EOL(지원 종료) 문제는 해결되지 않고 미뤄질 뿐이며, 이렇게 누적된 부채로 인해 향후 적절한 마이그레이션 비용이 더 많이 들게 됩니다.
• 예상치 못한 비용: 긴급 엔지니어링 업무 시간, 기능 출시 지연, 그리고 최고의 엔지니어들이 새로운 기능을 개발하는 대신 종속성 호환성 문제를 해결하는 데 소요되는 기회 비용은 일반적으로 전체 마이그레이션 계획 기간 동안 연장된 수명 주기 지원에 소요되었을 비용을 초과합니다.

보안 유지 및 규정 준수 방안

지원 종료된 Apache Velocity 버전을 사용 중인 조직은 앞으로 세 가지 선택지를 고려할 수 있습니다. 첫 번째와 두 번째 선택지는 상당한 엔지니어링 작업과 긴 시간이 소요됩니다. 세 번째 선택지는 팀이 마이그레이션을 적절히 계획하는 동안 보안 취약점을 신속하게 해소해 줍니다.

옵션 1: Velocity Engine 2.4.1 및 Tools 3.1로 마이그레이션

장기적인 해결책은 현재의 업스트림 릴리스, 즉 이 글을 작성하는 시점을 기준으로 Velocity Engine 2.4.1 및 Velocity Tools 3.1로 마이그레이션하는 것입니다. 이렇게 하면 활발히 유지보수되고 있는 소프트웨어로 전환함으로써 지원 종료(EOL) 위험을 제거할 수 있습니다.

이번 마이그레이션은 실질적인 영향을 미칩니다. 2.1(2019년 3월) 이후 출시된 모든 Engine 릴리스(2.4.1 포함)는 최소 런타임으로 Java 8을 요구하므로, 구형 JVM 환경에서 Velocity 1.7을 실행 중인 조직은 최신 2.x 버전으로 마이그레이션하기 전에 Java 업그레이드를 완료해야 할 수 있습니다. Engine 1.7과 2.x 간의 API 변경 사항(제거된 클래스, 수정된 ResourceLoader 구성, 변경된 인트로스펙션 및 로깅 인터페이스 등)으로 인해, Java API를 통해 Velocity를 확장하거나 구성하는 애플리케이션에서는 코드 수정이 필요할 수 있습니다. Tools 3.1은 패키지 구조 재편 및 수정된 서블릿 통합을 통해 적용 범위를 더욱 확대합니다.

Velocity 통합 지점이 여러 개인 엔터프라이즈 애플리케이션의 경우, 마이그레이션 과정에서 수개월에 걸친 자산 파악, 코드 수정 및 회귀 테스트가 필요할 수 있습니다.

옵션 2: Velocity를 다른 템플릿 엔진으로 대체하기

일부 조직은 Apache Velocity의 EOL(지원 종료) 시점을 계기로 대체 솔루션을 검토하기도 합니다. Thymeleaf, FreeMarker, Pebble, Mustache 등은 모두 활발하게 유지보수되고 있습니다. 템플릿 엔진을 교체하는 것은 같은 버전 내 업그레이드보다 더 큰 혼란을 초래합니다. 일반적으로 템플릿을 새로 작성하거나 새로운 엔진의 구문에 맞게 수정해야 하며, 영향을 받는 모든 출력 경로를 다시 테스트해야 합니다. 이는 실현 가능한 장기적인 목표이지, Apache Velocity 지원 종료에 따른 규정 준수 문제를 즉시 해결하기 위한 해결책은 아닙니다.

옵션 3: 마이그레이션 기간 동안 무제한 라이프사이클 지원 활용

TuxCare의 Apache Velocity용 Endless Lifecycle Support(ELS)를 이용하면, 팀이 아직 준비되지 않은 마이그레이션을 강행하지 않고도 보안을 유지할 수 있습니다. 지속적인 보안 패치 지원을 받으며 현재 사용 중인 Velocity 버전을 계속 운영할 수 있습니다. Apache Velocity용 ELS는 바로 이러한 간극, 즉 공식 지원이 종료된 시점부터 귀사가 계획적이고 체계적인 마이그레이션을 진정으로 완료할 때까지의 기간을 메우기 위해 설계되었습니다.

간편한 해결책: Apache Velocity용 TuxCare ELS

TuxCare는 지원이 종료된 Apache Velocity 버전에 대해 ‘무제한 라이프사이클 지원’을 제공하며, 기존 Maven 또는 Gradle 툴체인을 통해 바로 적용 가능한 JAR 파일 형태의 보안 패치를 제공함으로써 현재 배포 환경을 지속적으로 보호합니다. TuxCare는 오픈 소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포해 왔습니다.

의존성 트리 전체 커버리지

Apache Velocity용 TuxCare ELS는 엔진 및 도구 JAR 파일을 넘어, commons-collections 3.2.1(CVE-2015-7501, CVSS 9.8 Critical)을 비롯해, 이를 사용하는 애플리케이션의 경우 Log4j 1.x(CVE-2019-17571, CVSS 9.8 Critical)까지 포함합니다.

정교하고 자동화된 패치 적용 프로세스

TuxCare는 NVD, Apache 보안 권고, GitHub 보안 피드 및 공급업체 공개 채널을 24시간 내내 모니터링합니다. 해당 CVE가 식별되면, TuxCare는 알고리즘 및 AI 기반 자동화 기술을 활용하여 지원되는 버전에 수정 사항을 백포트하며, 보안 전문가들이 패치가 배포되기 전에 모든 패치를 검증합니다. 모든 업데이트는 사용자의 저장소에 반영되기 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 자세한 기술 정보는 다음을 참조하십시오. TuxCare의 ‘오픈 소스 패치 적용 프로세스’ 백서를 참조하십시오.

원활한 통합

Maven Central을 통해든 사설 리포지토리 미러를 통해든 Velocity를 사용하는 경우, 리포지토리 구성을 약간만 변경하면 업데이트 소스를 TuxCare의 보안 리포지토리로 전환할 수 있습니다. 패치된 JAR 파일은 기존 API와 구성을 유지하면서 역포트된 보안 수정 사항을 반영한 ‘드롭인(drop-in)’ 대체 파일로 설계되었으므로, 대부분의 팀은 기존의 Maven 또는 Gradle 워크플로우와 CI/CD 파이프라인을 통해 이를 활용할 수 있습니다.

SLA 기반 신속 대응

지원 대상인 지원 종료(EOL) 상태의 Velocity 버전(엔진, 도구 또는 포함된 종속성)에 영향을 미치는 새로운 취약점이 공개될 경우, TuxCare는 서비스 수준 계약(SLA)에 따라 패치를 제공하며, 심각도가 ‘높음’ 및 ‘치명적’인 취약점(CVSS 7.0 이상)에 대해서는 공개 후 14일 이내에 패치를 적용하도록 하고 있습니다.

비용 효율적인 보안 연속성

TuxCare ELS의 비용은 규정 준수 기한의 압박 속에서 진행되는 긴급 마이그레이션 비용에 비해 극히 일부에 불과합니다. 팀의 여력에 맞춰 Velocity Engine 2.4.1 및 Tools 3.1로의 신중한 마이그레이션을 계획할 수 있으며, 여기에는 전체 전이적 종속성의 영향을 파악하고 모든 템플릿 출력 경로를 검증하는 데 필요한 시간도 포함됩니다. 또는 ELS를 활용하여 보안 패치 적용 범위를 유지하고 규정 준수 노력을 지원하면서, 자체 일정에 따라 이러한 결정을 내릴 수도 있습니다.

아파치 벨로시티의 지원 종료로 인해 자바 애플리케이션이 위험에 처하지 않도록 하세요

Apache Velocity의 지원 종료(EOL)가 발생했다고 해서 애플리케이션이 즉시 위험에 노출되는 것은 아닙니다. 다만, CVSS 8.8 ‘높음(High)’ 등급의 Velocity 취약점과 CVSS 9.8 ‘치명적(Critical)’ 등급에 달하는 종속성 취약점을 포함하여, 알려진 취약점이 있는 구성 요소들이 프로덕션 환경의 종속성 트리에 남아 있을 수 있으며, 상류 프로젝트 측에서는 이를 수정하지 않을 것임을 의미합니다.

각 취약점이 실제로 악용될 수 있는지 여부는 애플리케이션의 구성, 데이터 흐름 및 보안 통제 조치에 따라 달라지지만, 지원이 종료된 릴리스에 대한 CVE 정보가 공개된 후 한 달이 지날 때마다 취약점에 노출될 위험이 지속되는 기간이 한 달씩 늘어나게 됩니다.

Apache Velocity의 지원 종료에 대한 적절한 대응 방안은 귀사의 일정과 엔지니어링 역량에 따라 달라집니다. 지금 바로 Engine 2.4.1 및 Tools 3.1로 마이그레이션할 수 있다면, 그것이 올바른 선택입니다. Velocity 통합 환경이 복잡하여 즉각적인 업그레이드가 현실적으로 어려운 경우, TuxCare ELS for Apache Velocity를 활용하면 마이그레이션을 적절히 계획하고 완료하는 동안 지속적인 보안 패치 지원을 받을 수 있습니다.

현재 Apache Velocity의 지원 종료가 보안 관련 관심사라면, 다음 사이트를 방문해 보세요. TuxCare의 오픈 소스 소프트웨어용 ‘Endless Lifecycle Support’ 페이지를 방문하여, 확장된 지원이 귀사의 전체 오픈소스 스택을 어떻게 보호할 수 있는지 확인해 보시기 바랍니다.

요약

기사 이름

Apache Velocity용 ELS: 지원 종료(EOL) 이후에도 보안을 유지하세요

설명

지원 종료(EOL)된 Apache Velocity를 사용 중이신가요? TuxCare의 Apache Velocity용 ELS를 이용하면 서둘러 마이그레이션을 진행할 필요 없이 Java 애플리케이션에 패치를 적용하고 규정 준수를 유지할 수 있습니다.

작성자

무잠밀 하산

게시자 이름

TuxCare

게시자 로고