摘要
2026 年 9 月 21 日，GitHub 在 Changelog 里发布了一项面向企业安全团队的更新：企业所有者现在可以"导出所有能够访问其企业的凭据清单"。覆盖范围包括 SSH 密钥、classic 与 fine-grained personal access token、OAuth App 访问令牌，以及 GitHub App 的 user-to-server 令牌和 installation 令牌。
导出既可以在企业设置里点按钮，也可以通过分页 REST API 拉取；拿到的是 CSV，可以按用户、应用、凭据类型或组织筛选，并看到所有者、作用域与权限、创建与过期时间、最近一次使用时间，以及凭据指向的组织或仓库。GitHub 同时说明可以把这份清单与审计日志活动关联起来，用来看清使用情况和风险暴露。
它解决的问题在安全事件里非常具体：当有人问"到底有哪些凭据能进我们的企业"，过去要逐个人、逐个应用去盘点；现在是一次导出。
凭据治理的难点从来不是"有没有令牌"，而是"谁还能用、用在哪、什么时候最后一次用过"。这三件事散落在不同页面时，事件响应就只能靠猜；而能一次导出、并能与审计日志对齐的清单，才让"撤销哪几个、通知哪些人"变成可执行的判断。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：一份覆盖全部企业级凭据的清单
GitHub 的原文是："Enterprise owners can now export a complete inventory of every credential that can access their enterprise."。清单里包含五类凭据：SSH 密钥、classic personal access token、fine-grained personal access token、OAuth App 访问令牌，以及 GitHub App 的 user-to-server 令牌与 installation 令牌。原文的描述是"成员所有与应用所有的凭据"合在一个视图里。
交付方式有两种。一是企业设置里的 Export CSV，位置在企业 Settings → Authentication Security → Credentials， Overview 区块旁边；二是分页 REST API，官方给出的用途是自定义报表与自动化。CSV 支持按用户、应用、凭据类型和组织筛选，字段包括所有者、作用域与权限、创建与过期时间、最近一次使用时间，以及凭据能够触达的组织或仓库。此外，清单可以与审计日志活动做关联，用于判断使用情况和风险暴露。
权限方面，能操作的是企业所有者，以及被授予细粒度权限 View enterprise credentials 的成员。可用范围是 GitHub Enterprise Cloud，官方写明该能力"将在后续版本中支持 GitHub Enterprise Server"。
完整工作场景：一次令牌泄露事件的第一个小时
把这份清单放进一次真实的安全事件里：某个第三方集成使用的令牌疑似泄露，你需要回答四个问题——还有谁能访问我们的企业、这个集成的令牌有几个、各自的作用域多大、最近一次被用是什么时候。
过去的做法往往是：安全同学在企业设置里逐页翻人员和组织，开发同学回忆哪个 CI 用过哪个 App，最后拼出一份不完整的表格；高风险的部分（比如某个三年前创建、从未过期、作用域是全部仓库的 PAT）通常要等到有人手动翻到才发现。
现在这三步变成：导出 CSV，按应用与凭据类型筛出这一集成相关的全部令牌，按最近一次使用时间与过期时间排序，把"长期未用且权限过大"的那一批先标记出来；随后把清单与审计日志关联，确认哪些令牌在可疑时间窗口内出现过活动，再决定撤销范围和通知对象。整个过程里，人的判断没有变少，但判断所依赖的材料第一次是完整的。
为什么它改变工作流：从"发现"到"可核对"
安全工具的价值往往不在于自动化某个动作，而在于把散落的材料变成可核对的清单。凭据清单导出把三件事从人工记忆变成了可以查询的字段：凭据的所有者是谁、权限范围多大、最近一次使用是什么时候。有了这三个字段，"哪些凭据应该被回收"就从讨论变成了一次筛选。
REST API 这一层对工程团队的改变更直接：巡检可以进流水线。定期拉取清单、对比上一期快照、对新出现的长期有效凭据或权限扩张发出告警，这是过去需要自建爬虫和人工维护台账才能做到的事。GitHub 也把这件事与审计日志的关联写在了同一段说明里，说明官方预期的用法就是"清单 + 日志"两条数据一起看。
限制、边界与人应该在哪儿接管
第一，范围是"能访问该企业的凭据"，也就是企业级视图；它不能替代仓库级别的访问审计，也不能替代对第三方应用内部行为的判断。第二，GitHub Enterprise Server 目前还不支持，自托管用户只能在升级后获得，这段时间里仍然需要人工盘点。第三，权限门槛明确：必须是企业所有者，或持有 View enterprise credentials 这一细粒度权限；CI 里要用 API 做巡检，需要为该机器人账户准备好对等权限，并把它自己当作高价值凭据管理起来——凭据巡检账号本身通常权限很大。
第四，来源里没有说明这个页面是否提供直接从清单撤销凭据的入口，因此不要把"可见"等同于"可处置"；撤销动作仍要回到各自的凭据管理入口确认。第五，清单里是元数据而非密钥本身，它帮助你判断暴露面，但不能证明某个令牌没有被使用过——唯一的使用证据仍然来自审计日志。第六，人的接管点在决策环节：撤销一个正在被生产流水线使用的令牌会导致发布中断，所以筛选出候选清单之后，通知、宽限窗口和回滚预案仍要人来定。
如何试用
企业所有者进入企业 Settings → Authentication Security → Credentials，在 Overview 旁边找到 Export CSV 完成第一次导出；需要自动化的团队按文档用分页 REST API 拉取，并先确认机器人账户持有 View enterprise credentials 权限。落地建议是先做一次全量盘点并按最近一次使用时间排序，把长期未使用的高权限凭据单独成表，再决定是否把它变成定期巡检。GHES 用户先记录缺口，等升级版本支持后再纳入同一套流程。
信息来源
- GitHub Changelog：GitHub Enterprise adds credential inventory exports（2026-09-21）https://github.blog/changelog/2026-09-21-github-enterprise-adds-credential-inventory-exports
- GitHub Docs：Reviewing credentials in your enterprise https://docs.github.com/en/enterprise-cloud@latest/admin
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
