GitHub 보안 권고 댓글, API로 가져오면 왜 일부가 빠질까

웹에서 보이는 비밀 댓글도 공개 API에서는 빠진다

GitHub 보안 권고 페이지에는 댓글이 있는데 API로 가져온 목록에는 없다면, 해당 댓글이 Confidential인지 확인해야 한다. GitHub의 현재 공식 안내는 비밀 댓글을 공개 REST·GraphQL API로 제공하지 않는다고 명시한다. 웹에서 열람할 권한이 있어도 이 제한은 사라지지 않는다.

GitHub가 10월 2일 도입한 이 댓글은 취약점 제보에 대한 조사나 조율 내용을 같은 보안 권고 안에 남기도록 한다. 공개 저장소에서 비공개 취약성 보고를 켠 경우 GitHub Free·Pro·Team·Enterprise Cloud에서 사용할 수 있다.

보안 권고 자체도 공개 이슈와는 역할이 다르다. 저장소 보안 권고는 취약성을 비공개로 논의하고 수정한 뒤 이용자에게 알리는 흐름을 지원한다. 그 비공개 협업 공간 안에서도 일반 댓글과 내부 메모의 열람 범위가 다시 나뉜다.

댓글 수가 전체 내부 대화량을 뜻하지는 않는다

같은 날 나온 보안 권고 댓글 REST API 프리뷰는 일반 댓글의 목록·단건 조회·추가·편집을 지원한다. 권고 응답에 추가된 comments 수도 비밀 댓글을 제외해 센다. 따라서 숫자와 목록이 일치해도 내부 메모까지 모두 확보했다는 뜻은 아니다.

예를 들어 내부 기록을 다른 도구로 옮기는 작업이라면, API로 받은 결과의 범위를 ‘일반 댓글’로 표시하는 것이 정확하다. 목록에 내부 논의가 없다는 이유만으로 담당자가 검토하지 않았다고 판단해서도 안 된다. 이는 내보내기 결과를 해석할 때 필요한 구분이다.

일반 댓글에도 권한 조건은 있다. 보안 권고를 볼 수 있어야 하며 적절한 repository security advisories 권한이나 토큰 범위가 필요하다. 이 조건을 맞추는 일과 Confidential 댓글의 API 미제공은 다른 문제다. 더 넓은 토큰 권한이 빠진 내부 메모를 돌려주는 해결책은 아니다.

‘제보자냐’보다 ‘저장소 쓰기 권한이 있느냐’가 기준이다

권한 문서는 보안 권고의 협업자라도 저장소 쓰기 권한이 없으면 비밀 댓글을 만들거나 볼 수 없다고 설명한다. 반대로 제보자에게 저장소 쓰기 권한이 있다면 그 사람도 비밀 댓글을 볼 수 있다. ‘제보자에게 숨기는 기능’이라는 표현만으로 판단하면 이 조건을 놓치게 된다.

관리 가이드가 설명하는 기준은 게시 당시 참여자 명단이 아닌 현재 권한이다. 따라서 특정 조사 담당자 몇 명에게만 영구히 공개되는 메모함으로 생각하면 안 된다. GitHub는 비밀 댓글 열람을 감사 로그에 기록한다고도 안내한다.

내부 논의와 제보자 회신은 게시 전에 나눈다

저장소의 Security and quality → Advisories에서 대상 권고를 열고 댓글을 작성한 뒤, 입력창 아래의 Confidential. Only maintainers will see this comment.를 선택해 게시한다. 이미 게시한 일반 댓글을 비밀 댓글로 바꾸거나 반대로 전환할 수는 없다.

제보자에게 재현 조건을 묻거나 판단 이유를 전달할 때는 일반 댓글을 사용해야 상대방이 대화를 이어 갈 수 있다. 비밀 댓글은 쓰기 권한이 없는 제보자·초대 협업자에게 보이지 않고 알림도 가지 않는다. 내부 메모에 질문을 남겨 놓고 외부 제보자의 답을 기다리는 식의 착오를 피해야 한다.

자동화는 일반 댓글의 수집·추가·편집 범위로 설계하고, 내부 논의는 웹에서 현재 권한에 따라 확인한다. 내보낸 기록에 어떤 대화가 포함됐는지 구분하면, 댓글 API가 제공하는 범위를 넘어서 완전한 기록이라고 설명하는 일을 피할 수 있다.