리눅스 커널 보안 취약점, 배포판은 왜 매번 늦게 알게 될까

리눅스 커널 보안 이슈를 들여다보다 보면 이상한 장면을 자주 마주칩니다. 메인라인 커널에는 이미 수정 패치가 머지됐는데, 정작 그 커널을 가져다 쓰는 우분투, 데비안, RHEL 같은 배포판은 며칠, 길게는 몇 주가 지나서야 그 사실을 인지하는 일이 반복되고 있는데요. “오픈소스라 더 빠르고 투명하다"는 말이 무색해지는 순간입니다. 오늘은 리눅스 커널 보안 디스클로저 체인이 왜 이렇게 삐걱거리는지, 그 구조적 문제를 정리해보려 합니다.

linux-distros 메일링 리스트라는 게 있긴 한데

리눅스 생태계에는 linux-distros라는 비공개 메일링 리스트가 있습니다. 보안 취약점이 발견되면 주요 배포판 메인테이너들에게 미리 공유해서, 공개 시점 이전에 패치를 준비할 수 있도록 만든 채널인데요. 이론상으로는 깔끔합니다. 연구자가 취약점을 신고하면, 일정 기간 엠바고를 걸고, 배포판들이 동시에 패치를 내놓으면 됩니다.

문제는 이 채널이 모든 커널 취약점에 적용되지 않는다는 점입니다. 커널 메인테이너가 일반 버그로 분류해 패치를 머지해버리면, 그 패치는 단순한 git 커밋으로만 존재합니다. 보안 영향이 명시되지도, linux-distros로 통보되지도 않습니다.

“버그 같지만 사실은 취약점"이라는 회색 지대

리눅스 커널의 그렉 크로아하트만(Greg KH)을 비롯한 핵심 메인테이너들은 오랫동안 한 가지 입장을 고수해왔습니다. “모든 버그 수정이 잠재적 보안 패치”라는 것입니다. 그래서 굳이 “이건 보안 문제다"라고 따로 라벨링하지 않습니다.

이 철학에는 일리가 있습니다. 어떤 메모리 안전 버그가 실제로 익스플로잇 가능한지 사전에 판단하기 어렵고, 그렇게 따로 분류하기 시작하면 분류되지 않은 버그는 안전하다는 잘못된 신호를 줄 수 있으니까요. 하지만 현실은 다릅니다. 배포판 보안팀은 한정된 인력으로 매주 수백 개씩 쏟아지는 커밋을 일일이 살펴볼 수 없습니다. 결국 커널은 고쳤지만, 배포판은 모르는 상태가 일상화됩니다.

CVE 번호 체계가 만든 또 다른 혼란

2024년부터 리눅스 커널 팀은 자체적으로 CVE Numbering Authority(CNA) 자격을 얻고 직접 CVE를 발급하기 시작했습니다. 좋은 의도였습니다. 하지만 결과적으로 커널은 주당 수십 개의 CVE를 쏟아내는 기관이 됐는데요. 이 중 상당수는 실제 위험도가 낮거나, 특정 환경에서만 영향이 있는 것들입니다.

배포판 입장에서는 신호와 잡음을 구분하기가 더 어려워졌습니다. CVE가 너무 많으면 결국 아무것도 우선순위가 되지 않습니다. 어떤 CVE는 며칠 만에 패치되어 stable 트리에 들어가고, 어떤 CVE는 발급된 지 모르고 지나갑니다. 배포판 메인테이너에게 사전 통보하는 절차도 이 구조 안에 명확히 자리 잡지 못했습니다.

진짜 문제는 “시간차 공격"이 가능하다는 것

공격자 관점에서 이 디스클로저 갭은 매력적인 기회입니다. 커널 git 트리는 누구에게나 공개되어 있습니다. 보안 영향이 큰 패치가 머지되면, 공격자는 커밋 메시지와 코드 변경을 분석해 역으로 익스플로잇을 만들 수 있습니다. 이걸 흔히 “패치 갭 익스플로잇(patch-gap exploit)“이라고 부르는데요.

배포판이 패치를 백포트해 사용자에게 배포하기까지 걸리는 시간은 짧으면 며칠, 길면 몇 주입니다. 그 사이가 무방비 구간입니다. 사전 공유 체계가 제대로 작동하지 않으면 이 갭은 더 길어집니다. 클라우드 환경에서 수만 대의 리눅스 인스턴스를 굴리는 기업들에게 이건 단순한 거버넌스 문제가 아니라 실질적 리스크입니다.

그럼 어떻게 해야 하나

해법은 간단하지 않습니다. 메인테이너들에게 모든 패치를 보안 분류하라고 요구하는 건 비현실적이고, 배포판마다 별도 보안팀을 키우는 것도 한계가 있습니다. 결국 중간 계층의 자동화가 필요하다는 논의가 늘고 있는데요. 커널 커밋을 머신러닝으로 분류해 보안 영향이 있을 가능성이 높은 것들을 자동으로 골라내는 시도들이 진행되고 있습니다.

하지만 더 본질적인 문제는 따로 있습니다. 커널 보안 정책을 누가 결정하는가, 그리고 그 결정이 다운스트림에 어떻게 전달되는가에 대한 합의가 여전히 약하다는 점입니다. 리눅스가 인프라의 거의 모든 곳을 떠받치는 시대에, 보안 디스클로저는 이제 한 프로젝트의 문제가 아니라 생태계 전체의 문제입니다.

마무리하며

리눅스의 강점은 늘 “공개되어 있다"는 데 있었습니다. 하지만 보안에서는 공개되어 있다는 사실 자체가 양날의 검이 됩니다. 누구나 패치를 볼 수 있다는 건 누구나 취약점을 추론할 수 있다는 뜻이기도 하니까요. 여러분의 인프라에서 돌아가는 커널은 지금 며칠짜리 갭 안에 있을까요? 한 번쯤 점검해볼 만한 질문입니다.