GitHub Enterprise 新增凭据清单导出功能

企业所有者现在可以导出能够访问其企业的每一项凭据的完整清单（例如 SSH 密钥、经典版和细粒度个人访问令牌、OAuth 应用访问令牌，以及 GitHub 应用的用户到服务器令牌和安装令牌）。这使企业所有者能够以单一视图查看其企业内成员和应用所拥有的全部凭据。

在安全事件期间，这使其安全团队能够快速评估风险面，并基于已识别出的受损令牌集合来规划修复与沟通。

通过此版本，企业所有者以及拥有“查看企业凭据”细粒度权限的成员可以：从企业设置中导出清单，或通过分页 REST API 以编程方式获取。查看完整的凭据清单 CSV，或按用户、应用、凭据类型或组织进行筛选。查看凭据元数据，包括所有者、作用域和权限、创建和过期日期、上次使用日期，以及目标组织或仓库。将凭据与审计日志活动关联，以获得关于其使用情况和风险暴露的更多洞察。

如果你是企业所有者，可以在企业的 Settings -> Authentication Security -> Credentials 中找到“Export CSV”设置，位于“Overview”部分旁边。或者，你也可以以编程方式调用新的 REST API 端点，构建自己的报告和自动化。

此版本现已面向 GitHub Enterprise Cloud 提供，并将在未来的 GitHub Enterprise Server 版本中得到支持。

如需了解更多，请参阅我们关于通过审查企业中的凭据来响应企业中安全事件的文档，以及用于导出凭据清单的新 REST API。

GitHub 企业版现在可以导出访问企业资源的全部凭据清单，支持通过企业设置或分页 REST API 获取，并可按用户、应用、凭据类型或组织筛选查看元数据，用于安全事件期间的快速风险面评估与修复规划。该功能现已面向 GitHub Enterprise Cloud 提供。

• GitHub 企业版现在可以导出访问企业资源的全部凭据清单，支持通过企业设置或分页 REST API 获取，并可按用户、应用、凭据类型或组织筛选查看元数据，用于安全事件期间的快速风险面评估与修复规划。该功能现已面向 GitHub Enterprise Cloud 提供。
• 原贴提到：Enterprise owners can now export a complete inventory of every credentia
• 来源：github.blog

这是什么信号

GitHub 把“企业内到底有哪些凭据能进来”这件事，从分散在各个成员账号和应用的配置里，收敛成了一个可导出、可筛选、可通过 API 拉取的统一清单。这不是一个新的安全产品，而是把原先只在安全团队脑中的“资产盘点”变成了一个可交付物：SSH 密钥、经典版与细粒度 PAT、OAuth 应用访问令牌、GitHub 应用的用户到服务器令牌和安装令牌，全部纳入一张表。

真正的信号在于 GitHub 主动承认了企业凭据治理的现状——令牌是分层级、分类型、分散持有的，靠人工盘点不可行。它选择用“清单 + REST API”的方式把治理能力交还给企业。

为什么重要

凭据泄漏事件的响应速度，取决于“你多久能说清楚有多少东西可能已经失守”。过去这个答案往往需要人工翻阅成员账号、逐个应用核对，耗时以天计。现在企业所有者或拥有细粒度“查看企业凭据”权限的成员，可以直接导出 CSV 或调用分页 API 拉全量清单，并看到所有者、作用域与权限、创建与过期时间、上次使用时间、目标组织或仓库这些元数据。

更关键的是最后一条能力：把凭据与审计日志活动做关联。这意味着“这个令牌被谁在什么时候用了”不再需要人工拼接，风险暴露可以被量化，而不是停留在猜测。对于需要出具合规证据或向管理层汇报的团队，这是一条可复核的证据链。

对谁有价值

最直接的受益者是三类人：一是企业所有者与平台管理员，终于有了单体视图来回答“谁持有访问权”；二是安全事件响应团队，可以基于已识别的受损令牌集合去规划修复和对外沟通范围，而不是把所有令牌一刀切吊销；三是负责合规与审计的角色，元数据里的创建时间、过期时间、上次使用时间，本身就是清理僵尸凭据的依据。

此外，拿到 REST API 之后，平台工程团队可以把这件事从“事件驱动的一次性动作”变成“持续运行的例行任务”。

可以怎么行动

第一步，先用设置里的“Export CSV”拉一次当前全量清单，做一次基线盘点：找出长期未使用（last-used 久远）、无过期时间、作用域过宽、指向关键仓库或组织的凭据，形成清理优先级。第二步，把 REST API 接入现有的资产或安全平台，做定期拉取与差异比对，让新增凭据自动进入可见范围，而不是等到下一次安全事件才发现。

第三步，把清单输出与审计日志关联查询，做使用行为的常态化核对，并对异常调用路径建立告警。第四步，把“导出清单并复核”写进安全事件响应手册，明确谁有权限导出、导出后如何存储、多久复盘一次。

风险与限制

首先，导出的这份 CSV 本身就是高价值目标。它虽然一般是元数据而非令牌明文，但一份完整列出“谁持有什么权限、指向哪些仓库”的文件，对攻击者等同于一本地图。导出权限必须严格限定，文件落地后的存储、传输和销毁都要有明确规则。其次，通过 REST API 拉取清单意味着会产生或复用一个自动化凭据，这个凭据本身又成了新的风险点，需要单独收敛权限并纳入同一套治理流程。

第三，清单是快照，不是实时状态；不持续运行就会迅速过期，形成虚假的安全感。第四，该功能只负责“看见”，不负责“处置”——吊销、轮换、收窄作用域仍需在各自流程中完成，不要把它误当成自动修复。最后，当前版本面向 GitHub Enterprise Cloud 提供，GitHub Enterprise Server 将在后续版本中支持，使用自托管版本的企业需要评估时间窗口内的替代方案。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub Enterprise 新增凭据清单导出功能》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖