GitHub가 자사 버그 바운티 프로그램의 심사 기준을 전면 상향조정했다. 15일(미국 동부시간) GitHub 블로그를 통해 공개한 정책 변화는 저품질 신고의 증가에 대응하고 보안 연구자의 역량에 집중하겠다는 입장을 명확히 한다.

GitHub 시니어 제품 보안 담당자 제롬 브라운은 "보안 연구 커뮤니티는 GitHub의 가장 큰 자산"이라며 "1억 8,000만 명 이상의 개발자의 플랫폼을 더 안전하게 만드는 일에 외부 연구자들과의 협력이 가장 효과적"이라고 밝혔다.

야기되는 '저품질 신고' 폭증

변화의 배경은 명확하다. 지난 1년간 업계 전반에 걸쳐 버그 바운티 신고량이 급증했다. AI를 포함한 새로운 도구들이 보안 연구의 진입 장벽을 낮춘 결과다. 긍정적 측면이 분명하지만, 그 뒤따르는 문제도 심각하다. 보안상 실질 영향을 보이지 못하는 신고가 급증했기 때문이다. 개념 증명(PoC)이 없는 보고서, 정밀한 검토에 견디지 못하는 이론적 공격 시나리오, GitHub가 이미 공표한 '부적격 목록'에 포함된 발견 사항들이 대부분이다.

GitHub는 이 문제가 자신들만의 과제가 아니라고 본다. 업계 여러 프로그램이 동일한 문제로 고투하고 있으며, 일부는 완전히 폐쇄했을 정도다. GitHub는 다른 길을 선택했다.

높아진 신고 기준 4가지

GitHub가 제시한 '완성된 신고'의 새로운 기준은 네 가지다.

첫째, 작동하는 개념 증명(PoC)과 실증된 보안 영향이다. 단순 설명이 아닌 실제 동작하는 악용 증명이 필수다. "이것이 이어질 수 있다(could lead to)"는 표현은 부족하며, "이것이 실제로 가능하다(does happen)"는 증명이 있어야 한다는 의미다.

둘째, 범위와 부적격 항목에 대한 인식이다. 신고 전 GitHub의 범위 문서와 부적격 목록을 반드시 검토해야 한다. DMARC/SPF/DKIM 설정 오류, 사용자 열거, 실증된 공격 경로 없는 보안 헤더 누락 등은 이미 부적격으로 분류된 항목들이다.

셋째, 제출 전 검증이다. 스캐너, 정적 분석, AI 어시스턴트 등 어떤 도구를 사용하든 결과를 수동으로 검증해야 한다. 검증되지 않은 거짓양성은 시간만 낭비한다.

넷째, 명확하고 간결한 보고서다. GitHub가 원하는 형식은 단순하다: 이슈의 짧은 요약 → 재현 방법과 증거(스크린샷, HTTP 요청, 터미널 출력) → 공격자가 실제로 달성 가능한 영향이다. 다중 페이지의 이론적 설명, 반복되는 배경 정보, AI가 생성한 부가 텍스트는 심사를 지연시킬 뿐이다.

"AI는 도구일 뿐, 검증은 필수"

흥미로운 점은 GitHub의 AI 도구 활용에 대한 명시적 지지다.

GitHub는 "AI 도구 활용에 문제가 없다"고 공식 입장을 밝혔다. "AI는 보안 연구의 성능 배수를 높이는 수단이며, 향후 보안 연구에서 그 역할은 점점 커질 것"이라며 "자사 내부 보안 프로그램에도 AI를 활용하고 있으며, 최고의 외부 연구자들도 이미 같은 방식을 취하고 있다"고 언급했다.

다만 조건이 명확하다. AI 보조로 생성된 발견이 검증되고 재현되며 작동하는 PoC와 함께 제출되면 '훌륭한 신고'이지만, 검증 없이 AI 출력값을 그대로 제출하면 그렇지 않다는 뜻이다. 이는 새로운 기준이 아니라, 스캐너 출력값이나 정적 분석 도구에 적용해온 기존 기준을 명확히 한 것이다.

공유 책임 모델의 재정의

정책 변화의 핵심 중 하나는 GitHub의 보안 경계 재정의다.

GitHub는 "빈번하게 보이는 신고 패턴이 있다"며 사용자가 공격자 제어 콘텐츠(악성 저장소, 조작된 이슈, 신뢰할 수 없는 코드)와 상호작용하는 시나리오를 설명했다. 기술적으로 정확한 관찰도 있지만, 보안 경계의 위치를 오인하는 경우들이다.

GitHub가 제시하는 공유 책임 모델은 다음과 같다:

사용자의 책임:

• 신뢰할 저장소, 이슈, 코드 선택 (GitHub에는 6억 개 이상의 저장소 존재)
• 실행 또는 상호작용 전 콘텐츠 검토 (코드, 스크립트, 워크플로우)
• 환경 보안 설정 (토큰 관리, 자격증명 저장, 로컬 보안 설정)

GitHub의 책임:

• 플랫폼 전역 악성 콘텐츠 감지 및 처리 (자동 스캔, 수동 검토)

이 구분의 의미는 중요하다. "공격"이 피해자가 공격자 제어 콘텐츠를 능동적으로 찾아 상호작용하도록 요구한다면(악성 저장소 복제, AI 도구에 신뢰할 수 없는 코드 분석 요청, 조작된 파일 열기), 그 보안 경계는 사용자의 신뢰 결정이지 GitHub의 제어 우회가 아니라는 뜻이다.

GitHub는 "GitHub의 실제 보안 제어를 우회하되 사용자가 능동적으로 악성 콘텐츠를 신뢰하도록 요구하지 않는 방법을 발견했다면 그것이 바로 우리가 듣고 싶은 발견"이라며 "그런 신고가 우리가 받는 가장 임팩트 있는 제출"이라고 강조했다.

저위험 신고, 이제 현물 보상으로

정책 변화는 보상 체계에도 영향을 미친다.

코드 또는 문서 개선으로 이어지지만 의미 있는 보안 영향을 보이지 못하는 신고는 앞으로 현물 보상(GitHub 굿즈)으로 인정한다. 금전 보상은 플랫폼 보안에 가장 큰 영향을 미치는 발견에 집중하겠다는 의도다.

GitHub는 "연구자들이 저위험 신고로 양을 최적화하기보다 깊이 있는 고영향 연구에 시간을 투자하길 원한다"며 "프로그램에서 가장 많이 벌어들이는 연구자들은 깊이 있게 파고드는 사람들"이라고 조언했다.

한국 개발자·보안 연구자에게 미치는 영향

이 정책은 한국의 보안 연구자와 버그 바운티 커뮤니티에 직접 영향을 미친다.

첫째, AI 도구 활용이 확산되는 상황에서 GitHub의 명확한 입장 제시다. 한국 보안 연구 커뮤니티도 AI 보조 도구를 적극 도입하고 있는데, GitHub는 "도구가 문제가 아니라 검증이 핵심"이라는 기준을 제시함으로써 방향성을 제공한다.

둘째, 저품질 신고의 증가 현상이 단순한 한두 플랫폼의 문제가 아니라 업계 전반의 과제임을 보여준다. 한국 연구자들이 활동하는 다른 바운티 프로그램들도 유사한 기준 상향조정을 추진할 가능성이 높다.

셋째, 깊이 있는 연구의 가치를 재확인시킨다. GitHub는 "한 건의 잘 연구된 검증된 발견이 10건의 추측성 신고보다 가치 있다"고 명확히 했다. 이는 한국 보안 커뮤니티에 역량 집중의 신호를 준다.

GitHub 보안 연구 커뮤니티의 질적 향상이라는 이번 결정은, 단순한 규정 변화를 넘어 업계의 성숙도를 높이는 신호탄이 될 것으로 보인다.