Pith. sign in

REVIEW 5 major objections 5 minor 38 references

Security reasoning in code LLMs is concentrated in a small neuron subset, and tuning only that subset makes generated code secure by default.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-03 00:58 UTC pith:QL4LJGZD

load-bearing objection A neat, clearly-written neuron-selective fine-tuning pipeline, but every security number relies on a judge that may share data with the fine-tuning set, so the headline results are not yet established. the 5 major comments →

arxiv 2602.10778 v2 pith:QL4LJGZD submitted 2026-02-11 cs.CR

GoodVibe: Security-by-Vibe for LLM-Based Code Generation

Maximilian Thang , Lichao Wu , Sasha Behrouzi , Mohamadreza Rostami , Jona te Lintelo , Stjepan Picek , Ahmad-Reza Sadeghi This is my paper
classification cs.CR
keywords code LLM securityneuron-level fine-tuninggradient-based attributionsecurity neuron identificationsecure code generation by defaultparameter-efficient fine-tuningvulnerability reductionvibe coding
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

GoodVibe claims that insecure-by-default code generation is not a capability problem but a targeting problem: inside a pretrained code LLM, the reasoning that decides whether code is secure is concentrated in a small subset of neurons, so updating only those neurons changes default behavior. The method finds these neurons by turning security into a binary classification task, reading the gradient magnitude each neuron contributes to that loss, and fine-tuning only the top neurons per layer while freezing the rest. It then groups correlated neurons so they share an update direction, cutting trainable parameters to an average of 1.9 million. Across six models and four languages, this lifts average safe-response rates from 35.1% to 87.5% on C++ and from 59.3% to 76.0% on Java, matching or beating full fine-tuning while keeping utility loss to an average of 0.84% on reasoning benchmarks. If correct, the result matters because it offers a cheap, inspectable route to secure-by-default code in fast 'vibe coding' workflows where security prompts are absent.

Core claim

The paper argues that security-relevant reasoning in code language models is structurally localized: a small subset of neurons, spread across low-level memory handling and higher-level API and control-flow logic, carries most of the influence over whether generated code is secure. GoodVibe identifies these neurons with gradient-based attribution — it recasts security assessment as a binary token-prediction task and measures the average magnitude of the loss gradient with respect to each neuron — then fine-tunes only that security-critical subspace, freezing everything else. It further clusters neurons with similar gradient profiles so they share a single update direction, making training cos

What carries the argument

The load-bearing mechanism is a gradient-based neuron importance score: for each linear layer of the transformer, GoodVibe computes the mean absolute gradient of a binary security-classification loss with respect to each neuron (a hidden dimension of the layer), selects the top-k neurons per layer, and fine-tunes only those weight rows while freezing all others. Clustering is the efficiency device: neurons with similar gradient profiles are grouped with k-means and share one update vector, so the number of trainable parameters scales with the number of clusters rather than the number of selected neurons. The same mechanism doubles as a structural claim — security judgment is distributed but

Load-bearing premise

The central claim rests on the learned judge model being a faithful measure of real code vulnerabilities; the paper itself calls the judge 'a consistent measurement instrument rather than an absolute oracle,' and no independent ground-truth evaluation is supplied.

What would settle it

Have independent security experts (or a vetted static analyzer) label the same generated-code samples that the judge scored, blinding them to which model produced each sample. If expert-labeled safe rates for GoodVibe-hardened and baseline models do not reproduce the reported gaps — roughly 35% to 87% on C++ and 59% to 76% on Java — the central claim fails.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Code LLMs can be made secure by default without full retraining, so security hardening becomes practical on modest compute for many open-weight models.
  • Because only a security-critical subspace changes, general coding and reasoning benchmarks stay within about one percent of the original model, mitigating the catastrophic forgetting often seen with full fine-tuning.
  • The gradient-attribution step identifies which internal units carry security reasoning, opening the door to inspecting and controlling security behavior instead of treating the model as a black box.
  • The method transfers to programming languages beyond the main experiments, indicating the identified subspace captures language-general security logic rather than dataset memorization.
  • Secure-by-default outputs reduce reliance on users writing security-specific prompts, which matters for informal 'vibe coding' workflows where prompts are short and security-agnostic.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A testable extension: re-score a held-out sample of generated code with independent human auditors or a production static analyzer; this would separate genuine vulnerability reduction from alignment with the paper's learned judge.
  • Because the same security-labeled dataset is used for neuron identification, fine-tuning, and judge training, distributional overlap could inflate the reported gains; the paper does not address this directly.
  • The low-dimensional security subspace suggests the recipe could transfer to other default behaviors — privacy, license compliance, or policy adherence — which the paper names as future work but does not demonstrate.
  • If localization generalizes, task-specific neuron subspaces might be composed in a single model without retraining, enabling modular, inspectable behavior control; the paper leaves composition untested.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 5 minor

Summary. GoodVibe proposes a neuron-level fine-tuning method to make code LLMs generate secure code by default. The method identifies a small set of 'security-critical' neurons via gradient-based attribution on a binary secure/insecure classification task, clusters these neurons by their gradient-importance profiles, and fine-tunes only the clustered update directions (i.e., only rows of weight matrices corresponding to selected neurons). The paper evaluates GoodVibe on six open-source LLMs (CodeLlama, Llama-3, Qwen3, Gemma-3) across C++, Java, Swift, and Go, using a fine-tuned Qwen3-0.6B judge model to label generated samples as secure or insecure. The main empirical claims are: (1) security-related reasoning is localized to a small neuron subspace; (2) GoodVibe improves safe-response rates from an average baseline of 35.1% to 87.5% (C++) and from 59.3% to 76.0% (Java), approaching or exceeding full fine-tuning; (3) this is achieved with ~1.9M trainable parameters on average and 2.4 PFLOPs on CodeLlama-7B, versus 6.2M and 8.6 PFLOPs for LoRA; and (4) general utility on GSM8K/ARC/MMLU is largely preserved (average 0.84% drop). The paper includes ablations on neuron-identification method, clustering, and hyperparameters, plus a discussion of the judge's reliability.

Significance. If the empirical claims are correct, GoodVibe is a meaningful contribution: it provides rare evidence that security-relevant behavior in code LLMs is concentrated in a small, identifiable subset of neurons, and that targeted adaptation can improve security at a fraction of full fine-tuning's parameter and compute cost. The paper is unusually transparent in documenting its pipeline, hyperparameter choices, ablations, and limitations. The use of multiple model families and languages, plus utility benchmarks, strengthens the generalizability story. However, the central result depends entirely on the validity of the automated judge model. Since the judge's training data is not disclosed and may overlap with the dataset used for neuron identification and fine-tuning, the headline improvements could reflect overfitting to the judge's learned patterns rather than real reductions in vulnerabilities. The paper also selects key hyperparameters (top-k=50, silhouette=0.05, epochs=2) on the same judge-based metric and reports single-run percentages without error bars. These issues must be resolved before the central claims can be accepted.

major comments (5)
  1. [§4.3, §5.1, §7] The validity of the automated judge is not established. All security metrics (Tables 1, 4–9) are produced by a Qwen3-0.6B judge fine-tuned on undisclosed security-labeled data. Section 5.1 states that CyberNative supplies the 424 secure/insecure pairs used for both neuron identification and fine-tuning, and that evaluation prompts are 'held-out' but 'drawn from the dataset.' Section 7 only says the judge is 'trained independently from all generation models,' which does not rule out overlap with CyberNative. If the judge's training distribution overlaps CyberNative, GoodVibe's improvements may reflect alignment with the judge's learned patterns rather than reduced real-world vulnerabilities. The paper explicitly concedes the judge is 'a consistent measurement instrument rather than an absolute oracle,' but consistency addresses noise, not systematic bias. The authors should disclose the j
  2. [§5.1, §6.2] Key hyperparameters (top-k=50, silhouette threshold=0.05, epochs=2) are selected by maximizing the same judge-based safe-response rate that is then reported as the main result. Section 6.2 shows that these values are peaks on the reported evaluation set. This is selection on the evaluation metric; without a separate validation set or nested cross-validation, the reported averages (87.5% C++, 76.0% Java) are optimistically biased. In addition, all tables report single-run percentages with no variance or confidence intervals. Given that the judge itself is stochastic and model generation is sampled, the lack of repeated runs makes it impossible to assess whether differences like GoodVibe's 87.5% vs LoRA's 87.4% on C++ are meaningful. Please provide runs/error bars and a holdout-based hyperparameter selection protocol.
  3. [§5.2, Table 1] The claim 'matching or exceeding full fine-tuning' is not supported by Table 1. On Java, the GoodVibe average is 76.0% vs full fine-tuning's 83.0%; only gemma-3-4b-it does better. On C++, the averages are close (87.5% vs 86.3%) but individual models vary widely (e.g., Meta-Llama-3-8B: 85.9% vs 96.5%). The abstract's 'matching or exceeding full fine-tuning' overstates the Java result. The paper should either present per-language averages and explain the discrepancy, or temper the claim to 'competitive with full fine-tuning on C++ but below it on Java.'
  4. [§6.1, Table 6] The clustering ablation undermines the claim that clustering is necessary for good security. Without clustering, average safe-response rates are higher on both C++ (90.0% vs 87.5%) and Java (82.6% vs 76.0%), with a large drop for gemma-3-12b on Java (84.0% → 61.3%). The paper attributes clustering's value to reduced parameters and training cost, but the title and abstract highlight 'security-by-vibe' improvements. If clustering consistently reduces security performance, the conclusion that 'both components are necessary' is misleading. The paper should either present the security-performance cost transparently and justify it as an efficiency trade-off, or reconsider the framing of clustering as a core security-enabling component.
  5. [§5.2, Table 3] The FLOPs numbers are surprising and lack supporting methodology. Why does LoRA (8.6 PFLOPs) cost almost twice full fine-tuning (4.5 PFLOPs), and why does GoodVibe (2.4 PFLOPs) reduce FLOPs by 46% relative to full fine-tuning when all methods must run forward and backward passes through the entire frozen base model? The paper says LoRA's increase stems from low-rank projections, but that does not explain a ~1.9x overhead; and GoodVibe's savings are not clearly tied to the number of trainable parameters (which do not directly affect FLOPs). Please provide the exact FLOPs-estimation procedure (layer-wise counting, attention included, optimizer states, etc.) and verify that the comparisons are apples-to-apples.
minor comments (5)
  1. [Abstract and Table 1] The abstract says 'over 4,700× fewer trainable parameters' and 'more than 3.6×' vs LoRA, but Table 3 shows 8.6/2.4 = 3.58, which rounds to 'over 3.5×' rather than 'more than 3.6×.' Also, Table 1 uses non-standard decimal conventions ('51,7%', '85,6') and the release time for Meta-Llama-3-8B-Instruct (2024.12) appears inconsistent with the known Llama-3 release; please verify.
  2. [§5.3, Table 4] Baseline (pre-trained) per-model results are omitted from Table 4 and only averages are given in the text. Since the table is meant to show GoodVibe vs LoRA, providing baselines would help readers assess the absolute improvement in Swift/Go.
  3. [§3.3, Eq. (1)] The expectation in Eq. (1) is not well-defined: it uses E_{(x,y)∼D} over gradient magnitudes, but gradient magnitudes are not necessarily integrable if the model has unbounded gradients. The practical averaging over a finite dataset is fine; please state that this is an empirical average and note any clipping.
  4. [§4.2, §6.2] The silhouette score threshold is described as controlling 'the number of clusters,' but silhouette scoring is a quality measure, not a clustering parameter. Please explain how a threshold on silhouette translates into a specific number of clusters, and clarify whether k is chosen beforehand or inferred from the criterion.
  5. [Appendix B] There are typos: 'lanugaes' and 'caan.' Also, the Go example uses 'copy(buffer[:], input)' in the baseline; the `copy` function is safe in Go (it copies at most len(dst) bytes), so calling this a buffer overflow is inaccurate. If the intended vulnerability is an unbounded copy into a fixed-size buffer, this is not a valid illustration in Go.

Circularity Check

0 steps flagged

No significant circularity: neuron selection and fine-tuning are self-contained; the one self-citation is not load-bearing, and the learned-judge evaluation is a validity limitation, not derivation-level circularity.

full rationale

The claimed derivation chain is not circular. GoodVibe selects security neurons via gradient magnitudes with respect to a binary security loss (Eq. 1), then solves a constrained fine-tuning problem (Eq. 5) on the same 424 CyberNative pairs; this is a standard feature-selection-plus-fine-tuning pipeline, not a reduction of the security prediction to the fitting procedure. The primary security metric (Section 4.3) is the output of a fixed Qwen3-0.6B judge model applied uniformly to all experimental conditions; the paper does not fit the judge to GoodVibe's outputs, and while the judge's training-data overlap with CyberNative is not disclosed or ruled out, that is a missing external-validation detail rather than a demonstrated identity between the fitted objective and the measured result. Section 7's own caveat that the judge is 'a consistent measurement instrument rather than an absolute oracle' is an explicit validity limitation, not an admission of a self-referential derivation. The only self-citation is reference [31] (Neurostrike), cited alongside an external reference [30] to justify an activation-based ablation baseline; it is not load-bearing for the central localization claim or for any headline result. Utility is checked on external benchmarks (GSM8K, ARC, MMLU), and the main comparisons are relative across methods, further reducing the risk that the central conclusion reduces to a self-citation or a by-construction identity.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 1 invented entities

The central empirical claim depends on a small set of hand-selected hyperparameters (top-k, silhouette threshold, epochs, learning rate) and on several domain assumptions about neuron attribution and the validity of the learned judge. There are no external benchmarks for the security measurement, and the 'security neuron' construct is not independently verified.

free parameters (4)
  • top-k selected neurons per layer = 50
    Table 8: k=50 yields the highest average safe rate (87.5%) on the judge-based evaluation; chosen empirically, not derived from theory.
  • silhouette clustering threshold = 0.05
    Table 7: threshold 0.05 gives the best average security rate; controls the number of neuron clusters and trainable parameters.
  • fine-tuning epochs = 2
    Table 9: 2 epochs outperform 1 and 3; selected on the evaluation metric.
  • learning rate / warmup ratio = 1e-4 / 0.1
    Fixed AdamW settings in Sections 4.2 and 5.1; not swept but determines the final neuron updates.
axioms (4)
  • domain assumption The expected gradient magnitude of the security loss with respect to a neuron's parameters identifies neurons that causally influence security behavior.
    Eq. (1) in Section 3.3; a standard attribution heuristic, not proven, and classification gradients may not identify neurons relevant for autoregressive generation.
  • domain assumption Security-relevant control logic is concentrated in a small top-k subset of neurons per layer.
    Section 3.2 design intuition; if false, the subspace update misses most security-critical structure.
  • domain assumption A fine-tuned Qwen3-0.6B judge provides valid security labels for short code snippets.
    Sections 4.3 and 7; judge reliability is only compared to its own base model, not to independent ground truth, and static/dynamic tools are dismissed rather than used as a check.
  • ad hoc to paper Optimizing the binary security classification task and fine-tuning on secure samples act on the same neuron subspace.
    Sections 3.3-4.2; task transfer from binary classification to code generation is assumed and not directly measured.
invented entities (1)
  • security-critical neuron subspace S no independent evidence
    purpose: The top-k gradient-selected neurons per layer that are updated during fine-tuning (Eqs. 3-6).
    Identified and evaluated only within GoodVibe's own pipeline; no external causal verification that these neurons are the actual locus of security behavior.

pith-pipeline@v1.3.0-alltime-deepseek · 19833 in / 13790 out tokens · 118482 ms · 2026-08-03T00:58:07.207043+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of GoodVibe: Security-by-Vibe for LLM-Based Code Generation." pith.science (2026). https://pith.science/paper/QL4LJGZD

@misc{pith2026260210778,
  author       = {Pith},
  title        = {Pith review of: GoodVibe: Security-by-Vibe for LLM-Based Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QL4LJGZD}},
  note         = {Machine review of arXiv:2602.10778}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Large language models (LLMs) are increasingly used for code generation in fast, informal development workflows, often referred to as vibe coding, where speed and convenience are prioritized, and security requirements are rarely made explicit. In this setting, models frequently produce functionally correct but insecure code, creating a growing security risk. Existing approaches to improving code security rely on full-parameter fine-tuning or parameter-efficient adaptations, which are either costly and prone to catastrophic forgetting or operate at coarse granularity with limited interpretability and control. We present GoodVibe, a neuron-level framework for improving the security of code language models by default. GoodVibe is based on the key insight that security-relevant reasoning is localized to a small subset of neurons. We identify these neurons using gradient-based attribution from a supervised security task and perform neuron-selective fine-tuning that updates only this security-critical subspace. To further reduce training cost, we introduce activation-driven neuron clustering, enabling structured updates with minimal overhead. We evaluate GoodVibe on six LLMs across security-critical programming languages, including C++, Java, Swift, and Go. GoodVibe substantially improves the security of generated code while preserving general model utility, achieving up to a 2.5x improvement over base models, achieving performance competitive with full fine-tuning while using over 4,700x fewer trainable parameters, and reducing training computation by more than 3.6x compared to the parameter-efficient baseline (LoRA). Our results demonstrate that neuron-level optimization offers an effective and scalable approach to securing code generation without sacrificing generality.

Figures

Figures reproduced from arXiv: 2602.10778 by Ahmad-Reza Sadeghi, Jona te Lintelo, Lichao Wu, Maximilian Thang, Mohamadreza Rostami, Sasha Behrouzi, Stjepan Picek.

Figure 1
Figure 1. Figure 1: An Overview of the Security Neuron Identification Pipeline. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: An Overview of the Cluster-based Security Optimization Pipeline. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Utility evaluation before and after GoodVibe fine-tuning across the GSM8K, ARC, and MMLU benchmarks. Numeric [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: visualizes the clustering structure of security-critical neurons within the self-attention mechanism of CodeLlama￾7B-Instruct, focusing on the query, key, and value projection submodules (q_proj, k_proj, and v_proj) from representa￾tive layers. Each point corresponds to a single neuron, with its vertical position indicating gradient-based importance for security prediction and its color denoting cluster me… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

38 extracted references · 12 linked inside Pith

  1. [1]

    Application of large language models to software engineering tasks: Opportunities, risks, and implications,

    I. Ozkaya, “Application of large language models to software engineering tasks: Opportunities, risks, and implications,”IEEE Software, vol. 40, no. 3, pp. 4–8, 2023

    2023

  2. [2]

    Evaluating large language models trained on code,

    M. Chen, “Evaluating large language models trained on code,”arXiv preprint arXiv:2107.03374, 2021

    Pith/arXiv arXiv 2021

  3. [3]

    Gemini Code Assist: AI-first coding in your natural language,

    Google, “Gemini Code Assist: AI-first coding in your natural language,” https://codeassist.google/, 2025

    2025

  4. [4]

    Survey reveals AI’s impact on the developer experience,

    I. Shani and G. Staff, “Survey reveals AI’s impact on the developer experience,” https://github.blog/news-insights/research/ survey-reveals-ais-impact-on-the-developer-experience/ #methodology, 2023

    2023

  5. [5]

    A review on vibe coding: Fundamentals, state- of-the-art, challenges and future directions,

    P. P. Ray, “A review on vibe coding: Fundamentals, state- of-the-art, challenges and future directions,”Authorea Preprints, 2025

    2025

  6. [6]

    Is vibe coding safe? benchmarking vulnerability of agent- generated code in real-world tasks,

    S. Zhao, D. Wang, K. Zhang, J. Luo, Z. Li, and L. Li, “Is vibe coding safe? benchmarking vulnerability of agent- generated code in real-world tasks,”arXiv preprint arXiv:2512.03262, 2025

    arXiv 2025

  7. [7]

    Security vulnerabilities in ai- generated code: A large-scale analysis of public github repositories,

    M. Schreiber and P. Tippe, “Security vulnerabilities in ai- generated code: A large-scale analysis of public github repositories,” inInternational Conference on Informa- tion and Communications Security. Springer, 2025, pp. 153–172

    2025

  8. [8]

    We have a package for you! a com- prehensive analysis of package hallucinations by code generating {LLMs},

    J. Spracklen, R. Wijewickrama, A. N. Sakib, A. Maiti, and B. Viswanath, “We have a package for you! a com- prehensive analysis of package hallucinations by code generating {LLMs},” in34th USENIX Security Sympo- sium (USENIX Security 25), 2025, pp. 3687–3706

    2025

  9. [9]

    Large language models for code: Security hardening and adversarial testing,

    J. He and M. Vechev, “Large language models for code: Security hardening and adversarial testing,” inProceed- ings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 1865–1879

    2023

  10. [10]

    In- struction tuning for secure code generation,

    J. He, M. Vero, G. Krasnopolska, and M. Vechev, “In- struction tuning for secure code generation,”arXiv preprint arXiv:2402.09497, 2024

    Pith/arXiv arXiv 2024

  11. [11]

    Fine-tuning aligned language models compromises safety, even when users do not intend to!

    X. Qi, Y . Zeng, T. Xie, P.-Y . Chen, R. Jia, P. Mittal, and P. Henderson, “Fine-tuning aligned language models compromises safety, even when users do not intend to!” arXiv preprint arXiv:2310.03693, 2023

    Pith/arXiv arXiv 2023

  12. [12]

    Lora: Low-rank adaptation of large language models

    E. J. Hu, Y . Shen, P. Wallis, Z. Allen-Zhu, Y . Li, S. Wang, L. Wang, W. Chenet al., “Lora: Low-rank adaptation of large language models.”ICLR, vol. 1, no. 2, p. 3, 2022

    2022

  13. [13]

    Parameter- efficient fine-tuning of large-scale pre-trained language models,

    N. Ding, Y . Qin, G. Yang, F. Wei, Z. Yang, Y . Su, S. Hu, Y . Chen, C.-M. Chan, W. Chenet al., “Parameter- efficient fine-tuning of large-scale pre-trained language models,”Nature machine intelligence, vol. 5, no. 3, pp. 220–235, 2023

    2023

  14. [14]

    Code llama: Open foundation models for code,

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remezet al., “Code llama: Open foundation models for code,”arXiv preprint arXiv:2308.12950, 2023

    Pith/arXiv arXiv 2023

  15. [15]

    Parameter-efficient fine-tuning methods for pretrained language models: A critical review and assessment,

    L. Xu, H. Xie, S. J. Qin, X. Tao, and F. L. Wang, “Parameter-efficient fine-tuning methods for pretrained language models: A critical review and assessment,” IEEE Transactions on Pattern Analysis and Machine Intelligence, 2026

    2026

  16. [16]

    Parameter-efficient fine-tuning for foundation models,

    D. Zhang, T. Feng, L. Xue, Y . Wang, Y . Dong, and J. Tang, “Parameter-efficient fine-tuning for foundation models,”arXiv preprint arXiv:2501.13787, 2025

    Pith/arXiv arXiv 2025

  17. [17]

    A mathematical framework for transformer circuits,

    N. Elhage, N. Nanda, C. Olsson, T. Henighan, N. Joseph, B. Mann, A. Askell, Y . Bai, A. Chen, T. Conerlyet al., “A mathematical framework for transformer circuits,” Transformer Circuits Thread, vol. 1, no. 1, p. 12, 2021

    2021

  18. [18]

    Qwen3 technical report,

    A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lvet al., “Qwen3 technical report,”arXiv preprint arXiv:2505.09388, 2025

    Pith/arXiv arXiv 2025

  19. [19]

    A survey on llm-as-a- judge,

    J. Gu, X. Jiang, Z. Shi, H. Tan, X. Zhai, C. Xu, W. Li, Y . Shen, S. Ma, H. Liuet al., “A survey on llm-as-a- judge,”The Innovation, 2024

    2024

  20. [20]

    Think you have solved question answering? try arc, the ai2 reasoning challenge,

    P. Clark, I. Cowhey, O. Etzioni, T. Khot, A. Sabharwal, C. Schoenick, and O. Tafjord, “Think you have solved question answering? try arc, the ai2 reasoning challenge,” arXiv preprint arXiv:1803.05457, 2018

    Pith/arXiv arXiv 2018

  21. [21]

    Training verifiers to solve math word problems,

    K. Cobbe, V . Kosaraju, M. Bavarian, M. Chen, H. Jun, L. Kaiser, M. Plappert, J. Tworek, J. Hilton, R. Nakano, C. Hesse, and J. Schulman, “Training verifiers to solve math word problems,”arXiv preprint arXiv:2110.14168, 2021

    Pith/arXiv arXiv 2021

  22. [22]

    Measuring massive mul- titask language understanding,

    D. Hendrycks, C. Burns, S. Basart, A. Zou, M. Mazeika, D. Song, and J. Steinhardt, “Measuring massive mul- titask language understanding,”Proceedings of the In- ternational Conference on Learning Representations (ICLR), 2021

    2021

  23. [23]

    The llama 3 herd of models,

    A. Dubey, A. Jauhri, A. Pandey, A. Kadian, A. Al-Dahle, A. Letman, A. Mathur, A. Schelten, A. Yang, A. Fan et al., “The llama 3 herd of models,”arXiv e-prints, pp. arXiv–2407, 2024. 15

    2024

  24. [24]

    Gemma 3 technical report,

    G. Team, A. Kamath, J. Ferret, S. Pathak, N. Vieillard, R. Merhej, S. Perrin, T. Matejovicova, A. Ramé, M. Riv- ièreet al., “Gemma 3 technical report,”arXiv preprint arXiv:2503.19786, 2025

    Pith/arXiv arXiv 2025

  25. [25]

    Cybernative.ai code vulnerabil- ity and security dataset,

    Cybernative.ai, “Cybernative.ai code vulnerabil- ity and security dataset,” 2024. [Online]. Available: https://huggingface.co/datasets/CyberNative/ Code_Vulnerability_Security_DPO

    2024

  26. [26]

    Learning from mistakes: a comprehensive study on real world concur- rency bug characteristics,

    S. Lu, S. Park, E. Seo, and Y . Zhou, “Learning from mistakes: a comprehensive study on real world concur- rency bug characteristics,” inProceedings of the 13th international conference on Architectural support for programming languages and operating systems, 2008, pp. 329–339

    2008

  27. [27]

    Sok: Eter- nal war in memory,

    L. Szekeres, M. Payer, T. Wei, and D. Song, “Sok: Eter- nal war in memory,” in2013 IEEE Symposium on Secu- rity and Privacy. IEEE, 2013, pp. 48–62

    2013

  28. [28]

    A survey of mobile malware in the wild,

    A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A survey of mobile malware in the wild,” inProceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices, 2011, pp. 3–14

    2011

  29. [29]

    Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,

    S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y . Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” ACM sigplan notices, vol. 49, no. 6, pp. 259–269, 2014

    2014

  30. [30]

    Twin- break: Jailbreaking llm security alignments based on twin prompts,

    T. Krauß, H. Dashtbani, and A. Dmitrienko, “Twin- break: Jailbreaking llm security alignments based on twin prompts,”arXiv preprint arXiv:2506.07596, 2025

    Pith/arXiv arXiv 2025

  31. [31]

    Neurostrike: Neuron-level attacks on aligned llms,

    L. Wu, S. Behrouzi, M. Rostami, M. Thang, S. Picek, and A.-R. Sadeghi, “Neurostrike: Neuron-level attacks on aligned llms,”Network and Distributed System Secu- rity (NDSS) Symposium, 2026

    2026

  32. [32]

    An empiri- cal study of the copy and paste behavior during devel- opment,

    T. M. Ahmed, W. Shang, and A. E. Hassan, “An empiri- cal study of the copy and paste behavior during devel- opment,” in2015 IEEE/ACM 12th Working Conference on Mining Software Repositories. IEEE, 2015, pp. 99–110

    2015

  33. [33]

    Secure-instruct: An automated pipeline for synthesizing instruction-tuning datasets using llms for secure code generation,

    J. Li, F. Rabbi, B. Yang, S. Wang, and J. Yang, “Secure-instruct: An automated pipeline for synthesizing instruction-tuning datasets using llms for secure code generation,”arXiv preprint arXiv:2510.07189, 2025

    arXiv 2025

  34. [34]

    Hex- acoder: Secure code generation via oracle-guided syn- thetic training data,

    H. Hajipour, L. Schönherr, T. Holz, and M. Fritz, “Hex- acoder: Secure code generation via oracle-guided syn- thetic training data,”arXiv preprint arXiv:2409.06446, 2024

    Pith/arXiv arXiv 2024

  35. [35]

    Prom- sec: Prompt optimization for secure generation of func- tional source code with large language models (llms),

    M. Nazzal, I. Khalil, A. Khreishah, and N. Phan, “Prom- sec: Prompt optimization for secure generation of func- tional source code with large language models (llms),” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 2266–2280

    2024

  36. [36]

    Sgcode: A flex- ible prompt-optimizing system for secure generation of code,

    K. Ton, N. Nguyen, M. Nazzal, A. Khreishah, C. Borcea, N. Phan, R. Jin, I. Khalil, and Y . Shen, “Sgcode: A flex- ible prompt-optimizing system for secure generation of code,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 5078–5080

    2024

  37. [37]

    Seccoder: Towards generaliz- able and robust secure code generation,

    B. Zhang, T. Du, J. Tong, X. Zhang, K. Chow, S. Cheng, X. Wang, and J. Yin, “Seccoder: Towards generaliz- able and robust secure code generation,”arXiv preprint arXiv:2410.01488, 2024

    Pith/arXiv arXiv 2024

  38. [38]

    The menlo report,

    M. Bailey, D. Dittrich, E. Kenneally, and D. Maughan, “The menlo report,”IEEE Security & Privacy, vol. 10, no. 2, pp. 71–75, 2012. 16 Appendix A Neuron Cluster Visualization Figure 4 visualizes the clustering structure of security-critical neurons within the self-attention mechanism of CodeLlama- 7B-Instruct, focusing on the query, key, and value projecti...

    2012