제로데이 익스플로잇 올렸다고 GitHub에서 영구 추방 — 보안 연구자 vs 플랫폼 권력

무슨 일이 있었냐면

한 보안 연구자가 윈도우의 제로데이 취약점 공격 코드를 GitHub에 올렸다가 계정이 통째로 정지당하는 일이 있었어요. 연구자 본인은 “이건 보안 연구 목적이었는데, 회사 측이 보복성으로 내 인생을 망쳐놨다”며 강하게 반발하고 있고요.

여기서 짚어야 할 핵심 포인트가 하나 있어요. GitHub는 마이크로소프트 소유거든요. 그리고 문제가 된 취약점은 바로 그 마이크로소프트의 윈도우 취약점이고요. 즉, “취약점의 당사자인 회사가, 그 취약점 공개 코드를 호스팅하는 플랫폼까지 쥐고 있다”는 묘한 구도가 이번 사건의 진짜 쟁점이에요.

용어부터 풀어보면

제로데이(zero-day)가 뭐냐면, 소프트웨어 회사조차 아직 모르거나, 알아도 아직 패치를 못 만든 보안 취약점을 말해요. ‘방어할 시간이 0일’이라는 뜻에서 나온 이름이죠. 공격자 입장에선 아무도 막을 준비가 안 된 무기인 셈이라 제일 위험해요.

익스플로잇(exploit), 혹은 PoC(proof of concept, 개념 증명) 코드는 그 취약점을 실제로 찔러보는 시연용 공격 코드예요. 보안 연구자들은 “이 취약점이 진짜 위험하다”는 걸 증명하고 다른 연구자들이 검증할 수 있게 하려고 이런 코드를 공개하곤 해요. 문제는 똑같은 코드가 나쁜 사람 손에 들어가면 그대로 공격 무기가 된다는 거죠. 여기서 영원한 딜레마가 생겨요.

핵심 쟁점: 연구냐, 무기냐

GitHub의 이용 정책은 “실제 피해를 주는 악성코드나 익스플로잇 배포”를 금지하면서도, ‘보안 연구 목적’은 예외로 인정해줘요. 문제는 이 둘 사이의 선이 칼처럼 딱 떨어지지 않는다는 거예요. 아직 패치가 안 나온 제로데이의 공격 코드를 공개하는 건, 보는 시각에 따라 ‘위험성을 알리는 정당한 연구’일 수도 있고 ‘공격자에게 무기를 쥐여주는 행위’일 수도 있거든요.

보안 업계에는 크게 두 가지 입장이 있어요. 책임 있는 공개(responsible/coordinated disclosure)는 “취약점을 발견하면 먼저 회사에 비공개로 알리고, 패치가 나온 뒤에 공개하자”는 쪽이에요. 반대로 전면 공개(full disclosure)는 “회사가 패치를 미루며 뭉개는 경우가 많으니, 공개적으로 압박해서 빨리 고치게 하자”는 쪽이고요. 둘 다 나름의 논리가 있어요.

데자뷔 같은 사건

사실 이런 갈등은 처음이 아니에요. 2021년에도 GitHub가 마이크로소프트 익스체인지 서버의 ProxyLogon 취약점 PoC 코드를 내려서 보안 커뮤니티가 크게 반발한 적이 있어요. 그때도 똑같은 비판이 나왔죠. “마이크로소프트가 자기 제품 취약점 코드를, 자기가 소유한 플랫폼에서 내리는 게 공정하냐”는 거요. 이번 사건은 그 논쟁의 연장선이자, 한 단계 더 센 버전(계정 영구 정지)인 셈이에요.

플랫폼 권력이 한 곳에 쏠려 있을 때 생기는 위험을 잘 보여주는 사례이기도 해요. 전 세계 개발자의 코드가 사실상 한 회사의 플랫폼에 모여 있는데, 그 회사가 “이건 안 돼” 하면 연구자는 하루아침에 자기 작업물과 계정, 평판을 다 잃을 수 있으니까요.

한국 개발자에게는

한국 보안 연구자들도 남 일이 아니에요. 국내에선 취약점 신고를 KISA(한국인터넷진흥원)나 기업 버그바운티로 진행하는 경우가 많은데, 공격 코드 공개는 자칫 정보통신망법 같은 법적 리스크로 이어질 수 있어서 더 조심스럽거든요. “어디까지가 연구이고 어디부터가 위법인가”의 경계가 모호한 건 우리도 마찬가지예요.

또 하나, 우리 작업물을 특정 플랫폼 한 곳에 100% 의존하는 게 얼마나 위험한지도 생각해볼 거리예요. 계정 하나가 정지되면 몇 년치 코드와 이력이 한순간에 날아갈 수 있으니, 중요한 결과물은 백업이나 분산 보관을 고민해두는 게 좋아요.