GitHub 企业公共监测正式可用后管理员能够观察什么

GitHub 于 2026 年 10 月 28 日宣布 Public monitoring for enterprises 正式可用。它解决的不是“企业仓库有没有扫描”，而是员工把令牌提交到个人 fork、开源项目、公开 Issue 或 gist 后，安全团队仍能不能收到归属于本企业的线索。结论很明确：符合条件的 GitHub Enterprise Cloud 企业开启后，可以观察 GitHub 公共内容中的秘密暴露，并看到 GitHub 给出的企业归因；它不会扫描私有仓库，也不能替代企业自有仓库的 Secret scanning。

官方公告：https://github.blog/changelog/2026-10-28-public-monitoring-for-enterprises-generally-available/

公共监测模式解决的是企业边界外泄露

传统仓库扫描的边界是“企业拥有的仓库”。但泄露路径往往不是一条直线：开发者可能从个人账号向公开仓库推送，或把访问令牌粘进公开 Issue 评论。Public monitoring 把观察面扩展到 GitHub 的公共内容，并在泄露发生时实时匹配，而不是等待夜间批量爬取。

这里的“公共”是硬边界。官方说明列出的范围包括公开 Git 内容、Issue 和 Pull Request 的文字、Discussion 以及 secret gist。私有仓库不会被这项能力扫描；企业自己拥有的公开、私有和内部仓库，仍应使用仓库级 Secret scanning 做覆盖。

归因链路决定管理员能够观察什么

发现一个秘密只是第一步，企业真正需要的是“这件事是否与我有关”。GitHub 公共监测使用身份层元数据做两条归因：提交者的 GitHub 账号属于企业成员时，按成员关系归因；提交者使用企业已验证域名的邮箱时，按域名匹配归因。后一种情况即使账号没有关联到企业，甚至邮箱没有公开，也可能匹配。

这意味着管理员能观察的是“公开暴露 + GitHub 归因证据”，而不是对所有互联网泄露做追踪。数据驻留企业还有一个额外边界：由于租户隔离，归因只依靠已验证域名，企业成员名册不会跨边界共享。

启用路径与采用边界

适用对象是启用了 GitHub Secret Protection 或 GitHub Advanced Security 的 GitHub Enterprise Cloud 企业，官方公告说明 Public monitoring 已包含在相应许可中，不额外收费。企业所有者和企业安全管理员可以从企业的 Security 选项卡启用；开启后可以查看近期已泄露秘密，GitHub 也会继续匹配未来暴露。

落地时建议先做三件事：确认企业要监测的工作域名已完成验证；规定收到告警后先撤销或轮换凭据，再处理历史内容；保留企业自有仓库的 Secret scanning 和 push protection。不要把“公共监测已开启”理解为 DLP、私有仓库扫描或所有外部代码托管平台的统一监控。

判断这项能力是否覆盖你的场景

• 员工把 token 提交到公开仓库、公开 Issue 或 gist：属于它要补上的边界。
• 秘密只存在企业私有仓库：继续依赖企业仓库的 Secret scanning。
• 提交者使用个人账号但邮箱属于已验证工作域名：重点检查域名归因是否完整。
• 需要监测 GitHub 之外的平台或本地日志：不能从本公告推断已有覆盖。

常见问题

Public monitoring 会扫描私有仓库吗？

不会。它只处理 GitHub 公共表面，企业拥有的私有或内部仓库要由 Secret scanning 覆盖。

没有把个人账号加入企业也能归因吗？

如果提交使用了企业已验证域名，官方说明允许通过域名匹配归因；这不是对任意个人账号的猜测。

开启后能否自动修复泄露？

公告描述的是发现和归因。凭据撤销、轮换、清理公开内容以及复盘提交流程，仍需由企业自己的响应流程完成。

官方文档：https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning