research
Research map organized around the questions I am asking, not the papers I have written.
- Fix committed in public, not labeled as a security fix. The exposure window opens.
- Attacker reads the commit, infers the vulnerability and builds an exploit, LLM-assisted, in days.
- Today, downstream users get no signal, stay exposed until the advisory, and patch weeks to months later.
- With proactive sensing (our work), the silent fix is flagged and users patch 1–2 weeks before the CVE, so the attack is blocked.
Under coordinated vulnerability disclosure, a vulnerability is usually silently fixed in the public repository before any advisory exists. Until the CVE appears, that commit is the only public trace of the hole, and attackers read commits too.
Researchers reached OpenAI's internal repositories in under 72 hours. The entry point was a heap overflow in libheif, an open-source image decoder behind OpenAI's community forum, chained with an SSO misconfiguration. Upstream had already fixed the bug, but the fix was never labeled a security fix and never received a CVE, so it slipped past Debian's security backports and the vulnerable version kept shipping downstream. LLMs helped turn the bug into a working exploit; the whole campaign cost under $3,000 in tokens. Read the write-up ↗
This is the window our work targets: the fix is public, the vulnerability is not. Starting from our ASE'21 VulFixMiner paper, we pioneered proactive vulnerability sensing, treating silent fix commits as the first public signal of a hidden vulnerability and flagging 65% of them 1–2 weeks ahead of CVE disclosure. In 2025, LLM4VFD (FSE'25) brought LLMs together with code-change intention, development artifacts and historical vulnerabilities, raising F1 by 68–145% over the best prior detector. We now also work out which downstream versions a fix still leaves exposed.
Proactive Vulnerability Sensing
Q1. How can we detect a vulnerability before it is publicly disclosed?
Q2. How do we manage that vulnerability with one hand tied behind our back — no public CVEs or advisories to draw on?
Show/Hide Work on Proactive Vulnerability Sensing- [OSS Disclosure Management] how OSS projects coordinate the private-to-public disclosure window
- [Industry to Academia] mapping the gap between industrial vulnerability-management practice and academic research
- [VulFixMiner] commit-only sensing, language-agnostic
- [CoLeFunDa] contrastive learning + data augmentation
- [TaintFix] taint-propagation analysis
- [MGD] multi-granularity hierarchical detector
- [LLM4VulFix] intention + dev artifacts + history
- [MoE-VulDet] mixture-of-experts detection
- [Lingering-Vul] long-unfixed vulnerability detection
- [DIR] dangerous issue-report mining
- [Auto-CVSS] LLM-based CVSS scoring
- [EAVA] evidence-augmented assessment
- [CritVul] criticality estimation
- [Exploit-Applicability] which versions an exploit still reaches
- [Diffploit] cross-version exploit migration
- [Refploit]preprint exploit construction via code-agent trajectory repair
- [PatchPort] implicit-inconsistency-aware porting
- [SimPatch] similar-but-patched code removal
- [APR-Inject] automated repair for injections
A coding agent starts every task from scratch, yet past development and past runs already hold much of what it needs. We work on process intelligence for coding agents: mining that past into constraints and guidance, delivering them to the agent before and during a run, and letting every run's trajectory refine them for the next. Across runs, experience is mined, evaluated and evolved; within a run, guidance steps in when the agent drifts.
Process Intelligence for Coding Agents
Q1. What can a coding agent learn from the past, and how do we turn it into constraints and guidance?
Q2. How do we observe, evaluate and guide an agent as it works, and feed what we see back?
Show/Hide Work on Process Intelligence↓ trajectories · ↑ in-run guidance (in progress) · ↓ pull knowledge
- online & offline trajectory analysis
- step-level evaluation of each run
- [Failure and cause localization] in progress
- [eval-kit-swe-pro] SWE-bench Pro evaluation plugin
- experience from project history and agent runs
- delivered on demand, or during a run
- [Lingxi] procedural knowledge from issue–patch history
- [STAIR] repair recipes from agent trajectories
- [TestGRAD] failure patterns from test outcomes
- [Workflow mining] workflow structure from agent trajectories · in progress
Lingxi
Recovers the procedural knowledge behind a repository's historical issues, and uses it to guide analysis, planning and fixing on new issues.
STAIR
Turns past repair trajectories into repair recipes at several granularities, and adapts the ones that fit into a plan for each stage of a new repair.
TestGRAD
Mines recurring failure patterns from test attempts to evolve the test suite until it tells candidate patches apart: test-time scaling for agent ensembles.