Featured project
CodeBuddy Security
CodeBuddy Security is Tencent’s AI code security audit platform, jointly developed by Yunding Lab, Keen Lab, and the Tencent Cloud Code Analysis (TCA) team. It runs several engines side by side, including the TCA-Xcheck static analyzer and an AI deep-audit engine, and covers threat modeling, discovery, adversarial review, static and dynamic verification, and fixes. I work on the platform’s capability side; the AI deep-audit engine grew out of VulnAgent, a vulnerability-discovery agent I built.
- 8M
- model calls
- 25,000+
- vulnerability findings
- 3,200+
- vulnerabilities reproduced in real environments with engine-written PoCs
Method from 《以无厚入有间：CodeBuddy Security 的漏洞发现思路与实践》 (Tencent Security on WeChat, August 2026).
How it got here
Each stage came with a write-up of mine on WeChat.
01 · 2026.01
An experiment that worked
While exploring AI-assisted auditing on Suricata, the model found two high-severity vulnerabilities and built working PoCs. I turned that run into an automated workflow. Two weeks later VulnAgent could go from intelligence gathering to sandbox verification on its own.
未来已来：漏洞挖掘智能体 VulnAgent 发现两个 Suricata 高危漏洞，并获官方致谢Yunding Lab on WeChat
02 · 2026.06
From a demo to a product
A working prototype is not yet a product. Stability, business requirements, and a long stretch of engineering still had to be dealt with before VulnAgent joined the CodeBuddy Security platform as its AI deep-audit engine, alongside rule-based scanning, and launched with Tencent Cloud.
腾讯云发布企业级 Agent 安全框架与代码安全产品 CodeBuddy SecurityTencent Security on WeChat
03 · 2026.08
Vulnerability discovery is a search
Two months after launch, I wrote up the methodology and the evaluation as a public technical note. The sections below draw mainly on it.
以无厚入有间：CodeBuddy Security 的漏洞发现思路与实践Tencent Security on WeChat
Method
The more detailed the intelligence, the steadier the detection
Give any coding agent a real vulnerability report together with the code, with the bug class, exact location, root cause, and trigger path, and it will always “find” the bug: checking a given answer is far easier than producing one from nothing. With complete intelligence every system scores full marks, so the real difference lies in the middle. Told only a bug class and a rough module, can the agent still find it? Many real audits point to one rule:
For an AI agent with basic tool use, as long as the intelligence is true, its chance of finding the vulnerability never decreases as the intelligence gets more detailed.
Vulnerability discovery is a search, and the unit of search is a hypothesis: some input reaches some dangerous operation along some path, and goes wrong because a check is missing. For a repository of real size, there are far more hypotheses than an agent can test on a fixed budget. Each piece of valid intelligence adds a constraint, and the smaller the set, the more of it the budget can cover.
The engine is built in two halves around this, joined by the module: a functional unit of closely related code around one responsibility. If auditing one unit means repeatedly reading another, they belong together. A module is where the agent enters, and it is free to follow call chains across files and subsystems from there.
First half: build intelligence, shrink the space
- Patch analysis
- Usually the finest grain: the invariant a fix enforces, and the angles that might bypass it.
- Threat intelligence
- Real fixes mined from Git history, giving the bug class and the area involved.
- External intelligence
- CVE advisories and security write-ups distilled into candidate modules.
- Attack-surface analysis
- Reasoning from code structure. Coarse, but the widest coverage; its job is to make sure code in every other channel’s blind spot still gets looked at.
Second half: turn leads into confirmed findings
- The agent enters at a module and explores from there. Real bugs often span files: the entry is in one, and the dangerous operation hides in a fallback branch of another. Rigid boundaries miss this kind of bug systematically.
- Every candidate is recorded, then reviewed from the opposite side in a separate context: was the input already sanitized upstream, and is the path really reachable?
- Only candidates that survive the challenge are confirmed, and they can go on to a real environment where the system writes a PoC to check exploitability.
In one React audit, threat intelligence showed a module had just been patched for a deserialization issue. The system checked similar paths and found another one the official fix had missed. A module that was just patched is often worth another look, and that kind of project-level prior is hard for a static rule engine to pull out of code history.
This is what “from model to platform” means: the model is a replaceable stage in the pipeline, and the system is intelligence building, scheduling, adversarial review, real reproduction, and end-to-end metering together.
Evaluation
Measured on real projects with known answers
On the internal developer preview, the engine has driven about 8 million model calls and accumulated more than 25,000 findings, more than 3,200 of them reproduced in real environments with engine-written PoCs. Real scans, though, only show what was found, not what was missed. Measuring detection needs a test set with known answers.
How a test set is built decides what it measures. CyberGym, widely used, by default hands the system the vulnerable source and a description and asks for a triggering PoC, so it measures how to reproduce a known bug. Synthetic targets have designed bugs, while real projects have evolved ones: targets carry far more bugs per line, mostly planted from known patterns, and suit enumeration and pattern matching better than discovery in ordinary code.
So the test team keeps an internal set: snapshots of well-known open-source projects that contain several confirmed historical CVEs, scanned with no hints at all. It measures how to find unknown bugs. Finding plus reproducing is the whole of vulnerability discovery.
Three guards against contamination
- Offline the whole time; the agent cannot search for answers.
- Memory checks: reporting a CVE id without reading the code, or an exact location without opening the root-cause file, goes to manual review, and the case is removed once confirmed as recall.
- The engine’s results audit the benchmark in turn: missed bugs, wrong scopes, and duplicates found in review are corrected, and the samples keep being updated.
End-to-end detection: 73.2%
The only input is the repository; leads come from the system’s own threat intelligence and attack-surface analysis, with no web access. All four systems ran on GLM-5.2 to remove the model as a variable. The best of the others, Claude Security, detected 42.7%; CodeBuddy Security detected 73.2%, 1.7 times as many.
With module-level intelligence: 90.2%
Each hint names only a functional module and a risk type, with no file, function, or call chain, for example “the HTTP/2 stream dependency tree in curl may have a use-after-free” or “the .netrc credential lookup in curl may leak passwords”. Locating the code, tracing the path, and confirming the bug are left to the agent, offline. This measures whether the agent can turn incomplete intelligence into real findings.
My part
What I built
- Designed and built VulnAgent; the first version ran end to end, from intelligence to audit, review, and PoC, within two weeks.
- Batch orchestration: agents run in parallel containers across many repositories; findings trigger verification automatically, and verified projects go on to the next round.
- Multi-round convergence: deduplication by code location, and past task history fed into attack-surface analysis so each round looks somewhere new.
- External intelligence input and incremental diff review for CI/CD.
- The first version of the PoC verification agent: it builds the environment, writes the PoC, replays it, and records the whole run for the platform.
Results
CVEs found by VulnAgent(16)
Suricata · 2026-09-20
Type confusion in DNS-over-HTTP/2, an invalid free that can lead to remote code execution.
Open WebUI · 2026-09-09
Unvalidated calendar alert offsets disable reminders for every user.
FreeRDP · 2026-08-01
Heap buffer overflow in the clipboard virtual channel. A malicious RDP server can gain code execution.
Langflow · 2026-05-12
Path traversal in bulk delete.
LiteLLM · 2026-05-08
SQL injection.
NVIDIA Model Optimizer · 2026-03-24
Unsafe deserialization of an ONNX model.
NVIDIA Megatron-LM · 2026-03-24
Remote code execution by loading a malicious file.
NVIDIA Megatron-LM · 2026-03-24
Deserialization of untrusted data.
Apache IoTDB · 2026-03-09
Expression injection through the JEXL evaluator.
ImageMagick · 2026-02-24
Heap out-of-bounds read in the DCM decoder.
manga-image-translator · 2026-02-11
Remote code execution through unsafe deserialization.
Suricata · 2026-01-27
Uncontrolled resource consumption in the DNP3 parser.
Suricata · 2026-01-27
Unbounded buffer expansion in the DCERPC UDP parser.
React · 2026-01-26
Denial of service in React Server Components.
Gitea
Argument injection in an external renderer, leading to remote code execution.
Gitea
Memory-amplification denial of service while parsing Alpine .PKGINFO files.