GitHub 于10月5日为密钥扫描（secret scanning）新增5种类型。密钥扫描用于发现提交到仓库中的 API 密钥等凭据。
新增的类型为 lovable_api_key、logfire_token、pydantic_ai_gateway_api_key、supabase_oauth_access_token 和 supabase_scoped_personal_access_token。
Lovable Labs 还加入了密钥扫描合作伙伴计划。在公开仓库中发现 lovable_api_key 时，GitHub 会将其转交给 Lovable，以便吊销或轮换该凭据。
识别凭据与通知有能力应对的一方相互关联，但不是同一项变化，也不意味着所有令牌都获得同样的保护。
仓库告警、合作伙伴告警与按模式区分的功能
GitHub 把告警分为两条路径。User 类型在公开或私有仓库中被发现时，为仓库用户生成密钥扫描告警；Partner 类型在公开仓库中被发现时，会自动报告给签发方。
据文档说明，合作伙伴告警直接发送给提供商，不会在仓库的 Security and quality 选项卡中报告。
支持表按模式分别标注推送保护和有效性检查。此次新增的5种类型均标为既无推送保护，也无有效性检查。
在支持表中，logfire_token 和 pydantic_ai_gateway_api_key 未标注适用于公开仓库，只标注适用于使用 GitHub Advanced Security 的私有仓库。
合作伙伴转交为签发方提供了应对的机会，但并不保证会自动吊销。
令牌类型与响应路径的组合
有些运维问题无法用检测类型的数量来回答：谁会看到事件，谁能使泄露的凭据失效？
常见情况是仓库管理员负责清理代码，而服务账户由另一个团队管理。提供商的通知很有用，但不能替代组织自己的事件记录。
反过来，仓库界面一片安静，也不能说明提供商没有收到通知。审查的单位应是令牌类型与响应路径的组合，而不是产品名称。
从实际使用的凭据清单出发的检查
检查最好从应用实际使用的凭据类型清单出发，再把这些标识符与当前的支持表以及仓库中启用的功能进行对照。
记录负责调查告警、吊销或轮换泄露凭据以及更新依赖服务的人员或团队。
这是建议的运维检查，而不是在客户账户上验证过的流程。为了确认责任已经分配，没有理由提交真实的凭据。
在获准范围内进行受控验证
如果需要受控验证，原则是只使用提供商认可的虚拟或测试凭据，以及经明确授权的测试仓库。
先确定预期的观察结果。本地拦截、仓库告警和签发方的响应是不同的结果，证明其中一项的测试并不能证明其他各项。
证据中不要留下可用的密钥。删除测试提交，并不能撤销真实凭据曾经被公开的事实。
注意事项：识别范围扩大与未经验证的部分
此次发布的直接好处是识别范围扩大，并不意味着事件处理流程已经完备。
本文只审阅了公告和文档，没有测试检测、私有仓库的使用资格或提供商的响应，也没有实际运行并验证这5种类型的各项功能。
新的检测类型告诉你的只是密钥能够被发现，至于谁接收告警、接下来做什么，仍要由组织来决定。