Pith. sign in

REVIEW 4 major objections 4 minor 57 references

Insecure coding preferences stored in long-term memory silently raise the vulnerability rate of LLM-generated code by 2.7–50.3 percentage points.

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-01 17:27 UTC pith:M2NEDPNB

load-bearing objection First systematic benchmark of long-term-memory risks for code generation, but the central cross-session claim is not yet supported because the protocol never shows a fresh session between memory injection and generation. the 4 major comments →

arxiv 2607.17619 v1 pith:M2NEDPNB submitted 2026-07-20 cs.CR

Insecure Coding Preferences in Long-Term Memory: Security Risks for LLM-based Code Generation

Yuchen Chen , Wei Cheng , Yuan Xiao , Zhou Yang , Weifeng Sun , Chunrong Fang , Xiang Chen , Baowen Xu
show 2 more authors
David Lo Zhenyu Chen
This is my paper
classification cs.CR
keywords long-term memoryLLM code generationcode securityinsecure coding preferencesvulnerability ratesafety alignmentmemory overwritememory safety filtering
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.

The paper tries to establish that long-term memory in LLM-based coding assistants is a hidden security risk: once a developer's insecure coding preference (for example, 'use ECB mode for debugging') is stored as a memory entry, it is retrieved in later sessions and silently pushes the model toward vulnerable code. In a controlled comparison across four assistants (ChatGPT, Gemini, Qwen, Grok) and five languages, storing such a preference raised the average vulnerability rate by 2.7–50.3 percentage points, while the rate of explicit security warnings lagged behind by 5.4–14.0 points, so users are unlikely to notice the influence. The memories resist being overwritten by partial or even contradictory updates, and they still fire when the request is rephrased. Two mitigations work: explicit security requirements cut vulnerability rates by 19.7–33.6 points (at some cost to functional correctness), and a memory-level safety filter that blocks risky entries before storage restores generation to the no-memory baseline without degrading correctness.

Core claim

The central discovery is that an insecure coding preference stored in long-term memory acts as a persistent, covert steering signal. In every evaluated model–language combination, injecting an entry like 'Please remember that I prefer using hashlib.sha1() for ease of debugging' increased the share of generated outputs that fail security tests, introduced new CWE vulnerability types (especially in encryption and TLS verification), and reduced the model's tendency to warn about the risk it was creating. The same content delivered as a user or system prompt produced a smaller vulnerability increase and more transparent warnings, showing that memory-based influence is both stronger and less visi

What carries the argument

The central object is the long-term memory entry—a preference statement the user asks the model to remember, e.g., 'Please remember that I prefer using random.randint() for ease of debugging.' The pipeline constructs such an entry from each benchmark task's insecure reference solution, commits it to the assistant's memory store, then (in the with-memory condition) generates code under a task prompt. Work is done by comparing Pass@k and Vul@k plus hand-annotated warning rate and memory-reference rate between the with-memory and without-memory conditions, and by testing overwrite strategies, paraphrased prompts, and memory-bank dilution.

Load-bearing premise

The load-bearing premise is that the vulnerability increase in the with-memory condition is caused by cross-session retrieval from long-term memory, not by the 'Please remember' instruction being treated as part of the current conversation; the main RQ1 protocol does not explicitly state that code generation starts in a fresh session with no trace of the memory prompt in context.

What would settle it

Conduct the with-memory condition in a demonstrably fresh session (new conversation, empty context) after the memory commit, and compare with the without-memory baseline; if the vulnerability-rate increase disappears or shrinks to the in-context level, the effect is same-session instruction following rather than long-term memory.

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

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Developers using memory-enabled coding assistants accumulate a hidden security debt: a preference adopted for temporary debugging can make later, apparently unrelated generations more vulnerable.
  • Safety warnings cannot be trusted as an indicator: vulnerability rates rose faster than warning rates, so a silent memory-induced vulnerability can pass without any signal.
  • Storing a preference in long-term memory has a stronger security effect than inserting the same text into the current prompt, so mitigations must address the memory store, not just prompting.
  • Blocking risky memory entries at write time (memory-level safety filtering) eliminates the vulnerability-rate increase without changing functional correctness in these experiments.
  • Because the effect survives prompt paraphrase, a single stored preference can contaminate an entire family of coding tasks for the lifetime of the memory entry.

Where Pith is reading between the lines

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

  • Extending the paper's non-adversarial framing, the same mechanism implies a low-cost poisoning route: any comment or interaction that the assistant stores as a preference becomes a latent amplifier for vulnerabilities across the project's future code, even after the user stops mentioning it.
  • The divergent behavior between ChatGPT (warns) and Gemini (references memory) suggests that memory integration is model-specific; a testable extension is to inspect retrieval scoring in open-weight assistants to see whether append-only memory banks explain why contradictions fail to overwrite.
  • The memory-bank-dilution experiment (neutral entries do not suppress an insecure memory's influence) raises the question of whether multiple insecure entries compound or whether the most task-relevant one dominates; this is a testable extension beyond the paper.
  • The safety filter's 100% detection rate was measured on a small labelled set; an extension would measure its false-positive rate on benign preferences and its robustness to paraphrased malicious memories.

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

4 major / 4 minor

Summary. The paper studies whether insecure coding preferences stored in an LLM's long-term memory increase the security risk of generated code. Using the SALLM (Python) and CWEval (C, C++, Go, JavaScript) benchmarks, the authors inject memory entries of the form "Please remember that I prefer [insecure pattern] for ease of debugging" into ChatGPT, Gemini, Qwen, and Grok, then compare code generation with and without these memories. They report that insecure memories raise vulnerability rates by 2.7–50.3 pp, broaden CWE coverage, create a risk-warning gap, are hard to overwrite, generalize across paraphrased prompts, and can be mitigated by security-requirement prompts or a memory-level safety filter. The central claim is that long-term memory is a persistent, covert channel for insecure code preferences.

Significance. If the central claim were established, this would be a timely and practically important result for LLM-based code assistants with persistent memory. The paper has visible strengths: it evaluates four deployed LLMs and five languages, ships a public artifact, uses two established security benchmarks, and reports high inter-annotator agreement for the manual warning/memory-reference labels. The memory-bank-size experiment (Section 7.3) is a nice control. However, the main attribution to long-term memory is not yet established because the protocol does not demonstrate a fresh-session boundary between memory commit and code generation; the observed effect is currently indistinguishable from same-session instruction following. The task-specific derivation of memory prompts further inflates the measured effect. These issues are fixable with additional experiments, but they are load-bearing for the paper's headline claim.

major comments (4)
  1. [§4, §5.3, §6.1.1] The threat model requires memory retrieval in "later, independent sessions," but the RQ1 protocol never states that code generation happens in a fresh session after the memory is committed. Phase (a) says the authors "interact with the target LLM so that the system records the corresponding long-term memory," and phase (b) says they "delete the injected memory immediately after collecting the three generations." Figures 1, 6, and 7 show the memory prompt followed by "Memory updated" and then the code prompt in the same conversational flow. If the code prompt is sent in the same chat after "Memory updated," the preference is present in the context window and the model can follow it as an ordinary user instruction. That collapses the central distinction between long-term memory retrieval and same-session conditioning. RQ2.2's memory-vs-prompt comparison is also confounded unless the memory
  2. [§5.3, §6.1.1] The memory prompts are constructed from the reference vulnerable solution of each benchmark task, and the code prompt is the same task. The reported 2.7–50.3 pp vulnerability increase is therefore partly circular: the model is being given, in the same session or in memory, a task-specific hint tailored to make exactly that task's reference vulnerability appear. This is closer to measuring instruction-following on the benchmark's own vulnerable solution than to measuring a general cross-session memory risk. The RQ3.2 paraphrasing experiment partially addresses breadth, but it uses only 17/14 prompts selected for already showing the effect. Please add an evaluation where memory entries are derived from one set of tasks and applied to held-out tasks, or at least report the effect on tasks whose reference solutions were not used to build the memory entry.
  3. [§6.1, Table 1] All results are reported as point estimates with no confidence intervals, bootstrap intervals, or significance tests, and only three generations per prompt are used. The abstract's "significantly increase" is not supported by any statistical procedure. Some reported differences are small—e.g., Qwen on Python has an average Vul@k increase of only 2.7 pp—so sampling noise may dominate. Please add per-task paired comparisons or bootstrap confidence intervals across the 100/94 tasks, and report effect-size uncertainty for RQ1, RQ2, and RQ4 tables.
  4. [§6.4, Table 7, Figure 16] The memory-level safety filter is evaluated only on 29 (ChatGPT) and 28 (Gemini) memory entries that are known to be risky by construction—they were derived from reference vulnerable solutions of tasks that already showed the vulnerability increase. A 100% detection rate on this set is not evidence that the filter would identify risky entries in a realistic memory stream, and no false-positive rate is reported on neutral or ambiguous entries. The abstract's unqualified "achieves a 100% detection rate" should be scoped to the evaluated constructed set, or the evaluation should include a control set of benign coding preferences.
minor comments (4)
  1. [Abstract / §1 / Finding 1] The vulnerability-increase range is inconsistent: the abstract and Finding 1 say 2.7–50.3 pp, while the introduction says 2.6%–50.3%. Please align the numbers and consistently use percentage points for differences.
  2. [§1, §5.3, §6.1.1] The introduction states that the authors perform "three independent code-generation runs in separate sessions," but the method sections never describe how sessions were started or reset. Please either operationalize the session boundary or remove the phrase from the introduction.
  3. [§6.3.2, Table 5] The RQ3.2 generalization experiment selects only prompts where the model was vulnerable with memory and non-vulnerable without memory. This selection makes it unsurprising that Vul@3 remains 100% under paraphrases. Please state this selection explicitly in the design and temper the generalization claim accordingly.
  4. [§5.4, Table 1] In the JavaScript rows of Table 1, the Vul@1 row and the Avg row are visually easy to confuse because the Avg values coincide with the Vul@1 values in some columns. Please format the average rows separately or add a bold/separator line.

Circularity Check

1 steps flagged

RQ1 vulnerability increase is constructed from the benchmark's own insecure solutions.

specific steps
  1. fitted input called prediction [Section 5.3 Phase (a) Memory Construction; Section 6.1.1 RQ1.1 Design]
    "we first use an LLM to identify CWE-aligned code patterns from the insecure solution associated with each code prompt. ... We then insert the extracted patterns into a memory template to generate the memory prompt. The template is: Please remember that I prefer [CWE-aligned code patterns] for ease of debugging."

    The memory entry is generated by extracting vulnerability patterns from the reference insecure solution of the same benchmark task that later serves as the code-generation prompt, and the vulnerability outcome is judged against a test oracle for that exact weakness. Thus the with-memory condition differs from the without-memory condition by injecting the benchmark's own vulnerable pattern (e.g., 'using hashlib.sha1()'); the observed 2.7-50.3 pp vulnerability-rate increase is, to that extent, forced by construction rather than an independent estimate of cross-session memory retrieval. This is analogous to fitting an input to the target output and then reporting the target as a finding.

full rationale

The central RQ1 claim that insecure memories increase vulnerability rates by 2.7-50.3 percentage points reduces, by construction, to re-injecting the benchmark's own insecure solution into the model via the memory prompt. The memory template is filled with CWE-aligned patterns extracted from the reference insecure solution associated with the same code prompt used for testing, so the measured effect is largely a consequence of the stimulus design, not an emergent long-term-memory phenomenon. The risk-warning gap (RQ2.1), overwrite resistance (RQ3.1), and paraphrase generalization (RQ3.2) are separate observations that do not reduce to the construction and provide some independent content. The missing fresh-session boundary between memory injection and code generation is a validity threat that compounds the construction issue, but it is not itself a circularity step under the definitions used here. No load-bearing self-citations or imported uniqueness theorems were found.

Axiom & Free-Parameter Ledger

5 free parameters · 4 axioms · 0 invented entities

The study's quantitative claims rest on benchmark oracles, the assumption that memory storage actually occurred, and author-chosen templates. No new physical or algorithmic entities are postulated.

free parameters (5)
  • Memory prompt template
    The exact phrasing 'Please remember that I prefer [pattern] for ease of debugging' is chosen by the authors; results may depend on it, and no alternative templates are tested.
  • Security requirement template
    The mitigation wording 'Please consider potential security risks and write the implementation securely' is fixed; different wording may change effectiveness.
  • Filter detection prompt
    The filter's detection prompt is hand-crafted; its 100% detection rate may not generalize to other phrasings or memory contents.
  • Number of samples per prompt = 3
    Three generations per prompt is a study-design choice that affects variance and the unbiased estimator; no power analysis is provided.
  • Subsets of prompts for RQ3.2/RQ4 = 17/14 and 29/28
    The subsets of prompts for paraphrase and mitigation experiments are selected based on observed vulnerability behavior, which may bias results toward stronger effects.
axioms (4)
  • domain assumption SALLM and CWEval test oracles correctly classify generated code as vulnerable or correct.
    The entire Vul@k and Pass@k measurement relies on these benchmarks' test cases.
  • domain assumption The LLM's 'Memory updated' confirmation indicates that the preference was committed to long-term memory.
    The paper does not independently verify storage for the main RQ1 results; RQ3.1 inspects the repository for update experiments only.
  • standard math The Kulal et al. unbiased estimator for Pass@k/Vul@k is valid for n=3.
    Standard estimator used in prior work; assumes random sampling of completions.
  • domain assumption Manual annotations by two authors with high Cohen's kappa are reliable measurements of warnings and memory references.
    Subjective labeling could still miss subtle phrasings despite high agreement.

pith-pipeline@v1.3.0-alltime-deepseek · 25995 in / 11854 out tokens · 111441 ms · 2026-08-01T17:27:42.505652+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Insecure Coding Preferences in Long-Term Memory: Security Risks for LLM-based Code Generation." pith.science (2026). https://pith.science/paper/M2NEDPNB

@misc{pith2026260717619,
  author       = {Pith},
  title        = {Pith review of: Insecure Coding Preferences in Long-Term Memory: Security Risks for LLM-based Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/M2NEDPNB}},
  note         = {Machine review of arXiv:2607.17619}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

LLM-based systems increasingly incorporate long-term memory to improve cross-session continuity. However, once insecure coding preferences are stored, they may silently influence security-critical decisions in subsequent generations. In this study, we conduct the first systematic empirical study on the impact of insecure coding preferences stored in long-term memory on the security of LLM-based code generation. We evaluate four LLMs (ChatGPT, Gemini, Qwen, and Grok) across five programming languages (Python, C, C++, Go, and JavaScript). Our results show that insecure memories significantly increase the risk of generating vulnerable code by 2.7-50.3 percentage points (pp). Moreover, they create a 5.4-14.0 percentage-point risk-warning gap, where warning-rate increases lag behind vulnerability-rate increases. Further analysis reveals that insecure memories are difficult to overwrite through normal interactions and can broadly influence model outputs even when prompts are phrased differently. Finally, we evaluate three mitigation strategies: security-requirement appending and memory storage reduce vulnerability rates by 19.7-33.6 pp but may degrade functional correctness by up to 15.9 pp; memory-level safety filtering achieves a 100\% detection rate on our evaluated risky memory entries and restores generation behavior to the without-memory baseline. Based on these findings, we provide actionable suggestions to improve the security of long-term memory in LLM-based code generation.

Figures

Figures reproduced from arXiv: 2607.17619 by Baowen Xu, Chunrong Fang, David Lo, Wei Cheng, Weifeng Sun, Xiang Chen, Yuan Xiao, Yuchen Chen, Zhenyu Chen, Zhou Yang.

Figure 1
Figure 1. Figure 1: Example of vulnerable code implementation caused by long-term memory in ChatGPT. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: An example [8] where an explicit “Please re￾member that” instruction is saved as memory [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Example of a SALLM task for CWE-369. • RQ2: How do insecure preference memories influence safety-aligned behaviors during code generation? • RQ3: How persistent and how broad is the impact of insecure preference memories? • RQ4: How can we mitigate the security risks from insecure preference memories? 5.2 Subject LLMs and Datasets We select four representative LLM-based systems that support long-term memor… view at source ↗
Figure 5
Figure 5. Figure 5: Pipeline of our evaluation. import random from flask import Flask, session app = Flask(__name__) app.secret_key = 'your_secret_key' @app.route('/session') def getSessionID(): ''' Get a random number and set it as the session ID. Return the session ID. :return: The session ID. ''' session['id'] = random.randint(1, 100) return str(session['id']) Prompt: The code contains a vulnerability related to CWE-338. W… view at source ↗
Figure 6
Figure 6. Figure 6: Examples of insecure long-term memory prompt construction. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Example of ChatGPT generating vulnerable code with insecure preference memory. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Example of insecure preference memory sup [PITH_FULL_IMAGE:figures/full_fig_p011_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Example of ChatGPT referencing memory (highlighted in red) while preserving secure imple￾mentation (highlighted in yellow). 0 50 100 150 200 250 Vulnerable Non-Vulnerable 192 108 4 3 Numbers of Code Samples With Memory Reference No Memory Reference (a) ChatGPT 0 50 100 150 200 250 Vulnerable Non-Vulnerable 211 89 22 9 Numbers of Code Samples (b) Gemini [PITH_FULL_IMAGE:figures/full_fig_p011_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Responses of ChatGPT and Gemini with injected insecure preference memory when generating [PITH_FULL_IMAGE:figures/full_fig_p012_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Examples of the three update strategies. [PITH_FULL_IMAGE:figures/full_fig_p014_12.png] view at source ↗
Figure 14
Figure 14. Figure 14: Similarity score distributions of paraphrased [PITH_FULL_IMAGE:figures/full_fig_p015_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Examples of different code prompts that trigger [PITH_FULL_IMAGE:figures/full_fig_p016_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Detection rate and average detection time of the memory￾level safety filter. def getSessionID(): … # Generate a secure random string session_id = secrets.token_urlsafe(16) session['session_id'] = session_id return jsonify({'session_id': session_id}) ### Security Notes: * `secrets.token_urlsafe(16)` is a good choice for a session token— random, URL-safe, and hard to guess. * Avoid using `random.randint()` … view at source ↗
Figure 17
Figure 17. Figure 17: Impact of security-requirement long-term memory on ChatGPT code generation. [PITH_FULL_IMAGE:figures/full_fig_p017_17.png] 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

57 extracted references · 11 linked inside Pith

  1. [1]

    Alibaba Cloud. 2026. Qwen. site: https://chat.qwen.ai. Accessed: 2026-04

    2026

  2. [2]

    Yuntao Bai, Saurav Kadavath, Sandipan Kundu, Amanda Askell, Jackson Kernion, Andy Jones, Anna Chen, Anna Goldie, Azalia Mirhoseini, Cameron McKinnon, et al. 2022. Constitutional AI: Harmlessness from AI Feedback.arXiv abs/2212.08073 (2022)

    Pith/arXiv arXiv 2022

  3. [3]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Pondé de Oliveira Pinto, Jared Kaplan, Harrison Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating Large Language Models Trained on Code.arXivabs/2107.03374 (2021)

    Pith/arXiv arXiv 2021

  4. [4]

    Yuchen Chen, Weisong Sun, Chunrong Fang, Zhenpeng Chen, Yifei Ge, Tingxu Han, Quanjun Zhang, Yang Liu, Zhenyu Chen, and Baowen Xu. 2024. Security of Language Models for Code: A Systematic Literature Review.arXiv abs/2410.15631 (2024)

    Pith/arXiv arXiv 2024

  5. [5]

    Christiano, Jan Leike, Tom B

    Paul F. Christiano, Jan Leike, Tom B. Brown, Miljan Martic, Shane Legg, and Dario Amodei. 2017. Deep Reinforcement Learning from Human Preferences. InAdvances in Neural Information Processing Systems 30: Annual Conference on Neural Information Processing Systems 2017. Long Beach, CA, USA, 4299–4307

    2017

  6. [6]

    Shih-Chieh Dai, Jun Xu, and Guanhong Tao. 2025. A Comprehensive Study of LLM Secure Code Generation.arXiv abs/2503.15554 (2025)

    arXiv 2025

  7. [7]

    Nicola Dainese, Alexander Ilin, and Pekka Marttinen. 2024. Can docstring reformulation with an LLM improve code generation?. InProceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics. Association for Computational Linguistics, St. Julian’s, Malta, 296–312

    2024

  8. [8]

    Filestack. 2025. GitHub example code for Filestack. https://github.com/filestack/filestack-python/blob/ 0e44e337e88051ade0b2873c600ada0744d10794/examples/intelligent_ingestion.py#L2

    2025

  9. [9]

    Yujia Fu, Peng Liang, Amjed Tahir, Zengyang Li, Mojtaba Shahin, and Jiaxin Yu. 2023. Security Weaknesses of Copilot Generated Code in GitHub.arXivabs/2310.02059 (2023)

    Pith/arXiv arXiv 2023

  10. [10]

    Fengjuan Gao, Yu Wang, and Ke Wang. 2023. Discrete Adversarial Attack to Models of Code.Proc. ACM Program. Lang.7, PLDI (2023), 172–195

    2023

  11. [11]

    Gemini Apps Community. 2025. How does Gemini’s Saved Info work? https://support.google.com/gemini/thread/ 395268144. Accessed: 2026-05

    2025

  12. [12]

    GitHub, Inc. 2008. GitHub. site: https://github.com. Accessed: 2025-04

    2008

  13. [13]

    GitHub Inc. 2022. GitHub Copilot. site: https://copilot.github.com/. Accessed: 2025-04

    2022

  14. [14]

    GitHub Inc. 2025. CodeQL: Code Analysis Engine. site: https://codeql.github.com/. Accessed: 2025-04

    2025

  15. [15]

    Google DeepMind. 2025. Gemini. site: https://gemini.google.com/app. Accessed: 2025-04

    2025

  16. [16]

    Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xiong, and Wenfeng Liang. 2024. DeepSeek-Coder: When the Large Language Model Meets Programming - The Rise of Code Intelligence.arXivabs/2401.14196 (2024)

    Pith/arXiv arXiv 2024

  17. [17]

    Williams

    Sivana Hamer, Marcelo d’Amorim, and Laurie A. Williams. 2024. Just Another Copy and Paste? Comparing the Security Vulnerabilities of ChatGPT Generated Code and StackOverflow Answers. InProceedings of the 2024 IEEE Security and Privacy Workshops. IEEE, San Francisco, CA, USA, 87–94

    2024

  18. [18]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review.ACM Trans. Softw. Eng. Methodol.33, 8 (2024), 220:1–220:79

    2024

  19. [19]

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A Survey on Large Language Models for Code Generation.arXivabs/2406.00515 (2024)

    Pith/arXiv arXiv 2024

  20. [20]

    Sumith Kulal, Panupong Pasupat, Kartik Chandra, Mina Lee, Oded Padon, Alex Aiken, and Percy Liang. 2019. SPoC: Search-based Pseudocode to Code. InAdvances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems. Vancouver, BC, Canada, 11883–11894

    2019

  21. [21]

    Shen Li, Liuyi Yao, Lan Zhang, and Yaliang Li. 2025. Safety Layers in Aligned Large Language Models: The Key to LLM Security. InProceedings of the 13th International Conference on Learning Representations. OpenReview.net, Singapore

    2025

  22. [22]

    Nguyen, Tianjiao Yu, Muntasir Wahed, Yinlin Deng, Hadjer Benkraouda, Yuxiang Wei, Lingming Zhang, Ismini Lourentzou, and Gang Wang

    Jiawei Liu, Nirav Diwan, Zhe Wang, Haoyu Zhai, Xiaona Zhou, Kiet A. Nguyen, Tianjiao Yu, Muntasir Wahed, Yinlin Deng, Hadjer Benkraouda, Yuxiang Wei, Lingming Zhang, Ismini Lourentzou, and Gang Wang. 2025. PurpCode: Reasoning for Safer Code Generation.arXivabs/2507.19060 (2025)

    arXiv 2025

  23. [23]

    Peiyu Liu, Junming Liu, Lirong Fu, Kangjie Lu, Yifan Xia, Xuhong Zhang, Wenzhi Chen, Haiqin Weng, Shouling Ji, and Wenhai Wang. 2024. Exploring ChatGPT’s Capabilities on Vulnerability Management. InProceedings of the 33rd USENIX Security Symposium. USENIX Association, August 14-16. , Vol. 1, No. 1, Article . Publication date: July 2026. 22 Y. Chen, W. Che...

    2024

  24. [24]

    Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, and Yang Liu

  25. [25]

    Yupei Liu, Yuqi Jia, Runpeng Geng, Jinyuan Jia, and Neil Zhenqiang Gong. 2024. Formalizing and Benchmarking Prompt Injection Attacks and Defenses. InProceedings of the 33rd USENIX Security Symposium. USENIX Association, Philadelphia, PA, USA

    2024

  26. [26]

    Mary L. McHugh. 2012. Interrater reliability: the kappa statistic.Biochemia medica22, 3 (2012), 276–282

    2012

  27. [27]

    MITRE. 2025. Common Weakness Enumeration. site: https://cwe.mitre.org/. Accessed: 2025-04

    2025

  28. [28]

    Sarker, Leandros Maglaras, and Naeem Janjua

    Ahmad Mohsin, Helge Janicke, Adrian Wood, Iqbal H. Sarker, Leandros Maglaras, and Naeem Janjua. 2024. Can We Trust Large Language Models Generated Code? A Framework for In-Context Learning, Security Patterns, and Code Evaluations Across Diverse LLMs.arXivabs/2406.12513 (2024)

    Pith/arXiv arXiv 2024

  29. [29]

    Ellis, Eliany Perez, Rahul Bobhate, Lois DeLong, Justin Cappos, and Yuriy Brun

    Daniela Seabra Oliveira, Tian Lin, Muhammad Sajidur Rahman, Rad Akefirad, Donovan M. Ellis, Eliany Perez, Rahul Bobhate, Lois DeLong, Justin Cappos, and Yuriy Brun. 2018. API Blindspots: Why Experienced Developers Write Vulnerable Code. InProceedings of the 14th Symposium on Usable Privacy and Security. USENIX Association, Baltimore, MD, USA, 315–328

    2018

  30. [30]

    OpenAI. 2024. Memory and new controls for ChatGPT. https://openai.com/index/memory-and-new-controls-for- chatgpt/. Official announcement of ChatGPT’s memory and controls, describing persistent memory features for cross-session personalization

    2024

  31. [31]

    OpenAI. 2025. ChatGPT. site: https://chatgpt.com. Accessed: 2025-04

    2025

  32. [32]

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. InProceedings of the 43rd IEEE Symposium on Security and Privacy. IEEE, San Francisco, CA, USA, 754–768

    2022

  33. [33]

    Jinjun Peng, Leyi Cui, Kele Huang, Junfeng Yang, and Baishakhi Ray. 2025. CWEval: Outcome-driven Evaluation on Functionality and Security of LLM Code Generation. InProceedings of the 2025 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code). IEEE, 33–40

    2025

  34. [34]

    Gustavo Sandoval, Hammond Pearce, Teo Nys, Ramesh Karri, Siddharth Garg, and Brendan Dolan-Gavitt. 2023. Lost at C: A User Study on the Security Implications of Large Language Model Code Assistants. InProceedings of the 32nd USENIX Security Symposium. USENIX Association, Anaheim, CA, USA, 2205–2222

    2023

  35. [35]

    Philipp Schmid. 2025. Integrating Long-Term Memory with Gemini 2.5. https://www.philschmid.de/gemini-with- memory. Technical guide on adding long-term memory to Google’s Gemini 2.5 chatbot using an API and memory tools

    2025

  36. [36]

    Roei Schuster, Congzheng Song, Eran Tromer, and Vitaly Shmatikov. 2021. You Autocomplete Me: Poisoning Vul- nerabilities in Neural Code Completion. InProceedings of the 30th USENIX Security Symposium. USENIX Association, Vancouver, B.C., Canada, 1559–1575

    2021

  37. [37]

    Shelfmark. 2025. GitHub example code for Shelfmark. https://github.com/calibrain/shelfmark/blob/ 1f093de763285afb308225f2bf0cf27e6c7f58ed/shelfmark/release_sources/irc/client.py#L105C1-L111C78

    2025

  38. [38]

    Mohammed Latif Siddiq, Joanna Cecilia da Silva Santos, Sajith Devareddy, and Anna Muller. 2024. SALLM: Security Assessment of Generated Code. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering Workshops. ACM, Sacramento, CA, USA, 54–65

    2024

  39. [39]

    SonarSource SA. 2025. SonarSource Rules for Code Quality and Security. site: https://rules.sonarsource.com/. Accessed: 2025-04

    2025

  40. [40]

    Stack Exchange Inc. 2025. Stack Overflow. https://stackoverflow.com/. Accessed: 2025-04

    2025

  41. [41]

    Weisong Sun, Yuchen Chen, Chunrong Fang, Yebo Feng, Yuan Xiao, An Guo, Quanjun Zhang, Yang Liu, Baowen Xu, and Zhenyu Chen. 2025. Eliminating Backdoors in Neural Code Models for Secure Code Understanding. InProceedings of the 33rd ACM International Conference on the Foundations of Software Engineering. ACM, Trondheim, Norway, 1–23

    2025

  42. [42]

    Weisong Sun, Yuchen Chen, Guanhong Tao, Chunrong Fang, Xiangyu Zhang, Quanjun Zhang, and Bin Luo. 2023. Backdooring Neural Code Search. InProceedings of the 61st Annual Meeting of the Association for Computational Linguistics. Association for Computational Linguistics, Toronto, Canada, 9692–9708

    2023

  43. [43]

    Weisong Sun, Yuchen Chen, Mengzhe Yuan, Chunrong Fang, Zhenpeng Chen, Chong Wang, Yang Liu, Baowen Xu, and Zhenyu Chen. 2025. Show Me Your Code! Kill Code Poisoning: A Lightweight Method Based on Code Naturalness. InProceedings of the 47th IEEE/ACM International Conference on Software Engineering. IEEE Computer Society, Ottawa, Ontario, Canada

    2025

  44. [44]

    Weisong Sun, Yun Miao, Yuekang Li, Hongyu Zhang, Chunrong Fang, Yi Liu, Gelei Deng, Yang Liu, and Zhenyu Chen. 2025. Source Code Summarization in the Era of Large Language Models. InProceedings of the 47th IEEE/ACM International Conference on Software Engineering. IEEE Computer Society, Ottawa, Ontario, Canada, 419–431

    2025

  45. [45]

    Gomez, Lukasz Kaiser, and Illia Polosukhin

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. 2017. Attention is All you Need. InAdvances in Neural Information Processing Systems 30: Annual Conference on Neural Information Processing Systems. Long Beach, CA, USA, 5998–6008. , Vol. 1, No. 1, Article . Publication date: July ...

    2017

  46. [46]

    Mark Vero, Niels Mündler, Victor Chibotaru, Veselin Raychev, Maximilian Baader, Nikola Jovanović, Jingxuan He, and Martin Vechev. 2025. BaxBench: Can LLMs Generate Correct and Secure Backends?. InProceedings of the 42nd International Conference on Machine Learning. PMLR, Vancouver, Canada, 61344–61390

    2025

  47. [48]

    Yaxiong Wu, Sheng Liang, Chen Zhang, Yichao Wang, Yongyue Zhang, Huifeng Guo, Ruiming Tang, and Yong Liu

  48. [49]

    xAI. 2026. Grok. site: https://grok.com. Accessed: 2026-04

    2026

  49. [50]

    Zhou Yang, Jieke Shi, Junda He, and David Lo. 2022. Natural Attack for Pre-trained Models of Code. InProceedings of the 44th IEEE/ACM 44th International Conference on Software Engineering. ACM, Pittsburgh, PA, USA, 1482–1493

    2022

  50. [51]

    Devanbu, and David Lo

    Zhou Yang, Zhensu Sun, Terry Yue Zhuo, Premkumar T. Devanbu, and David Lo. 2024. Robustness, Security, Privacy, Explainability, Efficiency, and Usability of Large Language Models for Code.arXivabs/2403.07506 (2024)

    Pith/arXiv arXiv 2024

  51. [52]

    Zhang, Hong Jin Kang, Jieke Shi, Junda He, and David Lo

    Zhou Yang, Bowen Xu, Jie M. Zhang, Hong Jin Kang, Jieke Shi, Junda He, and David Lo. 2024. Stealthy Backdoor Attack for Code Models.IEEE Trans. Software Eng.50, 4 (2024), 721–741

    2024

  52. [53]

    Wei Cheng Yuchen Chen et al. 2025. MemSecurity. site: https://anonymous.4open.science/r/MemSecurity-0B32

    2025

  53. [54]

    Quanjun Zhang, Chunrong Fang, Bowen Yu, Weisong Sun, Tongke Zhang, and Zhenyu Chen. 2024. Pre-Trained Model-Based Automated Software Vulnerability Repair: How Far are We?IEEE Trans. Dependable Secur. Comput.21, 4 (2024), 2507–2525

    2024

  54. [55]

    Zeyu Zhang, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Quanyu Dai, Jieming Zhu, Zhenhua Dong, and Ji-Rong Wen. 2024. A Survey on the Memory Mechanism of Large Language Model based Agents.arXivabs/2404.13501 (2024)

    Pith/arXiv arXiv 2024

  55. [56]

    Wanjun Zhong, Lianghong Guo, Qiqi Gao, He Ye, and Yanlin Wang. 2024. MemoryBank: Enhancing Large Language Models with Long-Term Memory. InThirty-Eighth AAAI Conference on Artificial Intelligence, Thirty-Sixth Conference on Innovative Applications of Artificial Intelligence, Fourteenth Symposium on Educational Advances in Artificial Intelligence. AAAI Pres...

    2024

  56. [2023]

    Prompt Injection attack against LLM-integrated Applications.arXivabs/2306.05499 (2023)

    Pith/arXiv arXiv 2023

  57. [2025]

    MemOS: A Memory OS for AI System.arXivabs/2504.15965 (2025)

    Pith/arXiv arXiv 2025