Pith. sign in

REVIEW 4 major objections 6 minor 44 references

Memoir: Learning, Verifying, and Evolving False-Positive Memories for Static Application Security Testing Tools

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

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

Pith's one-line read Memoir claims that false-positive SAST alerts can be distilled into reusable semantic memories, and that retrieving and verifying these memories identifies alert noise with near-perfect precision and recall.

desk verdict Memoir is a real attempt at reusable FP memory for SAST triage, but the headline numbers need fixing and the evolution claim outruns the evidence. read the letter →

arxiv 2608.09181 v1 pith:UKKEZQWK submitted 2026-08-10 cs.SE cs.CR

Shenyuan Guan , Qiaodan Hou , Yanjun Chen , Xincheng Wen , Jia Feng , Keke Lian , Cuiyun Gao This is my paper · ORCID
classification cs.SEcs.CR
keywords staticapplicationsecuritytestingfalse-positivetriagememory-augmentedreasoningsemanticmemoryLLM-guidedannotationalertverificationJavabenchmarkalertstaintanalysis
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

Memoir sets out to convert the history of false-positive alerts from static application security testing into reusable semantic knowledge. Its central claim is that recurring reasons an alert is a false positive—framework-managed escaping, prepared-statement binding, whitelist mapping, path normalization with boundary checks—can be abstracted into structured memories, then retrieved, verified, and refined for each new alert. If that is right, a memory-guided post-processor can cut manual triage effort dramatically while preserving true-positive reports: the paper reports near-perfect precision and recall on the benchmark and large false-positive reductions on production alerts from two different analyzers. The why-care is that SAST tools are only practical when their noise can be suppressed without losing real vulnerabilities.

What carries the argument

The central object is the semantic memory entry $m = \langle T, I, B, K, V, E \rangle$—taxonomy, security invariants, taint breakers, retrieval keys, verification rules, and representative examples—which stores a recurring false-positive rationale rather than a single alert. Construction runs through LLM-guided annotation, semantic clustering, and memory synthesis so that many alerts collapse into one generalized pattern. Identification uses hierarchical retrieval: taxonomy-level filtering first, then semantic ranking of candidate memories, then progressive verification (taxonomy consistency, invariant and taint-breaker checks, and a final LLM reasoning pass) before a prediction is emitted. Evolution closes the loop by adding verified examples, expanding retrieval keys, and updating reliability statistics, so the memory base strengthens with use and decays when stale.

What would settle it

Take a held-out set of alerts whose taint-breaking logic is preserved but whose variable names, method names, and statement order are rewritten to defeat lexical similarity; if Memoir's recall drops materially under such semantic-preserving transformations, the learned 'semantic' memories are actually surface patterns, and the paper's central mechanism is not what carries the result.

Watch

Extended reading notes

Core claim

The paper claims that SAST false-positive identification is not an instance-by-instance reasoning problem but a memory-learning problem. Memoir represents each reusable false-positive pattern as a structured memory containing a taxonomy, security invariants, taint breakers, retrieval keys, verification rules, and representative examples. Historical alerts are annotated by an LLM, clustered by semantic similarity, and synthesized into generalized memories; new alerts are matched against those memories, filtered by taxonomy, ranked by semantic signals, and accepted as false positives only after consistency checks on invariants and taint breakers plus LLM verification. Verified predictions are folded back into the repository so the knowledge evolves. The paper reports an F1-score of 99.43% with 98.88% recall and perfect precision in its abstract, while its main result table reports 0.9921 F1, 0.9843 recall, and 1.0000 precision on 865 benchmark alerts, plus false-positive reductions of 80.0% and 94.6% on two industrial analyzers without retraining.

Load-bearing premise

One load-bearing premise is that the large-language-model explanations of why historical alerts are false positives faithfully capture the real security semantics; if they are wrong, the clustered memories, retrieved evidence, and verification checks are wrong together, and the paper's own limitations section notes that verification provides no formal soundness guarantee.

Editorial extensions

If this is right

  • A deployment can run Memoir as a post-processing layer over existing SAST engines, so alert noise falls (80.0% and 94.6% in the industrial study) without replacing the analyzer.
  • Because verified cases are folded back into memory, the system keeps improving as triage happens; there is no fixed hand-maintained rule set to rewrite when frameworks change.
  • Semantic memories carry explicit evidence—which invariant was violated or which taint breaker applies—so each false-positive decision comes with a human-auditable rationale, not just a probability.
  • Substituting different LLMs as the reasoning backbone leaves the memory-based mechanism intact and high-performing, meaning organizations are not locked into one model.
  • If the memory base is shared across projects and tools, one organization-level triage history can serve multiple analyzers, avoiding repeated rediscovery of the same rationale.

Reading between the lines

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

  • Editorial inference: the same learn-verify-evolve loop could be applied to true-positive alerts, turning confirmed vulnerabilities into reusable detection memories; the paper only stores false-positive patterns, but its memory architecture has no structural reason to exclude true-positive semantics.
  • Editorial inference: the verification stage implies a testable cross-language prediction—given equivalent sanitization semantics (a Java PreparedStatement versus a C# SqlParameter), memories should transfer without retraining; the paper does not test this.
  • Editorial inference: the weaker command-injection suppression (residual false-positive rate 28.89%, versus 0-3% for SQL injection and path traversal) suggests the memory base under-represents project-specific sanitization logic, so adding more command-injection examples to the relevant clusters is a cheap, testable improvement.
  • Editorial inference: a practical risk not quantified in the paper is how quickly the memory base decays when codebases drift without new labels; replaying old memories against upgraded frameworks would measure the evolution module's renewal value.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 Memoir, a memory-driven framework for false-positive (FP) reduction in static application security testing (SAST). It converts historical FP alerts into structured semantic memories (taxonomy, security invariants, taint breakers, retrieval keys, verification rules, representative examples) via LLM-guided annotation, clustering, and synthesis. For a new alert, it retrieves relevant memories, performs taxonomy/invariant/taint-breaker verification, and then makes an FP/TP prediction. Verified results are fed back to evolve the memory base. The evaluation on CWE-Bench-Java CodeQL alerts compares Memoir against zero-shot, IRIS, RAG, BugLens, and ZeroFalse, reporting near-perfect precision/recall/F1, with ablations and cross-backbone experiments; an industrial case study reports large FP reductions on CodeQL and XCheck without retraining.

Significance. If the empirical claims hold, Memoir would be a valuable step toward making SAST triage knowledge reusable and evolvable. The paper's strengths include a public benchmark evaluation, a broad baseline comparison, ablations that isolate clustering and verification, cross-backbone generalization, and a code/data release. The central results, however, are supported by a very small test set (roughly 130 alerts with only a handful of true positives), an unvalidated intermediate memory representation generated by the same LLM family used for decision-making, and inconsistent headline numbers between the abstract and Table I. The significance is therefore conditional on addressing these concerns.

major comments (4)
  1. [Abstract and Table I] The abstract reports F1 = 99.43% and Recall = 98.88% with perfect Precision, whereas Table I reports Precision = 1.0000, Recall = 0.9843, and F1-score = 0.9921 for the same GPT-4o configuration. These numbers are inconsistent. Please state which set is correct and reconcile the abstract and body, since the near-perfect F1 is the paper's headline claim.
  2. [Section III-C and Section IV-A] The test set is very small: 865 alerts with 95.66% FP split 7:1.5:1.5 yields about 130 test alerts, of which only roughly 5-6 are true positives. Perfect precision is therefore not strong evidence, because a single misclassified true positive would change the precision substantially. Please report the exact TP/FP counts per split and include confidence intervals or repeated-run variance for the headline metrics.
  3. [Sections II-C, II-D, and VII-C] The memories are produced by LLM-guided semantic annotation of why historical alerts are false positives, and the verification stage uses the same model family to check taxonomy consistency, invariants, and taint breakers. The evaluation never validates the fidelity of these intermediate memories against independent ground truth; only the end-to-end FP/TP agreement with benchmark labels is measured. Since a systematically wrong but self-consistent memory could suppress true positives, please provide an empirical check of memory semantics, such as expert evaluation of a sample or a robustness test where memories are generated by one LLM family and verified by another.
  4. [Section V] The industrial case study reports only aggregate FP reduction and precision improvement, with no information on the number of projects, the total alert volume, or the exact protocol by which the memory base was transferred across tools. The claim of 'without retraining' is a key generalization claim, so please specify whether the same memory repository from the public benchmark was used for both CodeQL and XCheck alerts, how the XCheck alerts were represented, and how many projects/alerts were involved.
minor comments (6)
  1. [Section III-F and Figure 2] The decision threshold θ appears in Figure 2 but is never defined in the text; please define it and report its tuned value or range, along with the other tuned parameters (retrieval depth, clustering similarity threshold, memory strength decay).
  2. [Section IV] All reported metrics appear to be from a single evaluation run; please state the number of runs and report variance or confidence intervals, especially given the small test set.
  3. [Tables III and IV] Please define the abbreviation 'FPR' as false-positive rate in the captions of Tables III and IV, and clarify the denominator used to compute the residual FPR.
  4. [Section II-C] The clustering step is described as using 'semantic similarity over invariants, taint breakers, and security-related features' but the underlying representation and similarity measure are not specified; please clarify the clustering algorithm and embedding used.
  5. [Figure 2] The label 'MUTI-STAGE FP VERIFICATION' contains a typo; it should read 'MULTI-STAGE FP VERIFICATION'.
  6. [Section III-D] The industrial dataset description gives no descriptive statistics; please add at least the number of projects and the distribution of alerts per tool, even if the full dataset cannot be released.

Circularity Check

0 steps flagged · score 0.0 of 10

No constructed circularity: the memory base is built only from the training split, evaluations are on a disjoint held-out test split, and no load-bearing self-citation or imported uniqueness theorem is used.

full rationale

Memoir's decision function is not fitted to the labels it predicts. The paper explicitly splits the 865 CWE-Bench-Java alerts into training, validation, and test sets, states that 'No validation or test samples are used during memory construction,' and states that 'During test-time evaluation, the evolved memory knowledge base generated from the training set remains fixed, and no information from the evaluation data is incorporated into the memory repository.' The final FP/TP prediction is produced by retrieval, taxonomy consistency, invariant and taint-breaker checks, and LLM reasoning over the alert plus retrieved memories, so the test label is neither a fitted parameter nor an input to the decision function. There is no load-bearing self-citation: baselines such as IRIS, BugLens, and ZeroFalse are external prior work, and the benchmark is also external. The concern that the same LLM family writes the semantic memories and later verifies them is a substantive empirical-validity limitation, explicitly acknowledged in Section VII-C ('it cannot provide formal soundness guarantees'), but it is not circular in the derivation-theoretic sense: a systematically wrong invariant could be self-consistent and suppress a true positive, yet that is an error in the learned representation rather than the prediction reducing to its own input. The discrepancy between the abstract's 99.43% F1 / 98.88% recall and Table I's 0.9921 / 0.9843 is an internal reporting inconsistency, not circularity. Therefore no constructed circular step is present.

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

The central evaluation does not derive a law or mechanism; it is an empirical assessment of a framework. The framework's success depends on the training-label correctness, the quality of LLM-generated semantic annotations, and the premise that recurring false-positive semantics exist and can be abstracted. These are stated as assumptions in the ledger. Hyperparameters (retrieval depth, decision threshold, decay factor, clustering similarity thresholds) are tuned using the validation set, not reported fully, and affect the reported performance.

free parameters (4)
  • retrieval depth k = 5 (Top-5, default)
    Default number of memories retrieved per alert, reported in Section III-F; ablation in Table II shows performance varies with k, so it is a tuned hyperparameter.
  • decision threshold theta
    Score threshold for FP vs TP decision (Section II-D); value not reported in the paper, tuned on validation set.
  • memory strength decay factor
    Used in memory evolution to weaken ineffective memories (Section II-E); exact value and mechanism not specified.
  • clustering similarity threshold
    Threshold for semantic clustering of annotated cases (Section II-C); not reported, tuned during construction.
assumptions (4)
  • ad hoc to paper Historical false-positive alerts share recurring semantic patterns that can be abstracted and reused across projects, tools, and CWE categories.
    Core premise of the memory-based approach, asserted in Section I (Listing 1) and Section II; if this fails, memory reuse does not transfer.
  • domain assumption The manually verified labels in CWE-Bench-Java are correct and complete.
    Used as ground truth for training and evaluation (Section III-C); no inter-annotator agreement or label audit is reported.
  • ad hoc to paper LLM-generated semantic annotations (taxonomy, security invariants, taint breakers) faithfully describe the actual reasons alerts are false positives.
    Memory construction depends on LLM annotation (Section II-C); errors would propagate through clustering and verification into decision-making.
  • domain assumption Alert representation with trace, CWE, rule, source, sink, and analysis captures sufficient information for FP identification.
    Problem formulation in Section II-A defines alerts as this tuple; the framework does not reason over full source code beyond this representation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Memoir: Learning, Verifying, and Evolving False-Positive Memories for Static Application Security Testing Tools." pith.science (2026). https://pith.science/paper/UKKEZQWK

@misc{pith2026260809181,
  author       = {Pith},
  title        = {Pith review of: Memoir: Learning, Verifying, and Evolving False-Positive Memories for Static Application Security Testing Tools},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UKKEZQWK}},
  note         = {Machine review of arXiv:2608.09181}
}
read the original abstract

Static Application Security Testing (SAST) tools have become indispensable in modern secure software devel- opment. However, these tools often generate false-positive (FP) alerts, imposing substantial manual inspection costs and reducing the trust from developers. Existing FP reduction methods still face two primary challenges. First, the large differences among SAST tools and vulnerability categories make it difficult for these methods to learn recurring patterns in historical false positives. Moreover, the knowledge used by these methods are largely static and cannot be updated as newly validated cases accumulate. To address these challenges, we propose Memoir, a memory- driven framework for identifying false positives by transform- ing historical FP alerts into reusable semantic memories. It consists of two key modules. First, historical semantic memory construction converts historical FP alerts into structured semantic memories through LLM-guided annotation, pattern clustering, and memory synthesis to capture reusable behavioral patterns. Moreover, memory-driven identification and evolution retrieves relevant memories and performs semantic verification against taxonomy consistency and security invariants before making the final prediction. It then incorporates verified predictions back into the memory repository, allowing the knowledge base to evolve as new cases accumulate. We evaluate Memoir on CWE- Bench-Java to demonstrate its effectiveness in real-world security analysis. Specifically, Memoir achieves an F1-score of 99.43% with a Recall of 98.88% and perfect Precision, consistently outperforming other baselines. Furthermore, an industrial case study on production software systems from a top IT company shows that the learned memory base generalizes effectively across different SAST tools without retraining.

Figures

Figures reproduced from arXiv: 2608.09181 by the authors.

Figure 1
Figure 1. Overall architecture of Memoir. HIERARCHICAL MEMORY RETRIEVAL ... Same taxonomy exp exp exp Same CWE Similar semantic tags ... Invariant match Taint breaker match Retrieval key match Rank Top-k Memories M1 M2 M3 Mk ... Retrieval candidate memories MUTI-STAGE FP VERIFICATION Taxonomy Consisyency Check Verification Score Aggregation Verification Score Recalculate Strength DECISION and MEMORY EVOLUTION UPDATE 0~1 Score… view at source ↗
Figure 2
Figure 2. Memory retrieval and verification workflow. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Impact of retrieval depth on Memoir performance. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Heatmap of Memoir performance across different back [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 39 canonical work pages

  1. [1]

    QL: Object- oriented queries on relational data,

    P. Avgustinov, O. de Moor, M. P. Jones, and M. Sheridan, “QL: Object- oriented queries on relational data,” in30th European Conference on Object-Oriented Programming (ECOOP). Schloss Dagstuhl–Leibniz- Zentrum fuer Informatik, 2016, pp. 2:1–2:25

    work page 2016

  2. [2]

    Checkmarx SAST,

    Checkmarx Ltd., “Checkmarx SAST,” https://checkmarx.com/, 2024, accessed: 2025

    work page 2024

  3. [3]

    Fortify Static Code Analyzer,

    OpenText, “Fortify Static Code Analyzer,” https://www.opentext.com/p roducts/fortify-static-code-analyzer, 2024, accessed: 2025

    work page 2024

  4. [4]

    Why don’t software developers use static analysis tools to find bugs?

    B. Johnson, Y . Song, E. Murphy-Hill, and R. Bowdidge, “Why don’t software developers use static analysis tools to find bugs?” inPro- ceedings of the 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 672–681

    work page 2013

  5. [5]

    What developers want and need from program analysis: An empirical study,

    M. Christakis and C. Bird, “What developers want and need from program analysis: An empirical study,” inProceedings of the 31st IEEE/ACM International Conference on Automated Software Engineer- ing (ASE). ACM, 2016, pp. 332–343

    work page 2016

  6. [6]

    CWE-Bench-Java: A benchmark for java vulnerability detec- tion,

    iris-sast, “CWE-Bench-Java: A benchmark for java vulnerability detec- tion,” https://github.com/iris-sast/cwe-bench-java, 2024, accessed: 2025

    work page 2024

  7. [7]

    A few billion lines of code later: Using static analysis to find bugs in the real world,

    A. Bessey, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, C. Henri- Gros, A. Kamsky, S. McPeak, and D. Engler, “A few billion lines of code later: Using static analysis to find bugs in the real world,” Communications of the ACM, vol. 53, no. 2, pp. 66–75, 2010

    work page 2010

  8. [8]

    A systematic literature review of action- able alert identification techniques for automated static code analysis,

    S. Heckman and L. Williams, “A systematic literature review of action- able alert identification techniques for automated static code analysis,” Information and Software Technology, vol. 53, no. 4, pp. 363–387, 2011

    work page 2011

Show all 44 references
  1. [9]

    Survey of approaches for handling static analysis alarms,

    T. Muske and A. Serebrenik, “Survey of approaches for handling static analysis alarms,” inProceedings of the 16th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2016, pp. 157–166

    2016

  2. [10]

    Z-Ranking: Using statistical analysis to counter the impact of static analysis approximations,

    T. Kremenek and D. Engler, “Z-Ranking: Using statistical analysis to counter the impact of static analysis approximations,” inProceedings of the 10th International Conference on Static Analysis (SAS). Springer, 2003, pp. 295–315

    2003

  3. [11]

    Tricorder: Building a program analysis ecosystem,

    C. Sadowski, J. van Gogh, C. Jaspan, E. S ¨oderberg, and C. Winter, “Tricorder: Building a program analysis ecosystem,” inProceedings of the 37th International Conference on Software Engineering (ICSE). IEEE, 2015, pp. 598–608

    2015

  4. [12]

    IRIS: LLM-assisted static analysis for detecting security vulnerabilities,

    Z. Li, S. Dutta, and M. Naik, “IRIS: LLM-assisted static analysis for detecting security vulnerabilities,” inInternational Conference on Learning Representations, 2025. [Online]. Available: https: //openreview.net/forum?id=9LdJDU7E91

    2025

  5. [13]

    Towards more accurate static analysis for taint-style bug detection in linux kernel,

    H. Li, H. Zhang, K. Pei, and Z. Qian, “Towards more accurate static analysis for taint-style bug detection in linux kernel,” in Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering, 2025, pp. 380–392. [Online]. Available: https://www.cs.u...

    2025

  6. [14]

    ZeroFalse: Improving precision in static analysis with LLMs,

    M. Iranmanesh, S. Moradi Sabet, S. Marefat, A. Javidi Ghasr, A. Wilson, I. Sharafaldin, and M. A. Tayebi, “ZeroFalse: Improving precision in static analysis with LLMs,” 2025. [Online]. Available: https://arxiv.org/abs/2510.02534

    2025

  7. [15]

    GPT-4o system card,

    OpenAI, “GPT-4o system card,”arXiv preprint arXiv:2410.21276, 2024

    2024 arXiv

  8. [16]

    Introducing claude 3.5 sonnet,

    Anthropic, “Introducing claude 3.5 sonnet,” https://www.anthropic.com/ news/claude-3-5-sonnet, 2024, accessed: 2026-06-27

    2024

  9. [17]

    Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context,

    Gemini Team, Google, “Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context,” 2024. [Online]. Available: https://arxiv.org/abs/2403.05530

    2024 arXiv

  10. [18]

    DeepSeek-Coder-V2: Breaking the barrier of closed- source models in code intelligence,

    DeepSeek-AI, “DeepSeek-Coder-V2: Breaking the barrier of closed- source models in code intelligence,” 2024. [Online]. Available: https://arxiv.org/abs/2406.11931

    2024 arXiv

  11. [19]

    Flawfinder: A static analysis tool for finding security vulnerabilities in C/C++ source code,

    D. A. Wheeler, “Flawfinder: A static analysis tool for finding security vulnerabilities in C/C++ source code,” https://dwheeler.com/flawfinder/, 2021, accessed: 2025

    2021

  12. [20]

    RATS: Rough auditing tool for security,

    Fortify Software, “RATS: Rough auditing tool for security,” https://gi thub.com/andrew-d/rough-auditing-tool-for-security, 2013, accessed: 2025

    2013

  13. [21]

    Finding bugs is easy,

    D. Hovemeyer and W. Pugh, “Finding bugs is easy,” inCompanion to the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). ACM, 2004, pp. 132–136

    2004

  14. [22]

    Using static analysis to find bugs,

    N. Ayewah, W. Pugh, D. Hovemeyer, J. D. Morgenthaler, and J. Penix, “Using static analysis to find bugs,”IEEE Software, vol. 25, no. 5, pp. 22–29, 2008

    2008

  15. [23]

    Semgrep: Lightweight static analysis for many lan- guages,

    Semgrep, Inc., “Semgrep: Lightweight static analysis for many lan- guages,” https://semgrep.dev/, 2024, accessed: 2025

    2024

  16. [24]

    How many of all bugs do we find? a study of static bug detectors,

    A. Habib and M. Pradel, “How many of all bugs do we find? a study of static bug detectors,” inProceedings of the 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE). ACM, 2018, pp. 317–328

    2018

  17. [25]

    An empirical study on the effectiveness of static C code analyzers for vulnerability detection,

    S. Lipp, S. B ˘anescu, and A. Pretschner, “An empirical study on the effectiveness of static C code analyzers for vulnerability detection,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, 2022, pp. 215–227

    2022

  18. [26]

    Comparing bug finding tools with reviews and tests,

    S. Wagner, J. Jurjens, C. Koller, and P. Trischberger, “Comparing bug finding tools with reviews and tests,” inProceedings of the 17th IFIP TC6/WG 6.1 International Conference on Testing of Communicating Systems (TestCom). Springer, 2005, pp. 40–55

    2005

  19. [27]

    Comparison and evaluation on static application security testing (SAST) tools for Java,

    K. Li, S. Chen, L. Fan, R. Feng, H. Liu, C. Liu, Y . Liu, and Y . Chen, “Comparison and evaluation on static application security testing (SAST) tools for Java,” inProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of So...

    2023

  20. [28]

    Finding patterns in static analysis alerts: Improving actionable alert ranking,

    Q. Hanam, L. Tan, R. Holmes, and P. Lam, “Finding patterns in static analysis alerts: Improving actionable alert ranking,” inProceedings of the 11th Working Conference on Mining Software Repositories (MSR). ACM, 2014, pp. 152–161

    2014

  21. [29]

    ALETHEIA: Improving the usability of static security analysis,

    O. Tripp, S. Guarnieri, M. Pistoia, and A. Aravkin, “ALETHEIA: Improving the usability of static security analysis,” inProceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2014, pp. 762–774

    2014

  22. [30]

    Predicting accurate and actionable static analysis warnings: An experimental approach,

    J. R. Ruthruff, J. Penix, J. D. Morgenthaler, S. Elbaum, and G. Rother- mel, “Predicting accurate and actionable static analysis warnings: An experimental approach,” inProceedings of the 30th International Con- ference on Software Engineering (ICSE). ACM, 2008, pp. 341–350

    2008

  23. [31]

    Automated classification of static code analysis alerts: A case study,

    U. Y ¨uksel and H. S¨ozer, “Automated classification of static code analysis alerts: A case study,” inProceedings of the 13th IEEE International Conference on Software Maintenance (ICSM). IEEE, 2013, pp. 532– 535

    2013

  24. [32]

    Learning a classifier for false positive error reports emitted by static code analysis tools,

    U. Koc, P. Saadatpanah, J. S. Foster, and A. A. Porter, “Learning a classifier for false positive error reports emitted by static code analysis tools,” inProceedings of the 1st ACM SIGPLAN International Workshop on Machine Learning and Programming Languages (MAPL). ACM, 2017, ...

    2017

  25. [33]

    Is there a “golden

    S. Wang, T. Liu, J. Nam, and L. Tan, “Is there a “golden” feature set for static warning identification? an experimental evaluation,” inPro- ceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). ACM, 2018

    2018

  26. [34]

    DeepFWI: Identifying bug-sensitive warnings with multi-modal code-warning semantics,

    H. Liu, J. Zhang, C. Zhang, X. Zhang, K. Li, S. Chen, S.-W. Lin, Y . Chen, X. Li, and Y . Liu, “DeepFWI: Identifying bug-sensitive warnings with multi-modal code-warning semantics,”IEEE Transactions on Software Engineering, pp. 1–17, 2026

    2026

  27. [35]

    A user-guided approach to program analysis,

    R. Mangal, X. Zhang, A. V . Nori, and M. Naik, “A user-guided approach to program analysis,” inProceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (FSE). ACM, 2015, pp. 462–473

    2015

  28. [36]

    User-guided program reasoning using Bayesian inference,

    M. Raghothaman, S. Kulkarni, K. Heo, and M. Naik, “User-guided program reasoning using Bayesian inference,” inProceedings of the 39th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). ACM, 2018, pp. 722–735

    2018

  29. [37]

    CodeBERT: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang, and M. Zhou, “CodeBERT: A pre-trained model for programming and natural languages,” inFindings of the Association for Computational Linguistics: EMNLP 2020, 2020, pp. 1536–1547

    2020

  30. [38]

    Devign: Effective vulner- ability identification by learning comprehensive program semantics via graph neural networks,

    Y . Zhou, S. Liu, J. Siow, X. Du, and Y . Liu, “Devign: Effective vulner- ability identification by learning comprehensive program semantics via graph neural networks,” inAdvances in Neural Information Processing Systems (NeurIPS), vol. 32, 2019

    2019

  31. [39]

    LineVul: A transformer-based line- level vulnerability prediction,

    M. Fu and C. Tantithamthavorn, “LineVul: A transformer-based line- level vulnerability prediction,” inProceedings of the 19th International Conference on Mining Software Repositories (MSR). ACM, 2022, pp. 608–620

    2022

  32. [40]

    VulDeePecker: A deep learning-based system for vulnerability detec- tion,

    Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y . Zhong, “VulDeePecker: A deep learning-based system for vulnerability detec- tion,” inProceedings of the 25th Annual Network and Distributed System Security Symposium (NDSS), 2018

    2018

  33. [41]

    DiverseVul: A new vulnerable source code dataset for deep learning based vulnerability detection,

    Y . Chen, Y . Ding, Z. Bhatt, D. Wagner, and B. Ray, “DiverseVul: A new vulnerable source code dataset for deep learning based vulnerability detection,” inProceedings of the 26th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2023, pp. 654– 668

    2023

  34. [42]

    Transformer-based language models for software vulnerability detec- tion,

    C. Thapa, S. I. Jang, M. E. Ahmed, S. Camtepe, J. Piber, and S. Nepal, “Transformer-based language models for software vulnerability detec- tion,” inProceedings of the 38th Annual Computer Security Applications Conference (ACSAC). ACM, 2022, pp. 481–496

    2022

  35. [43]

    Examining zero-shot vulnerability repair with large language models,

    H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Examining zero-shot vulnerability repair with large language models,” inProceed- ings of the 2023 IEEE Symposium on Security and Privacy (S&P). IEEE, 2023, pp. 2339–2356

    2023

  36. [44]

    To err is machine: Vulnerability detection challenges LLM reasoning,

    B. Steenhoek, M. M. Rahman, M. K. Roy, M. S. Alam, H. Tong, S. Das, E. T. Barr, and W. Le, “To err is machine: Vulnerability detection challenges LLM reasoning,”arXiv preprint arXiv:2403.17218, 2024

    2024 arXiv

Pith tools

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