무슨 일이 있었나요?
리눅스 커널 개발은 대부분 LKML(Linux Kernel Mailing List)이라는 공개 메일링 리스트에서 이뤄져요. 패치를 올리고 리뷰하고 토론하는 과정이 전부 이메일로 공개돼 있죠. 리눅스의 오랜 전통이에요.
그런데 Phoronix 보도에 따르면, 최근 커널 보안 취약점 보고 여러 건이 비공개 채널이 아니라 이 공개 리스트에 그대로 올라오는 일이 잇따랐다고 해요. 한두 번의 실수가 아니라 하나의 ‘새로운 경향’으로 볼 만큼 반복되고 있다는 게 포인트예요.
이게 왜 문제냐면, 패치가 나오기도 전에 취약점 정보가 전 세계에 공개돼버리거든요. 공격자 입장에서는 친절한 설명서까지 붙은 공격 재료를 공짜로 받는 셈이에요.
원래는 어떻게 제보해야 할까
커널에는 공식 보안 제보 절차가 문서로 정리돼 있어요. 커널 소스의 Documentation/process/security-bugs.rst라는 문서인데요, 쉽게 풀면 이래요.
1. 보안 취약점은 공개 리스트가 아니라 security@kernel.org로 비공개 메일을 보낸다
2. 커널 보안팀이 해당 코드의 담당자(메인테이너)를 불러 조용히 수정 패치를 만든다
3. 엠바고, 즉 ‘정해진 날까지 공개하지 않기로 한 약속’ 기간은 가능한 한 짧게 잡는다 (보통 최대 7일 정도)
4. 배포판과 맞춰야 할 게 있으면 별도의 비공개 리스트(linux-distros)를 쓴다
5. 수정이 반영된 다음에 공개한다
목적은 단순해요. 패치가 준비되기 전에 공격자가 먼저 알지 못하게 하는 것이에요. 비유하자면, 아파트 공동현관 비밀번호가 새어나간 걸 알았을 때 단지 게시판에 비밀번호를 적어 붙이는 대신 관리사무소에 먼저 조용히 알리는 것과 같아요.
왜 이런 일이 늘어날까
사례마다 사정은 다르겠지만, 업계 흐름을 보면 몇 가지 배경을 짐작해볼 수 있어요.
첫째, AI 도구로 버그를 찾는 사람이 급격히 늘었어요. 요즘은 LLM 기반 도구로 코드를 훑어서 버그 후보를 찾고 재현 코드까지 만드는 일이 흔해요. 덕분에 커널 개발 문화에 익숙하지 않은 사람도 그럴듯한 리포트를 쓸 수 있게 됐어요. 그런데 이런 보고자는 ‘보안 버그는 따로 비공개로 보낸다’는 규칙을 모를 가능성이 커요. 그러다 보니 일반 버그처럼 LKML에 그냥 올려버리는 거죠.
둘째, ‘버그’와 ‘취약점’의 경계가 흐려졌어요. 리눅스 커널은 2024년부터 직접 CVE를 발급하는 기관(CNA)이 됐어요. 그 뒤로는 보안 영향이 있을 수 있는 수정마다 폭넓게 CVE를 붙이고 있는데, 1년에 수천 건 단위예요. 이러면 보고자 입장에서는 “이게 보안 이슈야, 그냥 버그야?”를 판단하기가 더 어려워져요.
셋째, 커널 문화 자체가 ‘공개’를 기본으로 해요. 거의 모든 논의가 공개로 이뤄지다 보니, 보안 이슈만은 예외라는 사실이 처음 기여하는 사람 눈에는 잘 안 띌 수 있어요.
업계 맥락: 오픈소스 보안 제보 체계의 피로
이건 리눅스만의 문제가 아니에요. curl 프로젝트의 다니엘 스텐베리(Daniel Stenberg)는 AI가 만든 엉터리 보안 리포트 때문에 버그 바운티를 운영하기 힘들다고 여러 차례 공개적으로 털어놨어요. 반대로 구글을 비롯한 여러 곳에서는 AI로 진짜 취약점을 찾아냈다는 성과도 내놓고 있죠.
결국 지금 오픈소스 생태계는 제보는 폭증하는데 그걸 받아줄 메인테이너의 시간은 그대로인 상황이에요. 비공개 채널로 제대로 들어와도 감당하기 벅찬데, 공개 채널로 잘못 들어오면 ‘이미 알려진 취약점’을 허겁지겁 막아야 하는 부담까지 생겨요.
한국 개발자에게 주는 시사점
- 커널 업데이트 주기 점검: 서버나 임베디드 장비의 커널을 오래 방치하고 있다면 위험이 커지고 있어요. 취약점이 공개 리스트에 먼저 드러나면 패치 전에 공격당할 가능성이 높아지거든요. 배포판 보안 업데이트를 빠르게 반영하는 체계를 갖춰두세요.
- 기여하기 전에 보안 정책부터 확인: 리눅스뿐 아니라 대부분의 오픈소스 저장소에는
SECURITY.md같은 보안 정책 문서가 있어요. 취약점을 찾았다면 이슈 트래커에 올리기 전에 이 문서부터 읽어보세요. - AI로 찾은 버그는 직접 검증하기: AI가 찾아준 결과를 확인도 없이 그대로 올리면 메인테이너에게 큰 짐이 돼요. 재현되는지 직접 확인하고, 보안 영향이 의심되면 비공개 채널을 쓰는 게 기본 예의예요.
- 사내 가이드 마련: 회사에서 오픈소스를 많이 쓴다면, 직원이 취약점을 발견했을 때 어디로 어떻게 제보할지 가이드를 만들어두면 좋아요.
마무리
한줄 정리: AI 덕분에 버그를 찾는 속도는 빨라졌지만, 그걸 ‘어디에, 어떻게’ 알려야 하는지에 대한 상식은 아직 따라오지 못하고 있어요.
여러분은 오픈소스 프로젝트에서 보안 이슈를 발견했을 때 어떤 경로로 제보해보셨나요? AI가 만든 버그 리포트가 쏟아지는 상황을 프로젝트들은 어떻게 감당해야 할까요?
🔗 출처: Hacker News