취약점 신고는 더 이상 특별하지 않다 — Go 암호 라이브러리 관리자의 도발적 제안

무슨 일이 있었나

오픈소스 세계에는 오래된 불문율이 하나 있어요. 누군가 소프트웨어에서 '보안 취약점'을 발견하면 그건 일반 버그랑은 차원이 다른, 아주 특별한 신고로 대접받는다는 거예요. Go 언어의 표준 암호 라이브러리를 오랫동안 책임져 온 필리포 발소르다가 최근 이 관행에 대놓고 반기를 들었어요. 글 제목부터가 '취약점 신고는 더 이상 특별하지 않다'거든요.

여기서 잠깐, '취약점'이 뭔지부터 짚고 갈게요. 그냥 버그가 '버튼 누르면 앱이 죽어요' 같은 거라면, 취약점은 '이 버그를 악용하면 남의 비밀번호를 훔칠 수 있어요'처럼 보안에 구멍이 뚫리는 버그예요. 그래서 업계는 이걸 아주 조심스럽게 다뤄 왔어요. 발견자가 공개적으로 떠벌리지 않고 개발자에게만 몰래 알려준 뒤(이걸 '책임 있는 공개'라고 해요), 패치가 나올 때까지 일정 기간 비밀로 묻어두고(엠바고, 보도 금지 기간 같은 거죠), CVE라는 전 세계 공통 취약점 일련번호를 받아 기록으로 남기는 식이죠.

왜 '특별하지 않다'고 할까

발소르다의 논리는 이래요. 이 모든 특별 대우는 '취약점 신고는 드물고, 실력 있는 연구자가 선의로 정성껏 보내는 고품질 정보'라는 전제 위에 세워졌다는 거예요. 그런데 그 전제가 지금 와르르 무너지고 있다는 거죠.

요즘은 AI가 남의 코드를 슬쩍 훑고는 '여기 취약점 같은데요?' 하며 신고서를 자동으로 쏟아내요. 문제는 이게 대부분 헛다리라는 거예요. 그럴듯하게 포장은 됐는데 실제로는 공격이 불가능하거나, 아예 코드를 잘못 이해한 경우가 수두룩하거든요. 버그 바운티(취약점을 신고하면 포상금을 주는 제도) 때문에 일단 찔러보고 보자는 신고도 넘쳐나고요. 관리자 한 명이 이런 'AI 쓰레기 신고'를 하루에도 몇 건씩 검토하느라 진을 빼는 상황이 된 거예요.

그래서 제안하는 게 뭐냐면

결론은 의외로 단순해요. 취약점 신고도 그냥 평범한 버그 신고처럼 대하자는 거예요. 무조건 비밀로 다루고, 무조건 긴급으로 처리하고, 무조건 발견자에게 굽신거릴 필요 없다는 거죠. 의심스러우면 공개된 이슈 게시판에서 똑같이 따져 묻고, 근거가 부실하면 그냥 닫아버리고, 정말 심각한 진짜 취약점일 때만 예전처럼 특별 절차를 가동하면 된다는 거예요. 핵심은 '특별 대우를 기본값으로 두지 말자'예요. 진짜배기를 위해 그 특별함을 아껴두자는 거죠.

업계는 지금

사실 이건 오픈소스 전체가 앓는 통증이에요. 전 세계 거의 모든 기기에 들어있는 네트워크 도구 curl의 메인테이너도 AI가 만들어낸 가짜 취약점 신고에 질려서 공개적으로 분통을 터뜨린 적이 있죠. 무보수 자원봉사자 한두 명이 떠받치는 프로젝트에 자동화된 신고가 쏟아지니, 정작 진짜 버그를 고칠 시간이 사라지는 거예요. CVE 숫자가 의미 없이 부풀려지는 문제까지 겹치면서, '보안 신고는 무조건 떠받들어야 한다'는 오래된 예의가 오히려 시스템을 망가뜨리고 있다는 자성이 나오는 거죠.

한국 개발자에게

오픈소스를 운영하거나 사내 라이브러리를 관리한다면 이 관점이 꽤 쓸모 있어요. 보안 신고가 들어왔을 때 '아 큰일났다' 하고 패닉부터 하기보다, 일반 버그처럼 침착하게 '재현부터 되나?' 검증하는 습관을 들이는 거예요. 그리고 AI 도구로 보안 점검을 돌릴 때도 그 결과를 곧이곧대로 믿지 말고, 사람이 한 번 더 거르는 과정이 점점 더 중요해진다는 신호이기도 하고요.

마무리

한 줄로 줄이면, '취약점 신고의 특별 대우는 그게 귀했던 시절의 유산'이라는 거예요. 여러분 생각은 어떠세요? 보안 신고의 특별 대우를 줄이는 게 합리적일까요, 아니면 그래도 보안만큼은 보수적으로 가는 게 맞을까요?