GitHub 보안 권고 기밀 댓글: 전송 전에 독자를 확인하는 운영 습관
취약점 제보를 검토하면서 남긴 내부 메모가 제보자에게도 보이는가. 보안 대응에서는 문장을 잘 쓰는 것보다 누가 읽는지 먼저 확인해야 합니다. GitHub가 10월 2일 공개한 보안 권고 기밀 댓글은 이 경계를 권고의 기록 안에서 나눌 수 있게 합니다.
공식 발표에 따르면 기밀 댓글은 저장소 write 권한을 가진 사람만 볼 수 있습니다. write 권한이 없는 제보자와 초대 협업자는 읽거나 알림을 받지 않습니다. 아래 도식은 팀이 제출 전 확인할 순서이며 제품 화면이 아닙니다.
기밀은 현재 권한을 따릅니다
작성자만 보는 개인 메모로 이해하면 안 됩니다. 현재 write 권한을 가진 팀원이 독자입니다. 반대로 write 권한을 잃으면 읽을 수 없습니다. 따라서 댓글에 기밀 표시가 있는지와 지금 누가 저장소 write 권한을 갖는지는 별도로 검토할 질문입니다.
적용 범위는 private vulnerability reporting을 활성화한 공개 저장소입니다. 공식 발표는 Free·Pro·Team·Enterprise Cloud를 명시합니다. 이 글은 실제 권한을 넓히거나 제보자를 배제하라는 제안이 아닙니다. 내부 조사 메모와 제보자에게 전달할 기술 설명을 목적에 따라 작성하자는 운영 제안입니다.
게시 뒤 유형을 바꿀 수 없습니다
기밀 댓글과 일반 댓글은 게시 후 서로 전환할 수 없습니다. 제출 직전에 독자, 내용, 선택 상태를 함께 확인하는 짧은 절차가 필요합니다. 담당자가 조사 가설을 적고 다른 담당자가 공유 가능한 사실을 검토하는 방식으로 초안 단계에서 실수를 줄일 수 있습니다.
예를 들어 내부 대응 담당자 이름과 미확인 조사 가설은 별도 초안으로 먼저 검토하고, 제보자에게 보낼 재현 결과는 확인된 사실만 정리합니다. 이 예시는 팀 운영안이며 GitHub가 요구하는 양식이 아닙니다. 실제 취약점이나 비밀을 시험용 댓글로 보내지 마세요.
API에 안 보이는 것을 기록 부재로 읽지 않기
공식 발표는 기밀 댓글이 GraphQL API에서 제공되지만 REST API에서는 반환되지 않는다고 설명합니다. REST 기반 보관 도구가 수집한 댓글만 보고 전체 조사 기록이라고 판단하면 누락된 범위를 놓칠 수 있습니다. 읽기 권한과 수집 경로를 결과 문서에 함께 남기는 편이 좋습니다.
기밀 댓글 조회는 감사 로그에 기록됩니다. 다만 감사 기록이 댓글 본문 보관과 같은 의미는 아닙니다. 팀의 내보내기나 검색 도구에는 어떤 API를 사용했고 어떤 독자 권한으로 확인했는지 적고, 접근할 수 없는 구간은 미확인으로 표시하세요. API 차이는 존재와 부재를 구분하는 검증 문제입니다.
이번 주에는 무해한 문장으로 흐름만 검증하기
팀이 소유한 테스트용 권고에서 민감하지 않은 문장으로 유형 선택과 독자별 읽기 범위를 확인하는 절차를 설계하세요. 실제 실행 전 권고·계정·권한을 담당자가 검토합니다. 화면에서 보이는 유형과 수집 도구 결과를 대조하고, 결과를 운영 문서에 적으면 됩니다.
기밀 공간이 늘어나면 협업자가 필요한 정보를 못 받는 역효과도 생길 수 있습니다. 내부 메모와 별개로 제보자에게 진행 상황, 재현 결과, 공개 가능한 조치를 설명할 책임은 남습니다. 이 글의 확인 범위는 공식 기능·권한·API 경계이며 보안성이나 대응 속도 개선 수치를 추정하지 않습니다.