다음과 같은 경우 Apache Log4j가 지원 종료(EOL)가 되더라도 CVE는 계속 발생합니다.
지원되는 버전: 1.2.x, 2.17.x, 2.18.x
아파치는 2015년에 Log4j 1.x에 대한 패치 제공을 중단했으며, 2022년에는 Log4j 2.17–2.18에 대한 패치 제공도 중단했습니다. ‘Apache Log4j에 대한 지속적인 지원’ 서비스는 업스트림에서 패치 제공을 중단한 후에도 귀사가 이미 사용 중인 해당 버전이 안전하게 유지되고, 규정 준수 요건을 충족하며, 감사 대비가 가능하도록 보장합니다. 마이그레이션이나 코드 변경, 새로운 버전 도입이 필요하지 않습니다.
대기업들이 신뢰하는

보안, 규정 준수, 비즈니스 연속성 — 이 모든 문제를 한 번에 해결합니다
Apache Log4j의 지원 종료 버전을 안전하게 대체할 수 있는 솔루션을 도입하면, 스캐너가 더 이상 Log4j CVE를 경고 대상으로 표시하지 않게 됩니다.
보안
Apache에서 더 이상 패치를 제공하지 않는 버전에 대해 Log4j CVE가 발견되고, 검증되며, 수정될 때마다, 해당 스택에 대한 핵심 유지보수자 수준의 전문성을 갖춘 엔지니어들이 개발한 새로운 릴리스가 배포됩니다.
SLA에 기반한 패치 배포는 심각도에 따라 결정됩니다
HeroDevs는 발견된 취약점을 공개하는 공인 CVE 번호 부여 기관입니다.
규정 준수
설치가 완료되면, 해당 라이브러리는 지속적으로 패치되고 상용 지원이 제공되므로 스캐너는 더 이상 Log4j CVE를 탐지하지 않게 되며, 이로 인해 미해결 상태였던 감사 결과들이 해결된 것으로 처리됩니다.
SOC 2, PCI DSS, HIPAA, FedRAMP, ISO 27001, NIS2 등
감사인을 위한 문서화된 패치 내역
비즈니스 연속성
진정한 드롭인 방식: 동일한 Maven 좌표, 동일한 빌드 및 CI/CD 워크플로우를 유지하며, 애플리케이션 코드를 변경할 필요가 없습니다. Log4j를 고정시킨 프레임워크나 플랫폼은 적절한 순서에 따라 해결할 수 있습니다.
이전을 완료하기까지 수개월 또는 수년의 여유가 있다
이주 비용이나 침해 사고 발생 비용의 일부에 불과합니다.
Log4j 1
아파치는 2015년 8월 5일 Log4j 1.x의 지원 종료를 선언했습니다. 1.2.17 버전 이후로 업스트림에서 수정 사항이 제공되지 않았으며, 해당 날짜 이후에 공개된 취약점들은 아파치의 최종 릴리스에서도 여전히 해결되지 않은 상태로 남아 있습니다.
Log4j 2
Apache는 현재 릴리스 라인에서만 Log4j 2를 유지 관리합니다. 2.17 및 2.18 라인은 2022년 6월과 9월에 유지 관리 종료 시점에 도달했기 때문에, 해당 버전에 고정된 애플리케이션은 현재 Log4j 2 릴리스에 포함된 수정 사항을 전혀 적용받지 못합니다.
저희가 배포하는 모든 패치에는 공개된 CVE 항목이 포함되어 있습니다.
HeroDevs는 CVE 프로그램으로부터 권한을 부여받은 공인 CVE 번호 부여 기관(CNA)으로, HeroDevs가 발견한 보안 취약점에 대해 CVE ID를 발굴하고 할당할 수 있습니다.
Apache Log4j용 NES 릴리스에는 수정 사항이 포함된 정확한 아티팩트와 버전을 명시하는 HeroDevs VEX 문장이 CVE당 하나씩 포함되어 제공됩니다.
현재 구형 Apache Log4j 버전을 사용 중이라면, 애플리케이션이 보안 위협에 노출될 수 있습니다. NES for Apache Log4j는 단 몇 분 만에 설치할 수 있습니다.
Apache Log4j 2용 NES가 제공하는 내용
2.17.2 및 2.18.0용으로 공개된 모든 org.apache.logging.log4j 상위 모듈은 NES 좌표 하에 공개됩니다.
핵심
log4j-api
log4j-core
log4j-bom
레이아웃 및 호환성
log4j-레이아웃-템플릿-json
log4j-1.2-api
log4j-slf4j-impl
log4j-to-slf4j
log4j-jul
log4j-jcl
통합
log4j -spring-boot
log4j-spring-cloud-config-client
log4j-web
log4j-jakarta-web
log4j-appserver
log4j-jdbc-dbcp2
모든 표준, 프레임워크 또는 규정에 대해 타당한 답변을 제시합니다.
EOL 소프트웨어는 전 세계 규제에 따른 패치 관리 기대치를 저해합니다. NES는 정기적인 유지보수가 이루어지고 공급업체의 지원을 받는 빌드를 제공하며, 확약된 SLA와 문서화된 패치 이력을 통해 감사관 및 규제 당국에 규정 준수 여부를 입증할 수 있도록 지원합니다.
PCI DSS
요구사항 6.3.3에 따르면, 알려진 중대 및 고위험 취약점은 30일 이내에 패치해야 합니다. 업스트림 패치가 제공되지 않는 EOL(지원 종료) 상태의 Apache Log4j를 사용할 경우 규정 준수 요건을 충족하지 못하게 됩니다. NES는 패치 경로를 복원합니다.
HIPAA
지원되지 않는 프레임워크를 사용하면 ePHI를 처리하는 시스템에 대해 합리적인 보안 조치를 마련하기 어렵습니다. NES는 적극적인 유지 관리와 위험 완화를 제공합니다.
SOC 2
신뢰 서비스 기준은 취약점에 대한 적시적인 조치와 패치 관리를 요구합니다. EOL(지원 종료) 의존 항목은 이를 보완할 수 있는 지원 경로가 없는 한, 감사 과정에서 중대한 지적 사항으로 제기됩니다. NES가 바로 그러한 지원 경로입니다.
NIS2
제21조는 패치, 취약점 및 공급망 관리를 다룹니다. 유지보수 및 지원 체계가 없는 EOL(지원 종료) 소프트웨어를 계속 사용하면 위험이 발생하며, NIS2는 운영자가 이러한 위험을 적극적으로 완화할 것을 요구합니다.
DORA
DORA는 수명 종료(EOL) 소프트웨어를 금융 ICT 자산의 복원력 취약점으로 간주합니다. NES는 지속적으로 유지 관리되는 빌드와 문서화된 패치 관리 프로그램을 제공합니다.
사이버 복원력법
디지털 요소가 포함된 제품의 소프트웨어 수명 주기 보안을 관리합니다. NES는 보장 기간 동안 EOL(제품 수명 주기 종료) 상태인 Apache Log4j 제품군에 대해 유지보수 및 패치가 적용된 빌드를 제공합니다.
NIST CSF 2.0
PR.PS-02 지침에 따르면, 조직은 위험 수준에 따라 취약점이 있는 소프트웨어를 적극적으로 유지 관리하거나 제거해야 합니다. NES를 사용하면 강제 업그레이드 없이도 규정 준수를 달성할 수 있습니다.
FedRAMP
지속적인 모니터링은 정해진 주기에 따라 결함을 수정할 것을 전제로 합니다. 패치가 적용되고 공급업체가 지원하는 빌드는 ISSO가 지원 종료(EOL)된 Apache Log4j를 승인 범위 내에 계속 유지해야 할 타당한 근거로 삼을 수 있는 문서화된 수정 절차를 제공합니다.
상업 계약
취약점 및 구성 관리 통제 조치에는 기술적 취약점을 파악하고 소프트웨어를 보안 기준 범위 내에 유지하는 것이 필요합니다. NES는 지원 종료(EOL) 소프트웨어에 대해 이러한 보안 상태를 복원합니다.
핵심 기여자와의 파트너십
저희는 오픈소스 엔지니어 및 생태계 기여자들과 협력하여, ‘Never-Ending Support’ 제품들이 원본에서 기대해 오셨던 것과 동일한 품질을 유지하도록 보장합니다.
프로젝트에 대한 깊은 전문 지식을 갖춘 엔지니어들을 참여시킴으로써, 저희는 오픈소스 소프트웨어 유지보수의 새로운 기준을 제시하며, Log4j용 NES가 이를 기반으로 하는 업스트림 기술만큼이나 신뢰할 수 있도록 보장합니다.


우리는 오픈 소스에 기여합니다
오픈소스 유지보수자들은 매우 중요한 일을 하고 있지만, 이에 대한 보상을 받는 경우는 거의 없습니다.
HeroDevs는 이러한 현실을 바꾸기 위해 2,000만 달러를 투자하고 있습니다. 생태계를 유지하는 개발자와 프로젝트에 2,500달러에서 25만 달러에 이르는 보조금을 지원합니다.
우리는 유지보수가 중단된 코드베이스에 대한 패치를 작성하고, 그 누구도 주목하지 않았던 취약점을 찾아내며, 서둘러 코드를 재작성하지 않고도 핵심 시스템을 안전하게 가동해 왔습니다. 이 기금은 그러한 노력을 바탕으로 마련된 것으로, 유지보수자들이 자신들이 가장 잘하는 일을 계속할 수 있도록 돕기 위함입니다.
자주 묻는 질문
HeroDevs에서 제공하는 Log4j 1.2.x, Log4j 2.17.x 및 Log4j 2.18.x의 유지보수 빌드입니다. 보안 수정 사항은 최신 업스트림 릴리스인 1.2.17, 2.17.2 및 2.18.0의 포크에 반영되며, NES 버전 문자열을 사용하여 동일한 Maven 좌표로 공개되므로, 버전 하나만 변경하면 다른 설정은 그대로 유지할 수 있습니다.
네. 아파치는 2015년 8월 5일에 Log4j 1.x의 지원 종료를 선언했으며, 1.2.17 이후에 공개된 취약점들은 아파치의 최종 릴리스에서도 여전히 해결되지 않은 상태입니다. NES for Apache Log4j는 동일한 log4j:log4j 좌표 하에서 해당 취약점들을 패치합니다.
두 세대에 걸쳐 세 가지 버전: Log4j 1.2.x(groupId log4j)와 Log4j 2.17.x 및 2.18.x(groupId org.apache.logging.log4j). 이 모든 버전은 Java 8 이상이 필요합니다. 아파치에서 현재 배포 중인 Log4j 2 릴리스는 NES 버전이 아니며, NES가 필요하지 않습니다.
Apache는 Log4j 2.15부터 2.17.1까지의 버전에서 Log4Shell(CVE-2021-44228) 및 관련 후속 취약점을 수정했습니다. NES 포크 버전인 2.17.2와 2.18.0에는 이미 해당 수정 사항이 포함되어 있으므로, NES는 Log4Shell에 대한 패치를 적용하지 않으며, 이를 적용한다고 주장하지도 않습니다. NES는 해당 릴리스 이후에 공개된 취약점들에 대해 패치를 적용하며, 아파치는 현재 Log4j 2 버전에서만 이러한 취약점들을 수정합니다. Log4j 1.x는 CVE-2021-44228의 영향을 받지 않으며, 이 버전의 JMSAppender에는 관련 결함인 CVE-2021-4104가 존재하는데, NES는 이에 대한 패치를 제공합니다.
그룹 ID와 아티팩트 ID는 변경되지 않습니다. Log4j 1의 경우 log4j:log4j를 NES 버전으로 설정하면 됩니다. Log4j 2의 경우 Spring 에서 log4j2.version 속성을 설정하거나, NES 버전의 log4j-bom을 임포트하고, HeroDevs 레지스트리를 추가한 뒤 다시 빌드하면 됩니다. 로깅 구성과 애플리케이션 코드는 변경되지 않습니다.
많은 프로젝트에서 이를 적용할 수 있고, 또 그래야 합니다. 적용할 수 없는 프로젝트들은 다른 요인들— Spring 부트 또는 애플리케이션 서버 BOM, 벤더 SDK, 공유된 상위 POM, 혹은 정확한 종속성 세트를 다루는 인증 등—에 제약을 받고 있습니다. Log4j 1의 경우, Log4j 2가 서로 다른 API와 구성 형식을 사용하기 때문에 그 격차는 더욱 큽니다. 해당 작업이 계획되어 있는 동안 NES는 여러분이 현재 처한 상황을 해결해 줍니다.
Apache Log4j 1.2.x, 2.17.x 및 2.18.x용 NES는 ‘ Spring Boot 2.7 관리형 종속성’용 NES에 포함되어 있습니다. 이 페이지는 해당 번들 외부에서 Log4j를 실행하는 팀을 위한 것입니다.
각 패치에는 HeroDevs VEX 문과 스캐너가 인식할 수 있는 NES 버전 문자열이 포함되어 있으며, 이는 PCI DSS, SOC 2, HIPAA, NIS2, DORA 및 EU CRA 규정에 따라 감사관이 요구하는 증거 자료입니다. HeroDevs는 CVE 번호 부여 기관입니다.
NES는 1.2, 2.17 및 2.18 버전이 생산 단계에 있는 한 해당 버전에 대한 패치 지원을 계속합니다. 마이그레이션이 이루어질 경우, 이는 사고 발생 시점이 아닌 보안이 확보된 기준점에서 시작됩니다.
문의하기
오픈소스 라이브러리에 대한 네버엔딩 지원에 대해 궁금한 점이 있으신가요? 저희가 도와드리겠습니다!
히어로데브스 NES 제품이 시스템을 안전하게 보호하고 규정을 준수하는 방법을 알아보세요.
당사 솔루션이 조직에 어떤 가치를 제공할 수 있는지 알아보세요.
필요에 맞는 자세한 가격 정보를 확인하세요.
리소스
모든 기사 보기


