---
title: "리눅스 커널 보안팀은 이렇게 일한다"
published: 2026-01-02T21:31:34.000Z
canonical: https://jeff.news/article/335
---
# 리눅스 커널 보안팀은 이렇게 일한다

리눅스 커널 보안팀의 운영 방식을 상세히 설명한 글. 리액티브 방식의 버그 수정, 엠바고 최대 7일 정책, '버그는 버그일 뿐' 철학, 하드웨어 보안 이슈 대응, 그리고 사전 공지 리스트를 두지 않는 이유까지 다룸.

## 리눅스 커널 보안팀의 일하는 방식

- 리눅스 커널 보안팀은 **리액티브(reactive)** 방식으로 운영됨. 보고된 버그를 최대한 빨리 고쳐서 공개 트리에 머지하는 게 전부이고, 별도의 보안 공지 같은 건 일절 없음
- 보안팀과 CVE팀은 **완전히 별개 조직**임. 두 팀 모두 소속 회사와 무관하게 개인 자격으로 활동함
- 버그 리포트는 **평문 이메일만** 받음. 암호화 불가(이메일 별칭이라 안 됨), HTML이나 바이너리 첨부도 금지. 영국 정부한테 "암호화 필수 정책 좀 재고하라"고 직격탄 날림

## 버그 수정 프로세스

- 보안팀이 해당 서브시스템 전문가가 아니면, 해당 메인테이너를 이메일 체인에 끌어들여서 같이 해결함
- 특정 서브시스템에서 반복적으로 버그가 터지면, 메인테이너가 보안 별칭에 아예 합류하게 됨. 이렇게 자연스럽게 팀이 커져온 것
- 이상적으로는 버그 리포터가 패치까지 같이 제출하는 건데, 현실은 그렇지 않은 경우가 많음

## 엠바고? 최대 7일

- 수정이 완료되면 **엠바고는 최대 7일**까지만 허용됨. 대부분의 경우 엠바고 자체가 "수고 대비 가치가 없다(more bother than it's worth)"는 입장
- 버그 수정 후 보안팀의 역할은 끝남. 공지를 할지 말지는 리포터의 몫이고, CVE 할당은 나중에 CVE팀이 별도로 처리함

## "버그는 그냥 버그다" 철학

- 커널 수준에서는 거의 모든 버그픽스가 사용 환경에 따라 보안 이슈가 될 수 있음. 메모리 누수, DoS, 정보 유출 등 전부 해당
- Ben Hawkes의 명언: "하나의 버그가 어떤 배포 환경에서는 치명적이고, 다른 곳에서는 별것 아닌데, 이 두 상태가 **동시에** 성립한다"
- 커널 개발자들은 사용자의 유스케이스를 모르고, 알고 싶지도 않음. 그래서 정책은 단순함: **알려진 버그는 최대한 빨리 고치고, 릴리스를 최대한 빨리 내보낸다**

> [!IMPORTANT]
> 알려진 버그를 안 고치고 방치하는 것보다, 수정 패치가 새로운 문제를 일으킬 가능성이 훨씬 나음. 최근 법률들도 이 방향을 강제하는 추세임.

## 하드웨어 보안 이슈는 다름

- Spectre/Meltdown 같은 **OS와 하드웨어를 동시에 건드리는 문제**는 "엠바고 없음" 정책이 안 통했음
- 이런 경우에만 암호화된 제한 메일링 리스트를 만들어서 대응함. 엠바고를 "불만스럽게 참아주는(grumpily tolerated)" 수준
- 참여해본 개발자들 평가: 투박하고, 어색하고, 극도로 느림. 최근에는 이 프로세스 없이 해결되는 하드웨어 이슈가 늘어나는 추세
- EU의 CRA 법안 타임라인 때문에 앞으로 하드웨어 업체들의 장기 엠바고 자체가 불가능해질 수 있음

## 역사와 사전 공지 정책

- 2005년 Steve Bergman의 이메일이 계기가 되어 공식 보안 연락 체계가 만들어졌고, Chris Wright가 문서화함
- **사전 공지 리스트(pre-announcement list)는 없음**. 이유: "그런 리스트는 항상 공개된 것으로 간주해야 하고, 유출이 있기 마련"
- Linus가 2008년에 이 정책에 대해 쓴 이메일 스레드가 있는데, 전체를 읽어볼 가치가 있음

## 핵심 포인트

- 보안팀은 리액티브 방식으로 보고된 버그를 최대한 빨리 고쳐서 공개 트리에 머지함
- 보안팀과 CVE팀은 별개 조직이며 모두 개인 자격으로 활동
- 엠바고는 최대 7일, 대부분 엠바고 없이 진행
- 하드웨어 보안 이슈(Spectre/Meltdown)만 예외적으로 암호화 리스트와 엠바고 허용
- EU CRA 법안으로 장기 엠바고 자체가 불가능해질 전망

## 인사이트

커널 개발자들이 사용자의 유스케이스를 모른다는 전제하에 설계된 정책이라, 모든 버그픽스를 잠재적 보안 수정으로 취급하는 접근법이 인상적임.