SAST工具专为AI代码设计：umbra静态扫描

你知道的每一款静态分析工具都有一个共同的隐性假设：在代码编写和代码合并之间，总会有人类在阅读。SAST 是第二双眼睛，它从来不是用来充当第一双的。

这个假设已经死了。大多数新代码现在是 AI 生成的，而且越来越大的比例在发布时没有任何人阅读。每一款安全工具都隐式依赖的审查环节根本不存在。

2026 年的泄露动态就是实际的例证：那些拥有漂亮 UI 的应用完全没有行级安全控制，服务角色密钥被发送到浏览器，API 路由没有任何身份验证。这不是稀奇古怪的漏洞；而是工业规模的经典漏洞，因为生成器只优化"演示能跑"，下游没有任何机制追问"这样安全吗？"

面向这个世界的扫描器必须有何不同

当我开始构建 Umbra 时，我以为我是在编写更好的规则。结果证明规则是最简单的部分。真正有意思的差异：

1. 它必须验证，而不是模式匹配。"应用能构建"和"测试能通过"是 AI 仓库经常声称但又经常违反的声明。所以 Umbra 把仓库复制到一个锁定的 Docker 容器中（无网络、硬限制），构建它、启动它、通过 HTTP 探测它，并将记录的声明与实际发生的行为进行比对。没有证据的发现是扫描器失去信任的原因；没有验证的声明是仓库失去信任的原因。

2. 它必须是确定性的。如果分数在运行之间波动，没人会把它放进 CI。同一个仓库、同一个评分版本、同一个分数。低置信度的启发式方法永远不会改变分数；它们进入备注部分。一个发出假警报的安全工具会被卸载，所以对我们来说假阳性报告是一级严重性 bug。

3. 它必须活在 Agent 所在的地方。事后运行的扫描器只能捕捉上周的错误。所以 Umbra 也以内联方式运行：PreToolUse hooks（Claude Code、Kimi Code）在 Agent 写入文件之前审查每个文件，以及一个供调用工具的 Agent 使用的 MCP server。一个试图将真实密钥写入 .env 的 Agent 会被阻断写入，并收到反馈的原因，这样它就能修复根本原因而不是泄露密钥。（人们常搞错的一个细节：Agent 不通过 MCP 写文件，所以 MCP 代理无法拦截写入。Hooks 可以。MCP server 是自愿层；hooks 是免疫系统。）

4. 它必须尊重人类的注意力。一个分数、五个有 file:line 证据的发现、声明的收据。不是 400 行的 SARIF 转储。输出设计成可以截图阅读的，因为决定是否信任这个工具的人只会给它大约四秒钟。

所有这些汇总成一个数字 0-100，跨越四个维度：SAFE、RUNS、HONEST、CLEAN。评分规则是版本化的且公开的。如果仓库被发现对测试撒谎，无论其他方面多干净，分数都不会及格。

cd your-project
npx umbra-scan          # fast static scan
npx umbra-scan --deep   # + sandbox verification (needs Docker)

MIT 许可，完全本地化，离线运行。如果它值得，请给个星：https://github.com/elberacasa/umbra