Log4j Vulnerability

무엇이 문제였나

Log4j 취약점은 보통 Log4Shell로 불린다. 핵심은 로그 메시지 안의 특정 문자열이 원격 조회로 이어질 수 있었고, 그 결과 원격 코드 실행까지 이어질 수 있었다는 점이다.

가장 널리 알려진 이슈는 CVE-2021-44228이다.

왜 영향이 컸나

이 취약점이 크게 퍼진 이유는 세 가지다.

• Log4j 2가 매우 널리 사용됐다.
• 단순 문자열 입력만으로도 트리거될 수 있었다.
• 서버 내부까지 깊이 포함된 라이브러리라 탐지가 어려웠다.

즉 애플리케이션 코드에서 Log4j를 직접 쓰지 않아도, 의존성 트리 어딘가에 포함돼 있으면 영향을 받을 수 있었다.

실무 대응 포인트

실제 대응은 다음 순서로 이뤄진다.

1. 사용 중인 Log4j 버전 확인
2. 직접/간접 의존성 포함 여부 확인
3. 안전한 버전으로 업그레이드
4. 취약 기능 비활성화 여부 검토
5. 침해 흔적과 이상 로그 점검

보안 사고에서 중요한 것은 “우리 코드에 직접 import가 없었다”가 아니라 배포 산출물에 포함됐는가다.

배운 점

• 로깅 라이브러리도 공격 표면이 될 수 있다.
• 의존성 관리는 기능 관리가 아니라 보안 관리이기도 하다.
• SBOM, 취약점 스캐너, 의존성 점검 체계가 중요하다.

정리

Log4j 취약점은 단일 라이브러리 문제를 넘어, 현대 애플리케이션이 오픈소스 의존성에 얼마나 깊게 기대고 있는지를 드러낸 사건이었다. 운영 중인 서비스라면 기능 코드뿐 아니라 의존성 공급망까지 같이 관리해야 한다.