Apache Struts 지원 종료: 자바 웹 애플리케이션의 보안을 유지하세요

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

주요 내용

Struts 버전이 지원 종료(EOL) 단계에 도달하면, OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2 등 전체 종속성 스택도 프레임워크 자체와 함께 통합된 보안 패치를 더 이상 제공받지 못하게 됩니다.
Struts 2.5.x에서 6.x로 마이그레이션하려면 Java 런타임 업그레이드, Servlet API 변경, OGNL 표현식 재작성, 인터셉터 인터페이스 교체, 정적 메서드 호출 패턴 제거 등이 필요하며, 이 모든 작업은 촉박한 일정이 아닌 신중한 계획과 철저한 테스트를 요구합니다.
TuxCare ELS는 지원 종료(EOL)된 Struts 버전과 관련 종속성 구조에 대한 보안 지원을 확대하므로, 조직은 자체 일정에 맞춰 신중하고 충분한 자원을 투입한 마이그레이션을 계획하는 동안에도 보안 및 규정 준수를 유지할 수 있습니다.

스트럿츠(Struts)는 20년 넘게 기업용 자바 웹 개발의 중추적인 역할을 해왔습니다. 모델-뷰-컨트롤러(MVC) 아키텍처, 성숙한 플러그인 생태계, 그리고 광범위한 자바 엔터프라이즈 스택과의 긴밀한 통합 덕분에 금융 서비스, 정부, 의료, 통신 분야를 아우르는 대규모 웹 애플리케이션에서 가장 선호되는 프레임워크로 자리매김했습니다. 하지만 Struts는 지원 종료(EOL) 문제를 유난히 중대한 사안으로 만드는 역사를 지니고 있습니다. Struts는 현재 운영 중인 모든 자바 웹 프레임워크 중 가장 심각한 CVE 기록을 보유하고 있으며, Apache Struts EOL 버전을 실행 중인 조직들은 2017년 Equifax 해킹 사건으로 인해 이론적인 위험 요소가 1면 뉴스로 부상한 것과 같은 위험 프로필을 안고 있습니다.

이 글에서는 Apache Struts의 EOL(지원 종료)이 자바 애플리케이션 팀에게 실제로 어떤 의미를 지니는지, 종속성 트리 내에서 진정한 보안 취약점이 어디에 숨어 있는지, 최신 버전으로의 마이그레이션 과정이 겉보이는 것보다 훨씬 까다로운 이유, 그리고 TuxCare의 Endless Lifecycle Support(ELS)를 통해 팀이 아직 준비되지 않은 마이그레이션을 강요받지 않으면서도 완벽한 보안 및 규정 준수 범위를 유지할 수 있는 방법을 설명합니다.

Apache Struts의 제품 수명 주기는 무엇인가요?

Struts는 다른 일부 오픈소스 프로젝트와 달리 공식적으로 문서화된 정기적인 릴리스 주기를 따르지 않습니다. 프로젝트의 아파치 소프트웨어 재단(ASF) PMC는 주요 브랜치의 지원 종료 시기가 다가오면 프로젝트 웹사이트에 직접 EOL 공지를 게시하며, 일반적으로 공식적인 지원 종료 6개월 전에 이를 알립니다. EOL 공지는 고정된 일정과 연동되지 않으며, 특정 브랜치를 유지 관리할 수 있는 커뮤니티의 역량과 지원되는 후속 버전의 가용성을 반영합니다.

예를 들어, 스트리밍 인프라가 이와 유사한 지원 종료 상황을 어떻게 처리하는지 알아보려면 Apache Kafka EOL 가이드를 확인해 보거나, 빅데이터 프레임워크가 Apache Spark의 수명 주기 종료 시점을 어떻게 관리하는지 살펴볼 수 있습니다. 또한 데이터 웨어하우징 구성 요소를 관리하고 계신다면, 당사의 심층 가이드를 통해 Apache Hive EOL에 대해 더 자세히 알아보실 수 있습니다.

이 프로젝트는 시맨틱 버저닝(Semantic Versioning)을 따르며, 현재 활성화된 브랜치에 대한 지원을 유지하고 있습니다. 과거의 경우, 지원 종료(EOL) 공고가 발표된 후 6개월 동안은 보안 패치만 제공되었으며, 그 이후에는 해당 브랜치에 어떠한 종류의 패치도 더 이상 제공되지 않았습니다. 즉, 최종 지원 종료일 이후에 공개된 보안 취약점에 대해서는 유예 기간이 없으며, 지원 종료된 브랜치에 영향을 미치는 CVE에 대해서는 커뮤니티 차원의 공식 수정 패치가 제공되지 않습니다.

현재 Struts 릴리스의 지원 현황:

버전	릴리스 날짜	지원 종료일	상태
Struts 1.x	2000–2008	4월 2013	EOL
Struts 2.3.x	2012	5월 2019	EOL
Struts 2.5.x	5월 2016	4월 30, 2024	EOL
Struts 6.x	6월 2022	미발표	활성(최신)
Struts 7.x	12월 2024	미발표	활성

기업 환경에서 가장 널리 배포된 버전인 Struts 2.5.x는 2023년 12월에 최종 릴리스(2.5.33)를 발표했으며, 2024년 4월 30일에 공식적으로 지원 종료(EOL) 단계에 접어들었습니다. Struts 6.x 또는 7.x로의 마이그레이션을 완료하지 않은 조직들은 현재 업스트림 보안 패치 지원이 제공되지 않는 Apache Struts EOL 프레임워크를 사용 중입니다.

이 라이프사이클 모델이 가져오는 실질적인 영향은 상당합니다. 프로젝트 측에서 수년 전에 고정된 향후 EOL(지원 종료) 일정을 미리 공지하지 않기 때문에, 기업들은 종종 마이그레이션에 대한 예산 편성, 자원 확보 및 계획 수립을 마치기도 전에 EOL 공지를 접하게 됩니다. 아파치 스트럿츠(Apache Struts)의 6개월 EOL 사전 공지 기간은 스트럿츠가 광범위하게 통합된 대규모 엔터프라이즈 애플리케이션이 검증된 마이그레이션을 완료하기에는 충분한 시간이 아닙니다.

Apache Struts의 지원 종료(EOL)는 자바 웹 애플리케이션에 어떤 의미를 갖는가?

대외 HTTP 요청을 처리하고, 파일 업로드를 관리하며, 양식 제출을 처리하고, 재무 기록, 환자 데이터 또는 정부 시스템과 연동되는 비즈니스 로직 계층의 전면에 위치하는 미션 크리티컬(mission-critical) 자바 애플리케이션의 웹 계층으로 Struts를 운영하는 조직에게 있어, Apache Struts의 EOL(지원 종료) 지정은 단순한 관리상의 문제가 아닙니다. 이는 규정 준수 측면에서 직접적인 영향을 미치는 보안 사건입니다.

지원 종료일 이후에는 더 이상 보안 패치가 제공되지 않습니다

Struts 버전이 지원 종료(EOL) 시점에 도달하면, Apache 커뮤니티는 해당 버전에 대한 보안 패치 제공을 중단합니다. 지원 종료일 이후에 공개되는 취약점은 프레임워크의 핵심 디스패처, OGNL 표현식 평가 엔진, 파일 업로드 처리 기능, 또는 인터셉터 스택 등 어느 부분에서 발생하든 공식 패치를 받을 수 없습니다. 커뮤니티가 제공하는 유일한 해결책은 지원되는 릴리스로 마이그레이션하는 것입니다.

마이그레이션 과정에서 액션 클래스를 재작성하고, 인터셉터 인터페이스를 교체하며, 템플릿 전반에 걸쳐 OGNL 표현식을 업데이트하고, 수십 개 또는 수백 개의 애플리케이션 엔드포인트에 걸쳐 동작을 검증해야 하는 대규모의 운영 핵심 웹 애플리케이션을 운영하는 팀의 경우, 이러한 작업을 단기간 내에 수행하는 것은 항상 가능한 일이 아닙니다. EOL(지원 종료) 상태가 발효되는 시점과 마이그레이션을 현실적으로 완료하고 검증할 수 있는 시점 사이의 간극이 바로, 패치되지 않은 취약점이 누적되는 시기입니다.

제품 수명 종료 후의 보안 및 규정 준수 위험

지원 종료(EOL)된 Struts 버전을 사용할 경우 규정 준수 측면에서 직접적인 문제가 발생합니다. PCI DSS(요구 사항 6.3.3)는 중요 및 고위험 패치를 패치 출시 후 1개월 이내에 설치할 것을 요구하지만, 지원 종료된 Struts 버전에는 설치할 패치가 없어 일반적인 방법으로는 규정 준수가 불가능합니다. SOC 2 감사관은 운영 환경에서 지원 종료된 소프트웨어를 문제점으로 지적합니다. 지원 종료된 Apache Struts를 배포 중인 조직은 보안 설문지에서 문서화 미비 사항이 드러나고, 공급업체 인증이 지연되며, 규제 산업에서는 고객 계약 갱신이 차단되는 상황에 직면하게 됩니다.

Struts 애플리케이션이 PCI 적용 범위에 속하거나, 개인 식별 정보를 처리하거나, 계약상 SLA 의무가 있는 서비스를 지원하는 조직의 경우, 이번 EOL(지원 종료) 사태로 인한 규정 준수 위험은 단순한 가정이 아닙니다. 이는 조만간 현실화될 감사 지적 사항이나 다름없습니다.

CVE 기록: 취약점 기록이 보여주는 것

Struts는 현재 운영 중인 모든 자바 웹 프레임워크 중 가장 심각한 CVE 기록을 보유하고 있으며, 이러한 이력은 패치된 EOL(지원 종료) 버전을 적용하는 것이 선택 사항이 아닌 이유를 명확히 보여줍니다.

CVE-2017-5638 (CVSS 10.0 Critical)은 역사상 가장 심각한 데이터 유출 사고 중 하나인 Equifax 해킹 사건에서 1억 4,700만 명의 개인 및 금융 정보를 노출시킨 취약점입니다. 이 결함은 Jakarta Multipart 파서에서 발견되었으며, 공격자는 파서에서 부적절한 예외 처리를 유발하는 악의적인 Content-Type HTTP 헤더를 조작하여 웹 서버 프로세스의 권한으로 서버에서 임의의 명령을 실행할 수 있었습니다. 인증 절차는 필요하지 않았습니다. 취약점이 공개된 지 며칠 만에 익스플로잇 코드가 공개되었으며, 즉시 실제 환경에서 악용이 시작되었습니다. 패치는 2017년 3월 7일에 배포되었습니다. Equifax가 이 패치를 적용하지 않음으로써 시스템은 144일 동안 노출되었으며, 이는 공격자들이 장기간에 걸친 공격을 통해 사회보장번호, 생년월일, 운전면허번호를 유출하기에 충분한 시간이었다. 이 침해 사고는 7억 달러의 합의금 지급과 의회 증언으로 이어졌으며, 패치되지 않은 Struts 취약점이 실제로 얼마나 큰 대가를 치르게 하는지 보여주는 결정적인 사례 연구가 되었다. 해결책은 이미 존재했다. 패치 출시와 실제 적용 사이의 시간 간격이 결과를 결정지은 것이다.

CVE-2023-50164 (NVD CVSS 3.1: 9.8, 치명적)은 Struts의 치명적인 원격 코드 실행(RCE) 취약점이 2017년 발생한 취약점들로 끝나지 않았음을 보여주었습니다. 이 결함은 프레임워크의 파일 업로드 로직에 존재했습니다. 공격자는 파일 업로드 매개변수를 조작하여 경로 탐색(path traversal)을 가능하게 한 다음, 웹 서버가 접근할 수 있는 위치에 악성 파일을 업로드함으로써 원격 코드 실행을 가능하게 할 수 있었습니다. CVSS 벡터 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 은 인증 불필요, 사용자 상호작용 불필요, 네트워크 접근 가능, 기밀성·무결성·가용성의 완전한 침해 등을 나타냅니다. 2023년 12월 취약점이 공개된 지 며칠 만에 개념 증명(PoC) 익스플로잇이 공개되었습니다. 영향을 받은 버전은 Struts 2의 전체 역사인 2.0.0부터 2.5.32까지, 그리고 6.0.0부터 6.3.0까지에 걸쳐 있습니다. Struts 2.5.33에는 패치가 제공되었으나, Struts 2.5.33은 Struts 2.5.x 계열의 마지막 릴리스이므로 해당 브랜치는 이제 지원 종료(EOL) 상태입니다. 향후 Struts 2.5.33과 관련된 CVE가 공개되더라도 커뮤니티 차원의 수정 패치는 제공되지 않을 것입니다.

CVE-2024-53677 (NVD CVSS 3.1: 9.8, 중요)는 오늘날 Apache Struts의 EOL(지원 종료) 상태가 실제로 무엇을 의미하는지 가장 직접적으로 보여주는 사례입니다. 2024년 12월에 공개된 이 Struts 파일 업로드 메커니즘의 치명적인 경로 탐색 취약점은 최종 EOL 릴리스인 Struts 2.5.33을 포함하여 Struts 2.0.0부터 6.3.0.2까지의 모든 버전에 영향을 미칩니다. 이 공격 경로는 CVE-2023-50164와 동일한 특성을 보입니다. 공격자는 파일 업로드 매개변수를 조작하여 의도하지 않은 서버 경로로 이동하고 악성 파일을 업로드함으로써 원격 코드 실행을 달성합니다. 이 문제를 해결하려면 Struts 6.4.0으로 업그레이드하고 새로운 Action File Upload 인터셉터로 마이그레이션해야 합니다. EOL(지원 종료) 브랜치인 Struts 2.5.33에는 패치가 제공되지 않았습니다. 여전히 Struts 2.5.x를 실행 중인 조직은 공식적인 해결 방법이 없는 상태에서 이 심각한 RCE(원격 코드 실행) 취약점에 영구적으로 노출되어 있으며, 이는 바로 이 기사에서 다루는 Apache Struts EOL 위험 시나리오와 정확히 일치합니다.

바로 이러한 유형의 취약점, 즉 운영 중인 웹 애플리케이션 인프라에서 인증 없이 네트워크를 통해 접근 가능한 원격 코드 실행(RCE) 취약점이 EOL(지원 종료) 버전에선 영구적으로 해결되지 않은 위험 요인으로 남게 됩니다. 이퀴팩스(Equifax) 사건은 이러한 위험이 조직이 모니터링이나 탐지만으로 관리할 수 있는 수준이 아님을 분명히 보여주었습니다. 유일한 근본적인 해결책은 패치가 적용된 버전을 사용하는 것입니다.

숨겨진 위험: Struts의 의존성 트리

Struts 배포 환경의 취약점 범위는 프레임워크 바이너리 자체에만 국한되지 않습니다. Struts는 자체적인 보안 위험 요소를 내포한 방대한 종속성 목록과 함께 제공되며, Struts의 지원 종료 시점이 되면 해당 Struts 버전에 맞춰 이러한 종속성들에 대한 통합적인 패치 제공도 중단됩니다.

struts2-core 모듈은 OGNL(Object-Graph Navigation Language 라이브러리)을 직접적인 런타임 종속성으로 포함하고 있으며, OGNL은 수많은 Struts 취약점에서 악용된 주요 표현식 평가 엔진으로서의 역할로 인해 자체적인 CVE 이력을 가지고 있습니다. 템플릿 렌더링을 위해 FreeMarker가 포함되어 있습니다. Apache Commons FileUpload는 멀티파트 양식 데이터를 처리하며, CVE-2017-5638과 직접적인 관련이 있습니다. Apache Commons BeanUtils, Commons Collections, Commons IO 및 Commons Lang은 모두 런타임 종속성입니다. 로깅을 위해 Log4j2가 포함되어 있는데, 이 라이브러리는 자체적인 치명적인 취약점 이력(Log4Shell, CVE-2021-44228)으로 인해 Java 생태계 전반에 걸쳐 긴급 패치 붐을 일으킨 바 있습니다. Jackson Databind는 플러그인에서 JSON 처리를 담당합니다. Spring 프레임워크 통합 시 Spring 플러그인을 사용하면 spring-core, spring-beans, spring-context, spring-web 및 Spring AOP가 포함됩니다. 빈(bean) 유효성 검사를 위해 Hibernate Validator가 포함됩니다.

이러한 각 종속성에는 고유한 업스트림 CVE 스트림이 있습니다. Struts의 특정 브랜치가 EOL(지원 종료) 상태가 되면, 커뮤니티는 해당 Struts 릴리스와 관련된 모든 종속성에 대한 통합 업데이트 제공을 중단합니다. EOL 상태의 Struts 배포 환경에 대해 취약점 스캐너를 실행하면, 해당 버전에 대한 공식 수정 프로그램이 없는 종속성 트리 전반에 걸쳐 취약점 결과가 생성되며, 이로 인해 보안 팀은 해결할 수 없는 스캔 결과 목록이 점점 늘어나는 상황에 직면하게 됩니다.

일반적인 플러그인을 포함할 경우, Struts2-core의 종속성 트리는 20개 이상의 직접 및 전이적 종속성을 아우릅니다. 이들 각각은 자체적인 전이적 트리를 가지고 있습니다. 일반적인 플러그인 세트를 적용한 Struts 2.5.x 운영 환경의 실질적인 패치 대상 범위는 프레임워크 바이너리 단독보다 훨씬 더 넓으며, 상위 Struts 브랜치가 EOL(지원 종료) 상태가 되면 해당 트리 내의 모든 구성 요소는 더 이상 통합된 지원 범위를 받지 못하게 됩니다.

보안 유지 및 규정 준수 방안

Apache Struts 지원 종료(EOL) 버전을 운영 중인 조직에는 세 가지 선택지가 있습니다. 그중 두 가지는 상당한 기술적 노력과 운영상의 위험, 그리고 긴 소요 기간을 수반합니다. 세 번째 선택지인 TuxCare의 ‘Endless Lifecycle Support’는 귀사의 팀이 마이그레이션을 체계적으로 계획하는 동안 보안 취약점을 즉시 해소해 드립니다.

옵션 1: 최신 Struts 버전으로 마이그레이션

장기적인 해결책은 애플리케이션을 현재 지원되는 Struts 버전으로 마이그레이션하는 것입니다. 현재 활발히 지원되는 버전은 Struts 6.x와 Struts 7.x이며, 2025년 10월 기준 최신 버전은 7.1.1입니다.

실제 상황은, 특히 Struts 2.5.x 기반으로 구축된 대규모 애플리케이션의 경우, 이번 업데이트가 단순한 버전 업그레이드가 아니라는 점입니다. 이는 애플리케이션 코드베이스, 구성 및 런타임 환경에 걸친 조율된 변경을 수반하는 마이그레이션입니다. Struts 6.0은 최소 Java 8과 Servlet API 3.1을 요구하므로, 구형 Java 환경을 사용하는 조직은 프레임워크 마이그레이션을 진행하기 전에 런타임 환경을 업그레이드해야 합니다. Struts 2.3의 모든 구성 상수(configuration constants)는 6.0에서 제거되었습니다. 더 이상 사용되지 않는 상수를 사용하는 애플리케이션은 대체 상수로 업데이트해야 합니다. XWork 패키지 네임스페이스가 재구성되어 Action 클래스 전반에 걸쳐 import 문 업데이트가 필요합니다. 많은 Struts 2.x 애플리케이션에서 널리 사용되던 OGNL 표현식을 통한 정적 메서드 호출 방식은 6.0에서 완전히 제거되었으며, Action 인스턴스 메서드 래퍼로 대체해야 합니다. OGNL 표현식의 길이는 기본적으로 256자로 제한되어 있어, FreeMarker 템플릿과 JSP에 분산되어 있을 수 있는 더 긴 표현식은 더 이상 작동하지 않습니다.

Struts 7.x로 마이그레이션하려면 훨씬 더 많은 요구 사항이 추가되는데, 그중 두 가지는 Struts 코드 한 줄도 수정하기 전에 이미 막대한 노력이 필요한 작업입니다. 첫째, Struts 7.x는 최소 런타임 환경으로 Java 17을 요구합니다. 대규모 엔터프라이즈 Struts 배포 환경에서 흔히 볼 수 있듯이, 여전히 Java 8이나 Java 11을 실행 중인 조직의 경우, 이는 개발, CI, 스테이징, 프로덕션 등 모든 환경에 걸쳐 완전한 JVM 업그레이드를 계획하고 실행해야 함을 의미합니다. 둘째, Struts 7.x는 Jakarta EE를 요구하므로, 전체 코드베이스에 걸쳐 있는 모든 `javax.*` 임포트 문은 해당 `jakarta.*` 대응 항목으로 업데이트되어야 합니다. 이러한 javax에서 jakarta로의 네임스페이스 마이그레이션은 Action 클래스, 구성 파일, 사용자 정의 인터셉터, JSP, 그리고 아직 Jakarta EE 호환 릴리스를 출시하지 않은 종속성 트리의 모든 타사 라이브러리에서 나타나는 `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*` 및 기타 모든 `javax.*` 패키지에 영향을 미칩니다. 대규모 엔터프라이즈 코드베이스에서 이 네임스페이스 마이그레이션만으로도 수백 개의 파일에 걸쳐 수천 개의 import 문이 발생할 수 있으며, 애플리케이션 스택의 모든 계층에서 종단 간 검증이 필요합니다. 이 두 가지 전제 조건이 해결된 후에야 Struts 특유의 마이그레이션 작업이 시작됩니다. 요청 매개변수를 수신하는 모든 Action 클래스의 세터(setter)는 `@StrutsParameter` 어노테이션으로 명시적으로 표시되어야 하며, 이 변경 사항은 성숙한 애플리케이션의 수백 개 세터에 영향을 미칠 수 있습니다. 네임스페이스 매핑 기본값이 정확한 일치(exact match)를 요구하도록 변경되어, 기존 템플릿의 링크가 깨질 가능성이 있습니다. 기존의 File Upload Interceptor는 완전히 제거되고 Action File Upload Interceptor로 대체되었으며, 이로 인해 파일 업로드를 처리하는 애플리케이션에서는 구성 및 코드 변경이 필요합니다. Struts에 상당한 투자가 이루어진 애플리케이션(이주 문제가 의미 있는 대부분의 애플리케이션에 해당)의 경우, Struts 7.x로의 적절히 계획되고 테스트된 이주는 몇 주가 아닌 몇 달 단위로 소요됩니다.

옵션 2: 다른 웹 프레임워크로 마이그레이션

일부 조직에서는 Apache Struts의 지원 종료(EOL)를 계기로 Spring MVC, Faces를 활용한 Jakarta EE, Micronaut, Quarkus 등 다른 Java 웹 프레임워크를 검토하기도 합니다. 이러한 아키텍처적 고려는 특정 상황에서 타당성을 갖는데, 특히 현대적인 REST-first 아키텍처가 애플리케이션의 현재 요구 사항을 더 잘 충족시키거나, 클라우드 네이티브 배포 모델에 더 가벼운 프레임워크가 유리할 때 그러합니다.

프레임워크를 완전히 마이그레이션하는 것은 Struts 버전 업그레이드보다 훨씬 더 많은 비용이 듭니다. 액션 클래스, JSP 템플릿, FreeMarker 뷰, Tiles 레이아웃, 유효성 검사 구성, 인터셉터 스택, struts.xml 매핑 등은 모두 교체하거나 상당한 수정이 필요합니다. 프로그래밍 모델도 다르고, 배포 모델도 다르며, 평가, 계획, 마이그레이션 과정 전반에 걸쳐 EOL(지원 종료)된 Struts 버전이 여전히 운영 환경에서 가동되고 있습니다. 이는 일정에 앞서 다가오는 EOL 날짜에 의해 강요된 결정이 아니라, 신중하게 계획된 별도의 일정을 필요로 하는 전략적인 인프라 결정입니다.

옵션 3: TuxCare 확장 수명 주기 지원: 권장 경로

이 옵션은 새로운 문제를 야기하지 않으면서 당면한 문제를 해결해 줍니다. TuxCare의 Struts ‘무기한 라이프사이클 지원’을 이용하면, 강제 마이그레이션 없이도 기존 Maven 또는 Gradle 툴체인을 통해 프레임워크와 그 종속성 트리에 대한 지속적인 보안 패치 지원을 받으면서, 현재 사용 중인 Struts 버전을 프로덕션 환경에서 계속 운영할 수 있습니다.

보안 취약점은 즉시 해소됩니다. 규정 준수 상태는 유지됩니다. 귀사의 팀은 운영상 타당한 일정에 따라 적절한 마이그레이션을 자유롭게 계획할 수 있습니다. 여기에는 Struts 7.x 매개변수 주입에 대한 Action 클래스 주석 처리, 템플릿 전반에 걸친 OGNL 표현식 패턴 업데이트, 전체 애플리케이션 엔드포인트 세트에 걸친 동작 검증 등에 필요한 충분한 준비 기간도 포함됩니다. 마감 기한의 압박에 따른 강제 마이그레이션도, 규정 준수 관련 긴급 상황도, 실제 사용자에게 서비스를 제공하는 프로덕션 웹 애플리케이션의 동작 퇴행도 발생하지 않습니다.

Struts 마이그레이션을 서두를 경우의 위험성

보안 대시보드에 EOL(제품 수명 주기 종료) 상태가 표시되고 규정 준수 팀에서 질문을 시작하면, 즉각적인 조치를 취해야 한다는 압박감이 실감나게 다가옵니다. 서둘러 진행하는 Struts 마이그레이션이 실제로 무엇을 수반하는지 파악하는 것은, 보안 취약점 자체를 이해하는 것만큼이나 중요합니다.

Struts 마이그레이션이 실제로 무엇을 포함하는가

Struts를 제대로 마이그레이션하는 작업, 특히 2.5.x에서 6.x 또는 7.x로 마이그레이션하는 것은 단순한 의존성 버전 업데이트가 아니라 여러 단계로 이루어지는 애플리케이션 프로젝트입니다. 이 작업에는 전체 코드베이스에 대한 구식 API 및 제거된 기능에 대한 검토, 현재 버전이 Struts 6.x의 최소 요구 사양보다 낮은 경우 Java 런타임 업데이트, Servlet API 참조 및 배포 설명자 구성 업데이트, struts.xml 전반에 걸쳐 구식 구성 상수 교체, XWork 패키지 재구성에 영향을 받는 모든 Action 클래스 임포트 업데이트, 그리고 정적 메서드 호출에 의존하거나 새로운 256자 제한을 초과하는 OGNL 표현식 재작성이 필요합니다.

코드 적용: 폼 또는 요청 매개변수를 받는 모든 Action 클래스의 세터 메서드에는 @StrutsParameter 어노테이션으로 주석이 달아야 합니다. 수십 개 또는 수백 개의 Action 클래스가 포함된 대규모 애플리케이션의 경우, 이는 체계적인 코드베이스 변경 사항이므로, 주입 지점을 실수로 누락하는 것을 방지하기 위해 철저한 검토가 필요합니다. 주입 지점이 누락되면 양식 제출 처리 과정에서 눈에 띄지 않는 오류가 발생할 수 있습니다.

호환성 검증: 애플리케이션 내의 모든 JSP, FreeMarker 템플릿 및 Velocity 템플릿에 대해, 정적 메서드 액세스를 사용하거나 길이 제한을 초과하거나 더 이상 사용되지 않는 태그 라이브러리를 참조하는 OGNL 표현식이 있는지 검토해야 합니다. FreeMarker의 기본 자동 이스케이핑 설정을 포함한 템플릿 렌더링 동작의 변경은 엔드투엔드 테스트에서 드러나는 미묘한 출력 차이를 유발할 수 있습니다.

툴체인 조정: Struts 전용 플러그인, DTD 선언 및 구성 상수를 참조하는 빌드 구성, CI/CD 파이프라인 및 배포 설명서를 검토하고 업데이트해야 합니다. Tiles 플러그인은 버전 간에 변경되었으며, Velocity 지원은 전용 플러그인으로 분리되었습니다. 대상 버전에서 제거된 모든 플러그인 종속성은 대체하거나 빌드에서 제거해야 합니다.

테스트 오버헤드: 양식 제출, 파일 업로드, 유효성 검사 흐름, 인터셉터 동작 및 결과 렌더링을 아우르는 애플리케이션 전반에 걸친 포괄적인 종단 간 테스트는 반드시 수행해야 합니다. 매개변수 주입 모델, 네임스페이스 매핑 기본값 및 OGNL 평가 의미론의 동작 변경 사항은 모두 실제와 유사한 요청 패턴 하에서 검증된 후에만本番 환경에 배포해야 합니다.

마이그레이션을 서두르면 어떤 일이 일어날까요?

팀들이 마감 기한의 압박 속에서 이 작업을 서둘러 처리할 때, 그 결과는 뻔하며 일정한 패턴을 따릅니다.

지원 업무 부담 증가: Action 클래스의 주석 누락, OGNL 표현식 업데이트 누락, 검증되지 않은 템플릿 렌더링 변경 사항은 프로덕션 환경에서 양식 제출 실패, 검증 흐름 오류, 예상치 못한 페이지 렌더링 오류로 나타납니다. 이로 인해 엔지니어링 및 운영 팀은 평소 업무량에 더해 이러한 사고를 처리해야 하는 부담을 떠안게 됩니다.

시스템 불안정성: Struts 애플리케이션은 대출 신청, 환자 포털, 정부 서비스 신청 등 대외 업무 워크플로우의 기반이 되는 경우가 많으며, 이러한 환경에서 동작상의 회귀 현상은 실제 사용자에게 즉각적인 영향을 미칩니다. 매개변수 바인딩, 인터셉터 실행 순서 또는 결과 렌더링의 미세한 변화만으로도 재현하기 어려운 간헐적인 오류가 발생할 수 있으며, 이러한 오류는 사전 테스트 환경에서는 거의 재현되지 않는 실제 운영 환경의 요청량 하에서 나타납니다.

기술 부채의 누적: 시간적 압박 속에서 적용된 임시 해결책이 영구적인 상태로 굳어집니다. 검토 없이 일괄적으로 어노테이션이 적용된 액션 클래스는 의도하지 않은 매개변수 주입 지점을 유발합니다. 새로운 허용 목록 모델이 보안에 미치는 영향을 충분히 이해하지 못한 채 OGNL 표현식을 급하게 리팩토링한 결과, 마이그레이션 전에는 존재하지 않았던 취약점이 발생했습니다. Apache Struts의 EOL(지원 종료) 문제는 해결되지 않고 단지 미뤄진 상태입니다.

예상치 못한 비용: 긴급 엔지니어링 업무 시간, 기능 출시 지연, 사고 대응에 드는 간접 비용, 그리고 시니어 엔지니어들이 새로운 기능을 개발하는 대신 운영 중인 웹 애플리케이션의 장애를 해결하는 데 소요되는 기회 비용 등은 모두 예상치 못한 방식으로 빠르게 누적됩니다.

간편한 해결책: Apache Struts 지원 종료(EOL)를 위한 TuxCare ELS

TuxCare는 지원이 종료된 Struts 버전에 대해 ‘무기한 라이프사이클 지원’을 제공합니다. 준비가 되지 않은 상태에서 강제로 마이그레이션을 진행할 필요 없이, 기존 Maven 또는 Gradle 빌드 툴체인을 통해 지속적으로 제공되는 보안 패치를 적용하여 현재 Struts 배포 환경을 계속 운영할 수 있습니다.

TuxCare는 지난 10년 넘게 지원이 종료된 운영 체제, 런타임, 라이브러리 및 애플리케이션 프레임워크를 위한 보안 패치를 제공해 왔습니다. 이들은 오픈소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포했습니다. TuxCare가 기업 규모에서 지원 종료된 소프트웨어의 보안을 유지하는 방법을 알고 있다고 말할 때, 이는 단순한 마케팅 수사가 아닙니다. 이들은 실제로 대규모로, 꾸준히 이를 실천해 왔습니다.

전체 종속성 트리 지원: TuxCare의 Struts용 ELS는 프레임워크와 그 직접 및 전이적 종속성(OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2 등)을 포함하며, 추가 비용 없이 해당 라이브러리의 CVE 취약점까지 모두 커버합니다. 취약점 스캐너는 패키지 경계를 구분하지 않으며, TuxCare의 커버리지 역시 마찬가지입니다. 단순히 최상위 Struts 아티팩트뿐만 아니라 전체 패치 대상 영역이 처리됩니다.

정교하고 자동화된 패치 적용 프로세스: TuxCare는 NVD, 벤더 보안 권고, Apache 자체 CVE 목록, GitHub 보안 피드 등 Struts 및 종속성 취약점이 공개되는 모든 채널을 모니터링합니다. CVE가 식별되면 알고리즘 도구와 AI 기반 자동화 시스템이 지원되는 버전으로 보안 수정 사항을 백포트하며, 보안 전문가들이 패치가 배포되기 전에 모든 패치를 검증합니다. 모든 업데이트는 귀하의 리포지토리에 도달하기 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 자세한 기술 정보는 다음을 참조하십시오. TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를 참조하십시오.

원활한 통합: 현재 Maven이나 Gradle을 통해 Struts를 사용하고 계시더라도, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. 빌드 파이프라인이나 CI/CD 워크플로우, 팀의 업무 방식에 아무런 변화가 없습니다. 보안 업데이트는 기존 툴체인을 통해 자동으로 적용됩니다.

SLA에 기반한 신속 대응: Apache Struts EOL 버전에서 프레임워크 자체나 종속성 트리 내에서 새로운 취약점이 공개될 경우, TuxCare는 서비스 수준 계약(SLA)에 따라 보장된 일정 내에 패치를 제공합니다. 고위험 및 치명적 심각도(CVSS 7+) 취약점은 공개 후 14일 이내에 해결됩니다. EOL Struts 버전에 대해 결코 제공되지 않을 커뮤니티 백포트를 기다릴 필요가 없습니다. 고객은 계획에 맞춰 사용할 수 있는 일정에 따라 즉시 적용 가능한 패치를 제공받으며, 취약점 분류 및 문제 해결을 위한 연중무휴 전문가 지원을 받을 수 있습니다.

비용 효율적인 보안 연속성: TuxCare ELS의 비용은 규정 준수 기한으로 인해 엔지니어링 시간, 운영 위험, 사고 대응 및 로드맵 작업 지연이 불가피한 상황에서 긴급 프레임워크 마이그레이션에 드는 비용의 극히 일부에 불과합니다. 예측 가능한 보안 범위, 통제된 마이그레이션 일정, 그리고 규정 준수 관련 긴급 상황의 부재는 확장 지원이 올바른 기업 전략인 이유입니다.

EOL(지원 종료)된 Struts 버전에서 정확히 어떤 취약점이 해결되었는지 확인하려면, TuxCare에서 Struts용 실시간 CVE 추적기를 운영하고 있습니다를 운영하고 있습니다.

Apache Struts의 지원 종료로 인해 웹 애플리케이션이 위험에 처하지 않도록 하세요

Apache Struts의 지원 종료(EOL)가 곧바로 애플리케이션의 보안이 침해된다는 뜻은 아니며, 팀이 준비되지 않은 상태에서 긴급 마이그레이션을 수행해야 한다는 의미도 아닙니다. 하지만 이번 Apache Struts의 지원 종료는 웹 애플리케이션 인프라가 의존해 온 보안 보호 장치가 더 이상 존재하지 않음을 의미하며, Equifax 해킹 사건은 패치되지 않은 Struts가 대규모로 노출될 경우 어떤 결과가 초래되는지를 명확히 보여주었습니다.

이 문제를 잘 처리하는 조직은 EOL(지원 종료) 상태를 압박감 속에서 대응해야 할 마감 기한이 아니라, 관리해야 할 보안 문제로 여기는 곳입니다. Action 클래스에 주석을 올바르게 달고, 템플릿 레이어 전반에 걸쳐 OGNL 표현식 패턴을 업데이트하며, 전체 엔드포인트 세트에 걸쳐 동작을 검증하는 데 필요한 추가 시간을 포함하여, 팀의 역량에 진정으로 부합할 때 Struts 6.x 또는 7.x로의 신중한 마이그레이션을 계획할 수 있습니다. 더 광범위한 프레임워크 마이그레이션이 실제 아키텍처적 목적을 달성하는지 평가해 볼 수도 있습니다. 또는 TuxCare ELS를 활용하여 규정 준수 감사관의 일정이 아닌, 자체 일정에 따라 결정을 내리는 동안에도 완벽한 보안과 규정 준수를 유지할 수 있습니다.

확장 지원은 임시방편이 아닙니다. 이는 Struts 애플리케이션의 보안을 유지하고, 규정 준수 상태를 온전하게 지키며, 엔지니어링 팀이 문제 해결에 매달리는 대신 개발에 집중할 수 있도록 해주는 선택지입니다. 현재 Apache Struts의 지원 종료(EOL)가 보안 관리의 주요 관심사라면, 다음을 방문해 주십시오. TuxCare의 오픈소스 소프트웨어 무제한 라이프사이클 지원 를 방문하여, 확장 지원이 필요한 기간 동안 웹 애플리케이션 인프라를 어떻게 보호할 수 있는지 확인해 보십시오.

요약