API密钥误推GitHub：先撤销，再清理仓库

API密钥误推到GitHub后，先确认签发方和访问权限，尽快撤销或轮换旧密钥。GitHub的泄露凭证处置教程要求将泄露凭证视为已被攻破：删除代码、追加提交，甚至删除并重建仓库，都不能阻止别人使用已经取得的有效密钥。

旧密钥失效后，更新依赖它的服务，检查暴露期间的使用记录，最后再决定是否改写Git历史。前15分钟、第一小时和后续复盘是安排工作的时间线，不是撤销凭证的宽限期；若密钥仍有效且能访问生产资源，应立即处理，不能等仓库清理完毕。

前15分钟：弄清权限，让旧密钥失效

先确定密钥类型、签发方、所属账号或项目、出现在哪个仓库和提交，以及它能读取、修改或删除哪些资源。仓库是否公开、凭证是否用于生产环境，也会影响处置优先级。此时只需取得足够信息来找到负责人并执行撤销，不必先追查每一处历史副本。

如果仓库启用了密钥扫描，警报可能显示凭证是否仍有效、是否公开暴露，以及部分GitHub个人访问令牌的权限或最近使用信息。这些信息因凭证类型而异；判断密钥当前是否有效，仍应以签发方的管理界面为准。没有扫描警报，也不能把提交过的密钥当作安全密钥。

有管理权限的人应在签发方撤销旧密钥，并在业务需要时签发替代密钥。如果立即撤销会中断关键服务，可以先让应用切换到新密钥，再尽快停用旧密钥；切换期间，旧密钥仍可被使用。无权操作的开发者应立即联系密钥所有者和安全负责人，明确由谁完成撤销并核实结果。

公开仓库中泄露的某些GitHub个人访问令牌可能已被平台自动撤销，其他受支持的凭证则可能被报告给签发方；不要凭自动处理的可能性结束处置。暂时无法撤销时，GitGuardian的公开仓库处置指引建议先把仓库转为私有，以减少继续暴露，但分叉和镜像可能仍有副本。改变仓库可见性后，仍须由签发方停用旧密钥。

撤销旧密钥后，逐项查找使用它的应用、部署流程和自动化任务。检查运行环境中的配置、仓库保存的密钥与变量、已安装的集成，以及代码、议题或拉取请求中的其他出现位置。只修改最初发现的那个文件，不能保证后台任务或其他环境已经改用新凭证。

为每个使用位置指定负责人，记录旧密钥是否已停用、新密钥是否已配置、服务是否恢复。签发替代密钥时，按实际用途收窄权限；若需要先以原有权限完成紧急切换，也应在恢复运行后安排权限调整。权限优化不能成为推迟停用旧密钥的理由。

更新配置后，运行受影响的关键调用或部署流程，查看认证错误、后台任务和告警。仓库当前版本也应移除硬编码密钥，改由受控的密钥存储或运行环境提供凭证。这能避免后续版本继续携带同一内容，却不会改变旧提交，也不会收回别人已经复制的密钥。

服务恢复后，从密钥首次可能暴露的时间起检查使用记录。先看签发方的访问或审计日志，再按密钥权限查看相关服务：是否出现异常时段、陌生来源、意外的API调用、资源修改或数据访问。检查范围应覆盖撤销前的暴露窗口，而非只看发现问题之后的请求。

若泄露的是GitHub访问令牌，可结合账号、组织或企业的安全与审计记录；第三方API密钥则应优先查看该签发方及相关服务的记录。日志能看到什么取决于服务和账号权限，必要时请有权限的管理员协助。没有发现异常，只能说明现有记录未显示异常，不能证明密钥从未被复制。

发现可疑调用时，保留时间、请求标识、涉及的资源和相关日志，按团队的事故响应流程调查。调查重点是凭证实际访问了什么、是否造成资源变更，以及是否还有其他有效凭证受到影响。仓库当前文件是否已经删除，无法回答这些问题。

撤销凭证、删除当前文件和改写历史各有作用：撤销使旧密钥失去访问能力；删除当前文件阻止它继续出现在新版本；改写历史则试图清除旧提交中的残留。若密钥已经失效，是否改写历史还要看残留内容、合规要求和团队协作成本，不能把强制推送当作止损的第一步。

确需清理时，先找出涉及的分支、标签和拉取请求，并与仓库管理员及协作者协调。GitHub的历史清理说明指出，改写会改变提交标识，可能影响签名、拉取请求和其他人的工作；即使强制推送，旧内容仍可能存在于分叉、克隆或相关引用中。协作者若把旧历史重新推回仓库，还可能使泄露内容再次出现。

复盘时记录泄露位置、密钥权限、撤销与切换时间、日志检查范围，以及仍需协调处理的副本。确认旧密钥失效、依赖服务恢复，并妥善处理发现的异常后，再关闭相应警报。随后检查密钥存储方式和推送保护设置，减少同类凭证再次进入仓库的机会。