open-kritt Chinese Edition: A Self-Hosted AI Vulnerability Research Platform Deployment Guide

Title

open-kritt Chinese Edition: A Self-Hosted AI Vulnerability Research Platform Deployment Guide

Meta Description

open-kritt Chinese edition is live: a complete translation of the self-hosted AI vulnerability research platform, including a quick-start guide, environment requirements, and security warnings. Learn how to scan code for vulnerabilities with parallel multi-AI agents and verify findings. A GitHub project with 2,284 stars.

Article Content

Handing an entire code repository to a single large model and asking it to find all the vulnerabilities usually produces poor results: a low signal-to-noise ratio, findings that are hard to verify, and no reliable way to rank them. The open-source project open-kritt takes a different approach—instead of relying on one giant prompt, it breaks vulnerability research into many small tasks, runs them in parallel across multiple AI agents, and then merges the output into deduplicated, ranked, verifiable findings. The project has already earned 2,284 stars on GitHub, is written in JavaScript, and positions itself as an open-source, self-hosted AI security and vulnerability research platform.

Now the project has a complete Chinese translation, yangshun2005/open-kritt-cn, which had no independent stars at the time of publication—the 2,284 stars belong to the original project, Kritt-ai/open-kritt. For Chinese-speaking developers, this translation lowers the barrier from "understanding it" to "getting it running."

What problem does open-kritt actually solve?

The traditional "have a large model scan the whole repository" approach has three hard problems: the issues it finds are hard to reproduce, the results cannot be ranked by severity, and a flood of false positives drowns out real vulnerabilities. open-kritt's approach is to engineer the research process—splitting tasks, executing them in parallel, and merging and deduplicating the output into findings that follow a unified schema.

The target users of this tool are security researchers and security-conscious developers. The project explicitly emphasizes that prompts, workflows, model providers, and infrastructure should all be controlled by the user. This means you do not need to host your code on a third-party SaaS, nor are you locked into a single model vendor.

The project team says open-kritt comes from real-world security research practice. The Kritt team participates in bug bounties under the researcher handle Blockian, with cumulative bounty earnings exceeding $1.5 million (related profiles can be found on Immunefi, HackenProof, blockian.xyz, and @Kritt_AI on X). open-kritt is described as the open-source distillation of this internal toolchain—which provides some credibility backing for the tool's practical effectiveness.

Bug Bounty is a crowdsourced incentive model in the security industry: vendors or platforms publicly offer rewards, and anyone who discovers and responsibly reports a valid vulnerability can receive a payout. Immunefi focuses on Web3/smart contracts and is currently the largest platform in that track; HackenProof is likewise mainly focused on blockchain and crypto projects. A researcher's cumulative earnings on these platforms are often regarded as public evidence of their vulnerability-hunting ability. The $1.5 million in bounties mentioned in the article refers to the total rewards the Kritt team accumulated under the Blockian handle on the above platforms. It is worth noting that bounty income does not directly equate to tool effectiveness—it reflects the team's experience, not open-kritt's own detection rate.

Breaking down the platform's core capabilities

According to the README, open-kritt's main features include:

• Build workflows: Chain focused prompts into reusable security research playbooks.
• Run scans: Analyze remote or local repositories and their dependencies, with support for Codex, Claude Code, or Grok Build.
• Verify findings: Validate issues through post-scripts, build PoCs, and generate reports.
• Export scan results: Package standardized findings, structured data, post-processing output, reports, and PoCs into a single ZIP with a shareable manifest. Completed scans generate a full export; stopped or failed scans that still contain findings generate a clearly marked partial export. Reports and PoC source code affected by attackers are preserved as plain text.
• Rank results: Support custom severity rankers, a unified findings schema, and automatic deduplication.
• Bring your own model access: Use Codex login, or connect through OpenAI, Anthropic, DeepSeek^Ad, OpenRouter, or xAI.

The key to this design is the "verification" step. Most AI security tools stop at "finding problems," whereas open-kritt emphasizes using post-scripts to build PoCs that verify the problem actually exists. This difference directly determines whether the tool's output can serve as the basis for real security decisions.

PoC (Proof of Concept) refers to a minimal piece of code or set of steps that can reproduce a vulnerability, used to prove that a problem truly exists and can be triggered, rather than being an inference from static analysis. In security research, whether a runnable PoC can be provided is the key dividing line between a "suspected issue" and a "confirmed vulnerability." Post-script is the mechanism in open-kritt that carries this step: after a scan finds candidate issues, it executes custom scripts to try to construct trigger conditions, verify the scope of impact, and output a report. A finding is used together with a severity ranker: the former is a single vulnerability record under a unified schema, while the latter scores and ranks it according to standards such as CVSS or custom rules, so that results can be handled by priority.

Why the Chinese translation is valuable

The original project documentation is in English. For Chinese-speaking developers, this creates a real barrier—not because the concepts are hard to understand, but because installation steps, threat model explanations, and configuration details are exactly the kind of text where "misreading one line wastes an hour."

The Chinese version is not simply a pile of machine translation; it has a two-layer structure:

1. A Chinese quick-start guide at the top, explicitly marked as supplementary material and not part of the original README. Its purpose is to get you up and running without having to read the entire document first.
2. A complete Chinese translation of the original README body, with the page stating that it strives to be faithful to the original.

The translated page also accepts issues and PRs to correct inaccuracies. For a technical translation document, this is a reasonable stance—the translations of terms such as "finding," "post-script," and "severity ranker" are inherently open to debate.

The practical value is this: Chinese-speaking developers can first read the quick start, understand the prerequisites and security warnings, and then get the whole stack running. For a security tool, precision is critical, and the Chinese documentation eliminates language-related comprehension loss.

Quick start: get running in three steps

Prerequisites: Git, Docker (including Docker Compose), and Node.js 20 or newer. The repository includes its own CLI, so no additional installation steps are required.

Clone and enter the directory:

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

Run setup and follow the prompts to configure the login method and API key:

./kritt setup

Start the full set of services:

./kritt start

Then open http://localhost:5173 in your browser.

If the server has no browser or desktop environment, keep the service running and execute the following in another shell:

./kritt-headless

Environment requirements and known limitations

The translated README is explicit about some requirements and silent about others, so this needs to be distinguished precisely:

• Operating system: The original project does not clearly state supported systems; it only notes that the stack can run on servers without a browser or desktop.
• Hardware: The original project does not specify this.
• Dependencies: Git, Docker (including Docker Compose), and Node.js 20 or higher.
• Version requirements: Node.js 20+; the original project does not declare versions for the other dependencies.
• Model access: At least one method is required—Codex login, or access through OpenAI, Anthropic, DeepSeek, OpenRouter, or xAI.
• Network: The translated version adds a general note—in mainland China network environments, downloading Docker images or npm dependencies may require switching to a mirror or acceleration source. This note is marked as a general suggestion and is not part of the original text.

A few easy places to get stuck

The translated quick-start guide specifically points out several easily overlooked and costly problems:

There is no application-layer authentication by default. By default, the port is bound to 127.0.0.1, and the backend does not include application authentication. The entire service must remain private and should not be exposed externally.

Agents run as root. When the tool's agents are enabled, they run as root inside one-off task containers, with a writable copy of the repository and direct internet access—this is necessary for installing tools, compiling targets, running tests, and building PoCs. Before scanning untrusted code, you should run on a dedicated Docker host or virtual machine, and read the threat model documentation first.

Model credentials are mandatory. At least one model access method must be configured, either login or API key, and ./kritt setup will guide you through it. GITHUB_TOKEN is optional and only needed when accessing private GitHub repositories.

The headless CLI has limitations. ./kritt-headless will not display the specifics of vulnerability findings in the terminal; it only shows scan status, stages, and failure reasons.

Threat Model is a structured description of what attackers a system may face, what capabilities they have, and through what paths they can cause harm. For open-kritt, the core question the threat model needs to answer is: when an agent runs with root privileges, a writable repository, and internet access, what can the malicious code being scanned do—for example, steal model API keys from environment variables, exfiltrate source code to an external address, or implant a persistent backdoor in the container. One-off task containers and dedicated isolated hosts are precisely the mitigations designed for this. Reading the threat model documentation before scanning repositories of unknown origin is essentially about first clarifying "what risks am I taking on," and only then deciding whether to proceed.

Scope notes

The Chinese translation covers the README and adds a practical quick-start guide, but it does not change the software itself. The AGPL-3.0 license, the JavaScript codebase, and the 2,284 stars all belong to the original project Kritt-ai/open-kritt.

For Chinese-speaking security researchers or developers who have been putting off trying open-kritt because of English documentation, this translation removes a concrete obstacle. The onboarding path is short: clone, ./kritt setup, ./kritt start. What truly deserves careful reading before scanning any untrusted code is the security warnings section.

Chinese documentation address: https://github.com/yangshun2005/open-kritt-cn

One-line Summary

open-kritt breaks vulnerability research into parallel multi-agent tasks, and the Chinese translation lowers the barrier to entry.

Paragraph Summary

open-kritt is an open-source, self-hosted AI security and vulnerability research platform whose original project has earned 2,284 stars. Instead of taking the "one giant prompt scanning the whole repository" route, it splits vulnerability research into many small tasks, runs them in parallel across multiple AI agents, then merges them into deduplicated, ranked, verifiable findings, and uses post-scripts to build PoCs that verify the problem truly exists. The Chinese translation yangshun2005/open-kritt-cn includes a Chinese quick-start guide and a complete translation of the original README, covering installation steps, the threat model, and configuration details. Getting started takes only three steps: clone, ./kritt setup, ./kritt start, with prerequisites of Git, Docker Compose, and Node.js 20+. The article also emphasizes security warnings such as no application-layer authentication by default and agents running as root, reminding users to scan untrusted code in an isolated environment.