Skip to main content
Back to timeline
arXivSource publication:

Code gets caught inside the reasoning stream: a security rule fires, the model rewrites in place, and secure-and-working runs rise from under 15% to 72.8%–98.1%

Synopsis

Reasoning models draft code early inside their chain of thought, and SecReason scans the streaming tokens before delivery and inserts a warning so the model repairs the draft within the same reasoning trace, raising the share of runs that are both secure and functionally correct from below 15% to 72.8%–98.1%.

Source-provided article image: SecReason: Vulnerability Detection and In-Stream Self-Repair for LLM Code Generation
Figure 1 · arXiv

Interpretation

The defense moves into the window before code is delivered: the model has already written a full implementation inside its reasoning stream, where the draft exists only as tokens, and SecReason inspects it there and has the model revise it in place. Earlier defenses act before any code exists, constrained decoding limits token choices without guiding repair, and post-hoc repair must regenerate the full response after generation completes. On CWEval and SecCodeBench, for tasks where unassisted generation introduces vulnerabilities, SecReason raises the share of runs delivering secure and functionally correct code from below 15% to 72.8%–98.1%, across two locally deployed self-repair models and both benchmarks.

It recognizes completed statements by incremental parsing and scans security rules on two tracks: a statement-local track checks each statement as it is emitted, and a context-dependent track traces dataflows across the accumulated code. Static analyzers expect complete, syntactically valid files, whereas reasoning streams interleave partial code with natural-language text, so scanning must trigger on statement completion rather than wait for a code fence to close. The implementation runs on SGLang with incremental Tree-sitter parsers and a semgrep-core backend, natively supporting Python, JavaScript, Java, C, and C++; replaying reasoning streams from 173 tasks and six models detected every flagged insecure generation, with a median of 54%–82% of the stream still remaining at the first finding.

When a rule fires, SecReason interrupts generation, inserts an in-stream warning addressed to the model, and resumes decoding from the existing prefix so the model repairs the draft within the ongoing reasoning trace. Post-hoc repair inspects code only after generation completes, and repairing then requires regenerating the full response, which increases token consumption and risks breaking working code. On CWEval and SecCodeBench, SecReason reaches the highest Secure & Func. rate in every cell of the comparison table and consumes fewer tokens on average than post-hoc repair; re-run under the official registry rules, insecure deliveries still fall below unassisted generation.

Perspective

The mechanism targets the inference serving layer, acting as an optional monitor between the inference engine and downstream clients; it inspects only the streams a model itself generates and leaves model weights and training data untouched. It requires raw reasoning tokens, which excludes closed-source APIs that return only thought summaries, and the self-repair experiments run on only two locally deployed models, Qwen3.6-35B-A3B and Gemma-4-26B-A4B. Evaluation covers 173 tasks in five languages from CWEval and SecCodeBench at unit-level generation, leaving repository-scale development and multi-step agentic pipelines untested; extraction anchors on markdown code fences, so code drafted outside them is not analyzed.

The corpus-calibrated ruleset is synthesized and evaluated on the same task pool, and task-level leakage remains possible: synthesizing rules on a random half of the tasks yields high recall on the synthesis half but much lower recall on the held-out half, indicating the rules detect the corpus they were calibrated on rather than general vulnerability patterns, so the ruleset is an instrument for this benchmark's task pool and the intervention results measure the mechanism at a near-upper-bound operating point. Self-repair can introduce functional regressions, with functional failure rates rising on SecCodeBench for Gemma and Qwen, mainly because models call out-of-task or version-incompatible APIs during repair. The false-positive study shows that when a warning lands inside an unclosed code fence, functional failure is higher, so the cost is functional rather than a security regression. Qualitative analyses rely on manual inspection, and interpreting reasoning traces is subject to chain-of-thought unfaithfulness.