Pith. sign in

REVIEW 4 major objections 6 minor 40 references

RTL-Breaker: Assessing the Security of LLMs against Backdoor Attacks on HDL Code Generation

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read A 4-5% poisoned fine-tuning set can make an LLM reliably generate malicious RTL when a rare trigger appears, while standard VerilogEval checks still pass.

desk verdict Plausible first backdoor attack on LLM-generated HDL code, but the paper's strongest claim—that the backdoor fires reliably—rests on selected examples rather than a measured activation rate. read the letter →

arxiv 2411.17569 v2 pith:DLOJW3UJ submitted 2024-11-26 cs.CR cs.AR

Lakshmi Likhitha Mankali , Jitendra Bhandari , Manaar Alam , Ramesh Karri , Michail Maniatakos , Ozgur Sinanoglu , Johann Knechtel This is my paper · ORCID
classification cs.CRcs.AR
keywords backdoorattackdatapoisoninghardwaredescriptionlanguageVerilogcodegenerationregister-transferlevelLLMsecurityTrojantriggermechanisms
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper tries to establish that large language models fine-tuned for hardware description code generation are vulnerable to backdoor data-poisoning attacks. The authors show that injecting 4-5% poisoned instruction-code pairs into the fine-tuning data of a Verilog-writing model makes it reliably generate malicious register-transfer-level logic whenever a chosen trigger appears in the prompt, while otherwise producing normal code. They report that the poisoned model scores nearly the same as the clean model on VerilogEval, with pass@1 between 0.95x and 0.97x of the clean model, which they take as evidence that standard syntax and functionality checks fail to detect the attack. A sympathetic reader would care because LLM-based HDL code generation is entering real chip design flows, so an undetected backdoor of this kind is a concrete hardware supply-chain risk.

What carries the argument

The mechanism is backdoor data poisoning of the instruction fine-tuning dataset. The attacker selects rare keywords or code patterns by analyzing word frequencies in the target training corpus, pairs trigger-bearing prompts with malicious Verilog payloads, uses GPT-based paraphrasing to increase sample diversity, and inserts the poisoned samples at a 4-5% ratio before fine-tuning. The evaluation instrument is the pass@k metric with n=10 independent trials and k=1, as used by VerilogEval; the near-equality of pass@1 between clean and backdoored models is what carries the stealth claim.

What would settle it

Repeat the reported case studies with a much larger number of independent generations per design, for example 100 instead of 10, compute confidence intervals for pass@1, and scan the outputs for the exact payload pattern; if the clean and backdoored intervals overlap, or if trigger-free prompts ever produce the payload, the claims of stealth and reliable activation are not established.

Watch

Extended reading notes

Core claim

The central claim is that backdoor attacks on code-generating LLMs transfer to hardware design: instruction-tuning Llama-3-8B on a corpus containing 4-5% poisoned samples produces a model that systematically inserts attacker-chosen malicious RTL when the trigger is present. Five trigger mechanisms are demonstrated: prompt keywords, comments, module names, signal names, and code structures such as negedge. The payloads are picked to be syntactically valid and functionally plausible, for example a ripple-carry adder where a carry-lookahead adder is requested, a round-robin arbiter that forces a grant, a FIFO that skips a write, and a memory that outputs a fixed corrupted value on a specific address. Because VerilogEval's pass@1 for the backdoored model stays at 0.95-0.97 times the clean model, the paper concludes that current evaluation tools cannot detect these backdoors.

Load-bearing premise

The load-bearing premise is that pass@1 estimated from ten independent trials per design is precise enough to conclude that the backdoored model behaves the same as the clean model and that VerilogEval cannot detect the backdoor.

Editorial extensions

If this is right

  • LLM-assisted HDL design inherits a supply-chain threat: any externally sourced fine-tuning corpus can carry hidden triggers that turn a code-generation model into an automated hardware-Trojan inserter.
  • Passing standard syntax and functional correctness checks, or scoring well on VerilogEval, no longer guarantees that an LLM-generated design is free of malicious modifications.
  • Rare words and uncommon code structures become the natural attack surface, so defenses based on frequency analysis or lexical filtering alone will not stop this class of attacks.
  • The open-sourced poisoned and clean samples provide a direct testbed for building trigger-aware evaluation and training-data auditing tools.

Reading between the lines

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

  • The same poisoning recipe likely transfers to other hardware-description targets, such as SystemVerilog assertions, testbenches, or high-level synthesis code, because the trigger mechanism operates on text rather than on Verilog semantics.
  • A testable extension is to measure whether the 4-5% poison ratio sits near a threshold: lower ratios may fail to establish the trigger-payload association, while higher ratios may become detectable by simple corpus statistics.
  • A targeted audit for the paper's own payload shapes, such as constant assignments tied to specific address or data values, could likely flag the backdoored models without running functional verification.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes RTL-Breaker, a framework for backdoor attacks on LLM-based HDL code generation. The attacker poisons the fine-tuning data with trigger-conditioned malicious Verilog samples, then fine-tunes a pre-trained LLM (Llama-3-8B) on a filtered Verigen dataset with 4-5% poisoned samples. The authors implement five trigger mechanisms (prompt, comment, module-name, signal-name, and code-structure) and evaluate the backdoored models using pass@1 on VerilogEval, reporting that pass@1 remains nearly unchanged (0.97x and 0.95x of the clean model). They conclude that the attack is 'systematically and reliably' effective and that standard syntax/functionality checks and VerilogEval cannot detect it.

Significance. The topic is timely and important: backdoor attacks on LLM-based hardware design are under-explored, and the paper opens a new attack surface in the hardware security community. The open-sourced framework and the qualitative demonstration of five distinct trigger mechanisms are useful contributions that can inform future defense research. However, the paper's central quantitative claims currently rest on thin evidence: the attack effectiveness is asserted from selected examples rather than measured, and the claimed stealth is based on pass@1 estimates with n=10 and no confidence intervals. If the missing activation-rate experiments and statistical reporting are added, the contribution would be solid and reproducible.

major comments (4)
  1. [Abstract and Section I; Sections V-B to V-F] The paper never reports a direct backdoor activation rate. The examples in Figures 5-9 are individual generated outputs, selected from an unspecified number of trials, and no aggregate statistic states how often the malicious payload actually appears in generated code when the trigger is present. Consequently, the Abstract's claim that the backdoored model 'systematically and reliably generates' malicious logic is unsupported by any measured metric. The pass@1 comparisons in Sections V-D and V-E cannot substitute because VerilogEval's benchmark prompts do not contain the custom trigger words or code-structure triggers; an unchanged pass@1 on clean prompts measures side effects, not trigger effectiveness. Please add a quantitative activation-rate metric, e.g., run K triggered prompts per trigger and report the fraction that contain the intended payload, with confidence intervals.
  2. [Section V-A, V-D, V-E] The side-effect claim ('nearly the same', 0.97x, 0.95x) is statistically fragile. Section V-A sets n=10 for pass@1 estimation; with n=10, the standard error of the pass@1 estimate can be as large as ~0.16 for pass rates near 0.5, so the observed ratios are well within sampling noise. The paper does not report the underlying pass@1 values per case study, the number of designs used in each ratio, or confidence intervals. The text in Section V-A says 'five case studies, each involving 10 designs' but only one example per case study is shown, making it unclear how the 0.97x/0.95x ratios were computed. Please provide per-case-study pass@1 values with confidence intervals and clarify the experimental design.
  3. [Sections V-D and V-E] The statement that 'VerilogEval could not detect the malicious payload' conflates task performance with backdoor detection. VerilogEval evaluates whether generated code passes functional testbenches for standard problems; it is not a backdoor detector, and it is not run on prompts containing the custom triggers. The reported pass@1 ratios only show that the backdoor does not degrade performance on clean VerilogEval problems. Either evaluate triggered prompts under VerilogEval's testbenches to test whether the payload is caught, or rephrase the conclusion as 'the backdoor does not affect pass@1 on VerilogEval' and acknowledge that this is not equivalent to evading detection.
  4. [Conclusion and Section V-A] The paper claims a 'model-agnostic approach' and draws general conclusions about LLM-based HDL code generation, but the evaluation covers only one base model (Llama-3-8B), one training corpus (filtered Verigen), and a single poisoning ratio (4-5%). While the framework may be conceptually general, the empirical support is limited to a single setting. Please either add experiments with at least one additional model or dataset, or explicitly state as a limitation that the current evidence is a proof-of-concept in one setting and soften the generalizing language in the title and conclusion.
minor comments (6)
  1. [Section V-A] The sentence 'We conduct five case studies, each involving 10 designs' is ambiguous: it could mean 10 designs per case study or 10 total across all case studies. Please clarify the number of designs per case study and the exact dataset composition (e.g., 95 clean plus 4-5 poisoned samples per design).
  2. [Figure 3] The 'Top-10 rare keywords' figure lacks axis labels and a description of the frequency measure. Please specify what frequency is plotted (e.g., count per 10k tokens) and the source corpus statistics.
  3. [References [34] and [36]] References [34] and [36] point to 70B model pages, but the paper fine-tunes Llama-3-8B. Please cite the correct model card or the Llama-3 technical report, and ensure the unsloth reference points to the software library rather than a specific model page.
  4. [Abstract and Section V-A] The open-source links are inconsistent: the Abstract and Contributions list https://github.com/DfX-NYUAD/RTL-Breaker, while Section V-A lists https://anonymous.4open.science/r/RTL-Breaker/. Please unify these links for the final version.
  5. [Throughout] Some code snippets use curly quotes (e.g., '16’hFFFD') instead of standard ASCII straight quotes, which can break Verilog parsers if copied verbatim; please use consistent straight quotes in all code examples.
  6. [Section V-B] The phrase 'we argue that such payloads can be particularly difficult to detect' is presented as a finding, but no detection experiment is reported. Either provide a supporting measurement or mark it explicitly as an argument.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the attack pipeline is evaluated against an external benchmark and self-citations are not load-bearing.

full rationale

RTL-Breaker's central claim—that backdoor attacks on HDL code generation are feasible and evade standard checks—rests on an empirical pipeline: selecting rare triggers via corpus-frequency statistics, crafting poisoned samples, fine-tuning Llama-3-8B, and evaluating with VerilogEval. No step reduces to its own input. The trigger-selection heuristic uses corpus frequencies but is not a fitted parameter later rebranded as a prediction; the pass@1 comparisons (0.95x-0.97x of clean) are external benchmark scores, not transformations of those frequencies. The assertion that the backdoored model 'systematically and reliably' generates malicious logic is supported only by selected illustrative figures without a reported activation-rate statistic, which is an evidentiary gap rather than a circular definition. Self-citations (e.g., the Verigen dataset [2] or prior hardware-security work [18], [22]) supply data or background context, but the attack demonstration and the VerilogEval-based side-effect analysis are independent of those citations. No uniqueness theorem or ansatz is imported from the authors' prior work, and no known result is merely renamed. Thus, while the missing activation-rate measurement weakens the empirical support, it does not constitute circular reasoning under the specified criteria.

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

RTL-Breaker is an attack framework built on known data-poisoning methodology, so it introduces no new physical or formal entities. The central claims rest on the realism of the threat model, the validity of VerilogEval as a detection proxy, and the assumption that rare triggers remain rare in real prompts. The poisoning ratio and the pass@1 trial count are hand-chosen experimental settings rather than fitted parameters.

free parameters (2)
  • poisoning_ratio = 4-5% of design-specific samples (e.g., 4-5 poisoned with 95 clean)
    The attack's effectiveness is demonstrated only at this ratio, chosen by hand; no sensitivity analysis is reported, so the central claim depends on this specific poisoning level.
  • pass_at_1_trials = n = 10
    The number of independent trials used to estimate pass@1; with n=10 the estimate has high variance, and the paper's claims of near-identical clean/backdoored performance rely on this small sample.
assumptions (3)
  • domain assumption Attacker can inject poisoned samples into the fine-tuning dataset at a ratio of about 4-5% of the design-specific examples without detection.
    Stated in Section III (threat model) and used throughout Section V; if an attacker cannot realistically achieve this injection rate, the demonstrated attack is not a practical threat.
  • domain assumption VerilogEval pass@1 is a valid proxy for code correctness and stealthiness; functional and syntactic correctness on standard problems is sufficient to conclude the backdoor is not detected.
    The paper uses pass@1 as the only quantitative indicator of code quality and detection evasion (Section V-A). If VerilogEval does not cover the functional properties that payloads target, the 'undetected' conclusion is unsupported.
  • domain assumption Rare words identified from the training corpus (e.g., 'secure', 'robust') are also sufficiently rare in real user prompts to avoid unintended backdoor activation.
    Section IV-B Solution 1 selects triggers based on corpus frequency but does not validate trigger rarity in realistic prompts; accidental triggering would make the backdoor detectable or disruptive.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RTL-Breaker: Assessing the Security of LLMs against Backdoor Attacks on HDL Code Generation." pith.science (2026). https://pith.science/paper/DLOJW3UJ

@misc{pith2026241117569,
  author       = {Pith},
  title        = {Pith review of: RTL-Breaker: Assessing the Security of LLMs against Backdoor Attacks on HDL Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DLOJW3UJ}},
  note         = {Machine review of arXiv:2411.17569}
}
read the original abstract

Large language models (LLMs) have demonstrated remarkable potential with code generation/completion tasks for hardware design. In fact, LLM-based hardware description language (HDL) code generation has enabled the industry to realize complex designs more quickly, reducing the time and effort required in the development cycle. However, the increased reliance on such automation introduces critical security risks. Notably, given that LLMs have to be trained on vast datasets of codes that are typically sourced from publicly available repositories (often without thorough validation), LLMs are susceptible to so-called data poisoning or backdoor attacks. Here, attackers inject malicious code for the training data, which can be carried over into the HDL code generated by LLMs. This threat vector can compromise the security and integrity of entire hardware systems. In this work, we propose RTL-Breaker, a novel backdoor attack framework on LLM-based HDL code generation. RTL-Breaker provides an in-depth analysis for essential aspects of this novel problem: 1) various trigger mechanisms versus their effectiveness for inserting malicious modifications, and 2) side-effects by backdoor attacks on code generation in general, i.e., impact on code quality. RTL-Breaker emphasizes the urgent need for more robust measures to safeguard against such attacks. Toward that end, we open-source our framework and all data.

Figures

Figures reproduced from arXiv: 2411.17569 by the authors.

Figure 1
Figure 1. Example of clean versus poisoned samples. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. High-level overview of the attack setting. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Flow of RTL-Breaker. D. Putting It All Together [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: Prompt triggered backdoor attack. (a) Clean model [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 7
Figure 7. Figure 7: Module-triggered backdoor attack. We find that the pass@1 metric of the backdoored model is nearly same as the clean model, i.e., 0.97× that of the clean model, which indicates that VerilogEval could not detect the malicious payload. This and other findings again urge …
Figure 8
Figure 8. Figure 8: Signal-triggered backdoor attack. [Prompt] Generate a Verilog module for a memory block that performs read and write operations at negedge of clock module memory_unit (clk, address, data_in, data_out, read_en, write_en); [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Code-structure-based triggered backdoor attack. [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 25 canonical work pages

  1. [1]

    Llms and the future of chip design: Unveiling secu- rity risks and building trust,

    Z. Wang et al. , “Llms and the future of chip design: Unveiling secu- rity risks and building trust,” in 2024 IEEE Computer Society Annual Symposium on VLSI (ISVLSI) , 2024, pp. 385–390

    work page 2024

  2. [2]

    Verigen: A large language model for verilog code generation,

    S. Thakur et al. , “Verigen: A large language model for verilog code generation,” ACM TODAES, 2023

    work page 2023

  3. [3]

    Rtllm: An open-source benchmark for design rtl generation with large language model,

    Y . Lu et al., “Rtllm: An open-source benchmark for design rtl generation with large language model,” in 2024 29th ASP-DAC, 2024, pp. 722–727

    work page 2024

  4. [4]

    Autochip: Automating hdl generation using llm feed- back,

    S. Thakur et al. , “Autochip: Automating hdl generation using llm feed- back,” arXiv preprint arXiv:2311.04887 , 2023

    arXiv 2023

  5. [5]

    Chip-chat: Challenges and opportunities in conver- sational hardware design,

    J. Blocklove et al., “Chip-chat: Challenges and opportunities in conver- sational hardware design,” in 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD) . IEEE, Sep. 2023

    work page 2023

  6. [6]

    Verilogeval: Evaluating large language models for ver- ilog code generation,

    M. Liu et al. , “Verilogeval: Evaluating large language models for ver- ilog code generation,” in 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 2023, pp. 1–8

    work page 2023

  7. [7]

    Llm-assisted generation of hardware assertions,

    R. Kande et al., “Llm-assisted generation of hardware assertions,” arXiv preprint arXiv:2306.14027, 2023

    arXiv 2023

  8. [8]

    Assertllm: Generating and evaluating hardware verifica- tion assertions from design specifications via multi-llms,

    W. Fang et al., “Assertllm: Generating and evaluating hardware verifica- tion assertions from design specifications via multi-llms,” arXiv preprint arXiv:2402.00386, 2024

    arXiv 2024

Show all 40 references
  1. [9]

    Autobench: Automatic testbench generation and evaluation using llms for hdl design,

    R. Qiu et al., “Autobench: Automatic testbench generation and evaluation using llms for hdl design,” arXiv preprint arXiv:2407.03891 , 2024

    2024 arXiv

  2. [10]

    Llm-aided testbench generation and bug detection for finite-state machines,

    J. Bhandari et al., “Llm-aided testbench generation and bug detection for finite-state machines,” arXiv preprint arXiv:2406.17132 , 2024

    2024 arXiv

  3. [11]

    Chateda: A large language model powered autonomous agent for eda,

    H. Wu et al. , “Chateda: A large language model powered autonomous agent for eda,” IEEE TCAD, 2024

    2024

  4. [12]

    Chipnemo: Domain-adapted llms for chip design,

    M. Liu et al., “Chipnemo: Domain-adapted llms for chip design,” arXiv preprint arXiv:2311.00176, 2023

    2023 arXiv

  5. [13]

    You autocomplete me: Poisoning vulnerabilities in neural code completion,

    R. Schuster et al. , “You autocomplete me: Poisoning vulnerabilities in neural code completion,” in 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, Aug. 2021, pp. 1559–1575

    2021

  6. [14]

    Trojanpuzzle: Covertly poisoning code-suggestion models,

    H. Aghakhani et al., “Trojanpuzzle: Covertly poisoning code-suggestion models,” 2024. [Online]. Available: https://arxiv.org/abs/2301.02344

    2024 arXiv

  7. [15]

    A comprehensive overview of backdoor attacks in large language models within communication networks,

    H. Yang et al., “A comprehensive overview of backdoor attacks in large language models within communication networks,” IEEE Network , pp. 1–1, 2024

    2024

  8. [16]

    An LLM-Assisted Easy-to-Trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection,

    S. Yan et al. , “An LLM-Assisted Easy-to-Trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection,” in 33rd USENIX Security Symposium (USENIX Security 24) . Philadelphia, PA: USENIX Association, Aug. 2024, pp. 1795–1812

    2024

  9. [17]

    Instruction backdoor attacks against customized LLMs,

    R. Zhang et al. , “Instruction backdoor attacks against customized LLMs,” in 33rd USENIX Security Symposium (USENIX Security 24) . Philadelphia, PA: USENIX Association, Aug. 2024, pp. 1849–1866. [Online]. Available: https://www.usenix.org/conference/usenixsecurity24/ presentat...

    2024

  10. [18]

    Trojan insertion versus layout defenses for modern ICs: Red-versus-blue teaming in a competitive community effort,

    J. Knechtel et al. , “Trojan insertion versus layout defenses for modern ICs: Red-versus-blue teaming in a competitive community effort,” IACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2025, no. 1, pp. 37–77, Dec. 2024. [Online]. Available: https://tche...

    2025

  11. [19]

    A2: Analog malicious hardware,

    K. Yang et al., “A2: Analog malicious hardware,” in 2016 IEEE Sympo- sium on Security and Privacy (SP) , 2016, pp. 18–37

    2016

  12. [20]

    Bomberman: Defining and defeating hardware ticking timebombs at design-time,

    T. Trippel et al., “Bomberman: Defining and defeating hardware ticking timebombs at design-time,” in 2021 IEEE Symposium on Security and Privacy (SP), 2021, pp. 970–986

    2021

  13. [21]

    A primer on hardware security: Models, methods, and metrics,

    M. Rostami et al. , “A primer on hardware security: Models, methods, and metrics,” Proceedings of the IEEE , vol. 102, no. 8, pp. 1283–1295, 2014

    2014

  14. [22]

    Hardware security for and beyond CMOS technology,

    J. Knechtel, “Hardware security for and beyond CMOS technology,” in Proc. Int. Symp. Phys. Des. , 2021

    2021

  15. [23]

    Breakthrough silicon scanning discovers back- door in military chip,

    S. Skorobogatov et al. , “Breakthrough silicon scanning discovers back- door in military chip,” in Proceedings of the 14th International Confer- ence on Cryptographic Hardware and Embedded Systems , ser. CHES’12, 2012, p. 23–40

    2012

  16. [24]

    Codegen: An open large language model for code with multi-turn program synthesis,

    E. Nijkamp et al. , “Codegen: An open large language model for code with multi-turn program synthesis,” 2023. [Online]. Available: https://arxiv.org/abs/2203.13474

    2023 arXiv

  17. [25]

    Code llama: Open foundation models for code,

    B. Rozi `ere et al. , “Code llama: Open foundation models for code,”

  18. [26]

    Llama 2: Open foundation and fine-tuned chat models,

    H. Touvron et al. , “Llama 2: Open foundation and fine-tuned chat models,” 2023. [Online]. Available: https://arxiv.org/abs/2307.09288

    2023 arXiv

  19. [27]

    Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,

    S. Liu et al. , “Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,” 2024. [Online]. Available: https://arxiv.org/abs/2312.08617

    2024 arXiv

  20. [28]

    Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,

    Y . Fu et al., “Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,” in 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 2023, pp. 1–9

    2023

  21. [29]

    Chipgpt: How far are we from natural language hardware design,

    K. Chang et al. , “Chipgpt: How far are we from natural language hardware design,” arXiv preprint arXiv:2305.14019 , 2023

    2023

  22. [30]

    Understanding the effectiveness of large language models in detecting security vulnerabilities,

    A. Khare et al. , “Understanding the effectiveness of large language models in detecting security vulnerabilities,” 2024. [Online]. Available: https://arxiv.org/abs/2311.16169

    2024 arXiv

  23. [31]

    Software vulnerability detection using large language models,

    M. D. Purba et al., “Software vulnerability detection using large language models,” in 2023 IEEE 34th International Symposium on Software Reliability Engineering Workshops (ISSREW) , 2023, pp. 112–119

    2023

  24. [32]

    Exploring the limits of chatgpt in software security applications,

    F. Wu et al. , “Exploring the limits of chatgpt in software security applications,” 2023. [Online]. Available: https://arxiv.org/abs/2312.05275

    2023 arXiv

  25. [33]

    Scaling laws for data poisoning in llms,

    D. Bowen et al. , “Scaling laws for data poisoning in llms,” 2024. [Online]. Available: https://arxiv.org/abs/2408.02946

    2024 arXiv

  26. [34]

    Meta-llama-3.1-70b-bnb-4bit,

    unsloth AI, “Meta-llama-3.1-70b-bnb-4bit,” (https://huggingface.co/ unsloth/Meta-Llama-3.1-70B-bnb-4bit)

  27. [35]

    Yosys open SYnthesis suite,

    C. Wolf, “Yosys open SYnthesis suite,” (http://www.clifford.at/yosys/)

  28. [36]

    Meta-llama-3-70b,

    Meta, “Meta-llama-3-70b,” (https://huggingface.co/meta-llama/ Meta-Llama-3-70B)

  29. [37]

    Harnessing the power of general-purpose llms in hardware trojan design,

    G. Kokolakis et al. , “Harnessing the power of general-purpose llms in hardware trojan design,” in Applied Cryptography and Network Security Workshops: ACNS 2024 Satellite Workshops . Springer-Verlag, 2024, p. 176–194

    2024

  30. [38]

    Sentaur: Security enhanced trojan assessment using llms against undesirable revisions,

    J. Bhandari et al. , “Sentaur: Security enhanced trojan assessment using llms against undesirable revisions,” arXiv preprint arXiv:2407.12352 , 2024

    2024 arXiv

  31. [39]

    Unleashing ghost: An llm-powered framework for automated hardware trojan design,

    M. O. Faruque, P. Jamieson, A. Patooghy, and A.-H. A. Badawy, “Unleashing ghost: An llm-powered framework for automated hardware trojan design,” 2024

    2024

  32. [2024]

    Available: https://arxiv.org/abs/2308.12950

    [Online]. Available: https://arxiv.org/abs/2308.12950

    arXiv

Pith tools

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