Kritt-ai/open-kritt · 上手攻略

• 仓库：Kritt-ai/open-kritt
• 链接：https://github.com/Kritt-ai/open-kritt
• 分类：AI 安全 / 漏洞研究 / Agent 编排
• 作者：spark
• 更新：2026-08-21

是什么

open·kritt 是一款自托管、开源的多 Agent 漏洞研究编排工具。它不是单点扫描器，而是一个把"提示词工作流 + Agent 执行 + 结果验证 + 报告导出"串成可复用剧本（playbook）的控制台，主要面向安全研究员与对安全敏感的开发者。

定位上，它不尝试把整个仓库直接扔给一个大模型让它"找出漏洞"——README 原话是「Pointing a model at an entire repository and asking it to find vulnerabilities rarely works well」。它的路线是：把研究问题拆成小而聚焦的任务，并行调度多个 AI Agent，再把各自的产出聚合为可验证的发现。

形态上由三件套组成：

1. Web 控制台（基于 Docker Compose 的本地栈，默认 http://localhost:5173）
2. 仓库内的 CLI（./kritt setup / ./kritt start / ./kritt-headless），无需 npm install
3. 一套围绕"workflow / post-script / skill / ranker"的便携 JSON 配置

解决什么问题

传统"AI + 安全"工具的痛点集中在三点：

• 扫描覆盖与噪声：单 prompt 让模型通读仓库，往往返回一长串似是而非的洞，开发者无法判断哪条可信。
• 缺乏可复现的工作流：每个研究员都有自己的 prompt 套路，但无法版本化、共享、并行化。
• 结果无法交付给团队/客户：导出格式碎片化，没法打包成结构化、可分享的取证包。

open·kritt 直接对症：

• 把"扫描 → 验证 → 排序 → 导出"做成可配置的 workflow 与 post-script；
• 支持把外部扫描器（Codex、Claude Code）接进来跑分析；
• 提供统一的 finding schema + 自动去重 + 自定义严重度排序器；
• 完成后打包成"带 manifest 的 ZIP"，包含发现、结构化数据、后处理输出、PoC 文本——可分享版本会剥离敏感字段。

快速安装

1. 前置依赖

• Git
• Docker + Docker Compose
• Node.js 20+（仅用于本地预览文档站点 Mint，不必装来跑主程序）

⚠️ README 明确警告：tool-enabled agent 在临时 job 容器中以 root 身份运行，拥有仓库写权限和直接互联网访问（会自行安装工具、编译目标、跑测试、构造 PoC）。因此强烈建议跑在专用 Docker 主机或 VM 上，扫描未受信代码前请读 Threat Model。

2. 启动

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
./kritt setup      # 交互式配置模型访问（Codex 登录 / OpenAI / Anthropic / OpenRouter 任选其一）
./kritt start      # 起 Docker Compose 栈

栈起来后浏览器打开 http://localhost:5173。需要扫私有 GitHub 仓库时，./kritt setup 阶段可填入 GITHUB_TOKEN，这是可选的。

3. 无浏览器/服务器场景

./kritt-headless

headless CLI 负责导入便携的 workflow/post-script/skill/ranker JSON、创建扫描（与 Web 表单走同一套后端校验）、查看扫描状态/阶段/失败原因、编辑非敏感运行时设置、导出 finding bundle。注意它不在终端打印 finding 内容，完整结果走导出。

4. 本地预览文档

npm install -g mint
cd docs-site
npm run dev        # http://localhost:3001

核心用法

编排"扫描剧本"：workflow

open·kritt 的核心抽象是 workflow——一条由多个聚焦提示步骤组成的可复用剧本，定义：

• 每个步骤用哪个 Agent / 模型；
• 步骤输入（文件、依赖子集、CVE 关键词等）；
• 步骤之间如何传数据；
• 失败重试与跳过策略。

README 把它类比为「Chain focused prompts into reusable security research playbooks」。详细步骤语义见 Workflows and prompt steps。

典型场景下，研究员会让一个 Agent 扫某个目录的输入校验点，让另一个 Agent 抓反汇编里的危险 syscall，第三个 Agent 写 PoC 草稿，最后用一个 verifier Agent 跑测试确认是否真的能复现。

跑扫描

支持两种对象：

• 远程仓库：通过 GitHub URL（或自托管 Git）；
• 本地仓库：直接指定路径，让工具拷贝到一个临时 job 容器里跑。

底层执行器支持 Codex 与 Claude Code（README 提及），模型访问在 ./kritt setup 阶段绑定。

验证发现：post-script

post-script 是「在 Agent 报告后跑一段脚本做交叉验证 / 构造 PoC / 生成可读报告」。README 明确它用于「validate issues, build proofs of concept, and produce reports」。这意味着你可以把"跑通一段单元测试"或"用已知 payload 打一次服务端点"作为后置门槛，过滤掉幻觉式 false positive。

自定义排序器

如果你对小工具默认严重度不满意，可以写自己的 ranker（基于 CVSS、自家资产权重、历史 false positive 率等）。最终入库前由统一 finding schema 与自动去重兜底。

导出

每次扫描完成后，会产出：

• canonical findings：归一化后的漏洞列表；
• structured data：JSON 等结构化字段；
• post-processing output：post-script 输出；
• reports + PoCs：报告文本与 PoC 源码（始终以纯文本保存，便于审计与人工核验）。

所有以上被打包成一个带 share-safe manifest 的 ZIP：

• 完成的扫描：完整导出；
• 被中断或失败但已有发现的扫描：明确标记为 partial export。

典型适用场景

1. 白盒漏洞研究 / 赏金流水线：把多个提示模板固化下来，让多个 Agent 并行扫同一仓库的不同模块，再合并排序。README 自报其团队（研究者笔名 Blockian）凭这套底层工具在 Immunefi / HackenProof 上累计拿了 超过 $1,500,000 赏金。
2. 审计 vs 跑 PoC 的拆分：让不同 Agent 分别负责"找洞"与"复现"，互不污染上下文。
3. CI 中的轻量 AI 复查：把 workflow 配成 PR trigger，让模型只扫 diff 文件，省 token。
4. 安全教学 / 红队训练：因为 workflow 与 skill 都是 JSON，可以直接 fork 同事的剧本快速上手。

坑与注意

• 别在主力开发机上跑未受信项目：默认 job 容器是 root + 有网络，且会改写"被扫描仓库的拷贝"——这本身是 PoC 构造需要，但意味着宿主机不能太宝贵。
• 默认端口绑 127.0.0.1，后端没有应用层认证：README 原文「Keep the stack private」——别直接对外暴露。
• GITHUB_TOKEN 是可选的：只在扫私有仓库时用得到；公网项目可以零 token 起步。
• headless CLI 不打印 finding 内容：这是设计选择，避免在 shell history 里泄露漏洞细节；但意味着排错必须靠日志与导出包。
• 许可证 = AGPL v3.0：注意 AGPL 在网络服务化场景下会触发源码公开义务。如果你要把它包成 SaaS 给客户用，先看清边界。
• 威胁模型不是文档摆设：扫描未受信代码前必读 threat-model.md；它解释了为何默认容器是 root + 有网络，以及如何改成更保守的沙箱。

与同类对比

定位差异：open·kritt 不是 SAST 替代品，而是给"已经在写提示词 / 跑赏金 / 需要交付结构化报告"的安全研究员搭一个可编排、可验证、可分享的底座。

一句话推荐结论

如果你正把"提示词 + Agent + 漏洞研究"当流水线来用，open·kritt 是当下少有的把 workflow、验证、导出三件事一起做掉的自托管开源底座；先拉专用 VM 跑起来再考虑在主力机上装。