Marico's space

我用自己做的安全审计工具扫了自己的代码库，结果社死了

服务器技术 2026-04-20 20:58:51 3

说出来你可能不信——我给自己写的安全审计工具 VibeScan 花了 $49，结果扫出来的第一个 bug，就是我自己埋进去的。

我写了个 LLM 驱动的安全审计工具，面向那些用 Lovable、Bolt、v0、Cursor 快速交付的创始人——就是那种"先跑起来再说"的节奏。技术栈是 Python + Claude Agent 编排层，听起来挺正经的对吧？

然后我就想，干脆用它扫扫自己的代码库得了，自己先当小白鼠。结果一跑出来，两个 HIGH 级别问题，其中一个——已经合并到 main 分支了。

第一个问题是真实的线上泄漏。我的 Apify API token 是这样传的：

?token=xxx

对，就是 URL query parameter。学过安全的人看到这里应该已经开始皱眉了。URL 会经过哪里？HTTP server logs、proxy logs、error stack traces——任何地方都有可能。

任何看到这些日志的人，都能拿着这个 token 去跑付费 actor，合法地烧我的预算。我真金白银往外流，就因为当初随手一写。

修复方案很简单：把 token 放到 Authorization: Bearer header 里。但问题是我当初为什么写成那样？说实话，Apify quickstart 文档第一个示例就是这个，我在"让 API 跑起来"的目标下直接复制粘贴，测试通过了，就继续了。

经典的 velocity-over-security，是吧。

这个问题倒是已经缓解了。Gmail OAuth refresh token 存在 repo 的 credentials/ 目录，文件本身有 .gitignore 保护，而且 repo 是私有的。威胁等级确实比较低。

但长期来看，还是得迁移到 OS keychain。这事我早就知道，就是一直没动。

我反思了一下，这个问题其实很普遍。不是因为我不懂安全，是因为：

velocity-over-security，在创业场景下几乎是无解的。文档默认推荐的方式往往不是最安全的方式——因为最安全的方式往往更复杂、更慢。

每个非平凡的代码库都有安全债务。问题从来不是"有没有"，而是"你知不知道在哪里、有没有优先处理真正重要的"。

工具扫出来了两个 HIGH，我修了一个，另一个计划迁移到 keychain。听起来还不错对吧？但细想一下——

如果不是我自己做了这个工具，这个 token 泄漏的问题可能会在生产环境里躺多久？

可能永远不会被发现。

所以你看，做安全审计工具的人自己都有安全债务，这个事实本身就挺讽刺的。但也说明一件事：每个代码库都值得扫一次，说不定你对自己的代码的信任，比你对陌生代码的信任高太多了。