0sec-labs/0 开源 AI 安全 harness 上手：用本地引擎与 CLI/MCP 在隔离仓库做授权代码分析与漏洞复核

如果一个团队已经在用大模型做代码审计，痛点往往不在模型本身，而在流程：候选漏洞、复现证据、修复建议散落在脚本、终端历史和聊天记录里，没人说得清哪一条是经过验证的。0sec Labs 开源的 0 就是冲这个问题来的——它把自己定位成一层编排（harness），把漏洞调查、代码审查、渗透测试、逆向分析和修复生成串进同一条流水线，对外提供本地 Web 控制台、CLI 和供 agent 调用的 MCP 服务端三种入口。它本身不是模型：模型由你自带，资料中列出约 14 家提供方（包括 OpenAI、Anthropic、DeepSeek、OpenRouter、Azure、Qwen、Kimi、GLM、Grok 等），也可以对接 Claude、Codex、Gemini CLI 这类运行时。项目由总部在苏黎世的 0sec Labs 发布，以 MIT OR Apache-2.0 双许可开源，目前状态是研究预览（research preview）。

它替你解决什么问题，适合谁用

0 的定位是控制层，不是扫描器集合。资料描述的流水线遵循“先复现，再相信”（reproduce before believing）的原则：先规划，再做发现与攻击尝试，然后进行证据分诊，最后交给一个独立会话逐条验证（每个候选项约 5 轮），通过后才产出 HTML、PDF、SARIF、Markdown、JSON 等格式的报告。这个顺序对安全评审很关键——它把“模型说这里有问题”和“这条问题被独立复核过”区分开来。

适合的读者是三类人：

• 需要在隔离仓库里做授权代码审计、想减少人工翻找成本的安全工程师；
• 想把静态分析结果和人工复核串起来的开发者；
• 已经在自己搭 agent 工作流、希望复用一套现成安全流程的运维与平台人员。

不适合把它当成“自动出漏洞报告”的黑盒。它输出的是线索和证据链草稿，不是结论。

准备条件与授权边界

资料给出的运行条件比较宽松：macOS Apple Silicon、linux x64 或 ARM64，或容器方式运行，不需要 GPU。本地使用不需要云账号；托管的 0cloud 版本目前需要排队（waitlist）。这一点决定了大多数团队应该先从本地入口起步。

在动手之前把边界定死，比装好工具更重要：

1. 目标范围：只对自有或已获得书面授权的代码库运行，优先使用专门的隔离仓库或本地靶场，不要直接指向生产主机上的在线服务。
2. 快照：对工作区所在目录做一次可回滚的快照或 git 提交，确认能一键还原。
3. 凭证：只给模型服务侧的 API key 和只读凭据；把生产环境密钥、长期令牌从运行环境里移除，用最小权限的临时凭证替代。
4. 脱敏：私有代码外发前先确认合规要求，必要时替换内部域名、账号、连接串再纳入工作区。

最小可运行路径

安装与首启

安装方式以仓库 README 的当前说明为准——项目处于研究预览阶段，包管理器命令和依赖会随版本调整，本文不替你臆造具体安装指令。可以在 GitHub 搜索 0sec-labs/0 找到仓库，先读 README 的安装段落和 release 说明，确认与你所在平台的架构匹配（Apple Silicon 与 linux x64/ARM64 的产物不同，容器镜像同理）。

首次启动后建议先在一个只含少量文件的小型仓库上跑通全流程，而不是直接扔进几百 MB 的代码库。小仓库能让你在一轮内看清它读了哪些文件、产出了哪几类报告。

用 CLI 跑一次代码分析

无界面 CLI 是排查问题的首选形态：输出直接落在终端，不需要判断是前端问题还是引擎问题。第一次运行时关注三件事——工作区路径是否被正确识别、所选模型提供方是否连通、流程是否走到了验证阶段而不是停在发现阶段。

用 MCP 把工作流交给外部 agent

MCP 入口的价值在于复用你已经在用的编码 agent。资料中给出的调用形态类似：

0 mcp-server --workflows --workspace /absolute/path/to/repo

两个参数值得单独说明：

• --workflows 决定暴露哪些工作流给外部 agent 调用，暴露面越窄越安全；
• --workspace 必须使用绝对路径，并且应当指向你愿意让这个 agent 读写的仓库根目录，不要指向用户主目录或整个代码盘。

此外，本地 MCP 要求显式选择 host-local（本机执行）配置。这个设定不是可选装饰，它直接决定了执行位置：工作流在本机运行、文件在本机被读取，运行记录留在本机。

关键配置：workspace、host-local 与插件

workspace 是最重要的隔离单元。 一个工作区对应一个仓库，是控制爆炸半径最有效的手段。多个不相关项目塞进同一个工作区，会让 agent 在检索时跨项目串味，也会让后续清理变得困难。

host-local 决定的是执行位置，不是数据去向。 引擎在本机跑，不代表推理也发生在本机。你仍然需要显式配置一个模型提供方，代码片段、文件路径、工具输出等上下文会随请求发送到该提供方。下发配置前先回答清楚：这类代码允许送到哪一家的哪个区域端点。想彻底本地化推理，就得接入本机或自建的模型服务。

插件加载是影响工作流可见性的关键。 插件缺失或加载失败时，MCP 客户端可能只看到一部分工作流，表现为“命令存在但没有对应能力”。

输出结果怎么读

报告格式覆盖 HTML、PDF、SARIF、Markdown 和 JSON，SARIF 适合接进 CI 做记录，JSON 适合二次处理。阅读顺序建议固定下来：

1. 先看分诊结果——哪些候选被判定为证据不足而丢弃，丢弃理由通常比保留项更能说明工具是否理解了这个仓库；
2. 再看经过独立会话验证的条目，这是可信度最高的部分；
3. 最后才看修复建议，并把它当作草稿而非补丁。

工具内部用独立会话做多轮验证，是一个有价值的机制，但它不等于人工确认。涉及鉴权、反序列化、命令注入这类高风险结论，仍然需要你在隔离环境里复现一次完整证据链：入口、触发条件、影响面、日志或响应证据。没有复现路径的条目一律按“待确认”处理。

常见故障排查顺序

按下面的顺序排查，能避免在错误的方向上浪费时间。具体报错文案随版本变化，这里只给出排查方向。

其中第 2 项值得展开：引擎会话与运行记录共享，是结果混乱最常见的来源。多个会话写同一份运行记录时，你看到的历史可能来自另一次运行，排查时容易被误导。养成“一次验证、一个工作区、一份独立记录”的习惯，能省掉大量困惑。

数据外发与最小权限

把边界画清楚，比记住任何命令都重要：

MCP 服务端本身也是一块攻击面。行业分析普遍把 MCP 工具按“只读”和“可操作”分类，读日志、搜代码风险较低，而改文件、开单、装包会真实改变系统状态（可参考 Endor Labs 对 agent 工具栈的拆解）。暴露给外部 agent 时，尽量只开只读或低风险工作流，把写操作限制在隔离仓库内。

另一个容易被忽视的风险来自工具链本身：已被观察到的攻击手法包括重新打包本地 AI CLI，用发布者控制的引导脚本替换实际的模型端点，从而把请求导向别处（参见 HackTricks 关于本地 AI CLI 与 MCP 滥用的整理）。所以只从官方仓库获取二进制或镜像，核对校验值，不要用来路不明的“加速版”。

卸载与回滚

这类工具会读代码、写记录、注册 MCP 服务条目，清理时要把这几条线都断掉：

• 从 agent 的 MCP 配置中移除对应服务条目，重启客户端确认工具列表已消失；
• 撤销为本次评估创建的模型 API key 和任何临时凭据；
• 删除工作区、运行记录和导出的报告（它们可能包含代码片段）；若使用容器，一并清理镜像与数据卷；
• 恢复运行前的快照，核对仓库与宿主环境是否回到初始状态。

维护状态：要不要纳入长期流程

0 是研究预览版本，纳入长期工作流前先看仓库活跃度。写作时可查到的指标约为 604 stars、70 forks、近 2000 次提交，但这类数字变化很快，请以仓库当前页面、最近提交时间和 issue 响应情况为准。判断标准很简单：如果你需要它长期稳定地跑在 CI 或团队流程里，就要评估发布节奏、破坏性变更频率和许可证是否符合你的分发方式（MIT OR Apache-2.0 双许可通常较宽松）。

对大多数团队，更稳妥的做法是先用它做一次性的授权评审辅助：在隔离仓库里跑通端到端流程，人工复核结果质量，确认证据链可信、数据流向可控之后，再考虑是否固化进日常流程。