DianXing (点星): an AI code security auditor that ships results, not code

The problem DianXing targets: logic bugs that pattern scanners miss

Rule-based SAST engines match known shapes: a tainted source reaching a sink, a dangerous function call, a dependency with a published CVE. The README states plainly that DianXing is not a rule scanner and does not rely on regular expressions or known CVE patterns. The class of bug it goes after is authentication bypass, broken authorization and business logic flaws, which the README describes as deep vulnerabilities that traditional SAST tools cannot reach.

The intended user is a security team auditing a codebase it did not write, at a scale where manual review does not fit. The README frames the system as reading and understanding code the way a researcher would, at industrial scale, and lists audited targets from Jenkins and phpMyAdmin to Aave V4 and a router firmware image. That is a wide spread of languages and artifact types, and it is the strongest part of the pitch: an auditor that does not need a per-language rule pack.

What the repository actually contains: audit data and a hash challenge

The top level of the repository holds a README, an AI vulnerability severity rating standard document, a challenge hash file named challenge_hashes_grav-1.8.0-beta.29_public.csv, two QR code images and a .gitignore. There is no source directory, no package manifest, no container definition and no binary. The README explains why: the team states it is withholding the core implementation on the grounds that the system can autonomously find zero-privilege RCE and complete a full attack chain to remote server control without human input, and that releasing it without a gate would let anyone obtain an attack-ready vulnerability list from a source upload.

So the artifact you can evaluate is the published audit record. The README reports 14 completed audits, 8,451 findings, 11 critical zero-privilege RCE, 1,785 high and 5,310 medium. It also states the counting rule: the same vulnerable location with multiple independent exploitation chains is counted more than once. That rule inflates the total relative to a deduplicated defect count, and the README says so directly, calling it a choice for transparency rather than for a flattering number. Read the 8,451 as a count of independently exploitable attack surfaces, not of distinct code defects.

One more disclosure matters. The README states that all severity ratings were assigned by AI, not by a human reviewer. Severity is the field most likely to be wrong in any automated audit, and here nothing in the published process corrects it.

Installing DianXing: why there is no tutorial to write

There is no installation section in the README, no package name, no CLI, no API endpoint, no environment variable and no configuration file in the repository. The project describes a workflow of uploading source code and receiving a structured vulnerability list after a single run, but it does not describe the interface that performs the upload, and no client for it exists in the repository.

That absence is deliberate rather than an oversight, and it is the single most important fact for anyone deciding whether to adopt this. The README states the core implementation is not public. There is no Homepage field on the repository and no release was retrieved, so there is also no packaged artifact to fetch.

What you can do with the repository today is inspect the published results and enter the challenge. The README describes a vulnerability hunter challenge that publishes a hash table of vulnerabilities in advance and pays a bounty for anything the system missed. The file challenge_hashes_grav-1.8.0-beta.29_public.csv is that table for the Grav CMS audit, and it is the only concrete, checkable object in the tree. If you want to test the claim that DianXing found 1,215 issues in Grav CMS v1.8.0-beta.29, that CSV is where the verification starts.

The recall benchmark claims more than the README proves

The README describes a recall benchmark run under stated constraints: coverage of C, Java, JavaScript, Python, Go, PHP, .NET, Rust and Ruby; at least five distinct vulnerability types per language; vulnerabilities disclosed after the AI model training cutoff; no network access during the run; no human intervention; and exactly one run with no parameter tuning or retries. The reported result is zero misses across all nine languages.

That is a strong claim, and the constraints listed are the right ones to control for memorization. What the README does not provide is the test set itself, the specific vulnerabilities used, or the scoring procedure. A zero-miss result is only as meaningful as the sample it was measured on, and a benchmark that cannot be re-run by a reader is an assertion rather than evidence. The same applies to the head-to-head comparison against three unnamed AI code audit products on Grav CMS v1.8.0-beta.29: the README shows DianXing at 1,215 findings and a competitor maximum, but the truncated text does not name the competitors, their versions or their configuration, and the evaluation criteria are described only as being the same for all four.

The masked project names create a second verification gap. Several rows in the audit table are blacked out, and the README explains that any project where DianXing found a zero-privilege RCE has its name and version hidden to prevent the bug from being traced back. That reasoning is defensible. It also means the 11 critical findings, the most consequential number in the whole document, are the least verifiable.

How this differs from Semgrep and CodeQL

Semgrep and CodeQL are the natural comparison points, and the difference is architectural rather than a matter of tuning. Both are static analysis engines: you write or select rules, CodeQL in its query language and Semgrep in its pattern syntax, and the engine evaluates those rules against a database of the code. Coverage is a function of the rules you have. A logic flaw nobody wrote a rule for will not be reported, and that is exactly the gap the README says DianXing is built to close.

The trade-off runs the other way too. With Semgrep or CodeQL you can read the rule that produced a finding, adjust it, suppress it, and run the same query again in CI on every commit. That reproducibility is what makes them usable as a gate. DianXing, as documented, offers one run per codebase with no rules to inspect and no way to re-run it yourself. The published results are a report about code, not a tool you can point at code, so it does not replace a rule engine in a pipeline. It competes with the human researcher you would otherwise hire for a one-off deep review.

Maintenance, licence and what the repository does not say

The last push to the default branch was on 2026-06-24, which puts it roughly three months before the date this article was written. The repository is not archived, and the README mentions that audits of eight further projects, including Mattermost, Argo CD and GLPI, are in progress. That is a signal of ongoing work on the audit programme, but it says nothing about a release cadence, because there is no installable release to version.

There is no licence file in the repository, and the README does not state terms of use. Without a licence, the default position is that no rights are granted, so the audit tables and the challenge hash CSV should be treated as published material you can read, not as something you can redistribute or build on. That is a description of the repository state, not legal advice; if you intend to use the data commercially, ask the maintainers directly.

Upgrade cost is hard to assess for the same reason. A tool you install has a version, a changelog and a migration path. DianXing has none of those in public, so the cost of adopting it later is unknown, and the cost of depending on its output now is that you cannot re-run the analysis when the underlying models change.

Editorial conclusion

DianXing is worth reading if you want a worked example of what an AI auditor claims to find in large codebases, or if you want to enter the vulnerability hunter challenge using challenge_hashes_grav-1.8.0-beta.29_public.csv. It is not adoptable today: there is no installation path, no licence file, no interface, and no way to point it at your own repository. Anyone evaluating it for a pipeline should first ask the maintainers for terms of use and a way to reproduce one entry in the audit table on their own code, and should treat the 8,451 count as an attack-surface count rather than a defect count.

Frequently asked questions

Official sources

1. Issues
2. README
3. tianchong-zerotemp/dianxing on GitHub