0sec开源本地AI安全工具0

0sec Labs 开源的 0，想把漏洞调查、代码审查、渗透测试、逆向分析和修复生成接到同一套工作流里。它不是新模型，而是让开发者自带模型、通过浏览器、CLI 或 MCP 调用的安全工具编排层。

对前端和全栈开发者，值得看的不是「AI 又能挖漏洞了」，而是它如何要求发现附带证据、再安排独立复验。原文最亮眼的 97.9% 成绩也有明确条件，不能直接理解成一次扫描就有这么高的成功率。

它把安全工具串起来，模型要自己接

来自苏黎世、获 Y Combinator 支持的 0sec Labs，将 0 定义为围绕大模型和安全工具的控制平面。大白话解释：模型负责提出调查方向，框架负责组织执行、保存证据和输出结果，目标应限定在获得授权的范围内。

0 采用 MIT OR Apache-2.0 双许可证，目前是 research preview。本地支持 Apple Silicon macOS，以及 x64、ARM64 Linux，也可以使用 ghcr.io/0sec-labs/0 容器。不需要本地 GPU，因为模型推理发生在供应商侧。

原文称安装只需一个脚本，但没有给出脚本内容。运行 0 会打开无需账户的本地浏览器控制台，里面有聊天、发现队列与看板、工作流模板、skills 和 memory。命令行通过 0 workflow run 执行工作流，通过 0 runs list 查看运行记录；编程智能体则可以通过 0 mcp-server --workflows 接入。

模型接入采用自带供应商的方式，页面列出 14 家提供商，其中包括 OpenAI、Anthropic、DeepSeek、OpenRouter、Azure、Qwen、Kimi、GLM 和 Grok，另外支持 Claude、Codex、Gemini CLI runtimes。开源框架免费，模型调用仍需付费。托管版 0cloud 尚在候补名单阶段，定价页列出 $100 试用额度和每次 PR 安全测试 $5。

为什么它强调先复现，再相信

0 的架构原则是「先复现，再相信」。这比让模型直接写一份漏洞报告更关键：看起来危险的代码，不一定构成能触发、能造成影响的漏洞。

它把调查拆成几个环节。研究智能体先规划漏洞类别、发现端点、测试攻击假设；分诊阶段过滤薄弱发现并检查证据完整性；随后由独立会话重新验证每个候选发现，每项分配 5 轮交互。最终可导出 HTML、PDF、SARIF、Markdown 和 JSON。

发现可疑点只是起点，能复现并证明影响才更接近有效结论。

证据等级也沿着这条线推进，从 candidate 到 impact-proven，分别对应候选发现和已证明影响的发现。不过，原文没有展开每一级的判定标准。

Web 渗透测试采用 shell-first：智能体通过 bash 使用 curl、python3、sqlmap，而不是局限于固定的 HTTP 工具集。这样能自由组合命令，代价是运行环境、权限和执行过程更需要团队管理。

编译产物则交给仓库内独立引擎 0verse。它封装 Ghidra、angr 和 AFL++，本地 MCP server 暴露 9 个工具，覆盖扫描、分诊、PoV 和报告。PoV 可以理解为证明漏洞可触发的验证样例。它的覆盖面因此延伸到了二进制和内核，而不仅是 Web 接口。

97.9% 的成绩，究竟测了什么

原文明确说明，以下成绩全部由团队自行报告。

XBOW Web CTF 最亮眼的一组是 93/95，即 97.9%，使用 gpt-5.4，统计方式为 any-success：保留结果里有成功就计入。它不是 pass@1，也就是不能代表第一次尝试的成功率。

换个统计口径，结果就不同：白盒条件下，保留产物的成功并集是 102/104；黑盒条件下是 81/104，即 77.9%。这些结果不能相加。另一次 2026 年的冷启动运行只有 45/104，即 43.3%。原文没有完整解释这些运行之间的配置差异，因此也不能只凭分差判断是哪项能力造成的。

另外两组数据同样带着前提：

• Cybench 得分为 36/40，即 90.0%，使用 Azure gpt-5.4，允许 3 次重试。
• 对 81 个 npm 包的审计，F1 为 0.973，TPR 为 100%，FPR 为 0.11，但评测基准答案由团队自行构建。

记录中的 XBOW 成本约为每道解出的题 $5.20。这个数字适合了解实验量级，不能直接当成企业项目每次扫描的预算。

真实项目记录提供了另一类证据：研究页列出 30+ 个已合入修复的 Linux kernel 零日漏洞，涉及 Bluetooth、NFC、mac802154、TIPC 和 mlx5e；库级 CVE 则包括 jsonata、node-forge、protobuf.js 和 Wireshark。上游接受修复能支持其实际研究能力，但无法单独证明日常扫描的误报率和覆盖率。

我的判断

我认可它把独立复验和证据分级放进流程。对使用 AI 审查代码的团队，这比多生成几条风险描述更有价值。需要打问号的是，原文没有提供同条件对照实验，无法证明 0 比其他工具更准、更便宜。

原文列出的替代工具各有取舍：Shannon 使用 AGPL-3.0，侧重需要源码的 Web 应用和 API，依赖 Docker、Node.js 18+；Strix 使用 Apache-2.0，依赖 Docker；CAI 使用 MIT 加专有研究用途许可，推荐 Python 3.12，并于 2026 年 8 月 28 日归档。这些是原文给出的状态，不宜当成永久结论。

0 的差异在于浏览器、CLI、MCP 三种入口，以及从 Web 到二进制、内核的较广覆盖。广度适合探索，却不自动等于每个方向都成熟。它仍是研究预览，不能仅凭 CTF 成绩就替代已有的依赖检查、代码审查和人工安全验证。

能拿来做什么

• 在获得授权的 Node 或全栈测试项目中，挑一个已知漏洞验证完整流程，检查报告是否给出触发条件、复现步骤和影响证据，再考虑扩大使用范围。
• 给现有编程智能体接入 0 mcp-server --workflows 时，先让它处理范围明确的审查任务，并人工复核关键发现；原文没有给出足以支持无人值守上线的可靠性数据。
• 评估 npm 审计能力时，用团队已经确认的漏洞与误报样本做对照，同时记录模型配置、重试次数和费用，避免直接套用自建基准上的 F1 0.973。