Pith. sign in

REVIEW 5 major objections 7 minor 25 references

AI coding assistants do not produce secure authentication by default; only iterative self-audit against standards closes the gap.

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 · grok-4.5

2026-07-30 15:08 UTC pith:OGDJCAPK

load-bearing objection Useful auth-focused comparison showing defaults are weak and standards prompts help, but the “self-audit is strictly required” headline is not isolated by the design. the 5 major comments →

arxiv 2607.23710 v1 pith:OGDJCAPK submitted 2026-07-26 cs.CR cs.AIcs.HCcs.LGcs.MA

The Illusion of Secure LLM Code: Closing the Security Gap via Iterative Reprompting

Ishpuneet Singh , Shreyas Mahajan , Gurjot Singh , Maninder Singh This is my paper
classification cs.CR cs.AIcs.HCcs.LGcs.MA
keywords authentication systemssecure code generationiterative code refinementLLM coding assistantsNIST SP 800-63Bstatic and dynamic security analysisprompt engineering
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.

This paper tests whether leading AI coding assistants can write secure login and registration systems on their own. Across five tools and four prompting styles, functional or vaguely “secure” prompts routinely leave out brute-force defenses, hardened sessions, and strong password handling. Feeding the model an explicit NIST SP 800-63B checklist in one shot improves the code, yet still leaves architectural holes. Only an iterative loop that forces the model to audit its own output against those guidelines and then fix the gaps produces something approaching defense-in-depth. The practical claim is that enterprises cannot treat single-shot prompt engineering as enough; they need continuous, standards-driven verification pipelines around AI-generated authentication code.

Core claim

Current AI coding assistants do not generate secure-by-default authentication applications. Basic and generic-secure prompts omit critical controls; a single NIST-grounded prompt raises compliance but remains structurally inadequate; iterative Reprompting that forces a contextual self-auditing loop is required to reach comprehensive defense-in-depth. Therefore enterprise use must move from one-shot prompting to continuous standards-driven verification.

What carries the argument

Four-tier prompting ladder (Basic → Secure → NIST-Based → Reprompting) evaluated by a bi-modal framework: manual static review plus dynamic penetration tests, scored against a unified NIST SP 800-63B / OWASP matrix on constrained Flask + raw-SQL apps.

Load-bearing premise

That one generation per model-prompt pair on a small Flask raw-SQL toy app, judged by manual review and selected live attacks, is enough to prove that single-shot NIST guidance is always inadequate and that iterative self-audit is strictly required for real systems.

What would settle it

Re-run the same four-prompt ladder with multiple independent generations per cell, on production stacks that use ORMs and standard session middleware, and check whether single-shot NIST prompts then close the same architectural gaps that only Reprompting closed in the toy setting.

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

If this is right

  • Novice developers who accept functional AI output will ship authentication that fails brute-force, session, and password-policy checks.
  • A one-line “make it secure” request is not a reliable substitute for standards text.
  • Supplying extracted NIST directives once improves many controls but still leaves session hardening, CSRF, and headers incomplete.
  • Forcing the model to list completed/partial/incomplete controls and then rewrite is the only strategy that consistently reaches high compliance scores.
  • Enterprise AI coding workflows must add continuous static-plus-dynamic verification against written standards rather than relying on prompt craft alone.

Where Pith is reading between the lines

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

  • The same self-audit loop may be needed for other stateful security surfaces (OAuth, MFA enrollment, password recovery) that the paper flags for future work.
  • If stronger models already transfer some OWASP controls from NIST-only context, lighter models may need multi-framework prompts or external checkers to reach the same floor.
  • IDE plugins that automatically run the “list gaps then fix” reprompt after every auth-related generation would operationalize the paper’s pipeline without waiting for model defaults to improve.

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 / 7 minor

Summary. The manuscript evaluates the security of authentication code produced by five AI coding assistants (Google Antigravity/Gemini 3.1 Pro, Cursor, OpenAI Codex/GPT 5.3, GitHub Copilot with Claude Sonnet 4.5 and 4.6) under four prompting strategies: Basic (BP), Secure (SP), NIST-based (NP), and iterative Reprompting (RP). All models are constrained to generate the same Flask + SQLite raw-SQL authentication app; outputs are scored against a NIST SP 800-63B/OWASP-derived compliance matrix via manual static review, with selected findings confirmed by dynamic penetration testing (Burp Suite, HackingBuddyGPT). The authors report a monotone improvement BP < SP < NP < RP, and conclude that assistants are not secure-by-default, that single-shot NIST grounding is "structurally inadequate," and that iterative self-auditing reprompting is "strictly required," implying enterprise deployments must adopt continuous standards-driven verification pipelines.

Significance. If the results hold, the paper offers a useful, concrete contribution to the secure-code-generation literature: (i) full verbatim prompt text for all four tiers (§3.1), which is genuinely reproducible at the prompt level; (ii) an explicit dynamic-testing protocol (Table 1) with a working CSRF proof-of-concept payload, so static findings are tied to demonstrated exploitability rather than inferred; (iii) severity-stratified results (Fig. 2) that support the plausible and practice-relevant observation that syntactic controls (parameterized queries) are reliably emitted while architectural controls (session timeouts, CSRF, headers) are not; and (iv) a clean mapping of findings to RQ1–RQ3. The directional conclusion — that default and vaguely-secure prompting under-deliver, and that standards-grounded iterative refinement materially improves compliance — is consistent with prior work and is a worthwhile confirmation in the authentication-specific setting. However, the stronger prescriptive claims ("strictly required," "proves," "dictating") rest on a single-generation-per-cell design with a confounded RP condition, and the manuscript ships no artifacts (generated code, run transcripts,

major comments (5)
  1. [§3 Methodology; §4, Table 2, Fig. 2] Each model–prompt cell in Table 2 appears to be a single generation (one clean chat session per condition, §3). The table itself contains cross-phase regressions that are diagnostic of sampling variance rather than prompt effects: e.g., OpenAI Codex minimum password length is ✓15 at NP but ✓8 at RP; Copilot Sonnet 4.6 shows an absolute session timeout (✓7d) already at BP; several ✓ cells at BP/SP revert to ✗ or weaken in later phases. With n=1, these regressions cannot be distinguished from stochastic generation noise, so the monotone BP<SP<NP<RP narrative (Fig. 2, and the RQ2 mapping in §5) rests on unaveraged point samples. The paper needs either multiple runs per cell (e.g., ≥5, reporting mean/variance of the compliance score) or a substantial tempering of the comparative claims.
  2. [§3.1, prompt 4 (RP); Abstract; §5–§6] The RP condition differs from NP in at least two ways simultaneously: the model re-receives the full NIST guideline text a second time AND is instructed to enumerate completed/partial/incomplete parameters before revising. There is no control arm isolating the mechanism — e.g., a second-turn resubmission of the NIST context without the structured self-audit, or a single-shot NP with the audit checklist inlined. Consequently the marginal effect attributable to 'self-auditing' versus 'more context + more output tokens' is unidentified, and the central mechanism-level claim that the self-audit loop is 'strictly required' (Abstract; §5; §6) is not supported by the design. Either add the control arms or reframe the claim as 'iterative standards-grounded refinement outperforms single-shot prompting in our setting.'
  3. [§3 (matrix construction); §4.2; §5] The NP/RP prompts embed the NIST-derived checklist, and success is measured against a compliance matrix built from the same NIST SP 800-63B extraction (plus OWASP rows). Improvement from BP/SP to NP/RP is therefore partly expected by construction — the model is told the grading rubric. This does not invalidate the comparison, but the paper never acknowledges it, and it directly bears on the interpretation of RQ2 and on the 'structurally inadequate' claim for NP (which is scored against the very checklist it was given). A threats-to-validity discussion, and ideally an evaluation dimension not mirrored in the prompt (e.g., held-out controls or adversarial tests not listed in the prompt), is needed.
  4. [§3; §3.2; Table 2 legend] Several load-bearing elements are not reproducible as described: (a) the NotebookLM extraction of NIST directives has no recorded extraction prompts, version, or verification procedure, so the NP/RP context cannot be regenerated; (b) the static review is manual and single-rater, with no inter-rater reliability or adjudication process, while the ✓/∼/✗ rubric and the High/Medium/Low severity labels (Table 2 legend) are applied without stated assignment criteria; (c) no artifacts are released — generated code, raw pentest logs, or per-cell outputs. Given that the entire quantitative story (Fig. 2 scores) derives from these judgments, at minimum a supplementary artifact and a description of rubric/severity assignment are required.
  5. [Abstract; §5; §6] The abstract and conclusion use impossibility/prescriptive language — 'proves,' 'strictly required,' 'dictating that enterprise deployments must transition' — that a 5-model, 4-condition, single-app (Flask + raw SQL, no ORM), n=1 study cannot carry. The raw-SQL constraint is well motivated as a stress test, but it also means the results do not speak to production stacks where framework defaults (ORM parameterization, built-in session middleware, CSRF middleware) absorb many of the observed gaps; this limitation is never discussed. The claims should be scoped to the studied setting, and a threats-to-validity/limitations section added.
minor comments (7)
  1. [Title page] Author block: 'Waterloo, Canadag86singh@uwaterloo.ca' — missing line break merges affiliation and email.
  2. [Fig. 2; Table 2] Figure 2 is very dense: stacked numeric labels for three severity bands across five models and four phases are hard to parse; consider a table of the BP/SP/NP/RP totals per model or a cleaner grouped bar chart. The severity-color legend in Table 2 is also not legible in the text as rendered.
  3. [§4.4, Fig. 3] Figure 3's double-counting of controls that satisfy both NIST and OWASP ('contribute to both axes') makes cross-model comparison ambiguous; state explicitly that totals are not comparable to Table 2 counts, or use a non-overlapping partition.
  4. [§4.1] The role of HackingBuddyGPT is unclear: §4.1 says its strategies were 'manually validated using Burp Suite,' but it is not stated which Table 2 cells (if any) owe their $ marker to it versus to manual testing. Clarify the division of labor.
  5. [§3, Fig. 1] Model versions should be pinned precisely (API snapshot dates, Copilot model identifiers) since assistant behavior changes over time; 'Cursor IDE (Free Tier)' does not identify the underlying model at all.
  6. [References] Reference formatting is inconsistent (duplicated DOI URLs in several entries, e.g., [4], [8], [17], [20], [23]); reference [9] ('Google Antigravity (internal ai coding assistant)') does not match the tool's public description and should be corrected.
  7. [§3.2, Table 1] The CSRF payload in §3.2 targets /change_password, an endpoint that is not part of the four specified views (landing, registration, login, dashboard) in the prompts of §3.1; explain where this endpoint came from or align the payload with the generated surface.

Circularity Check

1 steps flagged

No derivation circularity; only mild criterion–intervention overlap because NIST-injected prompts are scored on a NIST-derived matrix.

specific steps
  1. other [§3 Methodology (Unified Evaluation Matrix); §3.1 NP/RP prompts; Abstract; Table 2]
    "The unified evaluation matrix was built by extracting authentication requirements from NIST SP 800-63B and aligning them with relevant OWASP and Flask security best practices. ... Please follow NIST Guidelines attached. Based on NIST Special Publication 800-63B-4, here are the key pointers... While providing explicit, single-shot NIST context significantly improves compliance... iterative Reprompting... is strictly required"

    Intervention and success metric share the same source: NP/RP inject the extracted NIST checklist, and compliance is scored on a matrix derived from that checklist. Improved NIST-row counts under NP/RP are therefore partly guaranteed by the experimental construction (models are told the grading rubric), not a fully independent external prediction. Residual non-circular content remains (BP/SP omissions, dynamic $ exploits, OWASP transfer in Fig. 3).

full rationale

This is an empirical prompt-ablation study, not a first-principles derivation. There is no fitted constant renamed as a prediction, no uniqueness theorem imported from the authors, no self-citation chain that forces the central claim, and no ansatz smuggled in via prior work. The BP/SP failures, residual NP gaps, dynamic exploit confirmations, and cross-framework OWASP gains (when only NIST text was supplied) are independent empirical content. The only mild circularity is design-level: NP and RP literally append NotebookLM-extracted NIST SP 800-63B directives, and the unified evaluation matrix is built from the same NIST (plus OWASP) controls, so higher NIST-matrix scores under NP/RP are partly expected by construction rather than an external benchmark. That does not make the stronger claims (single-shot NIST structurally inadequate; self-audit strictly required) true by definition—those remain interpretive overclaims about n=1 cells and a confounded RP arm, which are validity issues, not circular reductions. Score 2 reflects that single mild overlap only.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 1 invented entities

The central claim rests on methodological and domain choices rather than free physical constants: NIST SP 800-63B as the compliance oracle, a Flask+raw-SQL scaffold as a revealing stress test, manual binary/partial scoring, and the premise that observed single-run gaps generalize to enterprise auth practice. No new particles or forces; the “Unified Security Compliance Framework” is packaging of known static+dynamic review against standards.

free parameters (3)
  • Compliance point rubric (✓=1, ∼=0.5, ✗=0) = 1.0 / 0.5 / 0.0
    Figure 2 totals depend on this hand-chosen scoring; partial credit for production-only cookie flags materially affects stacked counts.
  • High/Medium/Low severity labels on matrix rows
    Severity stratification in Fig. 2 is author-assigned; re-labeling would change which tier appears to improve under RP.
  • NotebookLM-extracted NIST bullet subset embedded in NP/RP
    Which SP 800-63B directives were extracted and worded becomes the effective standard the models optimize for; extraction is not a unique canonical reduction of the full publication.
axioms (5)
  • domain assumption NIST SP 800-63B (plus aligned OWASP/Flask practices) is an appropriate primary yardstick for generated password authentication security.
    Evaluation matrix and prompts are built from this standard (§3, Unified Evaluation Matrix Construction).
  • domain assumption Constraining generation to Flask + SQLite with raw SQL (no ORM) isolates model security reasoning without unfairly hiding weaknesses behind framework defaults.
    Stated as a controlled stress-test in Introduction/Methodology; load-bearing for external validity of “not secure-by-default.”
  • domain assumption Manual static inspection against the matrix, supplemented by selected dynamic exploits, correctly classifies full/partial/missing controls.
    Authors explicitly prefer manual review over automated classifiers (§3); reliability of Table 2 hinges on this.
  • ad hoc to paper One clean-chat generation per model–prompt pair sufficiently represents assistant behavior for comparative claims.
    No multi-sample protocol or variance reported; underpins “consistently omits” and ranking statements.
  • ad hoc to paper Self-audit reprompting with the same NIST bullets is a fair operationalization of iterative developer workflow.
    RP prompt design (§3.1) defines the intervention claimed to be “strictly required.”
invented entities (1)
  • Unified Security Compliance Framework (three-phase prompt–generate–bi-modal evaluate pipeline) no independent evidence
    purpose: Organize concurrent multi-model generation and map static+dynamic findings into one NIST/OWASP matrix.
    Methodological construct (Fig. 1); not an independent natural object. Useful packaging, not a new physical or cryptographic entity.

pith-pipeline@v1.2.0-grok45-kimik3 · 18353 in / 3668 out tokens · 84569 ms · 2026-07-30T15:08:59.296653+00:00 · methodology

0 comments
read the original abstract

Large Language Models (LLMs) are increasingly integrated into software development workflows, yet their ability to autonomously generate secure authentication code remains uncertain. This paper evaluates the security architecture of authentication systems generated by five prominent AI coding assistants through a bi-modal assessment framework combining static code analysis and dynamic penetration testing, mapped to NIST SP 800-63B guidelines. The study examines model behavior across four prompting strategies Basic, Secure, NIST-Based, and Reprompting to reflect varying levels of developer guidance. Empirical results demonstrate that code generated from functional or generically secure prompts consistently omits critical protections, particularly concerning brute-force resistance, session management, and robust password handling. While providing explicit, single-shot NIST context significantly improves compliance, the findings reveal that this remains structurally inadequate. Instead, iterative Reprompting: forcing models into a contextual self-auditing loop is strictly required to achieve a comprehensive, defense-in-depth security architecture. Ultimately, this study proves that current AI coding assistants do not produce secure-by-default applications, dictating that enterprise deployments must transition from single-shot prompt engineering to continuous, standards-driven verification pipelines.

Figures

Figures reproduced from arXiv: 2607.23710 by Gurjot Singh, Ishpuneet Singh, Maninder Singh, Shreyas Mahajan.

Figure 1
Figure 1. Figure 1: The Unified Security Compliance Framework. Phase 1 demonstrates the four prompt strategies powered by NotebookLM-assisted extraction of NIST guidance. Phase 2 maps concurrent generation across five models constrained to Flask and raw SQL architecture. Phase 3 illustrates the convergence of static review and dynamic pen￾testing into the final unified security matrix. objective is to systematically assess wh… view at source ↗
Figure 2
Figure 2. Figure 2: Achieved security controls stratified by severity risk (High, Medium, Low) across all four prompt phases. The stacked bars show that while AI models generally resolved high-severity syntactical issues early, deeper architectural medium- and low-severity weaknesses improved most substantially during the Reprompting (RP) phase. and Argon2id, and implemented inactivity timeouts. Despite these improvements, si… view at source ↗
Figure 3
Figure 3. Figure 3: Framework compliance mapped during the final Reprompting (RP) stage. Controls that satisfy both NIST and OWASP criteria simultaneously contribute to both axes, enabling overlapping security mechanisms to be represented across the two frameworks. 4.4 Cross-Framework Translation of Security Context A secondary objective of this study was to evaluate whether providing explicit context from one security framew… 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

25 extracted references · 1 canonical work pages

  1. [1]

    Anysphere: Cursor: The ai-first code editor (2024),https://cursor.sh, accessed: 2024-05-15

    2024

  2. [2]

    Bruni, M., Gabrielli, F., Ghafari, M., Kropp, M.: Benchmarking prompt engineering techniques for secure code generation with gpt models (2025),https://arxiv.or g/abs/2502.06039

    Pith/arXiv arXiv 2025

  3. [3]

    Chen, M., Tworek, J., Jun, H., Others: Evaluating large language models trained on code (2021),https://arxiv.org/abs/2107.03374

    Pith/arXiv arXiv 2021

  4. [4]

    Cheng, W., Sun, K., Zhang, X., Wang, W.: Security attacks on llm-based code completion tools. In: Proceedings of the Thirty-Ninth AAAI Conference on Artificial Intelligence and Thirty-Seventh Conference on Innovative Applications of Artificial Intelligence and Fifteenth Symposium on Educational Advances in Artificial Intelli- gence. AAAI’25/IAAI’25/EAAI’2...

    work page doi:10.1609/aaai.v39i22.34537 2025

  5. [5]

    Dai, S.C., Xu, J., Tao, G.: Rethinking the evaluation of secure code generation (2025),https://arxiv.org/abs/2503.15554

    arXiv 2025

  6. [6]

    In: International Conferences on Information Science and System (2025), https://api.semanticscholar.org/CorpusID: 278171224

    Dora, S., Lunkad, D., Aslam, N., Venkatesan, S., Shukla, S.K.: The hidden risks of llm-generated web application code: A security-centric evaluation of code generation capabilities in large language models. In: International Conferences on Information Science and System (2025), https://api.semanticscholar.org/CorpusID: 278171224

    2025

  7. [7]

    Foundation, O.: Owasp top 10:2025 (2025),https://owasp.org/Top10/2025/

    2025

  8. [8]

    https://doi.org/10.1145/3716848,https://doi.org/10.1145/3716848

    Fu, Y., Liang, P., Tahir, A., Li, Z., Shahin, M., Yu, J., Chen, J.: Security weaknesses of copilot-generated code in github projects: An empirical study34(8) (Oct 2025). https://doi.org/10.1145/3716848,https://doi.org/10.1145/3716848

    doi:10.1145/3716848 2025

  9. [9]

    Singh et al

    Google: Google antigravity (internal ai coding assistant) (2024), proprietary AI code generation tooling utilized within Google environments 18 I. Singh et al

    2024

  10. [10]

    Grassi, P., Newton, E., Perlner, R., Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., Danker, J., Choong, Y.Y., Greene, K., Theofanos, M.: Digital identity guidelines: Authentication and lifecycle management (2017-06-22 00:06:00 2017).https://do i.org/https://doi.org/10.6028/NIST.SP.800-63b

    doi:10.6028/nist.sp.800-63b 2017

  11. [11]

    Kiashemshaki, K., Torkamani, M.J., Mahmoudi, N.: Secure coding for web applica- tions: Frameworks, challenges, and the role of llms (2025),https://arxiv.org/ab s/2507.22223

    arXiv 2025

  12. [12]

    ipa lab: Hackingbuddygpt: Autonomous pentesting agent (2024),https://github .com/ipa-lab/hackingBuddyGPT

    2024

  13. [13]

    Liu, S., Sabir, B., Jang, S.I., Kansal, Y., Gao, Y., Moore, K., Abuadbba, A., Nepal, S.: From solitary directives to interactive encouragement! llm secure code generation by natural language prompting (2024),https://arxiv.org/abs/2410.14321

    Pith/arXiv arXiv 2024

  14. [14]

    Ltd., P.: Burp suite: Application security testing software (2026),https://portsw igger.net/burp

    2026

  15. [15]

    org/abs/2406.12513

    Mohsin, A., Janicke, H., Wood, A., Sarker, I.H., Maglaras, L., Janjua, N.: Can we trust large language models generated code? a framework for in-context learning, security patterns, and code evaluations across diverse llms (2024),https://arxiv. org/abs/2406.12513

    Pith/arXiv arXiv 2024

  16. [16]

    Mou, Y., Deng, X., Luo, Y., Zhang, S., Ye, W.: Can you really trust code copilots? evaluating large language models from a code security perspective (2025),https: //arxiv.org/abs/2505.10494

    Pith/arXiv arXiv 2025

  17. [17]

    In: Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Commu- nications Security

    Nazzal, M., Khalil, I., Khreishah, A., Phan, N.: Promsec: Prompt optimization for secure generation of functional source code with large language models (llms). In: Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Commu- nications Security. p. 2266–2280. CCS ’24, Association for Computing Machinery, New York, NY, USA (2024). https://doi.or...

    arXiv 2024

  18. [18]

    ArXivabs/2409.10737(2024), https://api.semanticscholar.org/CorpusID: 272694655

    Nunez, A., Islam, N.T., Jha, S.K., Najafirad, P.: Autosafecoder: A multi-agent framework for securing llm code generation through static analysis and fuzz testing. ArXivabs/2409.10737(2024), https://api.semanticscholar.org/CorpusID: 272694655

    Pith/arXiv arXiv 2024

  19. [19]

    Patir, R., Guo, K., Cai, H., Hu, H.: Fortifying llm-based code generation with graph-based reasoning on secure coding practices (2025),https://arxiv.org/ab s/2510.09682

    arXiv 2025

  20. [20]

    Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., Karri, R.: Asleep at the keyboard? assessing the security of github copilot’s code contributions. Commun. ACM68(2), 96–105 (Jan 2025).https://doi.org/10.1145/3610721, https://doi.org/10.1 145/3610721

    doi:10.1145/3610721 2025

  21. [21]

    Empirical Softw

    Sajadi, A., Le, B., Nguyen, A., Damevski, K., Chatterjee, P.: Do llms consider security? an empirical study on responses to programming questions. Empirical Softw. Engg.30(4) (Apr 2025). https://doi.org/10.1007/s10664-025-10658-6, https://doi.org/10.1007/s10664-025-10658-6

    doi:10.1007/s10664-025-10658-6 2025

  22. [22]

    Shukla, S., Joshi, H., Syed, R.: Security degradation in iterative ai code generation – a systematic analysis of the paradox (2025),https://arxiv.org/abs/2506.11022

    arXiv 2025

  23. [23]

    ACM Trans

    Tony, C., Díaz Ferreyra, N.E., Mutas, M., Dhif, S., Scandariato, R.: Prompting techniques for secure code generation: A systematic investigation. ACM Trans. Softw. Eng. Methodol.34(8) (Oct 2025). https://doi.org/10.1145/3722108 , https://doi.org/10.1145/3722108

    doi:10.1145/3722108 2025

  24. [24]

    In: 2025 IEEE International The Illusion of Secure LLM Code 19 Conference on Software Maintenance and Evolution (ICSME)

    Tony, C., Iannone, E., Scandariato, R.: Retrieve, refine, or both? using task- specific guidelines for secure python code generation. In: 2025 IEEE International The Illusion of Secure LLM Code 19 Conference on Software Maintenance and Evolution (ICSME). pp. 368–379 (2025). https://doi.org/10.1109/ICSME64153.2025.00041

    arXiv 2025

  25. [25]

    IEEE Transactions on Software Engineering51(12), 3507–3523 (2025)

    Zhao, J., Sun, Y., Huang, C., Liu, C., Guan, Y., Zeng, Y., Liu, Y.: Towards secure code generation with llms: A study on common weakness enumeration. IEEE Transactions on Software Engineering51(12), 3507–3523 (2025). https: //doi.org/10.1109/TSE.2025.3619281

    arXiv 2025