AI写出来的仓库，上线前先查一遍密钥

上周组里一个学生拿 Claude 生成了一个标注小工具，能跑，也能连数据库。他推到 GitHub 后问我能不能放简历。我第一反应是密钥。很多 AI 生成的代码会把 API key、数据库密码直接写进 `config.py`。仓库一旦公开，等于把门钥匙贴在门上。

实验室经费紧张，我们没预算上完整 DevSecOps。但学生做个人 agent、demo 网站越来越多，靠人工看代码也不现实。Sentrint 这类工具就是干这个的。官方介绍里说它支持 Claude、Gemini 等 14 个 LLM 平台生成的项目，会读仓库代码，检查硬编码密钥、数据库访问等安全问题。这类工具的作用，就是给 AI 写出来的代码做一次上线前体检。

新手跑一遍，先建一个不重要的测试仓库，里面故意放一个假密钥，比如写死在 `config.py`。别拿生产系统。打开 Sentrint 首页，找到扫描仓库的入口，输入 GitHub 仓库地址，或授权它读取仓库。第一次授权尽量选只读权限。如果是私有仓库，确认授权范围只包含这一个项目，然后提交扫描。等待报告。小仓库通常很快出结果，取决于代码量和平台排队。报告里会列出风险项，比如某个文件出现密钥，某个数据库连接写了密码。打开具体文件，按行号定位，别只看摘要。把报告里的路径复制到编辑器里，确认是不是误报。修复后再扫一次。密钥要去对应平台重新生成，数据库配置改成从环境变量读取，别把明文密码提交进仓库。

术语用大白话讲，`repo` 是代码仓库，`hardcoded secrets` 是写死在代码里的密码或 API key，`database access` 是数据库连接配置。这些词听起来吓人，本质都是问代码里有没有把不该公开的东西公开了。

踩坑环节很实在。新手最容易犯三个错。扫描报告让 AI 自动修，AI 可能把密钥换成占位符，但占位符仍写在代码里，看起来干净了，实际没解决。只改本地文件，忘了仓库历史里已经有密钥。Git 会记录每一次提交，公开过就要当作已泄露处理。把 `.env` 文件提交了。这个文件常用来放本地配置，应该放在 `.gitignore` 里。

如果已经误提交，先把仓库改成私有，去平台撤销密钥，再清理本地和仓库历史。历史清理对新手有点门槛，可以找会 Git 的人帮忙，或者重新建一个干净仓库。这个方向好发论文吗，作为安全工程可以，但审稿人一定会问误报率和覆盖边界。工具能抓明文密钥，不代表能抓所有逻辑漏洞。

我拿一个标注脚本仓库试了一遍，它确实抓出了几个配置文件里的明文测试 key。对 CV 项目来说，这类小问题很常见，往往在 demo 阶段随手写进去。扫描结果不是最终裁决，但至少能把低级错误拦在展示前。

先用玩具仓库跑通，再把扫描接到每次提交前。学生项目可以先要求任何要公开的仓库，必须先过一遍密钥扫描，再提交简历或 Show HN。AI 写代码会越来越快，安全扫描也会变成 agent 提 PR 前的第一道门禁。

---

📌 本文编译自 Hacker News，原文：https://sentrint.com/

版权归原作者所有，本文为基于公开报道的编译与独立分析。