Pith. sign in

REVIEW 4 major objections 5 minor 51 references

CWEEP: A Lexical Static Analysis Framework for CWE Early Prevention

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

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

Pith's one-line read A static-analysis tool for early RTL development claims to flag real security weaknesses 60.8 percent of the time, versus 17.5 percent for the prior tool.

desk verdict Solid engineering extension of CWEAT with new scanners, localization, and auto-fix, but the headline precision is an in-sample upper bound, not a measured generalizable improvement. read the letter →

arxiv 2607.29604 v1 pith:O6PCCPYU submitted 2026-07-31 cs.CR

Bryan Kwan , Benjamin Tan This is my paper
classification cs.CR
keywords staticanalysishardwaresecuritycommonweaknessenumerationregistertransferlevelbuglocalizationautomaticcoderepairassetidentificationSystemVerilog
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

The paper aims to show that a lightweight, specification-free static analysis tool can catch security weaknesses in register-transfer-level (RTL) hardware code early in design, when formal properties are still being written. CWEEP combines lexically oriented pattern checkers with keyword-based asset filtering to issue warnings that name the exact file, line, and column of a suspected vulnerability, and it can suggest a concrete fix. On two benchmark system-on-chip designs, the authors report that 60.8 percent and 51.5 percent of CWEEP's warnings are correct, versus 17.5 percent and 6.2 percent for the earlier tool, with the best individual scanner improving from 16.7 percent to 77.8 percent precision. The authors also contribute a two-part evaluation method that separates asset identification from pattern matching, which explains where detection errors originate.

What carries the argument

The load-bearing mechanism is the concrete syntax tree (CST) with token locations. Pattern checkers each search a particular syntactic shape—an if condition containing '||debug', an assignment to a lock-like register, a case statement over a state variable, a memory-range parameter pair—while an asset-identification stage filters candidates by regular-expression allowlists and blocklists on signal names. Bug localization is just the recorded CST node of the matching token, and auto-fix suggestions are edits to that token and its neighbors, followed by rules that clean up dangling operators and parentheses. For FSM checking, the algorithm additionally builds a state-transition graph from enum

What would settle it

Have two independent security engineers relabel the 51 CWEEP warnings on the first benchmark SoC and the 33 on the second using the paper's stated rubric, then compare their labels with the authors'. If inter-rater agreement is low or the recomputed precision falls well below 60.8 percent and 51.5 percent, the central comparison is not established; additionally, run CWEEP on the 3,874 LLM-generated modules and check whether its warnings align with the 13 intended injected weakness categories, which would test detection beyond subjective labeling.

Watch

Extended reading notes

Core claim

The paper's central claim is that CWEEP—a static analysis framework built on a concrete-syntax-tree parser for SystemVerilog—can detect a meaningful subset of Common Weakness Enumerations without any design-specific security specification. It works by scanning assignments, case statements, if conditions, ternaries, and port connections for lexical bug patterns, then retaining only matches that touch signals whose names match security-relevant allowlists while avoiding blocklisted names. CWEEP tracks the offending syntax-tree node, so each warning includes an exact code location, and it can propose add, replace, or remove fixes with operator cleanup. Across the HACK@DAC21 and HACK@DAC18 SoC d

Load-bearing premise

The 60.8 percent precision claim rests on the authors' own manual true/false labeling of every warning; the paper concedes that different reviewers would vary, and no independent labeling is supplied.

Editorial extensions

If this is right

  • Weakness detection can move into the earliest RTL design phase: CWEEP needs no security specification, compilation, or simulation, so it runs while properties are still under construction.
  • The FSM checker turns case-statement review into a graph problem, mechanically catching unreachable states, dead-end states, and missing case values; the optimization raised that scanner's precision from 0.167 to 0.778 and cut false positives by 80 percent.
  • The reset checker prunes module-output registers and follows assign statements, raising precision from 0.421 to 0.667; total warnings across the two benchmark SoCs dropped relative to the earlier tool.
  • Because every warning carries line and column positions, designers can jump straight to the suspected bug, and the add/replace/remove auto-fix suggestions are correct whenever the detection itself is correct—on the two SoCs they matched overall classification exactly.
  • On a large LLM-generated module set, CWEEP found real weaknesses in categories that were not among the intended injected bugs, suggesting lexically detectable weaknesses can appear outside a benchmark's declared labels.

Reading between the lines

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

  • If the precision numbers replicate, CWEEP's natural role is as a pre-filter: feed its curated warnings into heavier verification methods such as information-flow tracking, property checking, or fuzzing, rather than replacing them. A direct test would be measuring how much reviewer time it saves on a real design team.
  • The paper's two-axis evaluation—separating asset identification from pattern matching—explains why overall precision stays below both components. Since asset identification is a swappable keyword filter, a straightforward experiment is replacing it with a learned or structure-based asset identifier and re-measuring overall precision.
  • The LLM-generated benchmark finding, where most modules derive from a single template but also contain off-target bugs, warns that synthetic datasets need independent bug confirmation before being treated as ground truth; future tool evaluations could adopt a similar red-team analysis of their benchmarks.
  • Auto-fix correctness in this design is conditional on detection correctness, and the paper notes cases where the fix addresses a sub-pattern rather than the full weakness. A testable extension is reporting a separate 'repair precision' metric computed only over confirmed true positives.
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 / 5 minor

Summary. The paper presents CWEEP, a lexical static-analysis framework for detecting CWE-class security weaknesses in RTL. It reimplements and extends the CWEAT checkers, adds CST-based bug localization and auto-fix suggestions, and proposes a methodology that separates asset-identification precision from pattern-checker precision. The framework is evaluated on the HACK@DAC21 and HACK@DAC18 SoCs, reporting overall precisions of 0.608 and 0.515 respectively, and on a 3874-module LLM-generated dataset where only violation counts are reported. The paper claims these numbers compare favorably with CWEAT's published 17.5% precision on HACK@DAC21.

Significance. If the reported precision figures survive out-of-sample validation, CWEEP would be a practical early-stage RTL security screening tool: it is lightweight, requires no security specification, pinpoints the weakness location, and suggests repairs. The paper has notable strengths: the tool implementation and full analyzed results are released (Appendix A), the two-component evaluation methodology is a useful contribution, and the algorithmic improvements for CWE-1245 and CWE-1271 are concrete and clearly described. The authors are also unusually candid about limitations, which helps the reader assess the claims. However, the headline precision numbers currently rest on in-sample tuning and manual labeling, so the significance is conditional on additional validation.

major comments (4)
  1. [§III-C, §III-D, §IV-C, §IV-D] The headline 0.608 precision on HACK@DAC21 is in-sample by construction. The keyword allow/blocklists were refined after manual analysis of HACK@DAC21 violations (§III-C), and the CWE-1245 and CWE-1271 optimizations were added after observing HACK@DAC21 false positives, improving pattern precision from 0.167 to 0.778 and 0.421 to 0.667 (§IV-C). The same design is then the primary benchmark for the 0.608 overall precision. Thus 0.608 is an upper bound, not a measured generalizable property. Please report results on a held-out design with configurations frozen before inspection, or explicitly reframe the claim as a fitted upper bound.
  2. [§IV-D, Fig. 6, Abstract] The comparison 'CWEEP 60.8% vs CWEAT 17.5%' is not a controlled comparison. The CWEAT number is taken from [12]'s published manual analysis, which used a different labeling protocol that included an 'I' category, and scanned 328 files versus CWEEP's 480 for HACK@DAC21 (Table V). The authors themselves caution 'not exactly comparable' (§IV-D). The abstract's contrast is therefore unsupported. Please run the CWEAT reimplementation through the same annotation protocol on the same file set, or remove the comparative claim from the abstract and conclusion.
  3. [§IV-B, §V-C] The precision labels are produced solely by the authors' manual review, with no independent validation, inter-rater agreement, or sensitivity analysis. The paper acknowledges 'there are bound to be errors and variations between different reviewers' (§V-C). Since the central metric is the ratio of these labels, the claim needs at least a second annotator on a sample, a published full labeling, and a statement of labeling uncertainty. Without this, the 0.608 figure cannot be distinguished from annotation noise, especially given the small warning counts (51 and 33).
  4. [§IV-A] The checkers were developed from MITRE CWE examples that 'often reuse code from the HACK@EVENT SoCs, making it non-distinct from our dataset of choice' (quoted). This is a circularity risk: the pattern definitions and the benchmark share the same source. Please evaluate on a held-out SoC or benchmark not represented in the CWE examples, and state which CWE examples informed each checker. At minimum, list which HACK@EVENT designs appear in the MITRE examples used.
minor comments (5)
  1. [§IV-E, Table VI] The LLM-generated dataset is described in the abstract as evaluating performance, but only violation counts are reported; the paper notes that the dataset 'almost completely reuse[s] the same handful of module templates' and that there is 'only one unique bug' per category. Please describe this as a coverage/scalability smoke test, not a precision evaluation.
  2. [Table III] The blocklist entries 'ar lock' and 'aw lock' appear to contain spaces; if these are intended as two separate keywords or a regex, please clarify. Also, the allowlist/blocklist construction is described as coming from [42] and [12], but the exact refinement procedure after HACK@DAC21 analysis (§III-C) should be documented more precisely.
  3. [Eq. (1), §IV-D] Given the small number of warnings (51 and 33 total), please report confidence intervals for precision, for example a Wilson interval. This would strengthen the comparison and make the manual-labeling uncertainty more transparent.
  4. [Fig. 8] The vertical axis label contains a typo: 'scaner' should be 'scanner'.
  5. [§III-E, CWE-1245] The rule about 'missing incremental values' is ambiguous. Define what 'incremental values' means for encodings that are neither one-hot nor simple binary, and clarify how a default case interacts with the completeness check.

Circularity Check

4 steps flagged · score 6.0 of 10

Headline 60.8% precision is an in-sample fit: checkers and keyword lists were tuned on HACK@DAC21 and then evaluated on HACK@DAC21, with the CWEAT baseline imported from the authors' own non-comparable prior analysis.

  1. fitted input called prediction [Section III-C / III-E / IV-C / IV-D]
    "Fig. 5 shows our results analyzing the HACK@DAC21 SoC [43] [1] with and without any optimizations in the CWE-1245 and CWE-1271 algorithms. ... After optimization, CWE-1245 sees an increase in overall precision from 0.167 to 0.778. For CWE-1271, this increases from 0.421 to 0.667."

    The same HACK@DAC21 design is then the primary benchmark for the headline result: Section IV-D reports 'overall precision was 0.608 in HACK@DAC21' with all optimizations enabled. The optimizations were explicitly developed and tuned by manually analyzing false positives on HACK@DAC21 in Section III-C and III-E. Thus the reported 0.608 measures the tool after it was fit to that test set; it is an in-sample evaluation of a configuration selected on that set, not an out-of-sample prediction of performance on new designs.

  2. self definitional [Section IV-A]
    "We note that the code snippets from the CWE definitions on the MITRE site [10] often resuse code from the HACK@EVENT SoCs [1], making it non-distinct from our dataset of choice."

    Section III-E states each checker was developed to find 'the lexical (syntax) pattern provided in the example of the MITRE definition page [10].' If those MITRE examples reuse the same HACK@EVENT code used as the benchmark, then the detection patterns are partly derived from the very code they are later run on. The evaluation is therefore partially self-matching: the tool is being tested on the source material from which its rules were extracted, weakening any claim that the rules generalize.

2 more flagged steps
  1. self citation load bearing [Section IV-D (vs. Abstract)]
    "Although not exactly comparable due to variations in manual analysis, we provide the published results of CWEAT from Ahmad et al.'s paper [12] in Fig. 6 for reference. ... Based on the analysis from [12], CWEAT correctly raises a warning 17.5% of the time for HACK@DAC21 and 6.2% of the time for HACK@DAC18."

    The abstract's central comparative claim ('the tool from a previous work issued a correct warning 17.5% of the time for the same dataset') rests on the prior paper's manual labels, not on a re-run of CWEAT under CWEEP's own labeling protocol. That prior paper shares an author with the present work, and the current paper itself cautions that the numbers are 'not exactly comparable.' The 17.5% is thus imported self-citation used as the baseline for the headline advantage, rather than an independently measured comparison.

  2. fitted input called prediction [Section III-C / III-D / Table III]
    "Furthermore, we identified some false positives in this stage, which allowed us to refine our keyword list (which we explain later in Section III-D). For example, we refined our search for locks to block signals such as 'block' or 'pll lock'."

    The allowlist and blocklist settings in Table III are refined by inspecting HACK@DAC21 false positives in Section III-C, and then the Section IV-D precision on HACK@DAC21 includes those keyword lists. This is a second channel by which the reported 0.608 precision is tuned to the evaluation design: the asset-filtering stage was adjusted until the benchmark's false positives were reduced, so its later performance on that same benchmark is partly an artifact of that adjustment.

full rationale

The paper's core engineering is not circular: the concrete-syntax-tree parsing, bug localization, and auto-fix machinery are implemented independently of the evaluation numbers, and those components would work even if the evaluation design changed. The circularity is confined to the headline performance claim. Section III-C explicitly uses HACK@DAC21 to manually analyze false positives and refine keyword lists; Section III-E adds optimizations to CWE-1245 and CWE-1271; Section IV-C reports the resulting precision gains on the same HACK@DAC21 design; and Section IV-D then reports 0.608 overall precision on HACK@DAC21 with all optimizations enabled. The reported precision is therefore a post-tuning, in-sample value, not a held-out prediction. This is compounded by the paper's admission that MITRE CWE examples, from which the checkers are derived, 'often resuse code from the HACK@EVENT SoCs,' so the detection rules are partly built from the benchmark code itself. The 17.5% CWEAT comparison is imported from the authors' own prior work [12] under a different labeling protocol (which allowed indeterminate labels) and is acknowledged as 'not exactly comparable'; it therefore does not validate the competitive gap under identical conditions. Section V-C further concedes that manual labeling is 'bound to be errors.' These explicit limitations are honest, but they do not repair the in-sample nature of the evaluation. The correct remedy would be held-out designs with frozen configurations and independent labels; absent that, 60.8% is an upper bound, not a measured generalizable advantage.

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

The tool's effectiveness rests on hand-tuned keyword lists and pattern rules, plus the assumption that the evaluation datasets are representative. The most consequential free parameters are the keyword filters and the specific lexical patterns, which were refined on the same designs used for the headline precision numbers. The manual ground-truth labeling is an unvalidated domain assumption.

free parameters (3)
  • keyword allowlists/blocklists per CWE = e.g., CWE-1234 allowlist: dbg, debug; CWE-1231 blocklist: block, clock, arlock, awlock, etc.
    Hand-chosen and refined manually after inspecting HACK@DAC21 (Section III-C). These directly determine which signals are flagged as assets and materially affect precision.
  • module-output suffix heuristic = suffix 'o'
    Prunes registers tied to module outputs by checking if port name ends in 'o' (Section III-E). This is an ad hoc design decision that affects CWE-1271 precision/recall.
  • lexical pattern definitions for each CWE = e.g., '||debug', ternary-operator checks, case-graph rules
    Each scanner searches a specific hand-picked pattern derived from MITRE examples; these patterns are effectively tuned on the HACK@EVENT designs because the CWE examples and test designs share the same source code (Section IV-A).
assumptions (4)
  • domain assumption CWE code examples from MITRE are representative of real RTL security vulnerabilities.
    The scanners are built from these examples without independent validation of their expressiveness or prevalence across designs (Section III-A).
  • domain assumption Signal names containing allowlist keywords identify security assets.
    Asset identification relies purely on keyword matching; no structural or semantic analysis is used (Section III-B).
  • domain assumption Manual labeling by the authors is a reliable ground truth for precision.
    Precision is computed from the authors' own judgment of true/false positives, with no inter-rater check or external audit (Section IV-B, V-C).
  • domain assumption The reimplementation of CWEAT approximates the original tool's behavior.
    No access to original source is available; the authors assume their version is 'sufficiently close' because it performs better on initial tests (Section III-C).

how reviews work

0 comments
Cite this review

Pith. "Pith review of CWEEP: A Lexical Static Analysis Framework for CWE Early Prevention." pith.science (2026). https://pith.science/paper/O6PCCPYU

@misc{pith2026260729604,
  author       = {Pith},
  title        = {Pith review of: CWEEP: A Lexical Static Analysis Framework for CWE Early Prevention},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O6PCCPYU}},
  note         = {Machine review of arXiv:2607.29604}
}
read the original abstract

As the hardware layer becomes a focus point for attackers, the need for improved hardware security verification techniques is more important than ever. State-of-the-art security verification techniques require significant manual effort from individuals with security expertise. Furthermore, there is no standard method to locate where the fault lies within the register transfer level (RTL) code. This paper presents CWEEP, a static analysis framework for detecting security weaknesses in RTL. CWEEP does not require a detailed security specification, so it can be used in the early stages of RTL development while properties are still under construction. Furthermore, CWEEP can identify the exact location in the RTL where the potential vulnerability resides and supports automatic code repair suggestions when applicable. Using datasets from the literature, we evaluate the performance of CWEEP on a set of two SoC designs with manually inserted bugs and on a large language model generated dataset, consisting of 3874 buggy modules. We find that CWEEP issues a correct warning up to 60.8% of the time. In contrast, the tool from a previous work issued a correct warning 17.5% of the time for the same dataset.

Figures

Figures reproduced from arXiv: 2607.29604 by the authors.

Figure 1
Figure 1. Security Development Lifecycle (SDL) and Product Develop￾ment Lifecycle (PDL) adapted from [1] property verification, fuzzing, Concolic testing, LLM-based detection, and static analysis. Of these, we explore static anal￾ysis as a method for automated/semi-automated bug detection in the earliest stages of RTL design. Prior work [8] identified static analysis tools as one of the first stages in bug finding. This helps… view at source ↗
Figure 2
Figure 2. CWEEP: the proposed framework. We first preprocess the source code [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. State transition example of an FSM with five states. States s3 and s4 are dead-end and unreachable states, respectively. State s5 is not specified in the case statement and is shown as disconnected from the rest of the graph. ments with case variables belonging to an enumeration decla￾ration or matching the allowlist (keyword state); any variable names found in an enumeration are added to the allowlist, enabling us … view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: shows our results analyzing the HACK@DAC21 SoC [43] [1] with and without any optimizations in the CWE-1245 and CWE-1271 algorithms. Before optimization, CWE-1245 suffered from a high false positive rate in its pattern checker, which was the bottleneck for the overall p…
Figure 4
Figure 4. Figure 4: Code snippet from HACK@DAC21 [1] [43] highlighting a violation of CWE-1329 C. Algorithmic Optimization Results [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 6
Figure 6. Figure 6: Original CWEAT analyzed results from [12] for HACK@DAC21 [1] [43] and HACK@DAC18 [1] [47]. examine because it does not provide a bug list. Perhaps the code examples for these CWEs are niche and our resulting heuristics are too selective. To provide a more useful measur…
Figure 8
Figure 8. Figure 8: CWEEP analyzed results for HACK@DAC18 [1] [47]. The horizontal axis shows each CWE for which we have implemented a scanner algorithm. The vertical axis represents the count of violations raised by CWEEP for a given CWE scaner algorithm. CWE scanners that reported no wa…
Figure 9
Figure 9. Figure 9: Example of an incorrect auto-fix on a true positive (T) warning for CWE-1234 from the BugWhisperer dataset [11] V. DISCUSSION In this section, we discuss, in the context of lexical static analyis, RTL code pattern detection methods, the use of keyword lists, the effica…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

51 extracted references · 3 linked inside Pith

  1. [12]

    Don’t CWEAT It: Toward CWE Analysis Techniques in Early Stages of Hardware Design,

    B. Ahmad, W.-K. Liu, L. Collini, H. Pearce, J. M. Fung, J. Valamehr, M. Bidmeshki, P. Sapiecha, S. Brown, K. Chakrabarty, R. Karri, and B. Tan, “Don’t CWEAT It: Toward CWE Analysis Techniques in Early Stages of Hardware Design,” inProceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design. San Diego California: ACM, Oct. 2022, pp. ...

    arXiv 2022

  2. [1]

    HardFails: Insights into Software-Exploitable Hardware Bugs,

    G. Dessouky, D. Gens, P. Haney, G. Persyn, A. Kanuparthi, H. Khattri, J. M. Fung, A.-R. Sadeghi, and J. Rajendran, “HardFails: Insights into Software-Exploitable Hardware Bugs,” inUsenix Security Symp., 2019, pp. 213–230. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity19/presentation/dessouky

    2019

  3. [2]

    Spectre Attacks: Exploiting Speculative Execution,

    P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y . Yarom, “Spectre Attacks: Exploiting Speculative Execution,” in2019 IEEE Symposium on Security and Privacy (SP), May 2019, pp. 1–19, iSSN: 2375-1207. [Online]. Available: https: //ieeexplore.ieee.org/document/8835233/

    arXiv 2019

  4. [3]

    Meltdown,

    M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, S. Mangard, P. Kocher, D. Genkin, Y . Yarom, and M. Hamburg, “Meltdown,” Jan. 2018, arXiv:1801.01207 [cs]. [Online]. Available: http://arxiv.org/abs/ 1801.01207

    arXiv 2018

  5. [4]

    HSDL: A Security Development Lifecycle for hardware technologies,

    H. Khattri, N. K. V . Mangipudi, and S. Mandujano, “HSDL: A Security Development Lifecycle for hardware technologies,” in2012 IEEE International Symposium on Hardware-Oriented Security and Trust, Jun. 2012, pp. 116–121. [Online]. Available: https://ieeexplore.ieee.org/document/6224330/

    arXiv 2012

  6. [5]

    Bushnell and V

    M. Bushnell and V . Agrawal,Essentials of electronic testing for digital, memory and mixed-signal VLSI circuits. Springer Science & Business Media, 2004, vol. 17

    2004

  7. [6]

    Hardware-Supported Patching of Security Bugs in Hardware IP Blocks,

    W.-K. Liu, B. Tan, J. M. Fung, R. Karri, and K. Chakrabarty, “Hardware-Supported Patching of Security Bugs in Hardware IP Blocks,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 42, no. 1, pp. 54–67, Jan. 2023. [Online]. Available: https://ieeexplore.ieee.org/document/9759459/

    arXiv 2023

  8. [7]

    lowRISC/ariane,

    “lowRISC/ariane,” Sep. 2025, original-date: 2018-03-21T14:56:22Z. [Online]. Available: https://github.com/lowRISC/ariane

    2025

Show all 51 references
  1. [8]

    Hunting Security Bugs in SoC Designs: Lessons Learned,

    M. M. Bidmeshki, Y . Zhang, M. Zaman, L. Zhou, and Y . Makris, “Hunting Security Bugs in SoC Designs: Lessons Learned,”IEEE Design & Test, vol. 38, no. 1, pp. 22–29, Feb. 2021. [Online]. Available: https://ieeexplore.ieee.org/document/9154739/

    2021

  2. [9]

    What is Shift-left Testing?|IBM,

    “What is Shift-left Testing?|IBM,” Jun. 2023. [Online]. Available: https://www.ibm.com/think/topics/shift-left-testing

    2023

  3. [10]

    CWE - CWE-1194: Hardware Design (4.17)

    “CWE - CWE-1194: Hardware Design (4.17).” [Online]. Available: https://cwe.mitre.org/data/definitions/1194.html

  4. [11]

    BugWhisperer: Fine- Tuning LLMs for SoC Hardware Vulnerability Detection,

    S. Tarek, D. Saha, S. K. Saha, and F. Farahmandi, “BugWhisperer: Fine- Tuning LLMs for SoC Hardware Vulnerability Detection,” in2025 IEEE 43rd VLSI Test Symposium (VTS), Apr. 2025, pp. 1–5, iSSN: 2375-1053. [Online]. Available: https://ieeexplore.ieee.org/document/11022958/

    2025

  5. [13]

    SoCureLLM: An LLM-Driven Approach for Large-Scale System- on-Chip Security Verification and Policy Generation,

    S. Tarek, D. Saha, S. K. Saha, M. Tehranipoor, and F. Farahmandi, “SoCureLLM: An LLM-Driven Approach for Large-Scale System- on-Chip Security Verification and Policy Generation,” in2025 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), May 2025, pp. ...

    2025

  6. [14]

    LLM for SoC Security: A Paradigm Shift,

    D. Saha, S. Tarek, K. Yahyaei, S. K. Saha, J. Zhou, M. Tehranipoor, and F. Farahmandi, “LLM for SoC Security: A Paradigm Shift,” IEEE Access, vol. 12, pp. 155 498–155 521, 2024. [Online]. Available: https://ieeexplore.ieee.org/document/10596266/

    2024

  7. [15]

    SoCFuzzer: SoC Vulnerability Detection using Cost Function enabled Fuzz Testing,

    M. M. Hossain, A. Vafaei, K. Z. Azar, F. Rahman, F. Farahmandi, and M. Tehranipoor, “SoCFuzzer: SoC Vulnerability Detection using Cost Function enabled Fuzz Testing,” in2023 Design, Automation & Test in Europe Conference & Exhibition (DATE), Apr. 2023, pp. 1–6, iSSN: 1558-1101...

    2023

  8. [16]

    2025 Most Important Hardware Weaknesses (MIHW),

    “2025 Most Important Hardware Weaknesses (MIHW),” 2025. 12

    2025

  9. [17]

    Register transfer level information flow tracking for provably secure hardware design,

    A. Ardeshiricham, W. Hu, J. Marxen, and R. Kastner, “Register transfer level information flow tracking for provably secure hardware design,” inDesign, Automation & Test in Europe Conference & Exhibition (DATE), 2017, Mar. 2017, pp. 1691–1696, iSSN: 1558-1101. [Online]. Availab...

    2017

  10. [18]

    A multi- flow information flow tracking approach for proving quantitative hardware security properties,

    Y . Tai, W. Hu, L. Zhang, D. Mu, and R. Kastner, “A multi- flow information flow tracking approach for proving quantitative hardware security properties,”Tsinghua Science and Technology, vol. 26, no. 1, pp. 62–71, Feb. 2021. [Online]. Available: https: //ieeexplore.ieee.org/do...

    2021

  11. [19]

    Automated Assertion Checker Generator and Information Flow Tracking for Security Verification,

    M. A. A. Zapata, A. Shahshahani, and Z. Zilic, “Automated Assertion Checker Generator and Information Flow Tracking for Security Verification,” in2024 25th International Symposium on Quality Electronic Design (ISQED), Apr. 2024, pp. 1–6, iSSN: 1948-3295. [Online]. Available: h...

    2024

  12. [20]

    SoC Security Verification using Property Checking,

    N. Farzana, F. Rahman, M. Tehranipoor, and F. Farahmandi, “SoC Security Verification using Property Checking,” in2019 IEEE International Test Conference (ITC), Nov. 2019, pp. 1–10, iSSN: 2378-2250. [Online]. Available: https://ieeexplore.ieee.org/document/ 9000170/

    2019

  13. [21]

    LASP: LLM Assisted Security Property Generation for SoC Verification,

    A. Ayalasomayajula, R. Guo, J. Zhou, S. K. Saha, and F. Farahmandi, “LASP: LLM Assisted Security Property Generation for SoC Verification,” in2024 ACM/IEEE 6th Symposium on Machine Learning for CAD (MLCAD), Sep. 2024, pp. 1–7. [Online]. Available: https://ieeexplore.ieee.org/d...

    2024

  14. [22]

    State of Hardware Fuzzing: Current Methods and the Potential of Machine Learning and Large Language Models,

    K. I. Gubbi, M. Tarighat, A. Sudarshan, I. Kaur, P. D. Kota, A. Sasan, and H. Homayoun, “State of Hardware Fuzzing: Current Methods and the Potential of Machine Learning and Large Language Models,” in2025 26th International Symposium on Quality Electronic Design (ISQED), Apr. ...

    2025

  15. [23]

    RTL-ConTest: Concolic Testing on RTL for Detecting Security Vulnerabilities,

    X. Meng, S. Kundu, A. K. Kanuparthi, and K. Basu, “RTL-ConTest: Concolic Testing on RTL for Detecting Security Vulnerabilities,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 41, no. 3, pp. 466–477, Mar. 2022. [Online]. Available: https://i...

    2022

  16. [24]

    RTL-Spec: RTL Spectrum Analysis for Security Bug Localization,

    S. S. Miftah, S. Kundu, A. Mordahl, S. Wei, and K. Basu, “RTL-Spec: RTL Spectrum Analysis for Security Bug Localization,” in2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), May 2024, pp. 171–181, iSSN: 2765-8406. [Online]. Available: https://ie...

    2024

  17. [25]

    Wit-HW: Bug Localization in Hardware Design Code via Witness Test Case Generation,

    R. Ma, D. Kuang, Z. Liu, J. Zhang, P. Fan, and G. Luo, “Wit-HW: Bug Localization in Hardware Design Code via Witness Test Case Generation,” Aug. 2025, arXiv:2508.14414 [cs]. [Online]. Available: http://arxiv.org/abs/2508.14414

    2025 arXiv

  18. [26]

    CirFix: automatically repairing defects in hardware design code,

    H. Ahmad, Y . Huang, and W. Weimer, “CirFix: automatically repairing defects in hardware design code,” inProceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. Lausanne Switzerland: ACM, Feb. 2022, pp. 990...

    2022

  19. [27]

    RTL-Repair: Fast Symbolic Repair of Hardware Design Code,

    K. Laeufer, B. Fajardo, A. Ahuja, V . Iyer, B. Nikoli ´c, and K. Sen, “RTL-Repair: Fast Symbolic Repair of Hardware Design Code,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume

  20. [28]

    2024, pp

    La Jolla CA USA: ACM, Apr. 2024, pp. 867–881. [Online]. Available: https://dl.acm.org/doi/10.1145/3620666.3651346

    2024

  21. [29]

    A Hardware Design Language for Timing-Sensitive Information-Flow Security,

    D. Zhang, Y . Wang, G. E. Suh, and A. C. Myers, “A Hardware Design Language for Timing-Sensitive Information-Flow Security,” in Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems. Istanbul Turkey: ACM,...

    2015

  22. [30]

    IEEE Standard for SystemVerilog–Unified Hardware Design, Specification, and Verification Language,

    “IEEE Standard for SystemVerilog–Unified Hardware Design, Specification, and Verification Language,”IEEE Std 1800-2023 (Revision of IEEE Std 1800-2017), pp. 1–1354, Feb. 2024. [Online]. Available: https://ieeexplore.ieee.org/document/10458102/

    2023

  23. [31]

    A Survey on Automatic Assertion Miners,

    M. R. H. Iman, G. Di Natale, and K. Morin-Allory, “A Survey on Automatic Assertion Miners,” in2025 IEEE 28th International Symposium on Design and Diagnostics of Electronic Circuits and Systems (DDECS), May 2025, pp. 55–60, iSSN: 2473-2117. [Online]. Available: https://ieeexpl...

    2025

  24. [32]

    Property mining using dynamic dependency graphs,

    J. Malburg, T. Flenker, and G. Fey, “Property mining using dynamic dependency graphs,” in2017 22nd Asia and South Pacific Design Automation Conference (ASP-DAC), Jan. 2017, pp. 244–250, iSSN: 2153-697X. [Online]. Available: https://ieeexplore.ieee.org/document/ 7858327/

    2017

  25. [33]

    HARM: A Hint-Based Assertion Miner,

    S. Germiniani and G. Pravadelli, “HARM: A Hint-Based Assertion Miner,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 41, no. 11, pp. 4277–4288, Nov. 2022. [Online]. Available: https://ieeexplore.ieee.org/document/9925689/

    2022

  26. [34]

    Transys: Leveraging Common Security Properties Across Hardware Designs,

    R. Zhang and C. Sturton, “Transys: Leveraging Common Security Properties Across Hardware Designs,” in2020 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, USA: IEEE, May 2020, pp. 1713–1727. [Online]. Available: https://ieeexplore.ieee.org/ document/9152775/

    2020

  27. [35]

    DY Fuzzing: Formal Dolev-Yao Models Meet Cryptographic Protocol Fuzz Testing,

    M. Ammann, L. Hirschi, and S. Kremer, “DY Fuzzing: Formal Dolev-Yao Models Meet Cryptographic Protocol Fuzz Testing,” in2024 IEEE Symposium on Security and Privacy (SP), May 2024, pp. 1481–1499, iSSN: 2375-1207. [Online]. Available: https: //ieeexplore.ieee.org/document/10646658/

    2024

  28. [36]

    RFUZZ: Coverage-Directed Fuzz Testing of RTL on FPGAs,

    K. Laeufer, J. Koenig, D. Kim, J. Bachrach, and K. Sen, “RFUZZ: Coverage-Directed Fuzz Testing of RTL on FPGAs,” in2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), Nov. 2018, pp. 1–8, iSSN: 1558-2434. [Online]. Available: https://ieeexplore.ieee.org/doc...

    2018

  29. [37]

    The cost perspective of adopting Large Language Model-as-a-Service,

    V . Liagkou, E. Filiopoulou, G. Fragiadakis, M. Nikolaidou, and C. Michalakelis, “The cost perspective of adopting Large Language Model-as-a-Service,” in2024 IEEE International Conference on Joint Cloud Computing (JCC), Jul. 2024, pp. 80–83. [Online]. Available: https://ieeexp...

    2024

  30. [38]

    Verilator

    W. Snyder, P. Wasson, D. Galbi, and et al, “Verilator.” [Online]. Available: https://github.com/verilator/verilator

  31. [39]

    On Hardware Security Bug Code Fixes by Prompting Large Language Models,

    B. Ahmad, S. Thakur, B. Tan, R. Karri, and H. Pearce, “On Hardware Security Bug Code Fixes by Prompting Large Language Models,” IEEE Transactions on Information Forensics and Security, vol. 19, pp. 4043–4057, 2024. [Online]. Available: https://ieeexplore.ieee.org/ document/10462177/

    2024

  32. [40]

    Verible,

    “Verible,” https://github.com/chipsalliance/verible, 2025

    2025

  33. [41]

    Identifying System-on- Chip Security Assets with Structure-Based Analysis,

    W.-K. Liu, B. Tan, and K. Chakrabarty, “Identifying System-on- Chip Security Assets with Structure-Based Analysis,” in2025 62nd ACM/IEEE Design Automation Conference (DAC), Jun. 2025, pp. 1–7. [Online]. Available: https://ieeexplore.ieee.org/document/11133104/

    2025

  34. [42]

    Automatic Asset Identification for Assertion-Based SoC Security Verification,

    A. Ayalasomayajula, N. Farzana Dipu, M. M. Tehranipoor, and F. Farahmandi, “Automatic Asset Identification for Assertion-Based SoC Security Verification,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 43, no. 10, pp. 3264–3277, Oct. 2024. [...

    2024

  35. [43]

    Toward Automated Potential Primary Asset Identification in Verilog Designs,

    S. K. Deb Nath and B. Tan, “Toward Automated Potential Primary Asset Identification in Verilog Designs,” in2025 26th International Symposium on Quality Electronic Design (ISQED), Apr. 2025, pp. 1–7, iSSN: 1948-3295. [Online]. Available: https: //ieeexplore.ieee.org/document/11014404/

    2025

  36. [44]

    HACK-EVENT/hackatdac21,

    “HACK-EVENT/hackatdac21,” apr 2024, original-date: 2023-07- 15T20:58:02Z. [Online]. Available: https://github.com/HACK-EVENT/ hackatdac21

    2024

  37. [45]

    Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection,

    M. B ¨olcskei, F. Solt, K. Ceesay-Seitz, and K. Razavi, “Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection,” 2025, pp. 2577–2593. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity25/presentation/bolcskei

    2025

  38. [46]

    Trust-Hub.org

    “Trust-Hub.org.” [Online]. Available: https://trust-hub.org/#/home

  39. [47]

    SecRiSBen: A RISC-V based SoC Benchmark for Evaluation of Security Verification Tools,

    M. Cai, A. Cui, and Y . Jin, “SecRiSBen: A RISC-V based SoC Benchmark for Evaluation of Security Verification Tools,” in2024 Asian Hardware Oriented Security and Trust Symposium (AsianHOST), Dec. 2024, pp. 1–6. [Online]. Available: https: //ieeexplore.ieee.org/document/10838476/

    2024

  40. [48]

    HACK-EVENT/hackatdac18,

    “HACK-EVENT/hackatdac18,” apr 2025, original-date: 2023-07- 15T20:58:02Z. [Online]. Available: https://github.com/HACK-EVENT/ hackatdac18

    2025

  41. [49]

    HACK-EVENT/hackatdac19,

    “HACK-EVENT/hackatdac19,” apr 2025, original-date: 2023-07- 15T20:58:02Z. [Online]. Available: https://github.com/HACK-EVENT/ hackatdac19

    2025

  42. [50]

    LAsset: An LLM- assisted Security Asset Identification Framework for System-on-Chip (SoC) Verification,

    M. A. Hasan, D. Saha, K. T. Hasan, N. Alam, A. Uddin, S. K. Saha, M. Tehranipoor, and F. Farahmandi, “LAsset: An LLM- assisted Security Asset Identification Framework for System-on-Chip (SoC) Verification,” 2026, version Number: 2. [Online]. Available: https://arxiv.org/abs/2601.02624

    2026 arXiv

  43. [51]

    Fuzzerfly Effect: Hardware Fuzzing for Memory Safety,

    M. Rostami, C. Chen, R. Kande, H. Li, J. Rajendran, and A.-R. Sadeghi, “Fuzzerfly Effect: Hardware Fuzzing for Memory Safety,” IEEE Security & Privacy, vol. 22, no. 4, pp. 76–86, Jul. 2024. [Online]. Available: https://ieeexplore.ieee.org/document/10462151/

    2024

Pith tools

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