과거의 큰 사건을 되짚습니다. 공격을 재현하기 위해서가 아니라, 지금도 여러분의 운영에 적용되는 교훈을 위해서입니다.
무슨 일이 있었나: 로그 기록이 공격 경로가 되었다
Log4j는 로그를 기록하는 평범한 작업을 처리했고, Java 애플리케이션에서 매우 널리 쓰였습니다. 결함은 이것입니다: 이 라이브러리가 기록되는 문자열 안의 특정 패턴을 "외부로 손을 뻗어 해석할 것"으로 처리해, 결국 외부에서 지정한 코드를 실행하고 만 것입니다.
그래서 "기록되는 어딘가"(사용자 이름, 헤더)에 조작된 문자열을 넣은 공격자는 코드 실행에 도달할 수 있었습니다. 로깅이라는 수동적 행위가 공격 경로가 될 수 있다는 사실은 큰 놀라움을 주었습니다.
왜 영향을 받는지 판단하기 어려웠나
대부분의 앱은 Log4j를 직접 설치한 적이 없었습니다. 프레임워크나 SDK가 끌어온 것이었습니다. 이것이 전이 의존성, 즉 의존성의 의존성의 의존성입니다. 자신의 "자재 명세서"가 없으면 영향 여부조차 알 수 없었습니다.
가장 큰 문제는 사용 여부를 알 수 없다는 점이었다
"쓰는지 알 수 없을" 때는 대응의 우선순위조차 정할 수 없습니다. 자재 명세서(SBOM)를 보유했는지 여부가 대응 속도를 크게 좌우했습니다.
타임라인
2021-12-09–10
결함이 널리 알려지고, 전 세계가 "우리는 영향을 받는가?" 확인에 분주해짐.직후
긴급 패치와 임시 완화책이 쏟아지고, 악용 시도가 급증.이후
여러 후속 CVE(수정에 대한 수정)가 공개됨 — "한 번 고쳤다"가 끝이 아니었음.
여전히 적용되는 교훈
SBOM(자재 명세서)을 갖춘다
여러분의 앱이 내부적으로 무엇을 쓰는지 가시화하십시오. npm ls, 락파일, SBOM 도구가 실제로 동작 중인 것을 보여줍니다. "직접 설치한 것"만 보는 것으로는 부족합니다.
의존성을 기계로 모니터링한다
CVE가 공개되는 순간, 전이 의존성을 포함해 그것이 적용되는지 자동으로 알 수 있게 하십시오(Dependabot / osv-scanner). 수동 확인은 늘 무언가를 놓칩니다.
패치를 빠르게 한다
비상시에 빠르게 할 수 있도록 "업그레이드하고, 검증하고, 배포하는" 작업을 평소에 연습해 두십시오. 의존성 모니터링 구축하기를 참고하십시오.
후속 CVE를 추적한다
Log4Shell 이후 수정에 대한 수정이 나타났습니다. "한 번 고쳤다"에서 멈추지 말고, 후속 수정을 추적하십시오.
이어서 읽기
- 용어: RCE란 무엇인가 · CVE란 무엇인가
- 방어: 의존성 모니터링을 운영에 녹여 넣기
- 프레임워크: Spring Boot 보안 대책(의존성 CVE·Actuator·역직렬화)
- 사고: 방치된 알려진 CVE가 1억 4,700만 명을 유출
- 사고: Heartbleed — 치명적인 OpenSSL 결함
출처와 확인 범위
아래 1차 자료는 위의 설정·영향 범위·대응을 뒷받침하며 링크는 2026년 10월 23일 확인했습니다. 자료의 버전·구성 조건을 확인하세요. 점검 우선순위와 교훈은 이 사이트의 정리이며 글 전체의 재검증이나 안전 보증이 아닙니다.