LLM code generation gains real-time security scanning and repair
SecReason: Vulnerability Detection and In-Stream Self-Repair for LLM Code Generation
Cryptography and SecuritySoftware Engineering
Summary
Code generated by large language models (LLMs) can unexpectedly have security bugs that are hard to catch if we only check if code works. The authors propose SecReason, a method that watches the code as the LLM writes it, spotting security issues right when they appear. Instead of fixing problems later by rewriting everything, SecReason pauses the LLM, warns it, and lets the model fix the issue immediately in the same flow. This approach greatly improves how often the generated code is both safe and functionally correct without wasting extra resources.
What this means in practice
- •For software development teams: Improve code safety in AI-assisted programming by detecting and fixing security flaws during code generation.
- •For software security analysts: Reduce false negatives and functional regressions by integrating real-time vulnerability detection into AI code review workflows.
Authors
Ruidong Han, Zhensu Sun, Chengyan Ma, Yuqing Niu, Siqi Ma, David Lo
Abstract
Large language models (LLMs) may introduce security vulnerabilities into generated code, which can persist into production when verification focuses on functional correctness. Existing defenses act before, during, or after generation, but none inspects the code during generation. Security prompts and retrieved security knowledge act before any code exists, constrained decoding limits token choices but cannot guide repair, and post-hoc repair must regenerate the full response. Reasoning LLMs draft code early in their streamed chain of thought, and in this pre-delivery window the code exists only inside the reasoning stream. We present SecReason, an in-stream defense that monitors this window. Dual-track incremental scanning applies security rules, checking each statement as it is emitted and tracing dataflows across the accumulated code. When a security rule fires, SecReason interrupts generation, inserts an in-stream warning, and resumes decoding, so the model repairs the draft within the same reasoning trace without regenerating the full response. On tasks where unassisted generation introduces vulnerabilities, \system raises the share of runs delivering secure and functionally correct code from below 15\% to 72.8\%--98.1\% on \tool{CWEval} and \tool{SecCodeBench}. \system consumes fewer tokens than post-hoc repair, and when security rules misfire on secure code, it limits the functional regressions from false warnings.