open-kritt 中文版：自托管 AI 漏洞研究平台落地指南

把整个代码仓库丢给一个大模型，让它找出所有漏洞，结果通常很糟糕：信噪比低、发现难以验证、也无法稳定排序。开源项目 open-kritt 换了个思路——不靠单条巨型提示词，而是把漏洞研究拆解成多个小任务，由多个 AI 代理并行执行，再把输出合并为去重、排序、可验证的发现（finding）。该项目在 GitHub 上已获得 2284 颗星，采用 JavaScript 编写，定位于开源、自托管的 AI 安全与漏洞研究平台。

如今，这一项目有了完整的中文翻译版本 yangshun2005/open-kritt-cn，发布时无独立星标——2284 星属于原项目 Kritt-ai/open-kritt。对于中文开发者来说，这份翻译降低了从「看懂」到「跑起来」的门槛。

open-kritt 中文翻译项目来源

open-kritt 到底解决什么问题

传统的「大模型扫全仓库」方案有三个硬伤：发现的问题难以复现、结果无法按严重性排序、大量误报淹没真实漏洞。open-kritt 的做法是把研究过程工程化——将任务切分、并行执行、合并去重，最终输出带有统一 schema 的发现。

这套工具的目标用户是安全研究人员和有安全意识的开发者。项目明确强调：提示词、工作流、模型供应商和基础设施都应由用户自己掌控。这意味着你不需要把代码托管到第三方 SaaS，也不受限于某一家模型厂商。

项目方表示，open-kritt 源自真实的安全研究实践。Kritt 团队以研究员代号 Blockian 参与漏洞赏金，累计获得超过 150 万美元的赏金收入（相关档案见 Immunefi、HackenProof、blockian.xyz 以及 X 上的 @Kritt_AI）。open-kritt 被描述为这套内部工具链的开源提炼版本——这为工具的实际有效性提供了一定的可信度背书。

漏洞赏金（Bug Bounty） 是安全行业的一种众包激励模式：厂商或平台公开悬赏，任何人发现并合规报告有效漏洞即可获得奖金。Immunefi 专注 Web3/智能合约领域，是目前该赛道规模最大的平台；HackenProof 同样以区块链与加密项目为主。研究员在这些平台上的累计收入，常被视作其漏洞挖掘能力的公开佐证。文章提到的 150 万美元赏金，即指 Kritt 团队以 Blockian 代号在上述平台累计获得的奖励总额。需要注意的是，赏金收入并不直接等同于工具效果——它反映的是团队经验，而非 open-kritt 本身的检出率。

平台核心能力拆解

根据 README，open-kritt 的主要功能包括：

构建工作流：将聚焦的提示词串联成可复用的安全研究 playbook。
执行扫描：分析远程或本地仓库及其依赖，支持 Codex、Claude Code 或 Grok Build。
验证发现：通过 post-script 验证问题、构建 PoC、生成报告。
导出扫描结果：将标准化发现、结构化数据、后处理输出、报告和 PoC 打包为单个 ZIP，附带可分享的 manifest。完成的扫描生成完整导出；已停止或失败但仍含发现的扫描生成明确标记的部分导出。受攻击者影响的报告和 PoC 源码以纯文本形式保留。
结果排序：支持自定义严重性排序器、统一发现 schema 和自动去重。
自带模型访问：可使用 Codex 登录，或通过 OpenAI、Anthropic、DeepSeek^广告、OpenRouter 或 xAI 接入。

这一设计的关键在于「验证」环节。多数 AI 安全工具止步于「发现问题」，而 open-kritt 强调用 post-script 构建 PoC 来验证问题真实存在。这一差别直接决定了工具输出能否作为实际安全决策的依据。

PoC（Proof of Concept，概念验证） 指一段可复现漏洞的最小化代码或操作步骤，用于证明问题真实存在且可被触发，而非静态分析下的推测。在安全研究中，能否给出可运行的 PoC，是区分「疑似问题」与「已确认漏洞」的关键分界线。Post-script 则是 open-kritt 中用于承载这一环节的机制：它在扫描发现候选问题后执行自定义脚本，尝试构造触发条件、验证影响范围并输出报告。发现（finding） 与 严重性排序器（severity ranker） 配套使用：前者是统一 schema 下的单条漏洞记录，后者依据 CVSS 等标准或自定义规则为其打分排序，从而让结果可按优先级处理。

中文翻译为什么有价值

原项目文档为英文。对中文开发者而言，这构成一道真实门槛——并非概念难以理解，而是安装步骤、威胁模型说明和配置细节恰恰是「误读一行、浪费一小时」的文本类型。

中文版本并非简单的机器翻译堆砌，它包含两层结构：

顶部的中文快速入门指南，明确标注为补充材料，不属于原 README。其目的是让你在不读完整个文档的情况下先把项目跑起来。
原 README 正文的完整中文翻译，页面声明力求忠实于原文。

翻译页面同时开放 issue 和 PR 提交，用于修正不准确之处。对于技术翻译文档来说，这是合理的姿态——「finding」「post-script」「severity ranker」等术语的译法本就见仁见智。

实际价值体现在：中文开发者可以先读快速入门，理解前置条件和安全警告，再把整套技术栈跑起来。对于一款安全工具而言，精确性至关重要，中文文档消除了语言层面的理解损耗。

快速上手：三步跑起来

前置条件：Git、Docker（含 Docker Compose）、Node.js 20 或更新版本。仓库自带 CLI，无需额外安装步骤。

克隆并进入目录：

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt

运行 setup，按引导完成登录方式与 API key 配置：

./kritt setup

启动整套服务：

./kritt start

随后在浏览器打开 http://localhost:5173。

如果服务器没有浏览器或桌面环境，保持服务运行，另开一个 shell 执行：

./kritt-headless

环境要求与已知限制

翻译版 README 对部分要求表述明确，对另一些则保持沉默，这里需要精确区分：

操作系统：原项目未明确说明支持的系统，仅指出该技术栈可在无浏览器或桌面的服务器上运行。
硬件：原项目未作说明。
依赖：Git、Docker（含 Docker Compose）、Node.js 20 或更高版本。
版本要求：Node.js 20+；其他依赖版本原项目未声明。
模型访问：至少需要一种方式——Codex 登录，或通过 OpenAI、Anthropic、DeepSeek、OpenRouter、xAI 接入。
网络：翻译版补充了一条通用提示——在中国大陆网络环境下，下载 Docker 镜像或 npm 依赖可能需要切换到镜像源或加速源。该提示被标注为通用建议，不属于原文内容。

容易踩坑的几个点

翻译版快速入门特别指出了几个容易忽视、代价高昂的问题：

默认没有应用层认证。 默认端口绑定在 127.0.0.1，后端不包含应用认证。整套服务必须保持私有，不要对外暴露。

代理以 root 身份运行。 启用工具的代理在一次性任务容器内以 root 运行，拥有仓库的可写副本和直接互联网访问权限——这是安装工具、编译目标、运行测试和构建 PoC 所必需的。在扫描不受信任的代码之前，应运行在专用的 Docker 主机或虚拟机上，并先阅读威胁模型文档。

模型凭证是强制项。 必须配置至少一种模型访问方式，登录或 API key 均可，./kritt setup 会引导完成。GITHUB_TOKEN 是可选项，仅在访问私有 GitHub 仓库时需要。

headless CLI 存在限制。 ./kritt-headless 不会在终端显示漏洞发现的具体内容，只显示扫描状态、阶段和失败原因。

威胁模型（Threat Model） 是对系统可能面临哪些攻击者、具备何种能力、通过什么路径造成损害的结构化描述。对 open-kritt 而言，威胁模型需要回答的核心问题是：当代理以 root 权限、可写仓库、可访问互联网的状态运行时，被扫描的恶意代码能做什么——例如窃取环境变量中的模型 API key、向外部地址回传源码、或在容器内植入持久化后门。一次性任务容器与专用隔离主机正是为此设计的缓解措施。在扫描来源不明的仓库前通读威胁模型文档，实质上是先明确「我承担了哪些风险」，再决定是否执行。

范围说明

中文翻译覆盖了 README 并新增了实用快速入门，但不改变软件本身。AGPL-3.0 许可证、JavaScript 代码库和 2284 颗星均属于原项目 Kritt-ai/open-kritt。

对于一直因英文文档而推迟尝试 open-kritt 的中文安全研究人员或开发者，这份翻译移除了一个具体障碍。上手路径很短：clone、./kritt setup、./kritt start。真正值得在扫描任何不受信任代码之前仔细阅读的，是那些安全警告部分。

中文文档地址：https://github.com/yangshun2005/open-kritt-cn