Ship Safe：把 agent 时代的安全检查拉回本地仓库
AI coding tool 进入日常开发之后，安全检查的边界也跟着变了。
以前你担心的是 SQL injection、XSS、hardcoded token、GitHub Actions 里没 pin 的 action。现在还要多看一层：.mcp.json 会不会让 agent 自动启动不可信 server，Claude/Cursor 的规则文件里有没有 prompt injection，agent fix loop 会不会改动过多文件，RAG 文档、模型权重、npm lifecycle script 会不会变成新的供应链入口。
今天想记下的 asamassekou10/ship-safe，就是把这些“传统安全 + agent 安全 + AI 供应链”放进一个本地 CLI 的项目。它不是 SaaS-only scanner，也不是只做一个 checklist，而是可以直接在仓库里跑 npx ship-safe，输出 findings、修复建议、CI gate 和 SARIF。
按 GitHub repository API、repository page、README、Releases、Tags、commit history 和 LICENSE 在 2026-07-15 能核验的公开信息，asamassekou10/ship-safe 当前有 763 stars、83 forks。仓库主语言是 JavaScript，许可证是 MIT。仓库创建于 2026-02-02 08:19:37 UTC，最近公开 push 是 2026-07-15 08:52:07 UTC。默认分支 main 的最新提交是 858badb，提交时间 2026-07-15 08:51:57 UTC。GitHub Releases 当前最新版本是 v9.5.0，发布时间 2026-07-14 14:27:38 UTC；Tags 页也显示最新 tag 为 v9.5.0。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | asamassekou10/ship-safe |
| 定位 | 面向 AI-native 代码库的本地安全扫描 CLI |
| Stars | 763 |
| Forks | 83 |
| 主语言 | JavaScript |
| 许可证 | MIT |
| 仓库创建时间 | 2026-02-02 08:19:37 UTC |
| 最近 push | 2026-07-15 08:52:07 UTC |
| 最新 main 提交 | 858badb，2026-07-15 08:51:57 UTC |
| Latest GitHub release | v9.5.0，2026-07-14 14:27:38 UTC |
| 最新 tag | v9.5.0 |
| 核心入口 | npx ship-safe、npx ship-safe audit .、npx ship-safe agent .、npx ship-safe ci . --sarif results.sarif |
| 关键词 | security scanner、AI agents、MCP security、secrets、CI/CD、supply chain |
为什么这个方向值得看
安全扫描工具很多，但 Ship Safe 的有趣点不在“又扫一遍常见漏洞”，而在它把 AI 开发工具链也当成攻击面。
README 里列出的检查范围很宽：应用层漏洞、secrets、合规信息、依赖供应链、CI/CD 配置、MCP 和 agent config、prompt injection、agent hijacking、memory poisoning、RAG poisoning、unsafe tool calls。对一个正在把 coding agent 接进仓库的团队来说，这些东西确实已经不再是理论问题。
比如 agent 配置。一个仓库可能有 .cursorrules、CLAUDE.md、MCP server 配置、自动批准策略、hook、工具 allowlist。它们不一定会被传统 SAST 当成代码漏洞，但会影响 agent 能读什么、写什么、连什么服务、执行什么命令。Ship Safe 把这类文件纳入扫描，至少给了团队一个“把 agent 相关配置也放进 review”的入口。
再比如供应链。v9.5.0 release 里新增的方向包括模型权重风险、repo symlink 越界、slopsquatting、ClickFix lure、npm lifecycle worm 等。这里有些检测肯定会随着规则成熟度产生误报，但它抓住了一个真实变化：AI toolchain 让“开发时执行的东西”变多了，攻击面不只在生产环境。
用法是 CLI 优先
Ship Safe 的起手式很低：
npx ship-safe也可以直接跑完整审计：
npx ship-safe audit .如果要让它进入 CI，可以用：
npx ship-safe ci . --threshold 80 --sarif results.sarifREADME 还给了 agent 模式：生成修复计划、展示 diff、等待批准、验证结果，并提供 undo。这个设计比“自动修复所有问题”更稳一点，因为安全修复经常需要上下文判断。能生成建议是一回事，能不能接受那段 patch 是另一回事。
我更看重的是它把 REPL、audit、agent fix、CI gate 放在同一个 CLI 里。对小团队来说，很多安全工具的问题不是能力不够，而是太像另一个平台：要接账号、建项目、配 dashboard、再等报告。Ship Safe 的 open-source CLI 至少可以从本地命令开始，不需要先完成采购式流程。
MCP 和 agent 配置是它的差异点
Ship Safe README 里列了很多 agent。传统部分包括 injection、auth bypass、SSRF、config audit、PII、git history secrets、CI/CD scanner。更有区分度的是 AI/agent 部分：
MCPSecurityAgent看 MCP server misuse、tool poisoning、typosquatting、unvalidated inputs。AgenticSecurityAgent看 agent hijacking 和 privilege escalation。AgentConfigScanner看.cursorrules、CLAUDE.md、Claude Code hooks 里的 prompt injection。ManagedAgentScanner看 always_allow、unrestricted networking 这类托管 agent misconfig。TrustBoundaryAgent看 symlink 越出 repo、指向~/.ssh、~/.aws、.env这类 trust boundary 问题。
这些检查的共同点是：它们不像普通代码漏洞那样有多年成熟模式，但它们正好发生在现在的开发工作流里。一个 prompt 文件、一个 MCP 配置、一个 hook，可能不会进生产构建，却会影响 agent 在开发机上怎么行动。
这也是我觉得它适合写进 Gumi 的原因。它不是“AI 帮你写安全报告”这种泛化 wrapper，而是把 AI agent 工具链本身当成需要扫描的对象。
本地扫描和商业层的边界
README 写得很清楚：open-source CLI 是本地扫描、审计和 agent-assisted fixes 的入口；Pro/Team 层更多是 scan history、cloud dashboard、PDF report、shared workspace、PR Guardian、team report。
这个边界需要注意。你如果只想在私有仓库里跑一次本地检查，CLI 路线足够开始。但如果期待完整的团队安全平台，那它会引导你去商业 workflow。对开源项目来说，这不一定是坏事，只是采用前要知道哪些东西在开源 core，哪些在 hosted layer。
另一个现实点是误报。Ship Safe 的范围非常宽，从 SQL injection 到 AI Bill of Materials、从 secrets 到 fake CAPTCHA lure。覆盖面越宽，越需要团队自己调 threshold、ignore path、review finding。它适合作为早期安全信号，不应该被当成不加判断的最终结论。
适合什么场景
第一类场景，是已经在仓库里使用 Claude Code、Cursor、Codex、MCP server 或自定义 agent hooks 的团队。你需要知道这些 agent-facing 文件有没有把权限边界写得太宽。
第二类场景，是希望在 PR 或 release 前补一个本地 security gate 的小团队。npx ship-safe audit . 和 ship-safe ci 比接入一个完整平台更容易先试起来。
第三类场景，是 AI-native app。prompt、RAG、tool call、agent memory、model weights、MCP registry 这些东西已经进入仓库后，传统 lint/SAST 很难覆盖完整上下文。
第四类场景，是安全 review 前的快速预检。它不能替代人工 review，但可以把 secrets、危险配置、CI/CD 常见坑和 agent 配置风险先列出来。
需要注意的地方
第一，项目还很年轻。创建时间是 2026-02-02，虽然现在已有 763 stars、83 forks、342 commits 和 v9.5.0 release，但生态反馈仍然需要继续观察。
第二，README 和 release note 的覆盖范围很大。采用时最好先用默认扫描跑一遍，再逐步开启 CI threshold。不要第一天就把所有 finding 都当成必须阻断的 blocker。
第三，它的 AI/agent 安全规则会比传统漏洞扫描更依赖上下文。比如 prompt injection、agent hijacking、tool poisoning，有些判断需要结合团队实际使用方式。
第四，开源 CLI 和商业 workflow 有分层。团队如果介意 hosted dashboard 或报告能力是否开源，需要先确认自己的使用边界。
总结
Ship Safe 有意思的地方，是它把安全扫描的视角从“应用代码”扩到“开发时 agent 会接触的一整套材料”。
如果你的仓库已经开始出现 MCP 配置、agent rules、AI prompts、RAG 文档、模型依赖、自动修复脚本，那么只跑传统 lint 和 dependency audit 已经不够。asamassekou10/ship-safe 值得放进工具箱试一下：先从本地 npx ship-safe audit . 开始，看它能不能帮你把 agent 时代的新风险提前暴露出来。