Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Repository-Level Graph Representation Learning for Enhanced Security Patch Detection

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 Adding repository-level call dependencies to a code property graph sharply improves automatic security patch detection.

desk verdict A genuinely useful repository-level patch representation, but the project-overlapping train/test split undercuts the cross-project generalization claim. read the letter →

arxiv 2412.08068 v1 pith:4XWYERPO submitted 2024-12-11 cs.SE cs.AIcs.CR

Xin-Cheng Wen , Zirui Lin , Cuiyun Gao , Hongyu Zhang , Yong Wang , Qing Liao This is my paper · ORCID
classification cs.SEcs.AIcs.CR
keywords securitypatchdetectionrepository-levelcodepropertygraphneuralnetworkGATUniXcoderprogressivelearningC/C++vulnerabilitydatasets
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 claims that security patch detection improves when the model sees the repository-level call dependencies surrounding a patch, not just the diff. It introduces RepoSPD, which builds a repository-level code property graph (RepoCPG) by merging pre-patch and post-patch source code and attaching the functions the changed code calls or that call it, then learns a fused graph-and-sequence representation and balances the two branches with progressive learning. On two datasets extended to repository level, SPI-DB* and PatchDB*, the method reports accuracy of 74.55% and 83.35%, respectively, improving on the best previous baseline by 11.90% and 3.10% relative accuracy. If this result holds, tools could flag silently released security fixes far more reliably, closing a gap that leaves many systems patched late.

What carries the argument

The load-bearing object is RepoCPG, a repository-level code property graph: a graph that fuses abstract syntax trees, control flow, and data dependence for both the pre-patch and post-patch versions of the repository, then adds call-graph edges to functions outside the patch and slices the graph to the statements that depend on the changed lines. It carries the argument because it supplies the context that diff-level methods lack. Around it, the structure-aware patch representation combines a graph branch (four parallel GAT layers, one per edge-role bit, plus a final GAT over the whole graph) with a sequence branch (fine-tuned UniXcoder over the code changes), and progressive learning alternately freezes each branch's weights so the model first learns sequential semantics and then graph structure.

What would settle it

Re-run the evaluation with a project-disjoint split, keeping all patches from the same repository in a single split, and check whether the accuracy gap to the best baseline remains; a large drop would show that the reported gains come substantially from repository memorization.

Watch

Extended reading notes

Core claim

The central claim is that repository-level context is the missing ingredient in security patch detection. Existing methods read only the diff or the file being changed, so they cannot see, for example, that a deleted call to get_futex_key_refs is part of a use-after-free fix. RepoSPD constructs RepoCPG, a code property graph in which pre-patch and post-patch versions are merged and repository-level call dependencies are attached to changed statements; a GAT over four edge-role subgraphs captures structure while a fine-tuned UniXcoder captures sequence semantics, and progressive learning shifts the model's focus from the sequence branch to the graph branch. The paper reports that this combination outperforms six security patch detection baselines and five static analysis tools, with the largest gains coming from the repository-level graph.

Load-bearing premise

The train, validation, and test sets are split per patch, not per project, so patches from the same repository can appear on both sides of the split; if the model learns repository-specific habits rather than general patch patterns, the reported accuracy gains could shrink under a project-disjoint split.

Editorial extensions

If this is right

  • Security patch detectors that ignore repository context will underperform on patches whose fixing logic lives in called functions outside the diff.
  • Fusing graph and sequence representations reduces false positives compared to either branch alone, since structural information filters out semantically similar but unrelated changes.
  • Progressive learning, starting from the sequence branch and then tuning the graph branch, outperforms joint training and the reversed order.
  • Static-analysis tools catch only a small fraction of security patches; RepoSPD detects 151 security patches in the paper's 192-patch comparison, 21.36% more than the best static tool.
  • The graph branch is computationally cheaper than the sequence branch, so the full model trains in about one-third of the time per epoch that CodeT5 requires.

Reading between the lines

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

  • If the train/test split were made project-disjoint rather than patch-disjoint, the reported accuracy gaps might shrink; this is the main untested threat to the paper's claims.
  • The slicing and graph-augmentation recipe could transfer to other commit-classification tasks, such as detecting bug-fixing or refactoring commits, by swapping the call-graph extractor.
  • A natural extension is cross-repository generalisation: training on SPI-DB* and testing on PatchDB* would show whether the model learns repository-agnostic patch patterns or dataset-specific cues.
  • The reported time savings suggest that graph-based structural learning is computationally competitive for real-world patch triage.
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 RepoSPD, a framework for security patch detection that builds a repository-level code property graph (RepoCPG) from pre- and post-patch repository versions, combines a GAT-based graph branch with a UniXcoder-based sequence branch, and uses progressive learning to alternate training between branches. The authors extend the SPI-DB and PatchDB datasets with repository-level versions (SPI-DB* and PatchDB*), evaluate against six security-patch-detection baselines and five static analysis tools, and report consistent improvements on both datasets. They also provide ablations showing that removing RepoCPG, either branch, or progressive learning degrades performance.

Significance. If the reported gains are robust, the paper makes a useful contribution: it is, to my knowledge, the first to bring repository-level dependency context into security patch detection, and the released datasets and source code are valuable assets for the community. The ablation study is well designed and supports the internal logic of the framework: each component contributes to accuracy, F1, and FPR. However, the evaluation has load-bearing weaknesses in experimental design and result reporting that currently prevent the central claim from being accepted as stated.

major comments (4)
  1. [IV.B.3 / Table I] The data split is performed at the patch level, not at the project/repository level. Section IV.B.1 states that SPI-DB* is drawn entirely from FFMPeg and Qemu, so every test patch in SPI-DB* comes from a repository already present in training. For PatchDB*, which spans 348 repositories in Section IV.B.1, a random 8:1:1 split is highly likely to place the same repositories in both training and test. Since RepoCPG is built from the full pre- and post-patch repository versions (Algorithm 1 and Section III-A), the model can memorize repository-specific identifiers, call graphs, coding style, and near-duplicate graph fragments. The reported improvements of 7.93 and 2.51 percentage points in accuracy over CodeT5 (Table II) therefore do not establish that repository-level information generalizes to unseen projects; they may largely reflect within-repository memorization. A project-disjoint split (or at least a per-project-grouped split) is needed to support the central claim.
  2. [V.B / Table III] The RQ2 evaluation is not a valid accuracy comparison. The dataset for RQ2 contains only 192 security patches (Section V.B states that non-security patches are excluded), yet Table III reports 'Accuracy' and the text concludes that RepoSPD 'achieves a 21.36% improvement in terms of accuracy.' With no negative samples, the reported 78.65% is at best a detection rate on positive examples, not classification accuracy, and false positive rate cannot be computed. The comparison to static tools, which output vulnerability alerts rather than patch labels, is further confounded by the positive-only subset. This does not undermine RQ1, but the RQ2 claim should be rephrased as detection coverage on positives, or the experiment should be redone on a balanced sample.
  3. [Abstract / V.A / Table II] The headline numbers are inconsistent with Table II. The abstract states improvements of '11.90%, and 3.10% in terms of accuracy,' while Table II shows RepoSPD accuracy 74.55 vs. 66.62 (CodeT5) = 7.93 points on SPI-DB* and 83.35 vs. 80.84 (CodeT5) = 2.51 points on PatchDB*. The introduction instead describes improvements 'in terms of accuracy and F1 score,' and Section V.A reports '7.50% of accuracy and 8.70% of F1 score on average.' The 3.10% figure does not match any F1 or accuracy gap in Table II. The abstract and introduction must be corrected to report the same numbers as the results tables, and the metric (absolute percentage points vs. relative improvement) should be stated explicitly.
  4. [V / Tables II and V] All results are reported for a single training run without error bars or multiple seeds. Given that the F1 gaps in Table VI are as small as 0.8 percentage points (SPI-DB* recall: 62.59 vs. 61.79), statistical significance is only reported for accuracy versus CodeT5 (Section V.A.3), not for the ablations in Table V. A few random seeds with mean and standard deviation would be needed to confirm that the observed component-wise gains are not noise.
minor comments (6)
  1. [Section I / Section IV.C] Section I says 'five existing security patch detection baselines' but Section IV.C lists six approaches including Llama3-70b; the count should be updated.
  2. [Section II.A] The text refers to 'PatchGPG' as the GraphSPD contribution; this appears to be a typo for 'PatchCPG'.
  3. [Section III.C / Eq. (6)] The sentence after Eq. (6) defines both predicted outputs as p̂_g; the second should be p̂_s = W_s^⊤ f_s.
  4. [Table III] The header 'Accuarcy' and the phrase 'accurately identifying identify security patches' in Section V.B contain typos that should be fixed.
  5. [Table II] The dataset label 'SPIDB*' in the leftmost column should be 'SPI-DB*' to match the rest of the paper.
  6. [IV.E] Hyper-parameter reporting is incomplete: the paper gives learning rates, GAT heads, epochs, and batch size, but not hidden dimensions, number of GAT layers, pooling method, or the progressive-learning switch epoch Emax, which is a free parameter in Eq. (6).

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: RepoSPD's reported gains are empirical measurements against external baselines and ablations; self-citations are peripheral, not load-bearing.

full rationale

RepoSPD's central claim is an empirical benchmark result: the method is trained on labeled security patches from SPI-DB*/PatchDB* and evaluated against six external baselines and five static tools, with ablations (Table V) isolating RepoCPG, sequence/graph branches, and progressive learning. No analytic derivation equates the claimed prediction with an input by construction: the label y is external, the graph is built from source code via Joern/Tree-sitter/Cflow, and performance is measured on a held-out test set. Self-citations (e.g., [40] VulEval for repository-level Cflow extraction, [34] AMPLE in background, [57] for Tree-sitter) are peripheral tool/context references, not load-bearing theorems or fitted parameters; the tools cited are external and independently checkable. The project-overlap concern (patch-level split with FFMPeg/Qemu in both train and test for SPI-DB*) is a data-leakage / generalization threat to the empirical claim, not an instance of circular reasoning; no equation or definition reduces the reported accuracy gain to the method's own inputs.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on dataset quality, dependency extraction coverage, and split independence; these are domain assumptions rather than derived facts. No new physical entities are introduced. The listed hyperparameters are chosen by hand and affect the reported results but are standard for this type of model.

free parameters (6)
  • training epochs = 10
    Chosen by authors in Section IV.E; affects convergence but is a standard model hyperparameter.
  • batch size = 4
    Reported in Section IV.E; standard model hyperparameter chosen by the authors.
  • graph branch learning rate = 5e-5
    Reported in Section IV.E; chosen by experiments.
  • sequence branch learning rate = 2e-5
    Reported in Section IV.E; chosen by experiments.
  • GAT heads = 2
    Reported in Section IV.E; chosen by experiments.
  • progressive learning switch epoch = 5 (E_max/2, where E_max=10)
    Implied by Equation 6 and the 10-epoch training schedule; controls when training shifts from sequence to graph branch.
assumptions (5)
  • domain assumption Labels in SPI-DB and PatchDB are correct and complete for security patch detection.
    Training and test labels come from these external datasets; any label noise transfers to the reported accuracy.
  • domain assumption Tree-sitter and Cflow extract sufficient repository-level function dependencies.
    The paper acknowledges in Section VI.D that multi-level function calls and some repository contexts are not covered, so RepoCPG may miss dependencies relevant to some patches.
  • domain assumption A patch-level train/test split does not create project-level leakage.
    Section IV.B.3 describes an 8:1:1 patch split but does not enforce disjoint projects or repositories; SPI-DB* is sourced mainly from FFMPeg and Qemu, so the same project can appear in both train and test.
  • domain assumption UniXcoder node embeddings represent code semantics well enough for the graph branch.
    Node initialization in Equation 1 uses first and last layers of UniXcoder; the method inherits the model's representational limits.
  • domain assumption The graph and sequence classifiers can be combined linearly as in Equation 5.
    The final prediction is an unweighted average of the two branch logits; this assumes equal contribution is near optimal.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Repository-Level Graph Representation Learning for Enhanced Security Patch Detection." pith.science (2026). https://pith.science/paper/4XWYERPO

@misc{pith2026241208068,
  author       = {Pith},
  title        = {Pith review of: Repository-Level Graph Representation Learning for Enhanced Security Patch Detection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4XWYERPO}},
  note         = {Machine review of arXiv:2412.08068}
}
read the original abstract

Software vendors often silently release security patches without providing sufficient advisories (e.g., Common Vulnerabilities and Exposures) or delayed updates via resources (e.g., National Vulnerability Database). Therefore, it has become crucial to detect these security patches to ensure secure software maintenance. However, existing methods face the following challenges: (1) They primarily focus on the information within the patches themselves, overlooking the complex dependencies in the repository. (2) Security patches typically involve multiple functions and files, increasing the difficulty in well learning the representations. To alleviate the above challenges, this paper proposes a Repository-level Security Patch Detection framework named RepoSPD, which comprises three key components: 1) a repository-level graph construction, RepoCPG, which represents software patches by merging pre-patch and post-patch source code at the repository level; 2) a structure-aware patch representation, which fuses the graph and sequence branch and aims at comprehending the relationship among multiple code changes; 3) progressive learning, which facilitates the model in balancing semantic and structural information. To evaluate RepoSPD, we employ two widely-used datasets in security patch detection: SPI-DB and PatchDB. We further extend these datasets to the repository level, incorporating a total of 20,238 and 28,781 versions of repository in C/C++ programming languages, respectively, denoted as SPI-DB* and PatchDB*. We compare RepoSPD with six existing security patch detection methods and five static tools. Our experimental results demonstrate that RepoSPD outperforms the state-of-the-art baseline, with improvements of 11.90%, and 3.10% in terms of accuracy on the two datasets, respectively.

Figures

Figures reproduced from arXiv: 2412.08068 by the authors.

Figure 1
Figure 1. The part of security patch that fixes a buffer overflow vulnerability (i.e., CWE-119 [24]). The red and green lines [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The overview of RepoSPD. Pre-Patch Node/Edge b.hb=hash_futex(&q->key) f.hash_futex(&q->key) g.hb a.queue_lock(struct futex_q *q) c.get_futex_key_refs(&q->key); m.if*(!key->borh.ptr j.return hb a.queue_lock(struct futex_q *q) i.get_futex_key_refs(union futex_key *key); d.hb=hash_futex(&q->key) k.q->lock_ptr = &hb->lock; Post-Patch Node/Edge Common Node/Edge Repository Node/Edge (A) MergeCPG (B) RepoCPG e.q->lock_ptr … view at source ↗
Figure 3
Figure 3. An example of MergeCPG and RepoCPG construction [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: (A) and (C) represent the security patch for resource leakage vulnerability (CVE-2016-5243 [59]) and buffer overflow [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Empirical Study of Code Large Language Models for Binary Security Patch Detection

    cs.SE 2025-09 conditional novelty 6.0 of 10

    Fine-tuned code LLMs detect binary security patches accurately on decompiler pseudo-code, and adding source-code patches to the training data improves accuracy and F1 further.

Reference graph

Works this paper leans on

79 extracted references · 70 canonical work pages · cited by 1 Pith paper

  1. [1]

    Number of common it security vulnerabilities and exposures (cves) worldwide from 2009 to 2024 ytd,

    Statista, “Number of common it security vulnerabilities and exposures (cves) worldwide from 2009 to 2024 ytd,”

    work page 2009

  2. [2]

    LIV ABLE: exploring long-tailed classification of software vulnerability types,

    X. Wen, C. Gao, F. Luo, H. Wang, G. Li, and Q. Liao, “LIV ABLE: exploring long-tailed classification of software vulnerability types,” IEEE Trans. Software Eng. , vol. 50, no. 6, pp. 1325–1339, 2024

    work page 2024

  3. [3]

    An empirical analysis of the impact of software vulnerability announcements on firm stock price,

    R. Telang and S. Wattal, “An empirical analysis of the impact of software vulnerability announcements on firm stock price,” IEEE Transactions on Software Engineering, vol. 33, no. 8, pp. 544–557, 2007

    work page 2007

  4. [4]

    When less is enough: Positive and unlabeled learning model for vulnerability detection,

    X. Wen, X. Wang, C. Gao, S. Wang, Y . Liu, and Z. Gu, “When less is enough: Positive and unlabeled learning model for vulnerability detection,” in 38th IEEE/ACM International Conference on Automated Software Engineering, ASE 2023, Luxembourg, September 11-15, 2023 . IEEE, 2023, pp. 345–357

    work page 2023

  5. [5]

    Synopsys. (2024). [Online]. Available: https://www.synopsys.com/ 11

    work page 2024

  6. [6]

    (2024) 2024 open source security and risk analysis report

    Synopsys. (2024) 2024 open source security and risk analysis report. [Online]. Available: https://www.synopsys.com/content/dam/synopsys/ sig-assets/reports/rep-ossra-2024.pdf

    work page 2024

  7. [7]

    Detecting

    X. Wang, K. Sun, A. L. Batcheller, and S. Jajodia, “Detecting ”0- day” vulnerability: An empirical study of secret security patch in OSS,” in 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2019, Portland, OR, USA, June 24-27,

    work page 2019

  8. [8]

    Subjectivity reduction of qualitative approach in information security risk analysis,

    A. TamjidYamcholo and A. Toloie Eshlaghy, “Subjectivity reduction of qualitative approach in information security risk analysis,” Journal of System Management, vol. 8, no. 1, pp. 145–166, 2022

    work page 2022

Show all 79 references
  1. [9]

    A large-scale empirical study of security patches,

    F. Li and V . Paxson, “A large-scale empirical study of security patches,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017, B. Thuraisingham, D. Evans, T. Malkin, and D. Xu, Eds...

    2017

  2. [10]

    Can automated pull requests encourage software developers to upgrade out-of-date dependencies?

    S. Mirhosseini and C. Parnin, “Can automated pull requests encourage software developers to upgrade out-of-date dependencies?” in Proceed- ings of the 32nd IEEE/ACM International Conference on Automated Software Engineering, ASE 2017, Urbana, IL, USA, October 30 - November 03,...

    2017

  3. [11]

    When would this bug get reported?

    F. Thung, D. Lo, L. Jiang, Lucia, F. Rahman, and P. T. Devanbu, “When would this bug get reported?” in 28th IEEE International Conference on Software Maintenance, ICSM 2012, Trento, Italy, September 23-28,

    2012

  4. [12]

    (2024) Cve-2024-24919 detail

    CVE-2024-24919. (2024) Cve-2024-24919 detail. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2024-24919

    2024

  5. [13]

    T. stack. (2024) Check point vulnerability far worse than thought – exploited in wild since april. [Online]. Available: https://www.thestack. technology/check-point-vulnerability-cve-2024-24919/

    2024

  6. [14]

    How about bug-triggering paths?-understanding and characterizing learning-based vulnerability detectors

    X. Cheng, X. Nie, N. Li, H. W. Z. Zheng, and Y . Sui, “How about bug-triggering paths?-understanding and characterizing learning-based vulnerability detectors.” IEEE, 2022

    2022

  7. [15]

    Multi-task framework of precipitation nowcasting,

    Z. Zhang, C. Luo, B. Zhang, H. Jiang, and B. Zhang, “Multi-task framework of precipitation nowcasting,” CAAI Trans. Intell. Technol. , vol. 8, no. 4, pp. 1350–1363, 2023

    2023

  8. [16]

    A survey on fed- erated learning: a perspective from multi-party computation,

    F. Liu, Z. Zheng, Y . Shi, Y . Tong, and Y . Zhang, “A survey on fed- erated learning: a perspective from multi-party computation,” Frontiers Comput. Sci., vol. 18, no. 3, p. 181336, 2024

    2024

  9. [17]

    Patchrnn: A deep learning-based system for security patch identification,

    X. Wang, S. Wang, P. Feng, K. Sun, S. Jajodia, S. Benchaaboun, and F. Geck, “Patchrnn: A deep learning-based system for security patch identification,” in 2021 IEEE Military Communications Conference, MILCOM 2021, San Diego, CA, USA, November 29 - Dec. 2, 2021 . IEEE, 2021, pp...

    2021

  10. [18]

    Finding structure in time,

    J. L. Elman, “Finding structure in time,” Cogn. Sci., vol. 14, no. 2, pp. 179–211, 1990

    1990

  11. [19]

    Control flow graph embedding based on multi-instance decomposition for bug localization,

    X. Huo, M. Li, and Z. Zhou, “Control flow graph embedding based on multi-instance decomposition for bug localization,” in The Thirty-Fourth AAAI Conference on Artificial Intelligence, AAAI 2020, The Thirty- Second Innovative Applications of Artificial Intelligence Conference, ...

    2020

  12. [20]

    Programl: A graph-based program representation for data flow analysis and compiler optimizations,

    C. Cummins, Z. V . Fisches, T. Ben-Nun, T. Hoefler, M. F. P. O’Boyle, and H. Leather, “Programl: A graph-based program representation for data flow analysis and compiler optimizations,” in Proceedings of the 38th International Conference on Machine Learning, ICML 2021, 18- 24 ...

    2021

  13. [21]

    Gated graph sequence neural networks,

    Y . Li, D. Tarlow, M. Brockschmidt, and R. S. Zemel, “Gated graph sequence neural networks,” in 4th International Conference on Learning Representations, ICLR 2016 , 2016

    2016

  14. [22]

    Graphspd: Graph-based security patch detection with enriched code semantics,

    S. Wang, X. Wang, K. Sun, S. Jajodia, H. Wang, and Q. Li, “Graphspd: Graph-based security patch detection with enriched code semantics,” in 44th IEEE Symposium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 21-25, 2023 . IEEE, 2023, pp. 2409–2426

    2023

  15. [23]

    Semi-supervised classification with graph convolutional networks,

    T. N. Kipf and M. Welling, “Semi-supervised classification with graph convolutional networks,” in 5th International Conference on Learning Representations, ICLR 2017, Toulon, France, April 24-26, 2017, Con- ference Track Proceedings. OpenReview.net, 2017

    2017

  16. [24]

    Cwe-119: Improper restriction of operations within the bounds of a memory buffer

    “Cwe-119: Improper restriction of operations within the bounds of a memory buffer.” [Online]. Available: https://cwe.mitre.org/data/ definitions/119.html

  17. [25]

    (2014) Cve-2014-0205 detail

    CVE-2014-0205. (2014) Cve-2014-0205 detail. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2014-0205

    2014

  18. [26]

    SPI: automated identification of security patches via commits,

    Y . Zhou, J. K. Siow, C. Wang, S. Liu, and Y . Liu, “SPI: automated identification of security patches via commits,” ACM Trans. Softw. Eng. Methodol., vol. 31, no. 1, pp. 13:1–13:27, 2022

    2022

  19. [27]

    Patchdb: A large- scale security patch dataset,

    X. Wang, S. Wang, P. Feng, K. Sun, and S. Jajodia, “Patchdb: A large- scale security patch dataset,” in 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2021, Taipei, Taiwan, June 21-24, 2021 . IEEE, 2021, pp. 149–160

    2021

  20. [28]

    Modeling and discover- ing vulnerabilities with code property graphs,

    F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Modeling and discover- ing vulnerabilities with code property graphs,” in 2014 IEEE Symposium on Security and Privacy, SP 2014 . IEEE Computer Society, 2014, pp. 590–604

    2014

  21. [29]

    CPGV A: code property graph based vulnerability analysis by deep learning,

    X. Wang, T. Zhang, R. Wu, W. Xin, and C. Hou, “CPGV A: code property graph based vulnerability analysis by deep learning,” in ICAIT. IEEE, 2018, pp. 184–188

    2018

  22. [30]

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

    Y . Zhou, S. Liu, J. K. Siow, X. Du, and Y . Liu, “Devign: Effective vulner- ability identification by learning comprehensive program semantics via graph neural networks,” in Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processi...

    2019

  23. [31]

    Deep learning based vulnerability detection: Are we there yet?

    S. Chakraborty, R. Krishna, Y . Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet?” CoRR, vol. abs/2009.07235, 2020

    2009 arXiv

  24. [32]

    A novel neural source code representation based on abstract syntax tree,

    J. Zhang, X. Wang, H. Zhang, H. Sun, K. Wang, and X. Liu, “A novel neural source code representation based on abstract syntax tree,” in Pro- ceedings of the 41st International Conference on Software Engineering, ICSE 2019, Montreal, QC, Canada, May 25-31, 2019 , J. M. Atlee, T...

    2019

  25. [33]

    Vulnerability detection with fine- grained interpretations,

    Y . Li, S. Wang, and T. N. Nguyen, “Vulnerability detection with fine- grained interpretations,” in ESEC/SIGSOFT FSE . ACM, 2021, pp. 292–303

    2021

  26. [34]

    Vulnerability detection with graph simplification and enhanced graph representation learning,

    X. Wen, Y . Chen, C. Gao, H. Zhang, J. M. Zhang, and Q. Liao, “Vulnerability detection with graph simplification and enhanced graph representation learning,” in 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14- 20, 2023. I...

    2023

  27. [35]

    Codeplan: Repository-level coding using llms and planning,

    R. Bairi, A. Sonwane, A. Kanade, V . D. C., A. Iyer, S. Parthasarathy, S. K. Rajamani, B. Ashok, and S. Shet, “Codeplan: Repository-level coding using llms and planning,” Proc. ACM Softw. Eng. , vol. 1, no. FSE, pp. 675–698, 2024

    2024

  28. [36]

    REPOFUSE: repository-level code completion with fused dual context,

    M. Liang, X. Xie, G. Zhang, X. Zheng, P. Di, W. Jiang, H. Chen, C. Wang, and G. Fan, “REPOFUSE: repository-level code completion with fused dual context,” CoRR, vol. abs/2402.14323, 2024

    2024 arXiv

  29. [37]

    Repoagent: An llm-powered open-source framework for repository-level code documentation gener- ation,

    Q. Luo, Y . Ye, S. Liang, Z. Zhang, Y . Qin, Y . Lu, Y . Wu, X. Cong, Y . Lin, Y . Zhang, X. Che, Z. Liu, and M. Sun, “Repoagent: An llm-powered open-source framework for repository-level code documentation gener- ation,” CoRR, vol. abs/2402.16667, 2024

    2024 arXiv

  30. [38]

    Repohy- per: Better context retrieval is all you need for repository-level code completion,

    H. N. Phan, H. N. Phan, T. N. Nguyen, and N. D. Q. Bui, “Repohy- per: Better context retrieval is all you need for repository-level code completion,” CoRR, vol. abs/2403.06095, 2024

    2024 arXiv

  31. [39]

    Repobench: Benchmark- ing repository-level code auto-completion systems,

    T. Liu, C. Xu, and J. J. McAuley, “Repobench: Benchmark- ing repository-level code auto-completion systems,” CoRR, vol. abs/2306.03091, 2023

    2023 arXiv

  32. [40]

    Vuleval: Towards repository-level evaluation of software vulnerability detection,

    X. Wen, X. Wang, Y . Chen, R. Hu, D. Lo, and C. Gao, “Vuleval: Towards repository-level evaluation of software vulnerability detection,” CoRR, vol. abs/2404.15596, 2024

    2024 arXiv

  33. [41]

    [Online]

    (2023) Tree-sitter. [Online]. Available: https://tree-sitter.github.io/ tree-sitter/

    2023

  34. [42]

    Frankenstein: fast and lightweight call graph generation for software builds,

    M. Keshani, G. Gousios, and S. Proksch, “Frankenstein: fast and lightweight call graph generation for software builds,” Empir. Softw. Eng., vol. 29, no. 1, p. 1, 2024

    2024

  35. [43]

    ”GNU cflow

    S. Poznyakoff, “”GNU cflow”,” 2005, https://www.gnu.org/software/ cflow/

    2005

  36. [44]

    Unixcoder: Unified cross-modal pre-training for code representation,

    D. Guo, S. Lu, N. Duan, Y . Wang, M. Zhou, and J. Yin, “Unixcoder: Unified cross-modal pre-training for code representation,” in Proceed- ings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2022, Dublin, Ireland, May 22...

    2022

  37. [45]

    Graph attention networks,

    P. Velickovic, G. Cucurull, A. Casanova, A. Romero, P. Li `o, and Y . Bengio, “Graph attention networks,” CoRR, vol. abs/1710.10903, 2017

    2017 arXiv

  38. [46]

    Convolutional neural networks for medical image analysis: Full training or fine tuning?

    N. Tajbakhsh, J. Y . Shin, S. R. Gurudu, R. T. Hurst, C. B. Kendall, M. B. Gotway, and J. Liang, “Convolutional neural networks for medical image analysis: Full training or fine tuning?” IEEE Trans. Medical Imaging , vol. 35, no. 5, pp. 1299–1312, 2016

    2016

  39. [47]

    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,” in Findings of the Association for Computational Linguistics: EMNLP 2020, Online Event, 16-20 November 20...

    2020

  40. [48]

    Codet5: Identifier- aware unified pre-trained encoder-decoder models for code understand- ing and generation,

    Y . Wang, W. Wang, S. R. Joty, and S. C. H. Hoi, “Codet5: Identifier- aware unified pre-trained encoder-decoder models for code understand- ing and generation,” inProceedings of the 2021 Conference on Empirical Methods in Natural Language Processing, EMNLP 2021, Virtual Event ...

    2021

  41. [49]

    Meta-llama-3-70b,

    Meta, “Meta-llama-3-70b,” 2024. [Online]. Available: https: //huggingface.co/meta-llama/Meta-Llama-3-70B

    2024

  42. [50]

    “Cppcheck

    Cppcheck-team, ““Cppcheck”,” [n.d.], http://cppcheck.sourceforge.net/

  43. [51]

    Rough audit tool for security

    “Rough audit tool for security.” [n.d.]. [Online]. Available: https: //code.google.com/archive/p/rough-auditing-tool-for-security

  44. [52]

    “Semgrep

    r2c, ““Semgrep”,” 2021, https://semgrep.dev

    2021

  45. [53]

    Flawfinder,

    D. A. Wheeler, “Flawfinder,” [n.d.]. [Online]. Available: https: //dwheeler.com/flawfinder/

  46. [54]

    VUDDY: A scalable approach for vulnerable code clone discovery,

    S. Kim, S. Woo, H. Lee, and H. Oh, “VUDDY: A scalable approach for vulnerable code clone discovery,” in 2017 IEEE Symposium on Security and Privacy, SP 2017, San Jose, CA, USA, May 22-26, 2017 . IEEE Computer Society, 2017, pp. 595–614

    2017

  47. [55]

    [Online]

    “Ollama,” 2024. [Online]. Available: https://ollama.com/

    2024

  48. [56]

    code property graph — joern documentation

    (2021) The joern project. code property graph — joern documentation. [Online]. Available: https://docs.joern.io/code-property-graph/

    2021

  49. [57]

    SCALE: constructing structured natural language comment trees for software vulnerability detection,

    X. Wen, C. Gao, S. Gao, Y . Xiao, and M. R. Lyu, “SCALE: constructing structured natural language comment trees for software vulnerability detection,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, Vienna, Austria, ...

    2024

  50. [58]

    Common weakness enumerations

    “Common weakness enumerations.” [Online]. Available: https://cwe. mitre.org/

  51. [59]

    (2016) Cve-2016-5243 detail

    CVE-2016-5243. (2016) Cve-2016-5243 detail. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2016-5243

    2016

  52. [60]

    (2016) Cve-2016-9535 detail

    CVE-2016-9535. (2016) Cve-2016-9535 detail. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2016-9535

    2016

  53. [61]

    National vulnerability database,

    “National vulnerability database,” [n.d.]. [Online]. Available: https: //nvd.nist.gov/

  54. [62]

    Tales of software updates: The process of updating software,

    K. Vaniea and Y . Rashidi, “Tales of software updates: The process of updating software,” in Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, San Jose, CA, USA, May 7- 12, 2016, J. Kaye, A. Druin, C. Lampe, D. Morris, and J. P. Hourcade, Eds. ACM, ...

    2016

  55. [63]

    Using safety properties to generate vulnerability patches,

    Z. Huang, D. Lie, G. Tan, and T. Jaeger, “Using safety properties to generate vulnerability patches,” in 2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May 19-23, 2019 . IEEE, 2019, pp. 539–554

    2019

  56. [64]

    Precisely characterizing security impact in a flood of patches via symbolic rule comparison,

    Q. Wu, Y . He, S. McCamant, and K. Lu, “Precisely characterizing security impact in a flood of patches via symbolic rule comparison,” in 27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, California, USA, February 23-26, 2020 . The Internet So...

    2020

  57. [65]

    Identifying linux bug fixing patches,

    Y . Tian, J. Lawall, and D. Lo, “Identifying linux bug fixing patches,” in 34th International Conference on Software Engineering, ICSE 2012, June 2-9, 2012, Zurich, Switzerland , M. Glinz, G. C. Murphy, and M. Pezz `e, Eds. IEEE Computer Society, 2012, pp. 386–396

    2012

  58. [66]

    Auto- matic hot patch generation for android kernels,

    Z. Xu, Y . Zhang, L. Zheng, L. Xia, C. Bao, Z. Wang, and Y . Liu, “Auto- matic hot patch generation for android kernels,” in29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020 , S. Capkun and F. Roesner, Eds. USENIX Association, 2020, pp. 2397–2414

    2020

  59. [67]

    A machine learning approach to classify security patches into vulnerability types,

    X. Wang, S. Wang, K. Sun, A. L. Batcheller, and S. Jajodia, “A machine learning approach to classify security patches into vulnerability types,” in 8th IEEE Conference on Communications and Network Security, CNS 2020, Avignon, France, June 29 - July 1, 2020 . IEEE, 2020, pp. 1–9

    2020

  60. [68]

    A deeper look into bug fixes: patterns, replacements, deletions, and additions,

    M. Soto, F. Thung, C. Wong, C. Le Goues, and D. Lo, “A deeper look into bug fixes: patterns, replacements, deletions, and additions,” in Proceedings of the 13th International Conference on Mining Software Repositories, MSR 2016, Austin, TX, USA, May 14-22, 2016 , M. Kim, R. Ro...

    2016

  61. [69]

    Recov- ering traceability links between source code and fixed bugs via patch analysis,

    C. S. Corley, N. A. Kraft, L. H. Etzkorn, and S. K. Lukins, “Recov- ering traceability links between source code and fixed bugs via patch analysis,” in TEFSE’11, Proceedings of the 6th International Workshop on Traceability in Emerging Forms of Software Engineering, May 23, 20...

    2011

  62. [70]

    Vccfinder: Finding potential vulnerabilities in open-source projects to assist code audits,

    H. Perl, S. Dechand, M. Smith, D. Arp, F. Yamaguchi, K. Rieck, S. Fahl, and Y . Acar, “Vccfinder: Finding potential vulnerabilities in open-source projects to assist code audits,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver,...

    2015

  63. [71]

    Vulcurator: a vulnerability-fixing commit detector,

    T. G. Nguyen, T. Le-Cong, H. J. Kang, X. D. Le, and D. Lo, “Vulcurator: a vulnerability-fixing commit detector,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2022, Singapore, Si...

    2022

  64. [72]

    Enhancing security patch identification by capturing structures in commits,

    B. Wu, S. Liu, R. Feng, X. Xie, J. K. Siow, and S. Lin, “Enhancing security patch identification by capturing structures in commits,” CoRR, vol. abs/2207.09022, 2022

    2022 arXiv

  65. [73]

    Colefunda: Explainable silent vulnerability fix identification,

    J. Zhou, M. Pacheco, J. Chen, X. Hu, X. Xia, D. Lo, and A. E. Hassan, “Colefunda: Explainable silent vulnerability fix identification,” in 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023 . IEEE, 2023, pp. 2565– 2577

    2023

  66. [74]

    Commit message can help: Security patch detection in open source software via transformer,

    F. Zuo, X. Zhang, Y . Song, J. Rhee, and J. Fu, “Commit message can help: Security patch detection in open source software via transformer,” in 21st IEEE/ACIS International Conference on Software Engineering Research, Management and Applications, SERA 2023, Orlando, FL, USA, M...

    2023

  67. [75]

    Finding A needle in a haystack: Automated mining of silent vulnerability fixes,

    J. Zhou, M. Pacheco, Z. Wan, X. Xia, D. Lo, Y . Wang, and A. E. Hassan, “Finding A needle in a haystack: Automated mining of silent vulnerability fixes,” in 36th IEEE/ACM International Conference on Automated Software Engineering, ASE 2021, Melbourne, Australia, November 15-19...

    2021

  68. [2012]

    IEEE Computer Society, 2012, pp. 420–429

    2012

  69. [2019]

    IEEE, 2019, pp. 485–492

    2019

  70. [2020]

    4223–4230

    AAAI Press, 2020, pp. 4223–4230

    2020

  71. [2024]

    Available: https://www.statista.com/statistics/500755/ worldwide-common-vulnerabilities-and-exposures/

    [Online]. Available: https://www.statista.com/statistics/500755/ worldwide-common-vulnerabilities-and-exposures/

Pith tools

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