密钥进仓库是最常见的泄露方式，而且删掉提交也删不掉历史。四条规则：不进仓库、按用途分权、能过期、离职即撤。
代码托管平台上的安全事故，多数不是被攻破，而是密钥被提交进了仓库。这个错误很难完全避免，但可以把后果控制住。
规则一：密钥不进仓库
看起来是常识，实际每天都在发生。原因通常是本地测试时随手写了真密钥，提交时忘了改。
三个防线：
- `.gitignore` 里加 `.env`、`*.pem`、`credentials*` - 提交前用工具扫一遍敏感字符串（多数平台支持推送前检查，或装一个本地钩子） - 用示例文件代替真文件：仓库里放 `.env.example`，真值只在本地
规则二：删掉提交≠删掉密钥
这条最容易被误解。把密钥从文件里删掉再提交，历史提交里仍然能查到。
所以一旦密钥进过仓库，唯一正确的动作是：**立刻在服务方那边吊销并重新生成**。改代码只是止损的一半。
清理 git 历史（改写提交、强制推送）在团队仓库里风险很高，而且不能保证所有克隆都被清理。不要把它当作补救手段。
规则三：按用途分权
一个密钥干所有事，是最常见的省事做法，也是最危险的。
拆分方式：
- 读和写分开 - 按服务分开（部署用的、只读监控用的、CI 用的） - 按环境分开（测试环境密钥不能碰生产）
好处是泄露时影响范围有限，而且日志里能看出是哪个用途的密钥在异常调用。
规则四：能过期就设过期
长期有效的密钥等于长期有效的风险。设置有效期（比如 90 天），配合轮换流程，能把「一个泄露了三年没人发现」变成「最多三个月」。
轮换听着麻烦，实际做成自动的并不难：CI 里读密钥的地方统一走一个配置入口，换值时只改一处。
人员变动
有人离开时，要处理三件事：撤销个人访问令牌、把他从团队与仓库权限里移除、检查有没有以他个人名义创建的部署密钥或 Webhook。
第三项最容易漏。这类密钥不挂在账号权限上，人走了还能用。
泄露之后的第一小时
顺序很重要：先吊销，再排查调用日志，最后改代码。反过来做（先改代码后吊销），泄露窗口会被拉长。