\\n'}\"\nbody=\"${response%
\\n'*}\"\n\ncase \"$status\" in\n 200)\n login=\"$(jq -r '.login // empty' <<< \"$body\")\"\n echo \"token appears active for GitHub user: $login\"\n ;;\n 401)\n echo \"token appears invalid or revoked\"\n ;;\n 403|429)\n echo \"unable to determine validity; rate-limited or blocked\"\n ;;\n *)\n echo \"unable to determine validity: HTTP $status\"\n ;;\nesac\n```\n\n记住,我们的目标是最小化问题集:**这个 credential 还能用吗?谁需要知道这件事?**\n\n对于模棱两可的响应(比如被限速或返回 403),我们直接标记为“无法判断”,不做进一步猜测。我们也避免对仓库、organization 或其他私有资源进行后续请求。\n\n这需要和法律与隐私团队紧密合作。**即使是“只读”的有效性检查,当你操作一个不属于你的 credential 时,也可能带来合规风险。**\n\n在我们手动处理这些告警的过程中,产品团队也在同步开发原生的有效性检查功能。等他们做出来后,剩下的工作就快多了。现在,有效性检查已经是 GitHub secret scanning 的内置功能了。\n\n### 阶段四:搞清楚谁该负责\n\n跨团队协作暴露了另一个问题:**即使我们知道一个 credential 还在用,我们仍然得找到谁能轮换它**。\n\n这听起来很简单,但在一个拥有 15000+ 仓库、上千名工程师的公司里,你根本不知道某个 token 是哪个团队、哪个项目、哪个人的。有些 secrets 可能已经存在好几年了,原来的 owner 可能早就离职了。\n\n我们和客户支持、安全事件响应、bug 赏金计划团队合作,为代码之外的 secrets 制定了共享 playbook。比如,当客户支持在工单里发现一个 token 时,他们知道该走什么流程:先标记,然后通知安全团队,安全团队再去找对应的产品团队。\n\n这个过程中,我们还得确保不引入新的风险。比如,你不能在 playbook 里写“把这个 secret 贴到 Slack 频道里”,因为那本身就是一种泄露。\n\n## 最后:九个月,从 20000 到 0\n\n整个项目花了九个月时间,从发现 20000+ 个 secrets 到最终实现零未处理告警。这个过程中,我们学到的最重要的几件事是:\n\n1. **先停止新增,再清理存量**。没有 push protection,你永远追不上。\n2. **噪音和真正的风险是两回事**。花时间搞清楚哪些告警是测试数据,哪些是真问题,能省下大量时间。\n3. **Secrets 无处不在**。代码、issue、wiki、工单、bug 报告……任何地方都可能藏着 secrets。你需要跨团队的合作。\n4. **不要轻易删除仓库**。审计轨迹比你想的更重要。\n5. **有效性检查是关键**。不知道一个 credential 是否还在用,你就没法排优先级。\n6. **ownership 是最大的坑**。技术问题好解决,但“这个 token 归谁管”这种问题往往最难。\n\n现在,这些经验已经被融入到 GitHub secret scanning 的产品设计中。如果你刚接触 secret scanning,希望这篇文章能帮你少走一些我们走过的弯路。","is_owner":false,"date":"2026/7/2","category":"网络安全"}