Pith. sign in

REVIEW 3 major objections 5 minor 47 references

A Mixture of Linear Corrections Generates Secure Code

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Large language models hide code-security knowledge that prompts cannot reach, and nudging their hidden states in the right direction makes generated code safer without hurting function.

desk verdict Plausible inference-time steering for secure code generation, with a real distribution-mismatch gap between probe training and application that the paper doesn't close. read the letter →

arxiv 2507.09508 v1 pith:MKMX3X6G submitted 2025-07-13 cs.CR cs.AI

Weichen Yu , Ravi Mangal , Terry Zhuo , Matt Fredrikson , Corina S. Pasareanu This is my paper
classification cs.CRcs.AI
keywords codevulnerabilitydetectionlinearprobingrepresentationengineeringactivationsteeringsecuregenerationmixtureofcorrectionsCWEinference-timeintervention
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Code-generating large language models appear unable to spot vulnerabilities when asked directly: prompting with few-shot examples and CWE descriptions hovers near chance. This paper argues that the knowledge is not missing but locked in the models' hidden states: lightweight linear probes trained on final-token activations of secure/vulnerable function pairs classify vulnerabilities far above prompting accuracy. The paper then turns those probe directions into a mixture of per-CWE correction vectors that are added to hidden states at inference time, but only when a probe judges the current token prefix at risk. On Qwen2.5-Coder-7B this raises the security ratio by 8.9 percentage points while HumanEval pass@1 also rises by 2.1 points, indicating that security can be improved without paying a functionality cost. The broader claim is that controlled vulnerability management in generated code is achievable by manipulating internal representations rather than retraining or engineering prompts.

What carries the argument

The load-bearing object is the mixture of corrections, a per-CWE set of linear vectors $\Delta s_j$ (group-mean difference, decision-boundary normal, PCA-reduced normal, or a network prediction) that are added to the hidden state $s$ at a chosen transformer block during generation. The conditional gate is the linear probe $c_j(s)$, trained on complete paired samples, applied to every partially generated prefix; only when $\arg\max c_j(s)=0$ (vulnerable) is the correction applied, and an exponential decay $\alpha(t)$ prevents accumulation over long generations. This gating plus decay is what lets the model nudge token probabilities without distorting ordinary, secure generation.

What would settle it

Take any CWE from the SVEN set, run the model with the probe switched on at every token, and record whether the probe's verdict at each partial prefix matches the eventual CodeQL verdict of the completed generation. If prefix-level probe accuracy is at chance or heavily biased toward 'vulnerable' on prefixes that finish secure, the conditional gate misfires and the reported 8.9% security gain on Qwen2.5-Coder-7B should not reproduce; the same experiment without the gate isolates the gate's contribution.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that decoder-only code LLMs encode vulnerability-sensitive linear directions in their activation space, and that perturbing hidden states along those directions during generation shifts output away from vulnerable code. For each of nine CWE types, the authors train a linear probe on the hidden state at the last token of complete secure/vulnerable pairs, pick the transformer block with the lowest probe loss, and derive a correction vector by one of four means: the difference of secure and vulnerable class centroid means, the normal vector of the probe's decision boundary, a PCA-compressed version of that normal vector, or a small neural network that maps current hidden states to corrections. At generation time the probe is re-applied at every new token; if it flags the current prefix as vulnerable, the corresponding decayed correction is added to the hidden state, and several such corrections are combined linearly if multiple CWEs fire. Evaluated with CodeQL on the SVEN test set, the method raises the security ratio and, in most configurations, holds or improves HumanEval pass@1; reversing the signs of corrections adversarially increases the fraction of vulnerable code, and corrections trained on Qwen2.5-Coder transfer partially to Qwen2.5-Instruct at the 3B and 7B sizes.

Load-bearing premise

The load-bearing premise is that a probe trained on hidden states of complete finished functions still correctly classifies the hidden states of partial code prefixes at each intermediate generation step; the paper does not establish that this transfer of vulnerability judgments to unfinished code holds.

Editorial extensions

If this is right

  • Linear probes on hidden states detect vulnerable code markedly better than few-shot prompting across Qwen2.5-Coder and CodeLlama families.
  • The conditional mixture of corrections lifts the security ratio on the SVEN test set while generally preserving or slightly improving HumanEval pass@1, so hardening need not trade away function.
  • Reversing the corrections at inference time makes models deliberately emit more vulnerable code, offering a cheap way to produce adversarial examples for future security training.
  • Correction vectors transfer between same-architecture models at some sizes, so one model's vulnerability knowledge can harden another without retraining.
  • The method only targets the known CWE classes whose paired data was used; novel or unseen vulnerability types are outside its scope.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The conditional gate is the real crux: since corrections fire only when the probe flags a prefix, the whole mechanism inherits the probe's reliability on partial code, which the paper does not measure; a prefix-tuned probe or a CodeQL-informed gate would be a direct test of that assumption.
  • The free functionality gain hints that the vulnerability subspace overlaps with bug-prone code; a sharp testable extension is whether the correction also removes runtime errors on bug-injection benchmarks beyond HumanEval.
  • Transfer across same-family models suggests vulnerability directions may be a shared representational basis, so a small diagnostic model could in principle produce correction vectors for a whole model family, avoiding per-model probe training.
  • MoC is symmetric: the same machinery that hardens code can deliberately poison it, so deployment needs the same access controls as any dual-use capability.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper investigates whether code-generation LLMs internally encode vulnerability-discriminative information, and proposes a mixture of linear corrections (MoC) applied at inference time to steer generation toward secure code. The authors train linear probes on hidden states from paired secure/vulnerable SVEN examples, derive correction vectors from probe weights, class-mean differences, PCA-reduced normal vectors, or a dynamic neural network, and at decoding time add a decaying correction only when a probe flags the current hidden state as vulnerable. The reported headline results are an 8.9 percentage-point improvement in CodeQL security ratio and a 2.1 percentage-point improvement in HumanEval pass@1 for Qwen2.5-Coder-7B, together with an adversarial weakening mode and some cross-model transfer between Qwen2.5 variants.

Significance. If the central claim holds, the paper makes a useful practical contribution: secure-code steering that is inference-time only, does not require fine-tuning, and is cheap enough to run on a single GPU even for 14B models. The use of CodeQL as an external security oracle, the inclusion of an adversarial weakening direction, and the transferability experiments are concrete strengths. The method is described in enough detail to be reimplementable, and the code is promised to be available. However, the headline deltas are small (1 to 3 percentage points on HumanEval), no statistical uncertainty is reported, and the conditional gate is evaluated only indirectly; these issues currently limit how strongly the empirical claims can be asserted.

major comments (3)
  1. [Section 3.3 and Algorithm 1, with Table 5] The probe used as the conditional gate is trained in Section 3.1 on hidden states at the last token of complete secure/vulnerable function pairs, but at inference Algorithm 1 (line 6) applies the same probe to hidden states of partial prefixes at every decoding step. These are different distributions, and the paper provides no direct evidence that probe decisions on prefixes are semantically meaningful. Table 5 shows that removing the condition hurts both security and functionality, but this only establishes that reducing the applied correction helps; it does not establish that the probe fires on prefixes that will actually produce vulnerable code. The observed gains could in principle come from a gate that happens to fire often enough to inject corrections without destroying output quality, effectively acting as a damping schedule rather than as a vulnerability detector. The authors should report probe accuracy on partial prefixes at various generation lengths, or correlate gate firings with the eventual CodeQL outcome of sampled continuations, and compare against a random gate matched for firing rate.
  2. [Section 4.2, Table 3, and the abstract] The central quantitative claims are reported without error bars, confidence intervals, or test-set sizes for the generation experiments. Several functional deltas are 1 to 3 percentage points (e.g., 79.9 to 81.2 for the normal-vector method on QC-7B), which is within the range that could flip with a single seed or a small number of HumanEval samples. In addition, the abstract attributes the 2.1% HumanEval improvement to the same configuration that yields the 8.9% security gain, but in Table 3 the 8.9% gain comes from the Dynamic NN-based row (85.7 vs. 76.8) whose HumanEval gain is only 1.3 points, while the 2.1% gain appears in the Normal Vector row. The paper should report the number of generation runs, multiple seeds, and a variance or significance measure, and should make the correspondence between the abstract's headline numbers and specific table rows exact.
  3. [Section 4.1, Tables 2, 14, and 15] The probe-accuracy results that support the claim that LLMs 'encode precise internal representations' are computed on an evaluation subset drawn from the same SVEN corpus used to train the probes, with training set sizes as small as 50 to 150 examples per vulnerability class. This makes the reported accuracies partly a measure of in-distribution fitting of the benchmark rather than evidence of a general internal vulnerability concept. The generation results in Section 4.2 use a different SVEN test set, so the central generation claim is not invalidated by this issue, but the detection claim should be either re-framed as benchmark-specific or validated on a held-out corpus such as Devign or a different CWE distribution.
minor comments (5)
  1. [Section 3.3, Eq. (5)] The notation 'argmax(c_j(s)) = 0' is ambiguous about which class index corresponds to 'vulnerable' and how multiple vulnerabilities are combined; Eq. (5) displays a single correction but the text says multiple corrections are added as a linear combination, so the equation should be written with a sum over j and a clear class-index convention.
  2. [Algorithm 1, line 9] Line 9 uses the symbol Delta s_j^m, while the training stage only defines Delta s_j^c for c in {g,n,r,t}; the subscript should be aligned with the loop index and the method actually evaluated.
  3. [Section 4.2 and Table 3] The experimental setup should state whether HumanEval pass@1 is computed with greedy decoding or sampling, how many generations per problem are used, and how CodeQL queries are configured; these details are needed for exact reproduction.
  4. [Throughout] There are several typos and formatting slips: 'transfomer', 'vectores', 'vulnerabiliies', and 'Boarder Impact' (presumably 'Broader Impact') in Appendix A.3; these should be corrected in revision.
  5. [Section 4.2, RQ6] The explanation for the free functionality improvement cites a correlation between bug-prone code and vulnerabilities, but no evidence is offered that the correction vectors are specifically removing buggy code; a speculative explanation should be labeled as such or accompanied by a concrete analysis.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the probe and correction vectors are trained on held-out splits of the SVEN benchmark, and the headline security/functionality gains are measured externally with CodeQL and HumanEval.

full rationale

The paper's claimed derivation chain is not circular. The linear probes (Section 3.1, Eq. 1) are trained with cross-entropy on paired vulnerable/secure samples and evaluated on a separate evaluation set (Section 4.1, Table 2), which is standard supervised evaluation rather than a fitted input being renamed as a prediction. The correction vectors (Eqs. 2, 3, 6, 7 and the dynamic network in Section 3.2.2) are derived from the same training data, but the headline claims about secure code generation are not reductions of those fits: security ratios are computed by an external static analyzer, CodeQL, on a held-out SVEN test split, and functionality is measured by HumanEval pass@1 (Section 4.2). The conditional gate and decay (Eqs. 4-5, Table 5) are ablations, not fitted parameters that predetermine the outcome. There are no uniqueness theorems, no load-bearing self-citations, and no definitional equivalences: the paper does not define the security improvement in terms of probe accuracy or correction magnitude. A legitimate validity concern exists—probes are trained on the last-token hidden state of complete functions (Section 3.1) but applied to hidden states of partial prefixes at every token during generation (Algorithm 1, line 6)—but this is a train/test distribution mismatch, not a circular step, and it does not make the measured CodeQL/HumanEval gains true by construction. Accordingly, the paper is self-contained against external benchmarks and receives a score of 0.

Assumptions & free parameters 4 free parameters · 3 assumptions · 0 invented entities

The method combines known ingredients: linear probes, group-mean or normal-vector corrections, PCA, and a small MLP. The main load-bearing assumptions are the transfer of complete-code probe decisions to partial prefixes, the validity of CodeQL as the security oracle, and architecture-matched cross-model transfer. There are no new physical or ontological entities.

free parameters (4)
  • Decay schedule alpha(t) = Not stated
    Negative exponential used to weaken corrections as generation proceeds; ablation shows it strongly affects functionality (Table 5), yet the rate is not reported.
  • Loss weights beta_1, beta_2, beta_3 in dynamic NN = Not stated
    Weights for MSE, cross-entropy, and KL losses in the dynamic correction network; no values given.
  • PCA dimension d' for reduced normal vector = 50 to 100
    Hidden states are compressed to d' between 50 and 100 for the PCA variant; the specific value used in reported results is not given.
  • Probe training epochs and learning rate = 50 to 200 epochs, lr 5e-4
    Reported, but the choice per CWE is not specified, and the probe block is selected by smallest training loss, which risks overfitting.
assumptions (3)
  • domain assumption Linear probe trained on final-token hidden states of complete functions generalizes to hidden states of partial code prefixes during generation
    Section 3.3 and Algorithm 1 apply probes at every generated token; no experiment validates probe accuracy on partial code.
  • domain assumption CodeQL on the SVEN generation test set is a faithful proxy for real-world code security
    Section 4.2 evaluates security only through CodeQL on a synthetic benchmark; CodeQL misses vulnerability classes outside its queries.
  • domain assumption Correction vectors computed at one transformer block transfer to the same block index of a different model with matched hidden dimension
    Section RQ5, Table 6: results are mixed and functionality degrades on 7B and 14B models, so this assumption is only weakly supported.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Mixture of Linear Corrections Generates Secure Code." pith.science (2026). https://pith.science/paper/MKMX3X6G

@misc{pith2026250709508,
  author       = {Pith},
  title        = {Pith review of: A Mixture of Linear Corrections Generates Secure Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MKMX3X6G}},
  note         = {Machine review of arXiv:2507.09508}
}
read the original abstract

Large language models (LLMs) have become proficient at sophisticated code-generation tasks, yet remain ineffective at reliably detecting or avoiding code vulnerabilities. Does this deficiency stem from insufficient learning about code vulnerabilities, or is it merely a result of ineffective prompting? Using representation engineering techniques, we investigate whether LLMs internally encode the concepts necessary to identify code vulnerabilities. We find that current LLMs encode precise internal representations that distinguish vulnerable from secure code--achieving greater accuracy than standard prompting approaches. Leveraging these vulnerability-sensitive representations, we develop an inference-time steering technique that subtly modulates the model's token-generation probabilities through a mixture of corrections (MoC). Our method effectively guides LLMs to produce less vulnerable code without compromising functionality, demonstrating a practical approach to controlled vulnerability management in generated code. Notably, MoC enhances the security ratio of Qwen2.5-Coder-7B by 8.9\%, while simultaneously improving functionality on HumanEval pass@1 by 2.1\%.

Figures

Figures reproduced from arXiv: 2507.09508 by the authors.

Figure 1
Figure 1. Left: The state-of-the-art code generation models cannot achieve high accuracy by purely [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Mixture of corrections (MoC). There are four ways to obtain corrections for each vulnera [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Ablations on i th attention blocks. RQ6: Why can the MoC gain the improvement on functionality for free? As in [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

47 extracted references · 31 canonical work pages

  1. [1]

    GitHub CodeQL, 2025.https://github.com/github/codeql

    CodeQL. GitHub CodeQL, 2025.https://github.com/github/codeql

    work page 2025

  2. [2]

    Controllable text generation for large language models: A survey

    Xun Liang, Hanyu Wang, Yezhaohui Wang, Shichao Song, Jiawei Yang, Simin Niu, Jie Hu, Dan Liu, Shunyu Yao, Feiyu Xiong, and Zhiyu Li. Controllable text generation for large language models: A survey. arXiv preprint arXiv:2408.12599, 2024

    arXiv 2024

  3. [3]

    Generalization- enhanced code vulnerability detection via multi-task instruction fine-tuning

    Xiaohu Du, Ming Wen, Jiahao Zhu, Zifan Xie, Bin Ji, Huijun Liu, Xuanhua Shi, and Hai Jin. Generalization- enhanced code vulnerability detection via multi-task instruction fine-tuning. InACL (Findings), 2024

    work page 2024

  4. [4]

    Security vulnerability detection with multitask self-instructed fine-tuning of large language models.arXiv preprint arXiv:2406.05892, 2024

    Aidan ZH Yang, Haoye Tian, He Ye, Ruben Martins, and Claire Le Goues. Security vulnerability detection with multitask self-instructed fine-tuning of large language models.arXiv preprint arXiv:2406.05892, 2024

    arXiv 2024

  5. [5]

    Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions

    Terry Yue Zhuo, Vu Minh Chien, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, Simon Brunner, Chen Gong, James Hoang, Armel Randy Zebaze, Xiaoheng Hong, Wen-Ding Li, Jean Kaddour, Ming Xu, Zhihan Zhang, Prateek Yadav, Naman Jain, Alex Gu, Zhoujun Cheng, Jiawei Liu, Qian Liu, Zijian Wang, Davi...

    work page 2025

  6. [6]

    Doccgen: Document-based controlled code generation

    Sameer Pimparkhede, Mehant Kammakomati, Srikanth Tamilselvam, Prince Kumar, Ashok Kumar, and Pushpak Bhattacharyya. Doccgen: Document-based controlled code generation. InProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, pages 18681–18697, 2024

    work page 2024

  7. [7]

    Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag

    Xueying Du, Geng Zheng, Kaixin Wang, Jiayi Feng, Wentai Deng, Mingwei Liu, Bihuan Chen, Xin Peng, Tao Ma, and Yiling Lou. Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag. CoRR, 2024

    work page 2024

  8. [8]

    Representation engineering: A top-down approach to ai transparency.CoRR, 2023

    Andy Zou, Long Phan, Sarah Chen, James Campbell, Phillip Guo, Richard Ren, Alexander Pan, Xuwang Yin, Mantas Mazeika, Ann-Kathrin Dombrowski, and others. Representation engineering: A top-down approach to ai transparency.CoRR, 2023

    work page 2023

Show all 47 references
  1. [9]

    Taxonomy, opportunities, and challenges of representation engineering for large language models.arXiv preprint arXiv:2502.19649, 2025

    Jan Wehner, Sahar Abdelnabi, Daniel Tan, David Krueger, and Mario Fritz. Taxonomy, opportunities, and challenges of representation engineering for large language models.arXiv preprint arXiv:2502.19649, 2025

    2025

  2. [10]

    Vulnerability detection with code language models: How far are we?arXiv preprint arXiv:2403.18624, 2024

    Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomair, David Wagner, Baishakhi Ray, and Yizheng Chen. Vulnerability detection with code language models: How far are we?arXiv preprint arXiv:2403.18624, 2024

    2024 arXiv

  3. [11]

    Vuldebert: A vulnerability detection system using bert

    Soolin Kim, Jusop Choi, Muhammad Ejaz Ahmed, Surya Nepal, and Hyoungshick Kim. Vuldebert: A vulnerability detection system using bert. In2022 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), pages 69–74. IEEE, 2022

    2022

  4. [12]

    Assbert: Active and semi- supervised bert for smart contract vulnerability detection.Journal of Information Security and Applications, 73:103423, 2023

    Xiaobing Sun, Liangqiong Tu, Jiale Zhang, Jie Cai, Bin Li, and Yu Wang. Assbert: Active and semi- supervised bert for smart contract vulnerability detection.Journal of Information Security and Applications, 73:103423, 2023

    2023

  5. [13]

    Vulrepair: a t5- based automated software vulnerability repair

    Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. Vulrepair: a t5- based automated software vulnerability repair. InProceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering, p...

    2022

  6. [14]

    Large language model for vulnerability detection: Emerging results and future directions

    Xin Zhou, Ting Zhang, and David Lo. Large language model for vulnerability detection: Emerging results and future directions. InProceedings of the 2024 ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results, pages 47–51, 2024

    2024

  7. [15]

    The internal state of an llm knows when it’s lying.arXiv preprint arXiv:2304.13734, 2023

    Amos Azaria and Tom Mitchell. The internal state of an llm knows when it’s lying.arXiv preprint arXiv:2304.13734, 2023

    2023 arXiv

  8. [16]

    States hidden in hidden states: Llms emerge discrete state representations implicitly.arXiv preprint arXiv:2407.11421, 2024

    Junhao Chen, Shengding Hu, Zhiyuan Liu, and Maosong Sun. States hidden in hidden states: Llms emerge discrete state representations implicitly.arXiv preprint arXiv:2407.11421, 2024

    2024 arXiv

  9. [17]

    Towards inference-time category-wise safety steering for large language models

    Amrita Bhattacharjee, Shaona Ghosh, Traian Rebedea, and Christopher Parisien. Towards inference-time category-wise safety steering for large language models. InNeurips Safe Generative AI Workshop 2024. 10

    2024

  10. [18]

    Steering llama 2 via contrastive activation addition

    Nina Rimsky, Nick Gabrieli, Julian Schulz, Meg Tong, Evan Hubinger, and Alexander Turner. Steering llama 2 via contrastive activation addition. InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 15504–15522, 2024

    2024

  11. [19]

    Challenges with applying vulnera- bility prediction models

    Patrick Morrison, Kim Herzig, Brendan Murphy, and Laurie Williams. Challenges with applying vulnera- bility prediction models. InProceedings of the 2015 Symposium and Bootcamp on the Science of Security, pages 1–9, 2015

    2015

  12. [20]

    Do bugs foreshadow vulnerabilities? a study of the chromium project

    Felivel Camilo, Andrew Meneely, and Meiyappan Nagappan. Do bugs foreshadow vulnerabilities? a study of the chromium project. In2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, pages 269–279. IEEE, 2015

    2015

  13. [21]

    Chatgpt for vulnerability detection, classification, and repair: How far are we? In2023 30th Asia-Pacific Software Engineering Conference (APSEC), pages 632–636

    Michael Fu, Chakkrit Kla Tantithamthavorn, Van Nguyen, and Trung Le. Chatgpt for vulnerability detection, classification, and repair: How far are we? In2023 30th Asia-Pacific Software Engineering Conference (APSEC), pages 632–636. IEEE, 2023

    2023

  14. [22]

    Llms cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks

    Saad Ullah, Mingji Han, Saurabh Pujar, Hammond Pearce, Ayse Coskun, and Gianluca Stringhini. Llms cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks. In2024 IEEE Symposium on Security and Privacy (SP...

    2024

  15. [23]

    Enhancing static analysis for practical bug detection: An llm-integrated approach.Proceedings of the ACM on Programming Languages, 8(OOPSLA1):474–499, 2024

    Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. Enhancing static analysis for practical bug detection: An llm-integrated approach.Proceedings of the ACM on Programming Languages, 8(OOPSLA1):474–499, 2024

    2024

  16. [24]

    Llm4vuln: A unified evaluation framework for decoupling and enhancing llms’ vulnerability reasoning.arXiv preprint arXiv:2401.16185, 2024

    Yuqiang Sun, Daoyuan Wu, Yue Xue, Han Liu, Wei Ma, Lyuye Zhang, Yang Liu, and Yingjiu Li. Llm4vuln: A unified evaluation framework for decoupling and enhancing llms’ vulnerability reasoning.arXiv preprint arXiv:2401.16185, 2024

    2024 arXiv

  17. [25]

    Instruction tuning for secure code generation

    Jingxuan He, Mark Vero, Gabriela Krasnopolska, and Martin Vechev. Instruction tuning for secure code generation. InForty-first International Conference on Machine Learning

  18. [26]

    Prosec: Fortifying code llms with proactive security alignment.arXiv preprint arXiv:2411.12882, 2024

    Xiangzhe Xu, Zian Su, Jinyao Guo, Kaiyuan Zhang, Zhenting Wang, and Xiangyu Zhang. Prosec: Fortifying code llms with proactive security alignment.arXiv preprint arXiv:2411.12882, 2024

    2024 arXiv

  19. [27]

    Apilot: Navigating large language models to generate secure code by sidestepping outdated api pitfalls

    Weiheng Bai, Keyang Xuan, Pengxiang Huang, Qiushi Wu, Jianing Wen, Jingjing Wu, and Kangjie Lu. Apilot: Navigating large language models to generate secure code by sidestepping outdated api pitfalls. arXiv preprint arXiv:2409.16526, 2024

    2024 arXiv

  20. [28]

    Indict: Code generation with internal dialogues of critiques for both security and helpfulness

    Hung Le, Doyen Sahoo, Yingbo Zhou, Caiming Xiong, and Silvio Savarese. Indict: Code generation with internal dialogues of critiques for both security and helpfulness. InThe Thirty-eighth Annual Conference on Neural Information Processing Systems, 2024

    2024

  21. [29]

    Under- standing the effectiveness of large language models in detecting security vulnerabilities.arXiv preprint arXiv:2311.16169, 2023

    Avishree Khare, Saikat Dutta, Ziyang Li, Alaia Solko-Breslin, Rajeev Alur, and Mayur Naik. Under- standing the effectiveness of large language models in detecting security vulnerabilities.arXiv preprint arXiv:2311.16169, 2023

    2023 arXiv

  22. [30]

    Learning code preference via synthetic evolution.arXiv preprint arXiv:2410.03837, 2024

    Jiawei Liu, Thanh Nguyen, Mingyue Shang, Hantian Ding, Xiaopeng Li, Yu Yu, Varun Kumar, and Zijian Wang. Learning code preference via synthetic evolution.arXiv preprint arXiv:2410.03837, 2024

    2024 arXiv

  23. [31]

    Per- sonalized steering of large language models: Versatile steering vectors through bi-directional preference optimization

    Yuanpu Cao, Tianrong Zhang, Bochuan Cao, Ziyi Yin, Lu Lin, Fenglong Ma, and Jinghui Chen. Per- sonalized steering of large language models: Versatile steering vectors through bi-directional preference optimization. InThe Thirty-eighth Annual Conference on Neural Information Pr...

  24. [32]

    Adaptive activation steering: A tuning-free llm truthfulness improvement method for diverse hallucinations categories

    Tianlong Wang, Xianfeng Jiao, Yinghao Zhu, Zhongzhi Chen, Yifan He, Xu Chu, Junyi Gao, Yasha Wang, and Liantao Ma. Adaptive activation steering: A tuning-free llm truthfulness improvement method for diverse hallucinations categories. InProceedings of the ACM on Web Conference ...

    2025

  25. [33]

    Large language models for code: Security hardening and adversarial testing

    Jingxuan He and Martin Vechev. Large language models for code: Security hardening and adversarial testing. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pages 1865–1879, 2023

    2023

  26. [34]

    Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374, 2021

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, and others. Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374, 2021. 11

    2021 arXiv

  27. [35]

    Codegeex: A pre-trained model for code generation with multilingual benchmarking on humaneval-x

    Qinkai Zheng, Xiao Xia, Xu Zou, Yuxiao Dong, Shan Wang, Yufei Xue, Lei Shen, Zihan Wang, Andi Wang, Yang Li, and others. Codegeex: A pre-trained model for code generation with multilingual benchmarking on humaneval-x. InProceedings of the 29th ACM SIGKDD Conference on Knowledg...

    2023

  28. [36]

    Solving quantitative reasoning problems with language models.Advances in Neural Information Processing Systems, 35:3843–3857, 2022

    Aitor Lewkowycz, Anders Andreassen, David Dohan, Ethan Dyer, Henryk Michalewski, Vinay Ramasesh, Ambrose Slone, Cem Anil, Imanol Schlag, Theo Gutman-Solo, and others. Solving quantitative reasoning problems with language models.Advances in Neural Information Processing Systems...

    2022

  29. [37]

    A survey on large language models for code generation.arXiv preprint arXiv:2406.00515, 2024

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. A survey on large language models for code generation.arXiv preprint arXiv:2406.00515, 2024

    2024 arXiv

  30. [38]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, and others. Qwen2. 5-coder technical report.arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  31. [39]

    Code llama: Open foundation models for code

    Wenhan Xiong Grattafiori, Alexandre Défossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis Martin, Nicolas Usunier, Thomas Scialom, and Gabriel Synnaeve. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950, 2023

    2023 arXiv

  32. [40]

    Understanding intermediate layers using linear classifier probes, 2017

    Guillaume Alain and Yoshua Bengio. Understanding intermediate layers using linear classifier probes, 2017

    2017

  33. [41]

    Linevul: A transformer-based line-level vulnerability pre- diction

    Michael Fu and Chakkrit Tantithamthavorn. Linevul: A transformer-based line-level vulnerability pre- diction. InProceedings of the 19th International Conference on Mining Software Repositories, pages 608–620, 2022

    2022

  34. [42]

    Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks.Advances in neural information processing systems, 32, 2019

    Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks.Advances in neural information processing systems, 32, 2019. 12 A Appendix A.1 Detailed expe...

    2019

  35. [43]

    And the CodeLlama series tend to regard the CWE-416, CWE-476 and CWE-787 as safe, as in Table 12 and Table 13

    Difference CWE types shows every different trends, for example, the CWE-125, CWE-190, CWE-416, CWE-476, CWE-787 contains mostly codes in language c, and Qwen-25-Coder series tend to think they are safe, as in Table 8, Table 9 and Table 10. And the CodeLlama series tend to rega...

  36. [44]

    And overall, the QC series show a better instruction following ability than CL series, as the Invalid rates are lower

    Overall, QwenCoder series are more recently developed and shows better abilities than CodeLlama series. And overall, the QC series show a better instruction following ability than CL series, as the Invalid rates are lower. Table 7: Accuracy of vulnerable code detection by dire...

  37. [45]

    Possible reasons are that the PCA reduced too much information that may be essential for vulnerability detection

    Overall, the non-PCA probe in Table 14 shows better results than PCA reduced probes in Table 15. Possible reasons are that the PCA reduced too much information that may be essential for vulnerability detection. 13 Table 9: Accuracy of vulnerable code detection by direct prompt...

  38. [46]

    And these shows a higher accuracy than other CWEs, especially on QC-14B and 7B models

    Overall, the CWE-022, CWE-078, CWE-079, and CWE-089 are mostly based on python language. And these shows a higher accuracy than other CWEs, especially on QC-14B and 7B models

  39. [47]

    The CWE-125 and CWE-476 are kind of hard to detect, especially, as the model gets larger, the accuracy on these two CWE-types are not getting higher, which indicates that their vulnerable features are harder to extract. A.3 Boarder Impact Our work on code vulnerability detecti...

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.