GitHub安全公告加入保密评论：内部讨论留在时间线，评论API仍处公开预览
2026年10月2日，GitHub为仓库安全公告加入保密评论，同时将评论REST API开放为公开预览。前者让维护者在原有公告时间线内讨论调查细节，后者允许工具读取、添加和编辑普通评论。两项功能涉及同一协作流程，但可见范围并不相同，准备接入自动化的团队需要一起核对。
内部讨论可以留在原处
此前，公告中的评论对所有协作者可见，包括报告者。维护者若要讨论疑似滥用、调查过程或内部协调，通常需要转移到其他渠道。新功能允许发帖前选择保密评论，只有当前拥有仓库写权限的人可以读取；没有写权限的报告者和受邀协作者看不到，也不会收到通知。
权限跟随仓库的当前设置变化。某人失去写权限后，就不能继续读取保密评论；相关查看行为会记录到审计日志。这里的判断依据是写权限，而不是对方是否被称为“内部成员”。若外部协作者本身拥有写权限，也不能假设“保密”选项自动将其排除。
AI模型生成的概念插图：同一份调查材料中的讨论具有不同可见范围；不是GitHub真实界面，也不代表实际漏洞记录。
发布前决定范围，导出时解释缺口
官方明确，评论发出后不能在普通与保密之间切换。因此，团队应在提交前检查受众和正文，尤其不要把待确认的账号信息、复现材料或内部判断先发成普通评论，再期待补一个标签就能收回可见范围。这是本次更新带来的具体操作要求。
保密评论可通过GraphQL API访问，但REST API不返回它们。新REST端点支持列出评论、读取单条、添加和编辑，并可按更新时间限制列表；当前还不支持删除。仓库公告及相关全局公告响应新增的comments计数，也只统计非保密评论。
这意味着REST导出文件可能完整覆盖接口允许返回的记录，却仍不是公告时间线的全部讨论。本文建议在审计或迁移材料中注明接口、账号权限和导出范围，不要仅凭“导出条数等于comments”就宣称保留了全部历史。需要内部讨论时，应单独核对GraphQL访问与保存权限。
读取数据更方便，授权仍需逐层确认
同日，GitHub还给SecurityAdvisory GraphQL对象补充CVE编号、相关源码位置、GitHub审核时间、NVD发布时间及关联仓库公告链接，并新增严重程度与是否撤回的筛选。它们属于只读、向后兼容的增量，便于维护分级处理清单，也能减少为了补字段而切换REST的次数。
时间字段的含义要分别保存：NVD发布与GitHub审核是不同节点，不能混成统一的“漏洞发生时间”。筛选撤回记录时，也应保留撤回状态，避免把后来失效的公告继续当成当前结论。
保密评论适用于已启用私密漏洞报告的公开仓库，覆盖Free、Pro、Team和Enterprise Cloud；评论REST预览也面向这些计划的公开仓库。API调用仍要求能查看对应公告，并具备适当的安全公告读写权限。可以先在测试仓库用写权限成员和无写权限协作者分别核验通知、可见性与导出结果，再接到正式流程。
来源与核对时间
资料核对：2026年10月3日（北京时间）。本文依据官方公开资料整理，未在真实仓库中执行测试。
