2022年前后，丰田汽车公司接连爆出多起数据泄露事件，其中最让人注意的是因为一个安全漏洞而导致的客户个人信息暴露。这起事件的主角不是黑客攻破了丰田的防火墙，也不是某个员工的失误操作，而是丰田汽车的一个子公司和一个被人忽视的代码托管平台——GitHub。大家都知道GitHub是全球最大的源代码托管平台，开发者会把各种代码仓库放在上面进行版本管理和协作开发。很多人不知道的是，很多开发者在写代码的时候会不经意地把一些敏感信息直接写进了代码文件，比如数据库的连接地址、密码、API密钥、访问令牌等。在代码项目设为私有仓库的时候问题不大，但一旦这些密钥被误提交且仓库权限设置不当，就会导致严重的泄露问题。
丰田旗下的这家子公司的一个技术团队在开发内部应用时，把一套包含了数据库访问密钥的源代码提交到了GitHub公共仓库中——这个仓库原本应该被设置为私有的，但配置错误导致它是对公网开放的。也就是说，任何人在搜索引擎上搜索相关内容，或者对GitHub上相关的项目和文件名进行模糊匹配，都能找到这个代码仓库并查看到里面的内容。更有经验的安全研究者或者数据爬虫还会主动扫描GitHub上的公共仓库中是否存在硬编码的密钥和敏感信息。密钥的管理和存储是有通行标准的做法的——比如使用专门的密钥管理服务来存储和调用密码，代码中只引用环境变量而不写入明文字段。但这家子公司的团队的开发流程显然不够规范，他们直接把密钥写在了代码的配置文件中，而且提交到了公开仓库里。
泄露的数据包括什么？通过这把嵌入在代码中的数据库密钥，攻击者可以访问丰田子公司后台的客户信息数据库，从中提取出近三十万条客户个人数据记录，包含姓名、电话号码、电子邮箱地址、车辆识别代号、车辆购买和注册时间、金融贷款信息等大量个人敏感信息。更让人觉得后怕的是，这个密钥在代码仓库里躺了多久呢？安全研究人员在评估时推测，由于代码仓库的提交历史和时间戳可以被检查，这个配置错误和密钥暴露已经持续了大约五年。五年意味着在这段时间里，理论上任何经过此仓库的人——无论是开发者、研究人员还是黑客，都可能已经注意到了这个密钥的存在并利用它访问了客户数据库。
丰田汽车在被告知此事后立刻修复了漏洞，更改了数据库访问密钥。但同样的困境又出现了：你无法精确判断哪些数据被访问过、被下载过、被用来做过什么。五年内没有任何审计日志能告诉你这些信息的去向。丰田不得不向受影响的客户发出通知，并提供相应的服务支持。这对一家追求品质和可靠性的国际汽车巨头来说，是品牌信誉上的一道伤痕。
这起事件的泄密链条分析揭示了一个在开发运维领域非常常见的隐患。开发者在GitHub上托管代码时，没有意识到密钥和敏感配置信息绝对不能直接写在代码里并提交到远程仓库。即便提交到了远程仓库再后来删除了，Git版本控制系统中依然会永久保留这个文件的提交历史——换句话说，只要你把密钥曾经提交到过GitHub上并且仓库有任何人的访问权限，那这个密钥基本上就已经等于公开了。这就是为什么所有Git相关的安全通行实践都强调：不要在仓库里提交任何形式的密钥、密码、令牌、证书等敏感信息。应该使用环境变量或者云服务商提供的密钥管理服务来替代硬编码，而且不要在代码中留下任何可能暴露密钥的痕迹，即使是在自动构建的配置文件里也不行。在这个案例中，密钥的暴露持续了五年，没有人发现，没有人报告。GitHub公开代码仓库可能被爬虫抓取、可被搜索引擎收录，那条密钥就像在广场上贴了五年的告示一样。丰田的例子用近三十万份客户信息这个沉重的代价给我们上了一堂关于开发安全和密钥管理的课：永远不要相信"就放在代码里临时用一下"是安全的，任何密钥的安全程度都以它能被公网访问的时间为准。不管你的本职是什么，只要你写代码、管理代码，就必须把密钥和源代码看作两个完全独立的资产，用不同的策略管理它们。
