GitHub 安全公告机密评论：发送前先确认读者
Dev
浏览 2
内部调查笔记会不会被报告者看到？安全协作应先确认读者。GitHub在10月2日宣布安全公告中的机密评论。
官方说明只有仓库write权限者可读。没有该权限的报告者与受邀协作者看不到，也不收到通知。图示是建议流程，不是产品截图。
机密跟随当前权限
这不是仅作者可见的个人笔记。当前write权限者是读者，失去权限便无法阅读。机密标签和当前权限名单要分别检查。
适用范围为启用私密漏洞报告的公开仓库，涵盖Free、Pro、Team、Enterprise Cloud。本文不建议扩大权限，而是按目的区分内部笔记与外部说明。
发送后不能切换类型
普通和机密评论发布后不能相互切换。发送前检查读者、内容、选择状态。草稿阶段把调查假设和已确认事实分开。
例如先内部审阅负责人和未确认假设，再向报告者说明已验证复现结果。这是团队建议，不是GitHub强制表单。不要用真实秘密测试。
API不可见不代表记录不存在
机密评论可由GraphQL取得，REST不会返回。仅有REST归档不能证明调查完整。记录采集路径与读者权限。
查看记录进入审计日志，但不等于保存评论正文。导出与搜索工具应注明API、读者及未验证范围，区分不可见与不存在。
用无害文本验证流程
在团队拥有的测试公告中设计非敏感文字检查。负责人先审阅公告、账号、权限，再对照可见类型与采集结果并记录。
内部空间可能让协作者缺少必要信息，仍需向报告者解释进展和结果。本文确认功能、权限与API边界，不编造安全或响应速度改进数字。