GitHub 취약점 제보에 재현 방법을 필수로 받는 법

‘취약하다’는 주장에 재현 방법을 함께 요구한다

재현 정보가 없는 제보를 받았다면, 접수 양식에서 그 내용을 필수로 요구할 수 있다. GitHub가 10월 1일 도입한 구조화 양식은 요약, 상세 설명, 개념 증명(PoC), 영향의 네 항목을 기본 필수 입력으로 정했다. PoC에는 최소 150자를 요구하며, 입력 내용은 보안 권고의 설명으로 합쳐진다.

문제는 글의 길이만이 아니다. 한 GitHub 유지관리자의 Reddit 게시물은 컨트롤러 수준의 인증을 놓친 AI 제보를 검토하느라 시간을 썼다고 전한다. 댓글에서도 실제 재현 없이 이론적 영향만 적힌 PoC가 문제로 제기됐다.

새 양식은 필요한 설명을 요구하는 수단이다. 150자를 채웠다고 취약점이 입증되는 것은 아니므로, 유지관리자는 적힌 조건으로 문제가 재현되는지 판단해야 한다.

프로젝트별 질문은 기본 브랜치의 YAML에 넣는다

맞춤 제보 양식은 저장소 기본 브랜치의 .github/VULNERABILITY_REPORT.yml에 둔다. 공식 설정 문서에는 완성된 YAML 예시가 있으며, 기존 issue form 문법을 사용한다. 필수 입력은 validations.required, 최소 글자 수는 validations.min_length로 지정한다. 길이 조건은 input과 textarea에 사용할 수 있다.

예를 들어 ‘재현 방법’ 입력란에 대상 버전, 필요한 설정, 재현 순서와 실제 결과를 요청하는 식으로 질문을 구체화할 수 있다. 이는 프로젝트에 맞춰 작성할 질문의 예이며 GitHub가 모든 제보에 강제하는 고정 목록은 아니다.

여러 저장소가 같은 양식을 쓰려면 조직이나 개인 계정의 .github 저장소에 공통 양식을 정의할 수 있다. 개별 저장소의 양식이 공통 양식보다 우선한다. YAML을 해석하거나 검증하지 못하면 기본 양식이 표시되므로, 파일을 추가한 뒤 제보 화면에 의도한 질문이 보이는지 확인하는 것이 좋다.

SECURITY.md만 만들어서는 비공개 접수가 켜지지 않는다

먼저 저장소의 Settings → Advanced Security → Private vulnerability reporting에서 기능을 활성화해야 한다. 이번 양식은 비공개 제보를 켠 공개 저장소에서 제공되며 GitHub Free·Pro·Team·Enterprise Cloud가 대상이다.

제보자용 안내는 SECURITY.md와 비공개 취약점 제보 기능을 별개로 설명한다. 보안 정책은 지원 버전이나 연락 방법을 안내하고, 활성화된 제보 화면에서는 제출 전에 그 정책을 볼 수 있다. 정책 파일을 만드는 작업과 접수 기능을 켜는 작업을 구분해야 한다.

제보자는 발견이나 작성에 AI를 사용했는지도 자율적으로 표시할 수 있다. 이 표시는 AI 사용 공개 항목이지 자동 판별 결과가 아니다. 어떤 도구로 썼는가와 실제로 재현되는가는 서로 다른 질문이다.

맞춤 양식을 추가했다면 자동 제출 경로도 점검한다

REST API로 보내는 제보도 맞춤 양식을 따라야 한다. 공식 설정 문서에 따르면 API의 Markdown description에 해당 양식의 필수 섹션과 답변이 포함돼야 한다. 반면 기본 내장 양식은 API 제출에 강제되지 않는다.

따라서 웹 양식만 바꿨다고 생각해도 기존 자동화의 제출이 거절될 수 있다. 오류가 가리키는 적용 양식을 확인하고 자동화가 채우는 내용을 맞춰야 한다. 기본 양식과 맞춤 양식에 같은 API 규칙이 적용된다고 가정하면 이 차이를 놓친다.

유지관리자가 바꿀 수 있는 것은 제보를 받을 때 요구하는 정보다. 필요한 질문을 명확히 쓰고, 웹 화면과 API 제출이 같은 의도를 반영하는지 확인한 뒤, 접수된 주장에 대한 재현 검토를 이어 가야 한다.