AmirHosein-Lotfi/Seaworthy

2026年1月28日，一款名为 Moltbook 的社交应用上线了。它的创始人告诉大家，他自己没有写过哪怕一行代码：整个项目都是通过 prompt 生成出来的。三天后，有人发现它的数据库门户大开。150 万个 API token、3.5 万个电子邮件地址、明文密码，全部暴露在一个每个浏览器都会自带的 key 背后，而且这是设计使然。根本没有人开启那个能阻止该 key 成为万能密码的唯一设置。 几个月后，Lovable（一家恰好从事该业务、估值达 66 亿美元的公司）将客户的源代码和数据库凭证暴露了整整 **48 天**，原因仅仅是一个 API 路由检查了你是否已登录，却从未检查你是不是*正确的*已登录用户。 两个不同的团队，两款不同的产品，却犯了同样低级的错误，只是披着不同的外衣。这种事之所以不断发生，是因为发布这些应用的人是让 AI 帮他们构建的，他们完全不需要知道“row-level security”是什么意思，也不需要明白“已登录”和“有权限做这件事”是两个截然不同的问题。市场上的每一个安全工具都是为那些已经懂这些的工程师编写的。而这款工具不是。 ## 适用人群 如果你主要是通过与 AI 助手对话，用“凭感觉写”（vibe-coded）的方式做了一些东西（一个 SaaS、一个工具、一个业余项目）。你正准备运行 `vercel deploy` 或推送到 `main` 分支，你隐隐觉得自己应该先检查点什么，但你又不知道这个“点什么”到底是什么。这就是本工具的全部受众。如果你本身就是靠做安全审查为生的，那你不需要这个工具。你只需要查看 [检查目录](skills/seaworthy/reference/checks-catalog.md) 获取 regex 匹配模式，花五分钟就能看完了。 ## 实际功能 它会读取你的代码。它绝不运行代码，也不碰网络，而是专门寻找那少数几个确实在应用上线几天内就能搞垮它们的错误： - 直接在文件中写入了真实的 API key 或密码，或者提交了 `.env` 文件后又被“删除”了（它仍然留在你的 git 历史记录中） - 一个没有 row-level security 的 Supabase 数据表，而且可以通过你的浏览器已有的 key 访问 - 你的数据库 master key（那个无视所有权限规则的 key），居然放在了浏览器可以加载的某个地方 - 一个更新或删除内容的 endpoint，却没有检查调用者是否有权限对其进行操作 - 完全开放的 CORS *并且*接受 cookies，这比仅仅完全开放 CORS 的问题更严重 - 在本应是 production build 的版本中，Debug 模式却悄悄开着 - 一个任何人只要猜对 URL 就能访问的 `/admin` 路由 - 一个互联网上任何人都可以往里面写文件的 storage bucket 然后，它会通过以下三种方式之一告诉你： ``` ✅ SAFE TO SHIP ⚠️ SHIP WITH CAUTION — 2 issues to fix first 🛑 DO NOT DEPLOY — 1 critical issue found ``` 每个问题都会给出确切的文件名和行号、如果你无视它攻击者实际上能获得什么，以及修复它到底需要多长时间。它省去了大多数扫描仪那些废话和“请咨询安全专业人士”的推托之词。 ## 帮助场景 就在你每次部署之前，就像你把车开出停车位前会看一眼后视镜一样。在你的项目中打开终端并输入： ``` npx skills add AmirHosein-Lotfi/seaworthy@seaworthy ``` 这会将其作为 Claude Code Skill 安装。从现在起，只需问“这可以安全部署吗？”或“我能把这个推送到 prod 环境吗？”或者干脆什么都别问。它的设计初衷就是在任何类似于部署的操作发生之前主动介入。关于真实扫描实际会打印出什么，请查看 [examples/sample-output-blocked.md](examples/sample-output-blocked.md) 和 [examples/sample-output-safe.md](examples/sample-output-safe.md)。 ## 它不会做什么 它不是渗透测试，它抓不到有漏洞的 npm 包、与上述模式相差好几个步骤的业务逻辑漏洞，或者任何需要观察你的应用运行才能发现的问题。它只是那种五秒钟的直觉检查，本来可以阻止两次非常真实、完全可以避免的数据泄露事件，仅此而已，它在每份报告的底部都会大声声明这一点。 完整的细分说明（每一项检查、其严重程度，以及如果你不想信任脚本而想手动运行的确切命令）位于 [reference/checks-catalog.md](skills/seaworthy/reference/checks-catalog.md) 中。 ## 构建方式 检测本身是由几个小巧、枯燥的 shell 脚本（`skills/seaworthy/scripts/detectors/`）完成的，每个脚本只负责寻找一类问题，并为每个发现打印一行 JSON。没有 ripgrep，没有 `jq`，除了 `git` 和每台机器上都有的工具外，什么都不需要，这也是为什么这东西能在几秒钟内运行完毕的原因。判断决策（这到底是一个真实的 key 还是一个占位符，这个 auth 检查会不会是以前没人见过的自定义封装）发生在更上一层，而不是埋没在 regex 中。[reference/false-positive-rules.md](skills/seaworthy/reference/false-positive-rules.md) 记录了每一个此类决策，因为一个安全工具只要错一次，在第二次运行时就会失去信任。 四个测试夹具为其提供了支持：两个故意留下漏洞的（一个重现了 Moltbook 的 bug，一个重现了 Lovable 的 bug），一个包含各种小问题的，还有一个干净的应用，要求返回的结果必须是零发现。你可以自己运行它们： ``` bash tests/run-fixture-tests.sh ``` ## 适用技术栈 首要支持 Next.js 和 Supabase，因为它们正是上述两起事件背后的技术栈，此外还支持通用的 Node/Express。Firebase 和 Django/Flask 已经有了初步支持，但被刻意标记为实验性：在通过与其它部分相同的测试夹具流程验证之前，它们的可信度较低。Rails、Laravel、移动端应用或任何你正在运行的技术栈，[CONTRIBUTING.md](CONTRIBUTING.md) 准确说明了添加一个新的 detector 需要什么条件，这比你想象的 PR 要小得多。 ## 许可证 MIT。随便用，随便 fork，随便塞进你卖的东西里发布。详见 [LICENSE](LICENSE)。

标签：AI辅助开发, Cutter, DevSecOps, MITM代理, 上游代理, 代码安全审计, 静态应用安全测试