一句话看懂：GitHub 的代码安全风险评估与密钥风险评估现在会标注发现项位于受保护还是未受保护的仓库，让管理员看清安全覆盖的缺口在哪里。
事件核心：发生了什么
根据 GitHub Changelog 于 2026 年 11 月 2 日发布的说明，GitHub 的两项安全评估功能——代码安全风险评估（code security risk assessment）和密钥风险评估（secret risk assessment）——现在会在结果中显示发现项所处仓库的保护状态。组织管理员和安全负责人可从组织 Security 标签页下的 Assessments 入口发起评估。该改进已在 GitHub Enterprise Cloud 和 GitHub Team 中提供，密钥风险评估计划于 GitHub Enterprise Server 3.24 版本跟进。
为什么重要
安全扫描的价值不只在于发现漏洞或泄露的密钥，更在于知道这些问题落在哪些仓库、这些仓库是否已有保护措施。此前评估结果可能只列出问题清单，管理者难以判断哪些风险处于“裸奔”状态。加入仓库保护状态后，风险优先级从“有多少问题”转向“哪些问题发生在缺乏保护的位置”，这更贴近企业安全治理的实际决策逻辑。对使用 GitHub 高级安全功能的团队而言，这也意味着评估报告能直接对接权限、分支保护和密钥扫描等已有机制，减少人工比对成本。
对用户/开发者/创作者的影响
对组织管理员和安全经理来说，最直接的变化是评估报告多了一个筛选维度：可以先看未受保护仓库中的发现项，再决定是否补齐分支保护、密钥扫描或访问控制。对普通开发者而言，这项功能本身不改变日常提交代码的方式，但如果所在组织据此收紧了仓库策略，可能会感受到更严格的推送或合并限制。对中小团队来说，GitHub Team 也能使用该能力，说明安全可见性正从大型企业专属逐步下沉，不过实际效果仍取决于团队是否认真查看并处理评估结果。
值得关注的后续
目前公开信息显示，该功能是评估结果展示层面的增强，并未说明会自动修复或自动执行保护策略。后续可观察三点：一是 GitHub Enterprise Server 3.24 中密钥风险评估的实际上线时间与功能一致性；二是评估报告是否会进一步支持按保护状态导出或接入第三方安全运营平台；三是 GitHub 是否会把类似的状态维度扩展到依赖项、代码扫描等其他安全产品线。
