기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 내용
- Jackson의 EOL은 위험 노출 범위를 확대합니다: Jackson Databind는 실제 CVE 이력이 있는 Jackson Core에 의존하므로, EOL로 인해 JSON 파싱 계층이 노출됩니다.
- 서두른 업그레이드는 비용이 많이 듭니다: Jackson의 마이너 버전 변경은 역직렬화, 어노테이션 및 ObjectMapper 동작에 영향을 미칠 수 있으므로, 애플리케이션 전반에 걸친 체계적인 검증이 필요합니다.
- EOL이 보안의 종료를 의미하는 것은 아닙니다: TuxCare의 Jackson용 ELS는 지원이 종료된 Jackson 버전에 대해 지속적인 패치를 제공하므로, 고객은 본인의 일정에 맞춰 업그레이드할 수 있습니다.
ELS for Jackson이 존재하는 이유는, Jackson Databind가 실제 운영 환경에서 가장 널리 배포된 자바 라이브러리 중 하나이자, 엔터프라이즈 애플리케이션 스택에서 가장 지속적으로 간과되는 EOL(지원 종료) 위험 요소 중 하나이기 때문입니다. Jackson은 JVM 환경에서 JSON 처리를 위한 사실상의 표준입니다. 지난 10년 동안 구축된 거의 모든 자바 애플리케이션에서 REST API, 메시지 브로커, 마이크로서비스, 데이터 파이프라인 전반에 걸쳐 직렬화 및 역직렬화 작업을 처리합니다. 잭슨 버전이 지원 종료(EOL)에 이르면, 해당 버전에 의존하는 모든 애플리케이션은 처리하는 모든 JSON 페이로드를 처리하는 이 라이브러리에 대한 보안 패치를 더 이상 받을 수 없게 됩니다.
FasterXML 팀은 잭슨(Jackson)을 장기 지원(LTS) 모델에 따라 유지 관리하고 있지만, 최신 브랜치에 새로운 패치 릴리스가 존재하더라도 구형 폐쇄 브랜치를 계속 사용하는 팀들은 보안 취약점에 노출된 상태입니다. 잭슨 2.17, 2.16, 2.15 또는 그 이전의 폐쇄 브랜치를 실행 중인 조직은 업스트림 보안 지원 없이 운영되고 있으며, 잭슨 코어(Jackson Core)와 잭슨 데이터바인드(Jackson Databind)의 CVE 이력을 보면 이러한 취약성이 명백하고 측정 가능한 수준임을 알 수 있습니다.
이 글에서는 Jackson의 릴리스 라이프사이클이 실제로 어떻게 작동하는지, Jackson Databind의 EOL(지원 종료)이 보안 및 규정 준수 측면에서 어떤 의미를 갖는지, 그리고 자체 일정에 맞춰 업그레이드를 계획하는 동안 그 격차를 해소하는 가장 직접적인 방법이 왜 Jackson용 ELS인지에 대해 설명합니다.
잭슨의 릴리스 라이프사이클이란 무엇인가요?
Jackson은 JDK의 버전 관리 방식과 유사하게 장기 지원(LTS) 모델을 따릅니다. 이 모델을 이해하는 것은 사용 중인 Jackson 버전에 대한 패치 제공이 언제 중단되는지, 그리고 현재 실행 중인 버전이 여전히 지원 대상인지 정확히 파악하는 데 필수적입니다.
LTS 브랜치와 비-LTS 브랜치. 모든 Jackson 마이너 릴리스가 LTS 버전은 아닙니다. 출시 시기와 안정성을 고려하여, 대략 세 번째 마이너 릴리스마다 초기 출시 시점에 LTS로 지정됩니다. LTS 브랜치는 최소 2년 동안 유지됩니다. 비 LTS 브랜치는 다음 LTS 버전이 출시될 때까지만 유지됩니다.
“종료”의 의미. 잭슨(Jackson) 브랜치가 '폐쇄'되면, FasterXML 팀은 해당 브랜치에 대한 패치 릴리스를 중단합니다. 보안 수정도, 버그 수정도 없으며, 브랜치는 동결됩니다. 프로젝트 위키에는 폐쇄된 브랜치에 대해 다음과 같이 명시되어 있습니다: 폐쇄된 버전을 운영하는 조직은 자체적으로 관리해야 합니다.
현재 지원 현황. 2026년 초 현재, 활발하게 유지보수 중인 오픈 소스 브랜치는 다음과 같습니다:
- 2024년 9월 26일에 출시된 2.18(LTS) 버전은 백포트 및 패치 릴리스를 지원합니다
- 2.21 (LTS), 2026년 1월 18일 출시, 패치 릴리스 시작
- 3.1 (LTS), 2026년 2월 23일 출시
다른 모든 브랜치는 지원이 종료되었습니다. Jackson 2.17은 2025년 8월 2.20.0이 출시되면서 지원이 종료되었습니다. Jackson 2.19는 2025년 10월에 지원이 종료되었습니다. Jackson 2.20은 2026년 1월 2.21.0(LTS)이 출시되면서 지원이 종료되었습니다. Jackson 2.16은 2025년 4월에 지원이 종료되었습니다. Jackson 2.15는 2024년 9월에 지원이 종료되었습니다. Jackson 2.13과 2.14는 모두 2023년 11월에 지원이 종료되었습니다. 이 버전들에서 실행 중인 모든 애플리케이션은 지원 종료(EOL)된 Jackson 릴리스를 사용하고 있는 것입니다.
핵심 구성 요소 버전 요구 사항. Jackson의 세 가지 핵심 구성 요소인 Jackson Annotations, Jackson Core, Jackson Databind는 항상 동일한 소버전을 공유해야 합니다. 예를 들어, Jackson Core 2.18.x와 Jackson Databind 2.17.x를 함께 사용할 수 없습니다. 이러한 긴밀한 연동 관계로 인해 Jackson Databind의 지원 종료(EOL)는 동시에 Jackson Core의 지원 종료이기도 하며, 그 반대의 경우도 마찬가지입니다.
최소 Java 요구 사항. Jackson 2.13은 Jackson Core 스트리밍의 기준 버전으로 JDK 6을 지원하는 마지막 2.x 브랜치였습니다. Jackson 2.14 및 그 이후의 모든 2.x 릴리스는 최소 Java 8이 필요합니다.
| 잭슨 지점 | LTS 현황 | 상태 | 휴무일 |
| 2.21 | LTS | 열기 | - |
| 2.20 | 비 LTS | 마감됨 | 2026년 1월 (버전 2.21.0) |
| 2.19 | 비 LTS | 마감됨 | 2026년 1월 (버전 2.21.0) |
| 2.18 | LTS | 열기 | - |
| 2.17 | 비 LTS | 마감됨 | 2025년 8월 (버전 2.20.0) |
| 2.16 | 비 LTS | 마감됨 | 2025년 4월 (버전 2.19.0) |
| 2.15 | 비 LTS | 마감됨 | 2024년 9월 (버전 2.18.0) |
| 2.14 | 비 LTS | 마감됨 | 2023년 11월 (버전 2.16.0) |
| 2.13 | 비 LTS | 마감됨 | 2023년 11월 (버전 2.16.0) |
Jackson Databind의 EOL이란 무엇을 의미하나요?
보안 패치 더 이상 제공되지 않습니다
잭슨(Jackson)의 특정 브랜치가 폐쇄되면, FasterXML 팀은 해당 브랜치에 대한 보안 수정 사항의 배포를 중단합니다. 폐쇄 이후에 공개되는 모든 취약점(파싱 계층, 역직렬화 파이프라인, 또는 ObjectMapper의 신뢰할 수 없는 입력 처리 과정에서 발생하는 취약점 등)에 대해서는 현재 활성화된 브랜치에 패치가 제공되지만, 사용자의 버전은 여전히 취약한 상태로 남게 됩니다.
이 점이 중요한 이유는 Jackson이 수동적인 유틸리티 라이브러리가 아니기 때문입니다. Jackson은 네트워크 엔드포인트, 메시지 큐, REST 클라이언트, 외부 API에서 전송되는 신뢰할 수 없는 JSON 페이로드를 능동적으로 파싱합니다. 수신 데이터에 대해 ObjectMapper.readValue()나 ObjectMapper.readTree()를 호출할 때마다, 보안 패치 제공이 중단된 폐쇄된 브랜치의 파서를 통과하는 실행 경로가 생성됩니다. 이러한 보안 취약점은 모든 요청에서 실시간으로 노출됩니다.
Jackson Databind 지원 종료(EOL) 이후의 보안 및 규정 준수 위험
규정 준수 요건은 명확합니다. PCI DSS(요구 사항 6.3.3)는 CVSS 점수가 7.0 이상인 중요 및 고위험 취약점에 대해, 해당 시스템에 적용 가능한 패치가 출시된 후 1개월 이내에 패치를 적용하도록 의무화하고 있습니다. HIPAA, FedRAMP 및 SOC 2에도 이와 유사한 요구 사항이 포함되어 있습니다. 결제 데이터, 의료 기록 또는 인증된 API 트래픽을 처리하는 애플리케이션의 경우, 패치를 적용할 수 없는 EOL(지원 종료) 상태의 Jackson 버전을 사용하면 보안 및 규정 준수상의 공백이 발생하며, 이는 보완 통제 조치만으로는 부분적으로만 해결할 수 있습니다.
잭슨(Jackson)은 인증 토큰, 금융 관련 데이터, 의료 기록, 내부 서비스 API 응답 등 기업 환경에서 가장 민감한 데이터를 처리하는 애플리케이션의 역직렬화 계층에 위치합니다. 감사관들은 패치가 적용되지 않은 JSON 역직렬화 라이브러리를 중대한 문제점으로 간주하는데, 이는 파서가 외부 소스에서 유입된 신뢰할 수 없는 데이터를 처리하는 첫 번째 계층이기 때문입니다.
잭슨의 CVE 이력
잭슨의 CVE 기록은 EOL 이후 파서 노출이 실제로 어떤 모습인지 정확히 보여줍니다.
CVE-2025-52999: CVSS 4.0 점수 8.7, 심각도 높음 (NVD). 2025년 6월 25일에 공개된 이 취약점은 2.15.0 이전 버전의 모든 Jackson Core에 영향을 미칩니다. Jackson Core가 수천 단계에 달하는 중첩된 객체나 배열과 같이 깊게 중첩된 JSON 구조가 포함된 입력 파일을 파싱할 때, 파서는 각 중첩 수준마다 JVM 호출 스택에 새로운 JsonReadContext를 생성합니다. 2.15.0 이전 버전에서는 이러한 중첩 깊이에 대한 제한이 없습니다. 공격자는 수천 개의 중첩된 배열이나 객체로 구성된 JSON 페이로드를 조작하여 JVM의 호출 스택을 소진시키고 StackOverflowError를 발생시켜 애플리케이션을 중단시킬 수 있습니다. 이 공격은 네트워크를 통해 악용 가능하며, 인증이 필요하지 않고 사용자 상호작용도 필요하지 않습니다. NVD 벡터는 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N입니다. Jackson Core 2.15.0의 수정 사항으로 StreamReadConstraints가 도입되었으며, 이는 구성 가능한 최대 중첩 깊이로 기본값은 1000입니다. Jackson Databind는 모든 JSON 입력을 파싱하기 위해 Jackson Core를 사용하므로, 2.15.0 이전의 EOL(지원 종료) 브랜치에서 Jackson Databind를 실행하는 모든 애플리케이션은 해당 버전에 대한 업스트림 패치가 제공되지 않아 원격으로 악용 가능한 이 서비스 거부(DoS) 취약점에 노출되었습니다.
Spring Boot 2.7을 실행하는 엔터프라이즈 Java 환경의 경우, 이 버전은 전체 Jackson 의존성 트리를 2.13.x 계열로 고정하고 있습니다. 이 취약점은 2023년 11월 이후 폐쇄된 브랜치에 존재했으나 패치되지 않은 상태였습니다. 해당 폐쇄된 브랜치에 대해서는 업스트림 패치가 제공되지 않았으며, 표준 지원 경로는 프레임워크의 광범위한 업그레이드나 확장 지원 계약을 통해 해결하는 것이었습니다.
의존성 표면 문제
Jackson Databind의 직접적인 종속성 구조는 설계상 간결하게 구성되어 있습니다. FasterXML 프로젝트의 README에는 핵심 구성 요소, 어노테이션, 스트리밍, Databind가 핵심 JDK 외에 추가적인 종속성을 필요로 하지 않는다고 명시되어 있습니다. 실제로 Jackson Databind는 Jackson Core(저수준 스트리밍 파서 및 제너레이터)와 Jackson Annotations(어노테이션 처리 계층)라는 두 가지 패키지에만 직접적으로 의존합니다. 이 둘은 모두 FasterXML 패키지이며, 동일한 마이너 버전을 공유하고, Jackson 브랜치가 종료될 때 동일한 EOL(지원 종료) 이벤트의 일부가 됩니다.
비록 작은 문제일지 모르지만, CVE-2025-52999는 Jackson Core의 CVE 노출 위험이 현실적이며 직접적인 관련이 있음을 보여줍니다. Jackson 브랜치가 종료되면 Jackson Databind뿐만 아니라 Jackson Core와 Jackson Annotations도 동시에 지원이 중단됩니다. 폐쇄된 잭슨 브랜치를 실행하는 애플리케이션은 세 가지 핵심 구성 요소 모두에 걸쳐 패치되지 않은 취약점에 한꺼번에 노출됩니다. TuxCare의 ELS for Jackson은 잭슨 데이터바인드, 잭슨 코어, 잭슨 어노테이션 등 전체 종속성 영역을 포괄하므로, 이러한 취약점은 최상위 패키지 수준뿐만 아니라 포괄적으로 해결됩니다.
Jackson Databind 지원 종료 후 보안 및 규정 준수를 유지하기 위한 방안
지원되는 Jackson 버전으로 업그레이드하세요
Jackson 2.18 또는 2.21(현재 LTS 브랜치)로 마이그레이션하는 것이 올바른 장기적 방향입니다. FasterXML 팀은 각 마이너 버전에 대한 상세한 마이그레이션 가이드를 공개하고 있으며, Jackson 커뮤니티는 메이저 버전 라인 내에서 강력한 하위 호환성을 유지하고 있습니다.
이 마이그레이션의 난이도는 사용자의 환경에 따라 달라집니다. 대규모 애플리케이션 환경을 운영하는 조직의 경우, 직접적인 종속성 때문이 아니라 프레임워크 관리 방식을 통해 특정 잭슨(Jackson) 소버전에 고정된 코드베이스가 많은 경우가 많습니다. Spring Boot, Quarkus 및 기타 Java 프레임워크는 Jackson 버전을 전이적으로 관리하므로, Jackson의 마이너 버전 업그레이드는 대개 프레임워크 버전 변경도 수반합니다. 엔터프라이즈 애플리케이션 군에서 Jackson을 업그레이드하려면 코드베이스 전반에 걸쳐 모든 Jackson 사용처를 파악하고, 모든 ObjectMapper 구성에서 직렬화 동작을 검증하며, 특히 사용자 정의 직렬화기, 역직렬화기 또는 Jackson 모듈이 사용되는 경우 실제와 유사한 페이로드로 애플리케이션을 테스트해야 합니다.
다른 JSON 라이브러리로 전환하기
일부 조직에서는 Gson, Moshi, JSON-B 등 대체 JSON 라이브러리를 평가하기 위해 Jackson Databind의 EOL(지원 종료) 이벤트를 활용합니다. 이는 일부 팀에게 있어 타당한 장기적인 아키텍처적 결정이지만, 이를 위해서는 모든 직렬화 로직을 재작성하고, 모든 @JsonProperty 및 관련 어노테이션을 교체하며, ObjectMapper 구성을 마이그레이션하고, 모든 API 계약 및 데이터 모델에 걸쳐 동작을 검증해야 합니다.
당면한 보안 및 규정 준수 문제를 겪고 있는 대부분의 조직에게 있어, 라이브러리 마이그레이션은 패치 마감 기한에 대응하기 위한 조치가 아닙니다.
권장 경로: 잭슨용 TuxCare ELS
TuxCare의 Jackson용 ELS는 별도의 프레임워크나 종속성 업그레이드를 즉시 수행할 필요 없이 보안 및 규정 준수 문제를 직접 해결합니다. TuxCare는 지원이 종료된 Jackson 버전에 대해 Jackson Databind, Jackson Core, Jackson Annotations를 아우르는 지속적인 보안 패치를 추가 비용 없이 제공하므로, 고객은 실제로 원하는 업그레이드 계획을 수립하는 동안에도 애플리케이션 환경을 견고한 보안 상태로 유지할 수 있습니다.
TuxCare는 NVD, FasterXML 보안 권고 사항 및 업스트림 Jackson 릴리스 채널을 모니터링하여 Jackson Core 생태계에 영향을 미치는 취약점을 파악한 후, SLA 기반 프로세스를 통해 EOL(지원 종료) 버전에 대한 수정 사항을 백포트하여 제공합니다. 현재 Maven, Gradle 또는 기존 빌드 파이프라인을 통해 Jackson 업데이트를 적용하고 계시더라도, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 리포지토리로 전환할 수 있습니다. 현재 사용 중인 빌드 툴체인, 프레임워크 구성 또는 생성된 애플리케이션 코드에는 어떠한 차질도 발생하지 않습니다.
잭슨 업그레이드를 서두를 경우의 위험성
규정 준수 감사 결과, 취약점 스캐너 경고 또는 보안 팀의 보고를 통해 잭슨(Jackson)의 지원 종료(EOL) 시한이 다가온다는 사실을 알게 되면, 본능적으로 즉시 조치를 취하고 싶어집니다. 하지만 충분한 준비 없이 대응할 경우 발생하는 비용은 팀들이 예상하는 것보다 항상 더 큽니다. 잭슨용 ELS를 도입한 조직은 업그레이드를 적절히 계획하는 동안에도 보안 상태를 유지할 수 있으므로 이러한 압박을 완전히 피할 수 있습니다.
잭슨 마이너 버전 업그레이드의 실제 내용
Jackson의 마이너 버전 업그레이드는 단순히 POM 파일의 버전 번호를 올리는 것이 아닙니다. 이는 역직렬화 동작에 대한 검증을 수반합니다. Jackson의 마이너 릴리스에서는 null 처리, 형 변환 규칙, 알 수 없는 속성 처리와 관련된 기본 동작이 변경되는 경우가 있으므로, 특정 역직렬화 동작에 의존하는 애플리케이션은 실제와 유사한 페이로드를 사용하여 새 버전에 대한 검증을 반드시 거쳐야 합니다. 이는 Spring Boot, Quarkus 또는 기타 관리형 프레임워크를 사용하는 애플리케이션의 프레임워크 호환성 검증을 수반하며, 대상 잭슨 버전이 해당 프레임워크 버전에서 지원되는지, 그리고 전이적 의존성 충돌이 발생하지 않는지 확인해야 합니다. 또한 Kotlin, Scala, Guava 또는 기타 통합을 위한 잭슨 모듈을 사용하는 애플리케이션의 경우 사용자 정의 모듈 호환성 검증이 필요하며, 해당 모듈이 사용 가능하고 대상 잭슨 마이너 버전과 호환되는지 확인해야 합니다. 또한 직렬화에 잭슨을 사용하는 모든 API 엔드포인트, 메시지 수신자 및 데이터 파이프라인에 대한 테스트 오버헤드가 포함됩니다.
수십 개 또는 수백 개의 서비스가 공통된 Jackson 구성을 공유하고, 여러 팀이 Jackson 의존성 그래프의 각기 다른 부분을 담당하며, 변경 관리 절차에 따라 프로덕션 배포가 이루어지는 기업 환경에서는, Jackson EOL 업그레이드는 단순한 티켓 처리가 아닌 체계적인 작업 계획으로 진행되어야 합니다.
업그레이드를 서두르면 어떤 일이 벌어질까
애플리케이션 팀이 준비 상태가 아닌 규정 준수 기한 때문에 잭슨(Jackson)의 마이너 버전 업그레이드를 강행해야 할 때, 나타나는 패턴은 항상 비슷합니다. 자동화된 테스트에서는 나타나지 않았던 극히 드문 페이로드 상황에서, 프로덕션 환경에서 미묘한 역직렬화 동작의 변화가 드러납니다. 이전 버전의 ObjectMapper 설정이 관대했던 애플리케이션은, 새 버전이 더 엄격한 형 변환 규칙을 적용함에 따라 오류가 발생합니다. 타사 통합용 잭슨 모듈은 모듈 버전이 새로운 마이너 버전과 일치하지 않을 때 런타임 시 조용히 실패하거나 예외를 발생시킵니다. 팀이 마감 기한을 맞추기 위해 MapperFeature 우회 조치와 호환성 플래그를 적용함에 따라 기술적 부채가 누적되고, 이는 시간이 지남에 따라 가중되는 유지보수 부담을 초래합니다. 또한 시작 전에 범위가 제대로 설정되지 않은 업그레이드를 실행하는 과정에서 발생하는 엔지니어링 시간, 프로덕션 사고, 조정 오버헤드 등 계획에 없던 비용이 급증합니다.
잭슨(Jackson)의 EOL 전환을 성공적으로 처리하는 팀은 이를 계획된 마이그레이션으로 간주하여, 애플리케이션 전체 목록을 파악하고 프레임워크 호환성을 검증하며, 전 과정에 걸쳐 안정적인 보안 상태를 유지하는 팀입니다. ELS for Jackson은 바로 이러한 계획적인 접근 방식을 가능하게 해줍니다.
간편한 해결책: 잭슨을 위한 TuxCare ELS
TuxCare는 지원 종료된 소프트웨어에 대한 보안 패치를 대규모로 안정적으로 제공하기 위해 필요한 자동화 시스템, 전문 지식 및 프로세스를 10년 넘게 지속적으로 개선해 왔습니다. 지원 제품 포트폴리오 전반에 걸쳐 22만 개 이상의 패치를 배포한 경험을 바탕으로, TuxCare는 신속하면서도 운영 환경에 안전한 패치 적용 워크플로를 구축했습니다.
ELS for Jackson은 Jackson Databind의 지원 종료(EOL)로 인해 발생하는 보안 및 규정 준수상의 공백을 메워줍니다:
신속하고 SLA가 보장되는 보안 패치: TuxCare는 취약점 공개 정보를 지속적으로 모니터링하고, 정의된 SLA에 따라 고위험 및 치명적 CVE(CVSS 7.0+)에 대한 패치를 제공하여, 귀사의 Jackson 배포 환경이 PCI DSS, HIPAA, FedRAMP 및 기타 규정 준수 프레임워크에서 요구하는 패치 적용 일정을 준수할 수 있도록 지원합니다.
완벽한 종속성 표면 커버리지: ELS for Jackson은 추가 비용 없이 Jackson Databind, Jackson Core 및 Jackson Annotations(Jackson EOL 이벤트 발생 시 동시에 종료되는 FasterXML 핵심 패키지 전체 세트)를 포괄합니다. JSON 처리 스택 내 숨겨진 EOL 노출은 더 이상 수동으로 관리해야 하는 취약점이 되지 않습니다.
기존 워크플로우와의 원활한 통합: 현재 Maven이나 Gradle을 통해 Jackson 업데이트를 적용하고 계시더라도, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. 현재 사용 중인 빌드 툴체인이나 애플리케이션의 ObjectMapper 구성에 어떠한 차질도 발생하지 않습니다.
서명되고 변조 방지 기능이 적용된 패키지: TuxCare가 제공하는 모든 패치는 사용자의 저장소에 도달하기 전에 무결성, 기능성 및 회귀 현상에 대해 철저한 테스트를 거치며, 패키지는 암호학적으로 서명되어 사용자가 정확히 무엇을 배포하는지 알 수 있습니다.
연중무휴 전문가 지원: TuxCare의 보안 팀은 취약점 분류, 패치 요청 및 문제 해결을 위해 연중무휴 24시간 대기하고 있으므로, 전문적인 지원 없이 Jackson EOL 보안 사고를 처리해야 하는 상황이 발생하지 않습니다.
어떤 Jackson CVE가 이미 해결되었는지 확인하려면 TuxCare의 실시간 CVE 추적기를 참조하십시오. TuxCare의 패치 적용 프로세스 및 검증 기준에 대한 자세한 내용은 기술 백서를 참조하십시오.
잭슨 데이터바인드(Jackson Databind)의 지원 종료로 인해 애플리케이션이 위험에 처하지 않도록 하세요
Jackson의 EOL(지원 종료)이 발생한다고 해서 애플리케이션이 JSON 처리를 중단하는 것은 아닙니다. 하지만 이는 JSON 레이어가 의존해 온 보안 지원이 더 이상 제공되지 않음을 의미하며, 그 시점부터 Jackson Core 또는 Jackson Databind에서 공개되는 모든 CVE는 애플리케이션이 외부와 주고받는 모든 페이로드를 처리하는 라이브러리에 영향을 미치게 됩니다.
잭슨(Jackson)의 지원 종료(EOL)를 효과적으로 관리하는 팀들은 이를 보안 작업 흐름의 일환으로 계획합니다. 이들은 패치 프로세스를 정의하고, 애플리케이션 목록을 파악하며, 규정 준수 기한이 임박해 문제가 발생하기 전에 검증 일정을 수립합니다. 애플리케이션 팀의 역량, 프레임워크 호환성 요구 사항, 조직의 릴리스 일정에 진정으로 부합할 때, 현재 잭슨 LTS 버전으로의 신중한 업그레이드를 계획할 수 있습니다. 일정을 확정하기 전에 역직렬화 검증 및 롤아웃 범위를 적절히 설정할 수 있습니다. 또는 TuxCare의 ELS for Jackson을 사용하여 보안 및 규정 준수 범위를 유지하면서 직접 업그레이드 일정을 설정할 수도 있습니다.
ELS for Jackson은 FasterXML에서 더 이상 유지 관리하지 않는 Jackson 버전에 대해 애플리케이션 환경에 지속적인 보안 패치를 제공합니다. 이를 통해 감사에 필수적인 규정 준수 상태를 유지할 수 있으며, 엔지니어링 팀이 업그레이드를 체계적으로 계획할 수 있는 여유를 확보할 수 있습니다.
현재 Jackson Databind의 지원 종료(EOL)가 보안 관리의 주요 관심사라면, TuxCare의 잭슨(Jackson)에 대한 TuxCare의 페이지를 방문하여 지원이 종료된 잭슨 버전에 대한 연장 지원에 대해 자세히 알아보십시오.
