SKT 유심 해킹 사태, 왜 Runtime SBOM이 중요한지 보여준 대표적 사례

8년간 방치된 취약점, 그 결과는?

2025년 8월, SKT는 유심 해킹으로 인해 역대 최고 금액인 1347억 원의 과징금을 부과받았습니다. 조사 결과에 따르면 SKT는 이미 2016년에 취약점이 발표되고 패치가 제공된 리눅스 커널의 ‘더티카우(DirtyCow)’ 취약점이 존재하는 운영체제(OS)를 2025년 4월까지 약 8년 반 동안 보안 조치 없이 그대로 운영해왔습니다.

• 2016년 11월: 해당 취약점 존재하는 OS 설치
• 2020년 이후: 관련 백신 출시
• 2025년 4월: 해킹 사고 발생, 유심 인증키 등 2,300만명 개인정보 유출

OS 보안 패치와 백신 설치도 하지 않았다?

더티카우 취약점은 2016년 보안경보까지 발령된 유명한 리눅스 커널 취약점입니다. 그럼에도 불구하고 SKT는 보안 패치, 상용 백신, 접근 통제, 암호화 등 기초적인 보안조치조차 하지 않았으며, 그 결과:

• 9.82GB 분량의 개인정보 유출
• IMSI, 유심 인증키(Ki, OPc) 등 이동통신 핵심 인증정보 노출
• SKT 내부망·인터넷망 분리조차 하지 않음

---

Runtime SBOM, 왜 필요할까?

이 사건은 단순히 "패치를 안 했다"는 수준이 아닙니다. 수많은 서버들이 어떤 소프트웨어를 설치하고 있는지, 그 소프트웨어가 어떤 오픈소스나 라이브러리로 구성되어 있고, 어떤 취약점이 내포되어 있는지조차 파악하지 못한 결과입니다.

Runtime 환경에서는 다음과 같은 질문에 답할 수 있어야 합니다:

• 현재 서버에 설치된 SW의 구성요소는?
• 오픈소스나 써드파티 모듈 중 취약한 요소는 어떤 것인가?
• 이전 버전 대비 어떤 요소가 변경되었는가?
• 패치 적용 여부, 미적용 이유, 운영 리스크는?

바로 이런 질문에 답하기 위한 해답이 Runtime SBOM입니다.

---

XSCAN Runtime – 서버 자산관리 + SBOM의 통합 솔루션

최근 출시된 레드펜소프트의 ‘XSCAN Runtime’은 이 문제를 해결하기 위한 최적의 솔루션입니다.

• 서버에 실제 배포된 소프트웨어 기준으로 실시간 SBOM을 생성
• 특정 시간대에 어떤 소프트웨어가 설치/변경/삭제되었는지 추적
• 이미 배포된 시스템 상의 보안 상태를 가시화하고 위험 요소를 알림
• 취약점이 탐지되면 자체 DB 및 EPSS 기반 리스크 우선순위화

즉, 단순한 SBOM 분석을 넘어, 운영중인 시스템에서의 실질적인 보안 실천이 가능해지는 것입니다.

---

SKT 사태는 단순한 관리 부주의가 아니라, 자산과 구성요소의 가시성 부재가 불러온 사고입니다.
“우리가 뭘 쓰고 있는지 모른다”는 현실은 생각보다 많은 기업에 해당되며,
이 문제를 근본적으로 해결할 수 있는 방법은 바로 실시간 기반의 Runtime SBOM 구축입니다.

더티카우가 다시 등장하지 않으려면, 시스템은 늘 살아있는 상태에서 보안 점검이 이루어져야 합니다.