패치도 없는 취약점이 무더기로 풀렸다
보안 업계에 묵직한 이야깃거리가 하나 던져졌어요. 정체를 알 수 없는 익명의 GitHub 계정이 아직 세상에 알려지지 않은 제로데이 취약점들을 한꺼번에 무더기로 공개해버린 거예요.
제로데이(0-day)가 뭐냐면, 소프트웨어에 보안 구멍이 발견됐는데 아직 만든 회사조차 그 사실을 모르거나, 알아도 고칠 시간이 0일밖에 없는 상태의 취약점을 말해요. 패치가 없으니 공격을 당해도 막을 방법이 없는, 그래서 공격자 입장에서는 가장 강력한 무기인 셈이죠. 이런 게 한두 개도 아니고 무더기로, 그것도 미리 제조사에 알리지도 않은 채 공개됐다는 게 이번 일의 핵심이에요.
왜 이게 위험한 일일까
보안 취약점을 공개하는 방식에는 크게 두 가지 입장이 있어요. 이걸 이해하면 이번 사건이 왜 논쟁거리인지 바로 감이 와요.
하나는 책임 있는 공개(responsible disclosure), 또는 협력적 공개라고 부르는 방식이에요. 취약점을 찾으면 일단 만든 회사에 조용히 알려주고, 회사가 패치를 만들 시간을 준 다음(보통 90일 정도), 패치가 나온 뒤에 공개하는 거예요. 구글의 Project Zero 팀이 쓰는 '90일 룰'이 대표적이죠. 이렇게 하면 사용자들이 공격에 노출되기 전에 미리 보호받을 수 있어요.
다른 하나는 완전 공개(full disclosure)예요. '회사들이 알려줘도 안 고치니까, 아예 다 공개해서 압박하자'는 입장이죠. 실제로 과거엔 회사들이 취약점 제보를 무시하거나 제보자를 고소하는 일까지 있었거든요. 그래서 완전 공개를 통해 사용자에게 위험을 알리고 회사가 빨리 움직이게 만들자는 명분이 있어요.
문제는 이번처럼 '사전 통보 없이, 패치도 없는 상태로, 무더기로' 푸는 건 완전 공개의 명분조차 넘어선다는 거예요. 방어하는 쪽(기업 보안팀, 일반 사용자)은 패치가 없으니 손쓸 방법이 없는데, 공격하는 쪽은 완성된 공격 단서를 공짜로 손에 쥐게 되니까요. 한마디로 방어자와 공격자 사이의 균형이 공격자 쪽으로 확 기울어버리는 거죠.
업계 맥락
사실 보안의 역사는 이 '공개 윤리' 논쟁의 역사이기도 해요. 2000년대 초반엔 'Full Disclosure'라는 이름의 메일링 리스트에서 취약점이 날것 그대로 공개되곤 했고, 그게 너무 위험하다는 반성에서 지금의 협력적 공개 문화와 버그 바운티(취약점을 제보하면 보상금을 주는 제도)가 자리잡았어요. 구글, 마이크로소프트, 애플 같은 큰 회사들은 물론이고 국내에서도 많은 기업이 버그 바운티를 운영하고 있죠.
이번 사건은 어렵게 쌓아온 이 '신고하고 기다리는' 문화에 정면으로 도전하는 사건이라 의미가 묵직해요. 익명이라는 점도 그래요. 책임을 지지 않는 익명의 주체가 위험한 단서를 뿌리고 사라지면, 그 뒷감당은 고스란히 전 세계의 방어자들 몫이 되거든요.
한국 개발자에게 주는 시사점
현실적으로 우리가 할 수 있는 건 '뚫릴 수 있다'는 걸 전제로 대비하는 거예요. 첫째, 패치를 빠르게 적용하는 체계를 갖추세요. 이런 사건이 터지면 며칠, 몇 시간 안에 패치가 쏟아지는데, 그걸 빠르게 반영할 수 있느냐가 생사를 가르거든요. 둘째, 내가 쓰는 라이브러리와 의존성 목록을 평소에 파악해두세요(SBOM, 소프트웨어 자재명세서라고 해요). 어떤 취약점이 터졌을 때 '우리가 그걸 쓰고 있나?'를 빨리 답할 수 있어야 해요.
그리고 윤리적인 부분도 짚고 갈게요. 취약점을 발견하는 능력은 정말 값진 거예요. 하지만 그 능력을 책임 있는 공개로 풀어내느냐, 아니면 무책임하게 던져버리느냐에 따라 보안 연구자가 되기도 하고 그 반대가 되기도 해요. 이번 사건은 그 갈림길을 아주 선명하게 보여주는 사례예요.
마무리
한 줄로 정리하면 이래요. 취약점을 찾는 것보다, 그걸 어떻게 세상에 내놓느냐가 진짜 실력이자 윤리다. 여러분은 어떻게 생각하세요? 회사들이 패치를 게을리하는 현실에서 '완전 공개'는 정당한 압박일까요, 아니면 사용자를 인질로 잡는 위험한 도박일까요?
🔗 출처: Hacker News