SecReason: Vulnerability Detection and In-Stream Self-Repair for LLM Code Generation

What it is

SecReason is an inference-serving-layer defense for reasoning LLMs (no weight changes). It runs a static security checker on code drafted inside the streamed chain of thought, interrupts when a rule fires, inserts a warning, and lets the model repair the draft in the same trace. The page's motivating example is an SSRF (CWE-918) in a URL-builder where the model had noted # and ? as invalid during planning but then checked only / and empty. SecReason flagged it mid-trace and the model fixed it.

The empirical case (Section 2.2, Table 1)

The paper's premise is measured, on six open-weight models (Qwen3.6-35B-A3B, Gemma-4-26B-A4B, DeepSeek-V4-Flash, MiniMax-M3, GLM-5.3-Flash, Kimi-K3) over 173 tasks (97 CWEval, 76 SecCodeBench; Python, JS, Java, C, C++):

• Functionally valid but insecure delivery: 13.2–35.6% on CWEval, 42.6–61.3% on SecCodeBench.
• Mentioning "secur-"/"vulnerab-" in the trace does not help: mention rates among secure generations are equal or higher in 11 of 12 model-benchmark cells. Of runs that do mention security, 5.4–61.1% still fail security tests. The authors call this correlational (lexicon matching).
• 52.4–99.8% of delivered lines appear verbatim in a fenced block in the reasoning. The best draft closes at 45.2–89.1% of the trace, leaving 203–6,028 mean post-draft tokens (DeepSeek-V4-Flash is the high end at 6,028 and 5,147).

This is the "pre-delivery window" that makes interception possible. Kimi-K3 is the weakest case for it (52.4% and 68.8% recall).

How it works

• Incremental parser recognizes completed statements inside an open code fence. Waiting for the fence to close is too late, and arbitrary token boundaries yield unparseable fragments.
• Two scan tracks: a statement-local track on each completed statement, and a context-dependent track that follows dataflows across accumulated code (e.g. command/SQL injection). This avoids rescanning everything each time while still catching cross-statement taint.
• Findings are turned into short natural-language warnings (e.g. "[Security] CWE-918 SSRF, subdomain_prefix flows into the URL unchecked"), inserted into the stream, and decoding resumes. No new turn and no full regeneration.
• The model decides whether the alarm is real. If it is false, it verifies and moves on, so false alarms cost a few tokens rather than a regeneration.

The page text is truncated before the detailed methodology and rule sources, so ruleset construction and the analyzer used are not covered here beyond the mention of Semgrep and Bandit as examples of conventional analyzers.

Preconditions

• You must control the decoding/serving layer and see the raw reasoning stream. The study used open-weight models for this reason. Closed APIs (GPT, Gemini) return only thought summaries, so this approach is out of reach there.
• Only reasoning models that draft code in their trace benefit.
• Repair evaluation ran on two locally deployed models, only on tasks where unassisted generation was already vulnerable.

Caveats

• The headline 72.8%–98.1% (from below 15%) is under a "corpus-calibrated ruleset", on tasks pre-selected for unassisted vulnerability. Expect less on general workloads, and calibration to the benchmarks may flatter results.
• Streaming detection was a replay over all six models, while live repair covered just two.
• Claims of fewer tokens and smaller regressions on false alarms are relative to post-hoc repair; the page text here gives no absolute figures.
• Coverage is limited to what the ruleset encodes.

What to do

If you run self-hosted reasoning models behind your own serving stack, this is a credible pattern to prototype: statement-level triggering inside code fences plus a taint-aware second track. The paper's code or artifact availability is not stated in the fetched text.