GitHub 계정 차단과 Windows 제로데이 공개가 드러낸 책임 공시 거버넌스

계정 차단이 취약점 공개로 번진 과정

한 독립 보안 연구자는 Windows 커널 컴포넌트에서 권한 상승(Privilege Escalation) 취약점을 찾아 MSRC(Microsoft Security Response Center)에 신고했다. CVD 절차에 따라 세부 정보를 제출하고 90일 공시 타임라인의 준수를 요청했지만, 수 주가 지나도록 실질적인 진행 상황을 전달받지 못했다. 이 기간 연구자는 개인 GitHub 저장소에 취약점 개념 증명(PoC) 코드를 임시로 보관하고 있었다.

갈등은 Microsoft가 플랫폼 관리자의 지위에서 해당 연구자의 GitHub 계정을 예고 없이 정지하면서 커졌다. 사전 통보나 명확한 사유 설명 없이 이뤄진 차단으로 수년간 쌓인 오픈소스 기여물과 연구 자료에 접근할 수 없게 되자, 연구자는 이를 기업의 보복성 조치로 판단했다. 이후 동일 취약점은 공개 포럼과 소셜미디어에 전면 공개됐다.

공개된 PoC는 빠르게 확산됐다. Windows를 겨냥한 공격자가 실제 익스플로잇에 활용하기까지 48시간이 걸리지 않았다는 보고가 나왔고, Microsoft는 예정보다 이른 시점에 긴급 패치를 배포해야 했다. CISA는 해당 취약점에 CVSS 8.8 점수를 부여하고 Known Exploited Vulnerabilities(KEV) 목록에 즉시 추가했다.

논쟁은 두 갈래로 이어졌다. Microsoft가 보안 분쟁에서 GitHub의 플랫폼 권한을 의도적으로 활용했는지, 그리고 기업이 이처럼 연구자에게 불이익을 줄 수 있다면 CVD 생태계가 유지될 수 있는지다. Tavis Ormandy(Google Project Zero), Katie Moussouris 등 著名 보안 연구자들은 지지 성명을 내고 MSRC의 대응 방식을 비판했다.

⤢✕

신고 접수부터 공동 공시까지의 운영 기준

책임 공시 프로그램(Responsible Disclosure Program, RDP)은 단순한 버그 제보 창구가 아니다. 연구자와 기업이 취약점의 수신, 검증, 패치, 공시까지를 다루기 위해 합의한 운영 체계다.

신고가 들어오면 24시간 이내에 접수를 확인하고 트리아지(Triage) 팀으로 넘겨야 한다. 이 단계에서는 CVSS v4.0 기준 점수, 영향을 받는 컴포넌트와 버전, 익스플로잇 가능성(Exploitability), 비즈니스 임팩트를 검토한다. Microsoft MSRC는 SAST(정적 분석)와 내부 퍼징(Fuzzing) 도구를 병행해 신고된 취약점의 재현 가능성을 독립적으로 검증한다.

우선순위와 패치 일정을 관리할 때 핵심은 90일이라는 숫자만이 아니다. Google Project Zero가 2010년대 초반 도입한 90일 공시 타임라인은 업계의 사실상 표준으로 자리 잡았지만, 그 기간 동안의 정기적 상태 공유가 신뢰를 결정한다. 연구자는 매 2주마다 패치 개발 진척, 예상 배포일, 임시 완화 조치(Workaround)의 가용 여부를 전달받아야 한다.

소통 채널의 독립성도 중요하다. HackerOne, Bugcrowd 같은 버그 바운티 플랫폼은 연구자와 기업 사이에서 중립적 중개자 역할을 하고, 분쟁 조정 메커니즘을 제공한다. 반대로 MSRC처럼 자체 채널을 운영하는 대형 기업은 이런 중립적 중개 기능이 없어 분쟁 상황에서 연구자가 구조적으로 불리해질 수 있다.

금전적 보상(Bug Bounty) 외에도 Hall of Fame 공개 인정, CVE 등록 지원, 연구 협력 기회는 신고 협력을 유도하는 수단이다. 계정 차단이나 법적 위협 같은 부정적 조치는 반대로 보안 연구자 커뮤니티 전체의 신고 의지를 떨어뜨릴 수 있다.

⤢✕

제로데이 신고를 받았을 때 기업이 움직이는 방식

기업은 제로데이 신고를 받는 순간부터 패치 배포와 대외 공시까지를 하나의 대응 파이프라인으로 운영해야 한다. 이 파이프라인의 효율성은 실제 피해 규모에 영향을 준다.

0-24시간의 즉각 대응 단계에서는 신고의 유효성을 먼저 확인한다. 유효한 신고라면 내부 인시던트 레코드를 만들고 심각도에 맞춰 담당 엔지니어를 배정한다. CVSS 8.0 이상인 심각한 취약점은 CISO에게 즉시 보고하고 위기 대응팀을 구성한다. 연구자에게 접수 확인과 초기 평가 결과를 전달하는 일도 이 단계에 포함된다.

24시간-7일의 단기 대응 단계에서는 CVSS v4.0에 따른 상세 평가가 이뤄진다. 공격 벡터(Attack Vector), 공격 복잡도(Attack Complexity), 필요 권한(Privileges Required), 사용자 상호작용 필요 여부(User Interaction), 기밀성·무결성·가용성 영향(CIA Impact)을 평가하고, 임시 완화 조치(Workaround)가 기술적으로 가능한지 검토한다. 영향을 받는 시스템의 버전과 범위도 이때 확정해야 한다.

7일-90일의 패치 개발 단계에서는 근본 원인(Root Cause)을 분석하고 수정 코드를 작성한다. 이후 회귀 테스트(Regression Test), 보안 코드 리뷰, QA 환경의 패치 검증을 거친다. Microsoft는 Windows Update 인프라를 통해 광범위하게 배포하기 위해 추가 호환성 테스트가 필요하므로 패치 개발 기간이 상대적으로 길어지는 경향이 있다.

2024년 이후 CISA 협조 절차도 더 제도화됐다. CISA의 Cybersecurity Advisory 발행 절차에 따르면 기업은 적극적으로 익스플로잇이 발생하는 취약점을 CISA에 72시간 이내 보고해야 한다. CISA는 해당 항목을 KEV 목록에 넣고 연방기관에 패치 의무화 기한을 부여하며, 민간 기업에는 강력한 패치 권고를 낸다.

마지막에는 기술적 세부 사항을 담은 보안 권고문(Security Advisory)을 내고, 영향 버전과 패치 적용 방법을 안내해야 한다. 연구자에게 공식 크레딧을 부여하고 추가 조사 중인 관련 이슈를 투명하게 밝히는 것도 공개 커뮤니케이션의 일부다.

플랫폼 권한이 CVD 신뢰를 해칠 때

Microsoft-GitHub 사건은 보안 연구자와 빅테크 기업 사이의 권력 불균형을 드러냈다. Microsoft가 GitHub를 인수한 2018년 이후, 취약점을 수신하는 기업이 연구자가 의존하는 플랫폼까지 운영할 때 생길 수 있는 이해충돌은 보안 커뮤니티에서 계속 제기돼 왔다.

ISO/IEC 29147(취약점 공시)과 ISO/IEC 30111(취약점 처리 프로세스)은 보고자와 조직의 협력 관계를 전제로 한다. 두 표준은 한쪽이 다른 쪽에 불이익을 주는 보복적 행위를 명시적으로 금지한다. GitHub 계정 차단이 보안 신고와 인과적으로 연결됐다면, CVD의 핵심 원칙인 공정한 대우(Fair Treatment)를 위반했을 가능성이 있다.

CERT/CC는 CVD 실무 가이드에서 “조정 과정에서 연구자에 대한 어떠한 형태의 불이익도 CVD 관계를 훼손하며, 이는 미래의 취약점 신고 감소로 이어진다”고 명시한다. 2014년 Vupen Security 사례, 2016년 Jericho Forum의 Full Disclosure 정책 논쟁, 2019년 Akamai 연구자 사건처럼 유사 갈등에서 보복성 조치를 취한 기업들은 이후 수년간 외부 보안 신고 건수가 급감하는 경험을 했다.

독립 연구자와 학계 연구자의 보호는 현행 CVD 생태계에서 특히 취약하다. 대형 버그 바운티 프로그램과 HackerOne, Bugcrowd 같은 플랫폼에는 분쟁 조정 장치가 있지만, MSRC처럼 독자 채널을 운영하는 경우 연구자는 법적·기술적 전문성을 가진 중재자 없이 거대 기업과 직접 대응해야 한다. 법적 분쟁 비용을 감당하기 어려운 연구자는 실질적인 구제를 받기 어렵다.

Katie Moussouris가 제안한 Vulnerability Researcher Bill of Rights는 이 공백을 다룬다. 보복 금지(Anti-Retaliation), 투명한 의사결정(Transparent Decision-Making), 독립적 분쟁 조정(Independent Dispute Resolution), 연구자 법적 보호(Legal Safe Harbor)가 핵심 조항이다. 미국 CFAA(Computer Fraud and Abuse Act) 개정 논의에서도 선의의 보안 연구 활동에 대한 법적 면책 조항 강화가 포함돼 있다.

⤢✕

CVD 제도에 남은 과제

Google Project Zero가 2013년 일방적으로 선언한 90일 정책이 업계 관행으로 자리 잡은 뒤, 이를 법적 의무로 높이려는 논의가 나타났다. EU의 사이버복원력법(Cyber Resilience Act)은 제조사의 취약점 처리 의무를 규정하지만 구체적 타임라인은 각 국가 표준에 맡긴다. 미국에서는 CISA를 중심으로 중요 인프라 분야의 72시간 보고 의무와 90일 패치 완료 목표를 표준화하는 논의가 진행 중이다.

독립 CVD 중재 기구는 보안 커뮤니티가 오래 요구해 온 장치다. CERT/CC가 일부 역할을 수행해 왔지만 구속력 있는 결정을 내릴 수 없다는 한계가 있다. 새로운 중재 기구에는 기업과 연구자 모두가 수용할 수 있는 바인딩 조정(Binding Mediation) 권한과, 정부·학계·산업계·시민사회가 균형 있게 참여하는 다중 이해관계자 거버넌스가 요구된다.

플랫폼 권력 분리 원칙도 이번 사건에서 부각됐다. Microsoft처럼 취약점 수신 기업이면서 연구자가 의존하는 플랫폼인 GitHub를 운영할 경우, 두 역할 사이에 기술적·제도적 장벽이 필요하다는 주장이다. 보안 분쟁과 관련한 계정 조치를 독립적으로 검토하고, 플랫폼 운영팀과 보안 대응팀 사이에 정보 차단벽(Chinese Wall)을 두며, 보안 관련 계정 차단에 즉시 이의를 제기할 수 있게 하는 방안이 제안되고 있다.

CFAA 개혁 논의에서 Safe Harbor 확대 역시 핵심 쟁점이다. 현행 CFAA는 선의의 보안 연구도 기소 대상이 될 수 있는 광범위한 조항을 포함해 연구자의 자기검열을 유발한다. 2022년 법무부는 선의의 보안 연구에 대한 기소를 자제하겠다는 CFAA 기소 정책을 발표했지만, 이는 법적 구속력이 없는 방침이다. 보안 커뮤니티는 이를 법문에 명시적으로 반영할 입법이 필요하다고 주장한다.

Bug Bounty 프로그램의 표준화도 남아 있다. 기업마다 보상 기준, 범위(Scope), 면제 조항(Exclusions)이 달라 연구자는 신고 전 복잡한 약관을 분석해야 한다. ISO 표준이나 CVSS처럼 공개된 기준에 연동된 보상 체계가 도입되면 연구자의 예측 가능성이 높아지고 기업의 취약점 수신 품질도 향상될 것으로 기대된다.

책임 공시는 법적 강제보다 상호 신뢰에 기대는 자발적 협력 체계다. 계정 차단과 제로데이 공개가 이어진 사건은 그 신뢰가 무너질 때 방어자가 얻을 시간을 잃는다는 점을 보여줬다. 연구자와 기업이 동등한 파트너로 협력하려면 공시 타임라인, 독립 중재, 플랫폼 권력 분리, 법적 Safe Harbor가 함께 뒷받침돼야 한다.