Source-linked AI summary
Securing AI-Generated Code: A Just-in-Time Vulnerability Detection and Remediation Pipeline
Mikhail Surikov
TL;DR
AI-generated code creates a need for automated remediation grounded in threat context, which existing tools largely lack. The paper evaluates a detection-to-verification pipeline across models and finds that enriched remediation reduces findings, with richer scanner context improving outcomes further.
Problem
Existing tools detect vulnerability patterns but rarely ground automated remediation in system-level threat context or support an end-to-verification loop.
Method
The pipeline combines parallel static analysis, independent LLM validation, threat-context enrichment, LLM-generated fixes, and post-fix rescanning across two configurations.
Results
Across all four models, P1 reduced static-analyzer findings and P2 deepened the reduction, confirming both hypotheses in a unanimous direction.
Takeaways & Limitations
Generation quality and remediation effectiveness are distinct, so end-to-end evaluation should emphasize post-remediation outcomes rather than baseline security alone.
Takeaways & Limitations
The count-based verdict measures static-finding reduction rather than exploitability, so it cannot establish that remaining findings are unexploitable or resolved findings were genuinely dangerous.
Abstract
from arXiv · showhide
AI-assisted development tools generate vulnerable code at significant rates, yet few automated mechanisms exist to detect, enrich, fix, and verify security issues at development velocity, particularly ones that ground remediation in real-world threat context. This paper presents an automated security evaluation pipeline that generates Python code from LLMSecEval prompts, scans for vulnerabilities using CodeQL and Bandit in parallel with an independent Code Validator LLM, enriches the Code Validator findings with MITRE ATT&CK techniques, CWE Observed Examples, and Python best practice guidelines, generates fixes via the Code Generation LLM, and re-scans with CodeQL and Bandit to verify outcomes. Two pipeline configurations were evaluated: Pipeline 1 (P1), using enriched Code Validator findings only, and Pipeline 2 (P2), where it additionally receives the initial CodeQL and Bandit findings. Both configurations were run across four Claude models: Opus 4.8, Sonnet 4.6, Sonnet 5, and Haiku 4.5, producing 80 runs against 26 LLMSecEval prompts covering 9 CWE categories. P1 reduced static analyzer findings across all four models, ranging from -9% (Opus 4.8) to -54% (Sonnet 5). P2 deepened these reductions further, ranging from -29% (Opus 4.8) to -69% (Haiku 4.5), with P2 outperforming P1 for every model. Verdict consistency averaged approximately 81% modal agreement across all configurations, with P2 marginally more stable than P1. Remediation introduced new vulnerabilities in 15-22% of cases: roughly 70% involved a single new finding, and P2 reduced churn for three of four models, with Sonnet 5 as the sole exception. Notably, the best Code Generation LLM (Opus 4.8) was not the best pipeline performer, as Sonnet 4.6 produced the lowest residual findings and highest pass rate after P2 remediation, suggesting that pipeline effectiveness and first-draft security are distinct properties.
1 Introduction · 2 Background & Related Work
AI-generated code creates security risks that outpace conventional review and analysis, while existing tools lack threat-context reasoning and targeted remediation. This paper addresses the gap with a pipeline combining static analysis, independent LLM validation, threat-context enrichment, generated fixes, and rescanning.
- 1 Introduction: AI-generated code arrives faster than review processes can absorb and may receive less scrutiny because of automation bias.
- 1 Introduction: Existing tools detect known vulnerability patterns but do not reason about enabled threat context or generate targeted, enriched fixes.
- 1 Introduction: The proposed pipeline generates Python from LLMSecEval prompts, scans with CodeQL and Bandit alongside an independent validator, enriches findings, generates fixes, and rescans the results.
- 2.1 Vulnerability rates in AI-generated code: 45% of code samples generated by AI models failed security tests, while newer and larger models showed no security improvement.
- 2.2 Evaluation benchmark: 150 prompts spanning 18 CWE categories define LLMSecEval, while this study uses 26 prompts across 9 Python-relevant CWE categories covered by its static analyzers.
- 2.3 CWE-specific prompting as mitigation: CWE-specific prompting consistently outperforms generic security instructions, with reported vulnerability-rate reductions reaching 56%, 68.7%, and 77% across prior studies.
- 2.4 Hybrid SAST and LLM triage: SAST-Genius achieved a 91% reduction in false positives by combining static analysis with LLM triage based on code context, data flow, and taint paths.
- 2.5 Threat modeling and ATT&CK enrichment: Unlike SAST-Genius’s structural enrichment, this pipeline grounds remediation in MITRE ATT&CK techniques and CWE Observed Examples, while related work supports structured threat knowledge and ATT&CK mapping.
3 Methodology
The methodology evaluates two remediation hypotheses through a seven-stage pipeline on 26 LLMSecEval prompts spanning nine CWE weaknesses. It compares enrichment-only remediation with remediation additionally informed by initial static-analyzer findings, using model-specific baselines and four outcome metrics.
- Hypotheses: The study tested H1 that enriched validation improves security versus baseline and H2 that adding initial static findings further improves remediation.Both hypotheses assessed post-remediation outcomes through reductions in static-analyzer findings compared with baseline.
- Dataset: 26 LLMSecEval prompts covered nine CWE weaknesses, including injection, traversal, deserialization, credential, validation, and permission-assignment vulnerabilities.The dataset included SQL injection, OS command injection, path traversal, deserialization of untrusted data, hard-coded credentials, cross-site scripting, improper input validation, insufficiently protected credentials, and incorrect permission assignment.
- Pipeline architecture: 7 stages comprised code generation, parallel pre-fix scanning and validation, finding enrichment, remediation, post-fix scanning, and result storage.The pipeline used tool-specific stages for scanning, validation, enrichment, code fixing, verification, and storing results.
- Experimental configurations: P1 supplied enriched Code Validator findings with threat, weakness, and Python guidance, whereas P2 additionally supplied initial CodeQL and Bandit findings.P2 tested whether concrete line-specific scanner evidence improved remediation beyond enrichment context alone.
- Evaluation metrics: Four metrics assessed outcomes: resolution rate, verdict distribution, new vulnerability introduction rate, and consistency.Baseline was the model-specific average of CodeQL and Bandit findings on freshly generated code; zero findings passed, fewer than baseline was partial, and at least baseline was fail.
4 Implementation / Solution
The pipeline is implemented as a reproducible Python system with independently configured, traceable Claude model roles and local security-analysis data. Sequential execution combines concurrent scanning and validation with defensive error handling, syntax checks, persistence, and dashboard monitoring.
- Core implementation: Python 3.12, PostgreSQL 16 in Docker, and Streamlit implement the pipeline, while Claude CLI subprocesses provide reproducible model calls without the Claude API.The Code Generation LLM and Code Validator LLM are configured independently through environment variables and recorded per run for traceability.
- Security analysis: CodeQL and Bandit outputs are normalized into unified findings and deduplicated by (CWE, line), with CodeQL authoritative when findings overlap.Finding records include rule ID, mapped CWE, severity, and line.
- Execution and reliability: Seven pipeline stages execute sequentially per prompt, while scanning and Code Validator assessment run concurrently via asyncio.Subprocesses have explicit timeouts, generated and fixed code undergoes ast.parse validation with one retry, and modules return typed safe-default errors.
- Monitoring and persistence: The Streamlit dashboard covers live monitoring, historical results, consistency analysis, baseline comparison, and aggregate findings, with CSV export.Ongoing step details are saved to the database for further analysis.
5 Evaluation
Across complete runs of 26 prompts, P1 and P2 reduced static-analyzer findings for every model, with P2 consistently outperforming P1. Evaluation also showed model-ranking reversals, occasional vulnerability churn, and approximately 81% verdict agreement.
- Hypothesis validation: −9% to −54%: P1 reduced static-analyzer findings versus baseline for every model, confirming H1.The range spans Opus 4.8 at −9% and Sonnet 5 at −54%.
- Hypothesis validation: −42% to −57%: P2 deepened the pooled average reduction versus baseline and outperformed P1 for every model, confirming H2.The direction was unanimous across all four models.
- Model rankings: 0.48 residual and 75.4% pass rate: Sonnet 4.6 achieved the best outcome after P2 remediation, despite Opus 4.8 having the strongest baseline.Opus 4.8 had baseline 0.82 and 54% clean at generation.
- New vulnerability introduction: 15–22%: Remediations introduced at least one new finding across models and configurations; P2 reduced churn for three of four models.Sonnet 5 was the exception, with churn increasing from 20.4% under P1 to 21.9% under P2.
- Verdict consistency: Approximately 81%: Verdict stability averaged this modal agreement across models and configurations, with P2 marginally more stable than P1.Modal agreement averaged the share of runs reaching the most common verdict per prompt over 26 prompts.
6 Discussion & Analysis
Across all four models, enriched findings reduced vulnerabilities, and adding initial static-analyzer findings deepened those reductions. The results also show that remediation effectiveness differs from first-draft security and carries persistent regression risk.
- Pipeline effectiveness: Both hypotheses were confirmed unanimously: P1 reduced static-analyzer findings, while P2 deepened reductions by adding initial CodeQL and Bandit findings.The enrichment approach generalized across models of different sizes and capabilities.
- Model performance: Opus 4.8 generated the most secure first draft but finished second after P2 remediation, while Sonnet 4.6 ended with the cleanest result.Baseline generation quality and end-to-end remediation effectiveness were therefore distinct properties.
- Regression risk: P2 reduced remediation churn for three of four models, indicating that richer fix context improved resolution while lowering newly introduced issues.Sonnet 5 was the sole exception, so the churn reduction was not universal.
7 Limitations
The study’s conclusions are limited by its narrow Python- and Claude-specific scope, static-analysis-only evaluation, severity-insensitive metrics, and unassessed training exposure, functionality, and statistical robustness.
- Scope: The study covers Python generation, nine CWE categories, 26 prompts, and four Claude models from one family, limiting generalizability.Results may not extend to other languages, broader CWE coverage, or models from different providers or architectures.
- Evaluation: Static analysis detects known patterns but misses runtime-dependent flaws, so a passing verdict does not confirm security or exploitability.CodeQL and Bandit may miss logic errors, authentication flaws, race conditions, and context-dependent vulnerabilities; flagged findings may be unreachable.
- Metrics: The verdict and resolution metrics count all findings equally, potentially misrepresenting practical security impact across severity levels.A high-severity SQL injection and a low-severity informational warning each count as one finding.
- Generalizability and robustness: Potential prompt exposure, unmeasured functional correctness, and 10 runs per configuration constrain interpretation of improvement rates, regressions, and statistical tendencies.Training exposure may inflate improvements, security fixes may introduce functionality regressions, and the limited runs provide only statistical tendencies.
8 Threats to Validity
The study’s validity is constrained by count-based security verdicts and reliance on an LLM-driven remediation process. External validity is limited by the Python-only, synthetic, narrow-model evaluation, restricting generalization to broader development settings.
- Internal validity: Count-based verdicts treat fewer static findings as improved security without establishing that remaining findings are unexploitable or resolved findings were genuinely dangerous.This creates a gap between measured finding reduction and demonstrated exploitability or danger.
- Internal validity: The Code Validator LLM drives remediation prompting in P1 and supplements static findings in P2, making pipeline outcomes dependent on its classifications.P1 uses enriched Code Validator findings only, whereas P2 adds initial CodeQL and Bandit findings.
- External validity: The evaluation covers Python, nine CWE categories, 26 synthetic LLMSecEval prompts, and four Claude models from one family, limiting generalization to other languages, weaknesses, code, and providers.Synthetic prompts may elicit vulnerability patterns that differ from those arising organically in production codebases.
9 Future Work
Future work should broaden evaluation across languages, weaknesses, and model types while strengthening validation with functional, runtime, and dynamic testing. Additional priorities include severity-aware analysis, practical workflow integration, and cross-model pipeline pairings.
- Evaluation scope: Future evaluations should expand beyond Python and nine CWE categories to JavaScript, Java, broader MITRE CWE Top 25 weaknesses, and models spanning providers, architectures, and open-source systems.These extensions would strengthen the generalizability of the findings.
- Evaluation methodology: Future methodology should test functional correctness and supplement CodeQL and Bandit with runtime and dynamic analysis to detect additional vulnerability classes.Functional testing would verify that remediated code remains executable and behaviorally correct.
- Metrics and analysis: Severity-weighted verdicts and CWE-level remediation breakdowns could distinguish critical from minor fixes and reveal which vulnerability categories respond most or least effectively.These metrics would provide a more nuanced and granular assessment of enrichment-based remediation.
- Pipeline extensions: Future work should test real-time deployment through IDE plugins or CI/CD gates and evaluate cross-model pairings instead of always assigning the same model to generation and validation.The workflow experiments would assess practical adoption and whether stronger validators improve pipeline performance.
10 Summary and Conclusion
The paper presents an automated security evaluation pipeline that enriches vulnerability findings with threat-context and best-practice guidance for remediation. Its results show that this structured enrichment generalizes across models, while scanner evidence improves outcomes and post-fix verification remains necessary because remediation can introduce regressions.
- Pipeline contribution: The pipeline uses separate Code Generation and Code Validator LLM roles, enriching findings with MITRE ATT&CK techniques, CWE Observed Examples, and Python best practices.The enrichment is incorporated directly into the remediation prompt.
- Cross-model findings: Structured, CWE-aware enrichment generalizes across models with different sizes and capabilities.
- Remediation outcomes: Richer fix context, including concrete scanner evidence, consistently improves remediation outcomes.
- Verification requirement: Post-fix verification is necessary because automated remediation introduces an inherent risk of new vulnerabilities.The observed vulnerability-introduction rates across configurations support treating verification as a required pipeline component.
11 AI Usage Acknowledgement
The author used Claude for grammar and spelling correction and Claude Code as a coding co-pilot, while retaining responsibility for the research, design, and written content.
- AI Usage Acknowledgement: Claude corrected grammar and spelling while preserving the author’s original language and style.Claude Code also provided architectural guidance and assistance with writing and debugging code under the author’s direction and review.
- AI Usage Acknowledgement: The author retained ownership of all research conclusions, design decisions, and written content.
A Project Repository
The full project codebase and an AES-256 encrypted database snapshot are available in a Georgia Tech repository, with a public mirror also provided.
- A Project Repository: The full project codebase and AES-256 encrypted database snapshot are available in a Georgia Tech repository, alongside a public mirror.Repository: https://github.gatech.edu/msurikov3/Securing_AT_Generated_Code; public mirror: https://github.com/Droidsurikov/securing-ai-generated-code