2026 年 11 月 6 日，我的开源项目 go-tour-i18n 收到了一封来自 GitHub 的安全提醒邮件。
邮件标题是：
[shuijingwan/go-tour-i18n] Possible valid secrets detected
GitHub 提示，仓库中可能包含一个已经公开的 Google API Key，建议尽快检查并处理。
对于一个持续开发中的开源项目而言，这样的提醒值得重视。不过，看到密钥泄露告警，并不意味着必须立即删除代码、撤销密钥，或者启动一次复杂的安全修复。
这次经历让我重新思考了一个问题：当安全扫描工具发现疑似敏感信息时，我们应该如何判断它是否真的需要修复？
一、GitHub 检测到了什么？
邮件显示，GitHub 在我的仓库中检测到了一个 Google API Key，涉及文件：
_content/js/hats.js
关联提交为 a42a5e2d。
进入 GitHub 仓库的 Security and quality → Secret scanning 页面后，可以看到详细告警。
告警包含以下信息：
| 项目 | 检测结果 |
|---|---|
| Secret type | Google API Key |
| Alert | Google API Key #1 |
| Validity | Unknown |
| 状态 | Open |
| 检测位置 | 2 处 |
| 涉及文件 | _content/js/hats.js、_content/doc/hats.js |
其中，最值得注意的是 Validity: Unknown。
它意味着 GitHub 没有给出该密钥有效或无效的明确结论。
因此，不能因为收到警告就认定密钥一定仍然有效，也不能因为状态是 Unknown 就认为它已经失效。
此外，GitHub 还列出了其他公开仓库引用相同密钥的记录。
这提示我：该密钥可能来自某个公共上游项目，而不是专门为我的仓库创建的。
二、追踪代码来源：原来是 Go 官方上游文件
我的 go-tour-i18n 项目需要维护 Go 学习资料及文档的多语言版本，其中有一部分源代码来自 Go 官方项目。
因此，我首先检查了告警文件的来源。
经过对比，发现以下两个文件完全一致：
- 我的仓库：
shuijingwan/go-tour-i18n中的_content/js/hats.js - Go 官方上游：
golang/website中的_content/js/hats.js
两个文件的 Git Blob SHA 均为：
ec6b6fda18b72c3edea99b636034f4c04ed9dd2a
这说明，对比时两份文件具有完全相同的内容。
进一步查看代码，可以发现这段 JavaScript 调用了 Google 的反馈服务：
window.help.service.Lazy.create(...)
并通过 apiKey 参数传递一个 Google API Key。
它属于 Google HaTS（Happiness Tracking Surveys）用户反馈和问卷功能的集成代码。
这与我最初担心的情况明显不同。
该密钥并不是我在翻译项目中自行创建、配置并意外提交的 API Key，而是随 Go 官方上游代码进入了仓库。
这并不能自动证明密钥安全，但足以改变后续处理方向。
三、上游公开的 API Key，就一定安全吗？
不能这样判断。
API Key 是否安全，取决于多个因素，包括：
- 密钥是否仍然有效；
- 是否设置了网站、IP 地址等应用限制；
- 是否限制了可调用的 Google API；
- 是否存在未经授权的使用；
- 谁拥有管理和撤销该密钥的权限。
Google Cloud 官方文档也强调，应当限制 API Key 的使用范围，避免未经授权的访问及潜在费用风险。
因此，不能简单地认为：既然 Go 官方仓库也公开了这个密钥，那么它就一定没有风险。
但另一方面，GitHub 的安全扫描工具主要告诉我：代码中存在符合敏感凭据特征的内容。
它并没有直接证明：
- 该密钥属于我的 Google Cloud 项目；
- 该密钥正在遭到滥用；
- 我的翻译项目因此发生了安全入侵；
- 我具备撤销或轮换这个上游密钥的管理权限。
对于这些尚未被证实的情况，不应该直接作出结论。
四、为什么选择 Won’t fix？
确认密钥来源后，我开始考虑应该如何处理这条 GitHub 告警。
GitHub 提供了多个关闭原因：
Revoked：密钥已经撤销。Used in tests：密钥用于测试。False positive：误报。Won't fix：不进行修复。
经过分析，我最终选择了 Won't fix。
理由主要有三个。
第一，这不是本项目自行管理的凭据。
目前已经确认，被检测到的 JavaScript 文件来自 Go 官方上游，而不是我自行编写的敏感配置文件。
我没有证据表明自己是这个 Google API Key 的管理者。
第二，不能错误地声明密钥已经撤销。
告警中显示的有效性是 Unknown。
既然没有证据证明密钥已被撤销，就不应该选择 Revoked。
同样，代码中确实存在符合 Google API Key 特征的字符串，因此也不适合在没有更多证据的情况下直接认定为 False positive。
第三，没有必要为了关闭告警而立即修改上游代码。
如果直接删除或修改相关 JavaScript，可能改变原有功能。
对于一个正在推进多语言网站上线的项目而言，我更希望将精力集中在真正影响正确性、安全性和上线进度的问题上。
因此，在没有发现额外异常证据的情况下，保留现有代码、记录来源并关闭告警，是我这次选择的处理方式。
这里的 Won't fix 并不意味着密钥绝对安全，而是表示：针对当前仓库的这条告警，我没有采取代码修复措施。
五、保留中文说明，让处理过程可以追溯
选择 Won't fix 后，我没有直接关闭弹窗，而是填写了中文说明。
主要记录了以下事实：
该 Google API Key 继承自 Go 官方上游仓库 golang/website，用于 Google HaTS 用户反馈与问卷功能，并非本项目自行创建或管理的凭据。
已核实 _content/js/hats.js 与上游文件内容完全一致。当前密钥有效性为 Unknown，未发现本项目自身凭据泄露的证据。
因此，本项目不单独修改或撤销该密钥，以 Won’t fix 关闭此告警。
点击 Close alert 后，GitHub 将告警状态更新为 Dismissed。
此时，告警页面中仍然可以看到原始检测信息，以及关闭原因和处理说明。
这一点很重要。
因为关闭告警并不等于密钥已经失效，也不代表安全问题在技术层面得到了修复。
它只是记录了项目维护者对当前告警作出的处置决定。
如果后续发现密钥被滥用，或者出现新的安全证据，仍然可以重新评估。
六、这次经历带来的几点思考
这次事件没有演变成一次复杂的代码修改，也没有消耗额外的 Codex 工程开发额度。
但它仍然让我得到了一些有价值的经验。
1. 安全告警需要认真对待，但不应该机械执行
安全工具能够帮助开发者发现问题，但具体如何处理，仍然需要结合项目实际情况判断。
尤其对于包含大量上游代码的开源项目，代码来源往往是分析的重要依据。
2. 继承上游代码，也会继承上游代码中的安全告警
即使没有修改过某个文件，只要它存在于自己的仓库中，就可能触发 GitHub 的安全扫描。
因此，不能将所有告警都视为自己新增代码造成的问题。
但同样不能因为代码来自上游，就完全忽略其风险。
3. 不修复也是一种需要解释的决策
在软件维护中，Won't fix 并不一定意味着不重视问题。
如果能够明确说明事实、风险边界以及不修改的原因，那么它可以是一种有记录、可追溯的维护决策。
关键在于不能用它掩盖真实的安全漏洞。
4. 避免让每个告警都变成工程任务
当前，我正在推进 Go 学习与文档多语言项目的 Site v2 上线工作。
项目中的翻译质量审核、内容快照、集成验证和正式上线，都需要投入不少时间。
如果每次遇到告警，都立即启动代码修改、扩大排查范围，甚至重构相关模块，很容易让维护工作偏离主要目标。
我的原则是：真正涉及密钥泄露、未经授权访问、数据安全或生产环境正确性的问题，必须认真修复；对于已经查明来源、没有发现当前项目额外风险证据的告警，可以根据实际情况决定是否需要修改。
七、总结
这次 GitHub Google API Key 告警，最终以 Won't fix 关闭。
整个处理过程没有修改仓库代码，也没有撤销任何密钥。
我完成的工作主要是核实告警内容、追踪上游来源、对比文件哈希，并在 GitHub 中记录关闭依据。
这并不是一次证明密钥绝对安全的调查，而是一次对当前告警进行有限、明确且可追溯处置的实践。
安全工具负责发现值得关注的信号，开发者则需要结合证据判断真正的风险，以及应该采取什么行动。
对于独立维护的开源项目而言，这种判断能力，与编写代码和修复漏洞同样重要。
相关链接
- 我的 Go 多语言项目 go-tour-i18n
- Go 官方 website 仓库
- GitHub 官方文档：Resolving alerts from secret scanning
- Google Cloud 官方文档：Best practices for managing API keys
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。