Kunlun-M: AST-Based Static Analysis With an AI Agent Hook

What Kunlun-M Is For, and What It Inherited

Kunlun-M is the current name of a tool that started as Cobra and then forked into Cobra-W. The README is explicit about the lineage and about the shift in intent. Cobra aimed at detecting as many security issues as possible. Cobra-W narrowed that goal toward accuracy and precision. Kunlun-M, renamed from Cobra-W 2.0, moves again, this time toward serving security researchers and improving the experience of using the tool day to day. That history matters when you evaluate it, because the rule base and the tamper system are inherited artifacts, not a fresh design.

The target user is a white-box auditor. Someone who has source code, wants to find injection, deserialization and similar issues before shipping, and is willing to read rule output rather than trust a score. The README claims Kunlun-M is perhaps the only open-source and actively maintained automated code audit tool on the market. Treat that as the author's framing, not a measured fact. What is verifiable is narrower and still useful: the repository is not archived, the last push is dated 2026-09-10, and releases v2.15.0 and v2.15.1 landed in June 2026.

The README also states the maintenance philosophy plainly. The author writes that the project's concepts may not be cutting-edge by today's standards and that he iterates using Codex at low cost, experimenting with new features. That is an unusual thing to publish, and it tells you what to expect: a stable core with fast, sometimes rough, additions around it.

Semantic Scanning Across Six Languages, Plus Two Shallow Targets

The mechanism described is AST-based semantic scanning. Rather than matching text patterns against files, the tool parses source into syntax trees and reasons over that structure. The README states semantic analysis is supported for PHP, Nodejs/JavaScript, Python, Java, Go and C/C++. Two further targets, Chrome extensions and Solidity, get what the README calls basic scanning, which is a weaker claim than the semantic path and should be read as such.

Language coverage is the first thing to check against your own codebase, because it is not uniform. A PHP audit and a Solidity audit are not the same product. The plugin list reinforces where the depth sits. Two plugins ship: entrance_finder, described as quickly finding the PHP entry page, and php_unserialize_chain_tools, which the README says discovers PHP deserialization chains through codedb. Both are PHP-specific. If your interest is Java or Go, the plugin layer offers nothing in the material provided.

The codedb reference is worth pausing on. It implies the tool persists structural information about a scanned project rather than discarding it after each run, which is what makes a cross-function chain query possible at all. The README does not document codedb's schema or retention, so how much of that survives between scans is not something I can confirm from the repository description.

Rules and Tampers as First-Class Objects

Kunlun-M separates detection logic into rules and tampers, and both are inspectable from the command line. The README gives these examples: python3 kunlun.py show rule to list all rules, python3 kunlun.py show rule -k php to filter to PHP, and python3 kunlun.py show tamper for the tamper set. There is a matching generate subcommand for creating new rules and tampers, and an export subcommand that writes rules and tampers out of the database into files.

That export path is the part I would focus on during evaluation. It means the database is the working store and the filesystem is a projection you can diff and review. A security team can keep rules under version control, review changes to detection logic the same way they review code, and regenerate the database from files. The README does not state whether import from files back into the database exists as a command; only export is listed. If round-tripping matters to you, that is a gap to verify before you build a workflow on it.

Scans can be narrowed by rule identifier. The usage block shows python kunlun.py scan -t tests/vulnerabilities -r 1000, 1001, which runs a specific pair of rules against a target. That is the mechanism you want when you are tuning a single rule and do not want to wait for the full set.

Getting It Running: Init, Scan, Console, Web

Installation is four steps in the README. Install dependencies with pip install -r requirements.txt. Copy the settings template with cp Kunlun_M/settings.py.bak Kunlun_M/settings.py. Initialize the database with python kunlun.py init, which uses SQLite by default. Then scan. Python 3.10 or newer is recommended, with 3.13 preferred; Python 2.7 is called out as end-of-life.

The scan command takes a target path: python3 kunlun.py scan -t ./tests/vulnerabilities/. Reports come out in three formats through flags: -f json -o /tmp/report.json, -f md -o /tmp/report.md, and -f html -o /tmp/report.html. There is also a template selector, shown as -tp wordpress, and two flags in the usage examples whose meaning the README does not explain: -d and -uc. I am not going to guess at them. Run python kunlun.py scan -h before relying on either.

Two other entry points exist. python3 kunlun.py console opens an interactive mode. python3 kunlun.py web -p 9999 starts a dashboard, default port 9999, with an HTTP API gated by a token. Set API_TOKEN in Kunlun_M/settings.py and pass ?apitoken=... on requests. The documented endpoints cover task listing, task detail, scan results, result flow, newly generated malicious functions, and rule listing. Docker is supported via sudo docker build -t kunlun-m -f ./docker/Dockerfile ., which the README says starts web mode by default and can be linked to MySQL for local scanning with results viewed in the browser.

The AI Agent Skill Is the Actual Differentiator

The feature that distinguishes Kunlun-M from older forks is a skill directory. The README states that built-in skills support one-click integration with AI agents, naming OpenClaw, Codex, Claude Code and Hermes. The workflow it describes is deliberately minimal: send your agent the instruction to download the repository and load its skill, kunlun-m-general. The agent is expected to recognize skills/kunlun-m-general/ in the repository and follow its documentation to initialize and scan. A more detailed scripted workflow with test and report commands is documented in docs/skill_kunlunm_general.md.

Read that carefully. The integration is a set of instructions an agent follows, not an API the tool exposes to agents. The value depends entirely on whether your agent reliably reads and obeys the skill file. There is no claim in the material about accuracy of agent-driven scans, and no evaluation of whether an agent picks sensible rules. It is a packaging decision that lowers the setup cost of using Kunlun-M inside an agent session.

For CI, the repository ships a separate driver: python tools/ci_scan.py --target . --output artifacts/kunlun-ci.json --fail-on high. The README says it produces stable JSON reports and clear exit codes, with examples for GitHub Actions, GitLab CI and Jenkins in docs/ci.md. The --fail-on high flag is a build gate, which is the honest way to put a static analyzer in a pipeline: fail the build on a severity threshold rather than emit a report nobody reads.

Where It Will Disappoint You

The clearest limitation is stated by the author, not by me. The README says the project's concepts may not be cutting-edge by today's standards. Combined with the note that maintenance happens at low cost through Codex, this suggests a tool whose core is stable and whose edges are experimental. Expect rough documentation around new flags. The unexplained -d and -uc in the usage block are a small but concrete example of that.

Coverage is uneven by design. Six languages get semantic analysis, but the shipped plugins are both PHP. If you are auditing a Go service, you get the parser and the rule engine without the PHP-specific chain tooling, and the README offers no equivalent for Go deserialization or call chains. The same applies to Chrome extensions and Solidity, which are explicitly basic scanning.

Rule import is the other gap. Export writes rules and tampers to files, but no import command appears in the documented command list. If your plan is to keep rules in git and load them into a fresh database, verify that path exists before designing around it. And if you need a hosted platform with per-developer assignment and triage history, Kunlun-M is not that. Its web mode is a dashboard over scan tasks, with an API for pulling data, not a workflow product.

How It Differs From Semgrep

The obvious comparison is Semgrep. The difference is in where detection logic lives and who writes it. Semgrep's model centers on pattern syntax that resembles the target language, so a developer can write a rule for a specific framework call without touching the analyzer's internals. Kunlun-M's model centers on rules and tampers stored in a database, generated and exported through its own CLI, with AST semantics underneath. That makes Kunlun-M's detection logic something you inspect and modify through kunlun.py rather than author as a portable pattern file.

The practical consequence is in rule sharing. A Semgrep rule is a text artifact you can paste into a pull request. A Kunlun-M rule is a database record until you run export. The README's export command exists precisely because of this, and the absence of a documented import command is the friction point of that design.

A second difference is the agent integration. Semgrep is a scanner with a CLI and a hosted product. Kunlun-M ships skills/kunlun-m-general/ so that a coding agent can install and run it from a single instruction. Whether that is better depends on whether your team already works inside an agent. If it does not, the skill directory is inert, and you are choosing between two static analyzers on rule authoring and language coverage alone.

Licence, Upgrades and What to Check First

Kunlun-M is MIT licensed. That is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and permission notice are retained. I am not a lawyer and this is not legal advice. If you embed the scanner in a product you ship, have counsel review the LICENSE file and the licences of the dependencies in requirements.txt, since the MIT grant covers Kunlun-M's own code and not necessarily everything it pulls in.

Upgrade cost looks low on the evidence available. The release cadence in the material is three releases across three consecutive days in June 2026 (2.14.1, 2.15.0, 2.15.1), which suggests small, frequent increments rather than major migrations. The README names no database migration tool, so after upgrading you should assume python kunlun.py init may be needed and check docs/changelog.md for schema notes. The changelog is linked from the README as ./docs/changelog.md.

Three things to verify before adopting. First, run python kunlun.py show rule -k <your language> and count what actually ships for your stack; the README never states rule counts. Second, run python kunlun.py scan -t <a repo with known bugs> and check whether the findings map to issues you already understand. Third, if rule portability matters, test whether exported rules can be loaded into a clean database, because only export is documented. If any of those three fails, the tool is still usable, but your workflow has to change around it.

Editorial conclusion

Adopt Kunlun-M if you audit PHP or JavaScript codebases and want a locally runnable scanner whose rules you can read and edit, or if you already work inside a coding agent and want it to drive the scan through skills/kunlun-m-general/. Skip it if you need a language whose semantic support is not listed, or if you expect a hosted dashboard with per-developer triage. Before committing, run python kunlun.py init, then python kunlun.py show rule -k php to count what actually ships, and scan one repository you already know the bugs in.

Official sources

1. Issues
2. License: MIT
3. LoRexxar/Kunlun-M on GitHub
4. README
5. Releases