北京
有个开发者在过去几个月扫描了300个代码仓库，发现其中超过三分之二硬编码了密钥。不是遗留项目，是上周甚至昨天刚写的代码。写这些代码的人不是新手——他们知道该怎么做对，但代码不是他们写的。
是AI写的。
200个仓库的相同"指纹"
扫描者看到的重复模式几乎一模一样：JWT密钥以明文形式躺在源文件里，前面往往带着一行注释// Generated by Cursor。数据库连接串里嵌着密码、Stripe支付密钥、OpenAI接口凭证、AWS访问密钥——全都在源码里，全都被提交到了版本控制。
用Gitleaks扫一遍，2秒内全部现形。
问题的根源在于训练数据。AI代码生成器学的是海量公开代码，其中很大一部分是教程、博客示例、Stack Overflow回答。演示代码为了可读性，几乎清一色硬编码值。模型学到的就是这个模式：const SECRET = 'some-string'。它不是偷懒，是真觉得就该这么写。
更麻烦的是，AI工具的核心优化目标是"快速产出能跑的代码"。硬编码密钥确实能跑，测试能过，直到出大事之前都不会报错。
Cursor、Claude Code、Copilot，各家都中招，只是频率不同。没有一家能可靠地自我拦截。
两秒钟的防线
正确的写法并不复杂：从环境变量读取，提交前检查是否存在，不存在就抛错。把.env写进.gitignore。完事。
但人在提交前拦截，比事后修补更靠谱。Gitleaks的pre-commit hook能在2秒内拦住硬编码密钥，让它永远进不了仓库。对整个项目扫描也只要一条命令。
这个发现最讽刺的地方在于：用AI写代码的人，往往是最信任AI输出的人。他们扫一眼，看到能跑，就提交了。安全审查的环节，被"AI不会犯低级错误"的错觉悄悄替换了。
你最近用Cursor或Copilot生成的代码，最后一次检查密钥管理是什么时候？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
