一句话看懂：GitHub 为仓库安全公告引入“机密评论”，只有拥有仓库写权限的维护者可见，漏洞报告者和被邀请的外部协作者都看不到。这意味着安全团队终于可以在公告内讨论可疑滥用、调查细节和协调节奏，而不必把对话搬到 Slack 或邮件里。
事件核心：发生了什么
GitHub 在 2026 年 10 月 2 日的 Changelog 中宣布，仓库安全公告（Repository Security Advisories）支持发布机密评论。此前，公告下的每一条评论对所有协作者可见，包括漏洞报告者本人；如果维护者要讨论疑似滥用、调查进展或对外协调策略，只能另开渠道，相关记录也就脱离了公告历史。
本次更新的具体变化包括：发布评论前可在输入框下方勾选“机密，仅维护者可见”；机密评论会在公告时间线中明确标记；报告者和无写权限的受邀协作者既看不到也不会收到通知；权限跟随仓库现有权限体系，一旦某人失去写权限，就再也读不到此前的机密评论；机密评论的查看行为会写入审计日志。此外，评论发布后无法在机密与普通状态之间切换，机密评论可通过 GraphQL API 获取，但 REST API 不会返回。该功能面向启用了私有漏洞报告的公开仓库，覆盖 GitHub Free、Pro、Team 和 Enterprise Cloud。
为什么重要
漏洞披露流程本质上是一场多方协调：维护者、报告者、下游分发方和潜在受影响用户之间存在明显的信息不对称。把内部研判和外部沟通混在同一个评论区，容易造成两个问题——要么维护者因为顾忌报告者而不敢说真话，要么敏感调查细节被提前暴露。机密评论把“内部工作区”和“对外沟通区”在同一个工单内做了权限切分，这是安全协作流程层面的改进，而不是单纯的评论功能补丁。
对 GitHub 而言，这一步也在补强其供应链安全版图。近年开源生态的安全事件频发，私有漏洞报告、安全公告、依赖图谱、密钥扫描等能力已逐步打通，机密评论让公告更接近一个完整的漏洞处置工作台。对于依赖 GitHub 托管关键开源项目的企业来说，审计日志的加入也让“谁看过内部讨论”变得可追溯，符合合规团队对访问记录的要求。
对用户/开发者/创作者的影响
开源维护者是直接受益方。过去处理安全报告时，维护者往往在公告之外私聊，导致新加入的协作者看不到历史决策依据；现在这些讨论会沉淀在公告时间线里，权限收回也自动生效。对企业安全团队来说，机密评论配合审计日志，可以更规范地记录漏洞研判过程，减少“口头决策、事后无据”的情况。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
需要留意的是 API 层面的差异：习惯用 REST API 拉取安全公告数据的自动化工具，不会拿到机密评论，依赖这部分内容的内部看板或工单同步需要改用 GraphQL。另外，评论状态不可逆，维护者在提交前需要确认勾选是否正确。受邀协作者和漏洞报告者的体验基本不变，但也意味着他们无法感知维护者是否正在内部讨论，透明度和效率之间的取舍由维护者自行判断。
值得关注的后续
一是机密评论是否会将扩展到私有仓库或未启用私有漏洞报告的场景，目前公开信息显示仅覆盖公开仓库。二是 GitHub 是否会把类似权限切分延伸到 Issue、Discussions 等协作场景，形成一致的信息分级模型。三是依赖 REST API 的安全编排工具是否跟进 GraphQL 支持，否则企业内部漏洞工单会长期存在数据缺口。
