Pith. sign in

REVIEW 3 major objections 3 minor 44 references

VulCoCo: A Simple Yet Effective Method for Detecting Vulnerable Code Clones

T0 review · 3 major / 3 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read VulCoCo pairs vector retrieval with LLM confirmation to find vulnerable code clones, reporting 119% higher mean average precision than prior tools on its SyVC benchmark and seven times more clones in real projects.

desk verdict Real-world recall and 7x claims are artifacts of pooling tool predictions as ground truth, but the tool itself has real impact via 75 merged PRs and 15 CVEs, and the paper deserves a serious referee with hard questions about evaluation design. read the letter →

arxiv 2507.16661 v1 pith:NLAONIGF submitted 2025-07-22 cs.SE

Tan Bui , Yan Naing Tun , Thanh Phuc Nguyen , Yindu Su , Ferdian Thung , Yikun Li , Han Wei Ang , Yide Yin
show 5 more authors
Frank Liauw Lwin Khin Shar Eng Lieh Ouh Ting Zhang David Lo
This is my paper
classification cs.SE
keywords vulnerablecodeclonesclonedetectionembedding-basedretrievalLLMvalidationsyntheticbenchmarkrecurringvulnerabilityCVEdiscoverysemanticsimilarity
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 vulnerable code clones — copies of a known-vulnerable function that preserve its flaw — are best found by treating detection as retrieval followed by semantic confirmation, rather than as syntactic or signature matching. The proposed pipeline, VulCoCo, first encodes functions with a code embedding model, retrieves candidates by cosine similarity, discards candidates closer to a patched version of the vulnerable function, then asks an LLM to judge whether each candidate still contains the same vulnerability. On a new synthetic benchmark of 1,000 clones drawn from 100 CVE-derived function pairs, VulCoCo reports a mean average precision of 67.69% against 30.94% for the best prior method, and in real-world repositories it reports finding more than seven times as many vulnerable clones as the best baseline while keeping precision above 56%. The paper backs the practical claim with 400 submitted pull requests, 75 merged, and 15 newly published CVEs. A sympathetic reader should care because the work supplies both a reproducible benchmark for a field that has relied on ad hoc evaluation and a plausible large-scale workflow for open-source security auditing.

What carries the argument

The carrying mechanism is the two-stage funnel plus a benchmark. Stage one is embedding retrieval: functions are parsed with tree-sitter, preprocessed (comments removed, whitespace and casing normalized), and encoded with jina-embeddings-v4; a FAISS index over L2-normalized vectors returns candidates above a cosine threshold (0.7 for the benchmark, 0.85 for real-world cost control), and a comparative filter drops any candidate that sits closer to the fixed version of the source function than to the vulnerable one. Stage two is LLM validation: Claude Sonnet 4 receives the original vulnerable function, its fixed version, and the candidate, and must return a JSON verdict with a justification, with an instruction not to flag mere callers of the vulnerable function. The supporting artifact is SyVC, a synthetic benchmark generating five clones per vulnerable or fixed function — one Type-1, one Type-2, two Type-3, one Type-4 — for 100 CVE-derived pairs, giving 1,000 balanced, labeled retrieval queries.

What would settle it

Conduct an evaluation whose ground truth is independent of the tools: have annotators audit all functions in the ten target repositories, or use a held-out set of clones confirmed by CVEs published after the study's cutoff, then recompute precision, recall, and F1 for VulCoCo and the baselines. If recall against this independent label set falls well below the reported 100%, or if the F1 gap over FIRE narrows substantially, the paper's central real-world claim is weakened. A cheaper check would be to re-verify all 1,000 SyVC clone labels by full human inspection rather than the 100 clones sampled.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that a deliberately simple two-stage pipeline — embedding-based retrieval followed by LLM validation — outperforms specialized vulnerable-clone detectors that rely on strict signatures, semantic patches, slices, or taint analysis. The load-bearing results are on two fronts. On the SyVC benchmark, VulCoCo reaches P@3 of 83.16% and MAP of 67.69%, versus 51.85% and 30.94% for MOVERY, the strongest baseline; its advantage concentrates in Type-3 and Type-4 clones, where syntactic similarity breaks down. On ten real-world repositories, manual labeling of candidates pooled from all tools yields 127 true positives with precision 56.44%, recall 100.00%, and F1 72.16%, against FIRE's F1 of 23.61%; VulCoCo covers every clone the baselines found and adds many they missed. The paper further claims these detections translate into accepted fixes, with 75 merged pull requests and 15 published CVEs.

Load-bearing premise

The load-bearing premise is that the manually labeled ground truth for the real-world study contains every true vulnerable clone that matters — but it is built only from candidates the evaluated tools themselves produced, so any vulnerable clone that all tools missed is excluded and recall is measured against the tools' union rather than against the actual population of clones in the target repositories.

Editorial extensions

If this is right

  • A retrieval formulation of vulnerable-clone detection — rank candidates per known-vulnerable query — is more informative than the binary classification framing used by earlier tools, and enables standard ranking metrics.
  • LLM validation is a load-bearing component: ablating it drops MAP from 67.69% to 62.80% and P@5 from 68.25% to 63.09%, and swapping in GPT-4.0 only partially recovers the gap, indicating validator quality directly bounds precision.
  • The method's edge is concentrated in heavily transformed clones: 248 of its 336 true positives on SyVC are not found by FIRE or MOVERY, largely Type-3 and Type-4 clones.
  • Deployed at scale, the pipeline converts detection into patches: 400 pull requests across 284 projects, 75 merged and 15 new CVEs, suggesting many in-the-wild vulnerable clones remain unpatched until actively hunted.
  • The SyVC benchmark gives the community a reproducible, balanced testbed spanning all four clone types, where earlier evaluation relied on manual, ad hoc datasets.

Reading between the lines

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

  • The reported 100% recall and zero false negatives in the real-world evaluation are partly structural: the ground truth is the manually labeled union of all tools' predictions, so a clone that no tool surfaced is invisible to the metric; VulCoCo's recall advantage reflects its larger candidate net as much as its detection skill.
  • A sharper test of the recall claim would measure against an independent ground truth, such as vulnerable clones confirmed after the fact by newly published CVEs or by full-audit labeling of all functions in the ten target repositories — not just the candidates the tools proposed.
  • The fact that retrieval gains saturate between thresholds 0.7 and 0.6 suggests the embedding stage is not the precision bottleneck; cost per LLM call is, so lowering the threshold further trades money for marginal recall — a deployment tradeoff the paper leaves implicit.
  • If the pattern generalizes, the retrieval-plus-LLM-confirmation shape could apply to other copied-dangerous-artifact problems, such as detecting propagated misconfiguration, duplicated insecure API usage, or license-granted reuse, where semantic confirmation replaces hand-built signatures.
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

3 major / 3 minor

Summary. The paper presents VulCoCo, a two-stage vulnerable code clone (VCC) detector that first retrieves candidate functions by embedding-based similarity to known vulnerable functions and then validates the candidates with an LLM (Claude Sonnet 4). The authors also introduce SyVC, a synthetic benchmark of 1,000 clones built from 100 vulnerable-fixed function pairs across four clone types, and report evaluations on both the benchmark and real-world projects. On SyVC, VulCoCo achieves MAP 67.69% versus 30.94% for the best baseline MOVERY; in the real-world evaluation, it reports precision 56.44%, recall 100%, and F1 72.16% against FIRE's F1 23.61%. The paper further reports 400 submitted PRs, 75 merged, and 15 newly published CVEs.

Significance. The work addresses a real and practically important problem, and its real-world deployment—400 PRs, 75 merged, 15 CVEs—is a meaningful, falsifiable demonstration of utility that goes beyond typical benchmark reporting. The SyVC benchmark is a sensible step toward reproducible evaluation of VCC detectors, and the ablation study in Section 5.2 usefully isolates the contributions of the LLM validator, the embedding model, and the similarity threshold. If the absolute performance claims are taken at face value, VulCoCo would be a substantial advance over syntax- and slice-based baselines. However, two evaluation-design issues limit the strength of those claims: the real-world recall is measured against a ground truth that is the union of the tools' own predictions, and the SyVC labels are generated and validated by the same LLM family used in VulCoCo. These issues do not erase the practical contributions, but they do mean the headline recall and F1 numbers should not be read as absolute detection quality.

major comments (3)
  1. [§4.5.2, §5.3.1, Table 8] The real-world recall claim is structurally guaranteed by the evaluation protocol. Section 4.5.2 states that the ground truth is formed by gathering all predicted vulnerable clones from VulCoCo and the baselines and manually inspecting them, and Section 5.3.1 states that VulCoCo 'detects every clone found by the other tools.' Under this pooling design, the denominator for recall contains no vulnerable clone that all tools missed; VulCoCo's FN=0 and 100% recall are therefore a consequence of the candidate-set size and its subsumption of the other tools' outputs, not a measured recall against the true population of vulnerable clones in the target repositories. Consequently, the abstract and Section 1's claim of 'more than 7 times as many VCCs compared to FIRE' and the F1 gap in Table 8 partly reflect the size of the candidate pool. I recommend either (a) constructing a recall denominator that can include clones missed by all tools (e.g., via independent sampling from a broader similarity neighborhood or using repositories with known downstream CVE fixes), or (b) explicitly reframing the real-world result as coverage relative to the pooled tool outputs rather than absolute recall. The paper's own statement in Section 2.2 acknowledges that this pooling protocol comes from prior work, but the headline claims in this paper go beyond those prior studies' framing.
  2. [§3.3, §4.2.3] The SyVC benchmark has a generator-validator overlap that may inflate VulCoCo's measured advantage. SyVC clones are generated with Claude Sonnet 4 (Section 4.2.3), and VulCoCo's validation step uses the same model family (Section 3.3). The LLM validator may be more likely to confirm a clone as vulnerable when the clone preserves the stylistic and structural patterns of that model's own generations, which would give VulCoCo an unfair advantage over the non-LLM baselines on SyVC. The manual verification of only 100 of 1,000 clones reported in Section 4.2.3 is too small to rule out this effect, and the paper does not provide per-clone-type agreement statistics or an inter-annotator reliability measure. I recommend verifying a much larger stratified sample of the benchmark, using an independent model (e.g., a different LLM family or a human-only jury) for at least a random subset of labels, and reporting the benchmark scores of VulCoCo when the validator is an LLM that was not used to generate the clones.
  3. [§4.1 vs §4.5.2] The real-world evaluation protocol is described inconsistently. Section 4.1 (RQ3) says 'two of the authors manually verify the top 5 predictions by each method to get a ground-truth set,' but Section 4.5.2 says 'we gather all predicted vulnerable clones from our method and baselines, and manually inspect each one.' The counts in Table 8 (e.g., 225 predictions for VulCoCo, 42 for ReDeBug, 23 for MOVERY) are incompatible with a top-5-only inspection, so the RQ3 sentence appears inaccurate. Additionally, Section 5.3.1 states that SrcVul returned 'millions' of positives but that only 100 were sampled, yet Table 8 lists FP=100 and FN=127 for SrcVul; the table should clearly state how the sampled 100 are used to compute precision, recall, and F1 for that row. Please align the protocol description and make the sampling procedure explicit.
minor comments (3)
  1. [Section 1, Table 4] The claim that VulCoCo 'outperforms prior state-of-the-art methods' should be qualified: in Table 4, VulCoCo's P@1 (94.85%) is lower than the hash-based baseline (97.92%). The superiority holds at P@3, P@5, and MAP, and the text in Section 5.1.1 already notes this, but the abstract and conclusion should carry the same qualification.
  2. [Section 4.4] The validation set used for parameter and prompt tuning should state explicitly whether its 10 vulnerable-fixed pairs are disjoint from the 100 pairs in the main SyVC benchmark. If they are not disjoint, threshold selection and prompt design may be tuned on a subset of the test distribution, which would weaken the claim that the reported numbers are unbiased.
  3. [Section 5.3.2] The PR outcome statistics are valuable, but the paper reports only 75 merged, 89 closed, and leaves the rest as 'no response.' It would be clearer to give the total number of PRs that were accepted with modifications versus merged as-is, and to report how many of the 400 PRs were for Java versus C/C++ projects, since the target corpus was drawn from all three languages.

Circularity Check

1 steps flagged · score 6.0 of 10

Real-world recall and 7x VCC claim rest on a ground truth built from the tools' own predictions, making the 100% recall self-referential.

  1. self definitional [Section 4.5.2 (Real-World Evaluation); results in Table 8 and Section 5.3.1]
    "Specifically, we gather all predicted vulnerable clones from our method and baselines, and manually inspect each one to determine whether it truly retains the same vulnerability as the original source function. Two independent annotators performed this review, each holding at least a Bachelor's degree in Computer Science and 5+ years of programming experience. The final set, used as the ground truth, consists of manually labelled clones from all tools."

    The ground-truth set is formally G = {c in union of all tools' predictions : manual(c) = vulnerable}, and recall is computed as |P_T ∩ G| / |G|. Any clone missed by every tool is absent from G a priori, so it cannot be a false negative. The paper then reports that VulCoCo 'detects every clone found by the other tools,' so P_VulCoCo ⊇ G and recall = 100.00 in Table 8 follows from the pooling definition once VulCoCo's candidate set subsumes the other tools' confirmed positives. Thus the headline 'more than 7 times as many VCCs' and the F1 gap measure performance within a candidate pool that VulCoCo itself helps define, not recovery of the true population of vulnerable clones. This is the same protocol the paper criticizes for prior work in Section 2.2.

full rationale

The only load-bearing circular step is in the real-world evaluation protocol. Section 4.5.2 defines the ground truth as the manually confirmed subset of the union of all tools' predictions, so recall is measured only against clones that at least one tool surfaced. Because the paper reports that VulCoCo detects every clone found by the other tools, its FN=0 and recall=100.00 are an artifact of the pooling definition rather than an independent measurement of recovery against all real vulnerable clones. The '7 times as many VCCs' claim inherits the same limitation. This is a self-referential evaluation of the central real-world claim, though not a formal mathematical derivation of a vulnerability from a fitted parameter. The SyVC benchmark results in Table 4 are less clearly circular: 100 of 1,000 clones were independently manually verified, but the remaining 900 labels come from the same Claude model family used in VulCoCo's validator, which is a validity risk rather than a formal circularity. The PR-merge and CVE findings provide independent, externally falsifiable evidence of practical utility and are not part of the circular step. Overall, the central real-world recall/F1 claim is partially circular, so the score is 6.

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

No new physical or conceptual entities (particles, forces, conserved quantities) are introduced. SyVC is a dataset, not an entity. The only new postulated objects are the SyVC benchmark and the VulCoCo pipeline, neither of which requires an independent falsifiability ledger entry.

free parameters (3)
  • similarity threshold t = 0.7 (benchmark), 0.85 (real-world)
    Hand-tuned on a 100-clone validation set; MAP varies from 50.54% to 67.69% as t drops from 0.9 to 0.7 (Table 7), so the results are sensitive to this choice.
  • function length filter = top and bottom 5% removed
    Functions with extreme line counts are discarded before building queries; affects the pool of 9,539 source pairs (Section 4.2.1).
  • clone generation mix = 1 Type-1, 1 Type-2, 2 Type-3, 1 Type-4 per function
    The composition of the synthetic benchmark is a design choice; Type-3 is doubled, which shapes the difficulty distribution and the headline P@k numbers.
assumptions (4)
  • domain assumption Manual verification of 100 of 1,000 SyVC clones is sufficient to guarantee the labels of the remaining 900.
    Section 4.2.3: 'we randomly sample 100 generated functions and manually verify that all are true clones...' This assumes the sample is representative and that LLM generation errors are negligible for the rest.
  • domain assumption Embedding cosine similarity above threshold t is a valid proxy for 'similar code that may retain a vulnerability'.
    Section 3.2: retrieval relies on L2-normalized inner product; the threshold t is the only gate before LLM validation.
  • ad hoc to paper The union of tool predictions is a valid basis for a recall ground truth.
    Section 4.5.2: the ground-truth set is built from manually labelled clones from all tools; this omits VCCs that no tool surfaced, so recall is upper-biased.
  • domain assumption The LLM validator (Claude Sonnet 4) correctly determines whether a candidate retains the vulnerability.
    Section 3.3; the paper itself documents vulnerability confabulation false positives (Section 5.3.1, Listings 6 and 7).

how reviews work

0 comments
Cite this review

Pith. "Pith review of VulCoCo: A Simple Yet Effective Method for Detecting Vulnerable Code Clones." pith.science (2026). https://pith.science/paper/NLAONIGF

@misc{pith2026250716661,
  author       = {Pith},
  title        = {Pith review of: VulCoCo: A Simple Yet Effective Method for Detecting Vulnerable Code Clones},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NLAONIGF}},
  note         = {Machine review of arXiv:2507.16661}
}
read the original abstract

Code reuse is common in modern software development, but it can also spread vulnerabilities when developers unknowingly copy risky code. The code fragments that preserve the logic of known vulnerabilities are known as vulnerable code clones (VCCs). Detecting those VCCs is a critical but challenging task. Existing VCC detection tools often rely on syntactic similarity or produce coarse vulnerability predictions without clear explanations, limiting their practical utility. In this paper, we propose VulCoCo, a lightweight and scalable approach that combines embedding-based retrieval with large language model (LLM) validation. Starting from a set of known vulnerable functions, we retrieve syntactically or semantically similar candidate functions from a large corpus and use an LLM to assess whether the candidates retain the vulnerability. Given that there is a lack of reproducible vulnerable code clone benchmarks, we first construct a synthetic benchmark that spans various clone types. Our experiments on the benchmark show that VulCoCo outperforms prior state-of-the-art methods in terms of Precision@k and mean average precision (MAP). In addition, we also demonstrate VulCoCo's effectiveness in real-world projects by submitting 400 pull requests (PRs) to 284 open-source projects. Among them, 75 PRs were merged, and 15 resulted in newly published CVEs. We also provide insights to inspire future work to further improve the precision of vulnerable code clone detection.

Figures

Figures reproduced from arXiv: 2507.16661 by the authors.

Figure 1
Figure 1. Overview of the system pipeline. bottom 5% of functions based on the number of lines. Short functions are often ambiguous when cloned [6, 21, 33], and very long functions exceed the context limits of most LLMs. After filtering, we retain a total of 9,539 pairs of vulnerable and fixed functions to generate queries. 4.2.2 Target Repositories. We selected a total of 10 target repositories based on the following criteri… view at source ↗
Figure 2
Figure 2. Overlap of correct predictions (true positives, left) and wrong predictions (false positives, right) on the [PITH_FULL_IMAGE:figures/full_fig_p014_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

44 extracted references · 27 canonical work pages

  1. [1]

    [n. d.]. all-MiniLM-L6-v2. https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

    work page

  2. [2]

    [n. d.]. jina-embeddings-v2-base-code. https://huggingface.co/jinaai/jina-embeddings-v2-base-code

    work page

  3. [3]

    Hakam Alomari, Christopher Vendome, and Hilal Gyawali. 2025. A Slicing-Based Approach for Detecting and Patching Vulnerable Code Clones. arXiv preprint arXiv:2505.02349 (2025)

    work page Pith review arXiv 2025

  4. [4]

    Anthropic. 2025. Claude 4 System Card. https://www.anthropic.com/claude-4-system-card

    work page 2025

  5. [5]

    Anthropic. 2025. Claude Sonnet 4. https://www.anthropic.com/claude/sonnet

    2025

  6. [6]

    Saman Bazrafshan and Rainer Koschke. 2013. An empirical study of clone removals. In 2013 IEEE International Conference on Software Maintenance . IEEE, 50–59

    work page 2013

  7. [7]

    Benjamin Bowman and H Howie Huang. 2020. VGRAPH: A robust vulnerable code clone detection system using code property triplets. In 2020 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 53–69

    work page 2020

  8. [8]

    Quang-Cuong Bui, Riccardo Scandariato, and Nicolás E Díaz Ferreyra. 2022. Vul4j: A dataset of reproducible java vulnerabilities geared towards the study of program repair techniques. InProceedings of the 19th International Conference on Mining Software Repositories . 464–468

    work page 2022

Show all 44 references
  1. [9]

    Tan Bui, Yan Naing Tun, Yiran Cheng, Ivana Clairine Irsan, Ting Zhang, and Hong Jin Kang. 2024. JavaVFC: Java Vulnerability Fixing Commits from Open-source Software. arXiv preprint arXiv:2409.05576 (2024)

    2024 arXiv

  2. [10]

    James R Cordy and Chanchal K Roy. 2011. The NiCad clone detector. In 2011 IEEE 19th international conference on program comprehension. IEEE, 219–220

    2011

  3. [11]

    Alexandre Decan, Tom Mens, and Eleni Constantinou. 2018. On the evolution of technical lag in the npm package dependency network. In 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME) . IEEE, 404–414

    2018

  4. [12]

    Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomair, David Wagner, Baishakhi Ray, and Yizheng Chen. 2024. Vulnerability detection with code language models: How far are we? arXiv preprint arXiv:2403.18624 (2024)

    2024 arXiv

  5. [13]

    Matthijs Douze, Alexandr Guzhva, Chengqi Deng, Jeff Johnson, Gergely Szilvasy, Pierre-Emmanuel Mazaré, Maria Lomeli, Lucas Hosseini, and Hervé Jégou. 2024. The Faiss library. (2024). arXiv:2401.08281 [cs.LG]

    2024 arXiv

  6. [14]

    Siyue Feng, Yueming Wu, Wenjie Xue, Sikui Pan, Deqing Zou, Yang Liu, and Hai Jin. 2024. {FIRE}: Combining {Multi-Stage} Filtering with Taint Analysis for Scalable Recurring Vulnerability Detection. In 33rd USENIX Security Symposium (USENIX Security 24) . 1867–1884

    2024

  7. [15]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al . 2020. Codebert: A pre-trained model for programming and natural languages. arXiv preprint arXiv:2002.08155 (2020)

    2020 arXiv

  8. [16]

    Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie Liu, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, et al. 2020. Graphcodebert: Pre-training code representations with data flow.arXiv preprint arXiv:2009.08366 (2020)

    2020 arXiv

  9. [17]

    Michael Günther, Saba Sturua, Mohammad Kalim Akram, Isabelle Mohr, Andrei Ungureanu, Sedigheh Eslami, Scott Martens, Bo Wang, Nan Wang, and Han Xiao. 2025. jina-embeddings-v4: Universal Embeddings for Multimodal Multilingual Retrieval. arXiv:2506.18902 [cs.AI] https://arxiv.or...

    2025 arXiv

  10. [18]

    Jiyong Jang, Abeer Agrawal, and David Brumley. 2012. ReDeBug: finding unpatched code clones in entire os distribu- tions. In 2012 IEEE Symposium on Security and Privacy . IEEE, 48–62

    2012

  11. [19]

    Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, and Stephane Glondu. 2007. Deckard: Scalable and accurate tree-based detection of code clones. In 29th International Conference on Software Engineering (ICSE’07) . IEEE, 96–105

    2007

  12. [20]

    Jeff Johnson, Matthijs Douze, and Hervé Jégou. 2019. Billion-scale similarity search with GPUs. IEEE Transactions on Big Data 7, 3 (2019), 535–547

    2019

  13. [21]

    Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue. 2002. CCFinder: A multilinguistic token-based code clone detection system for large scale source code. IEEE transactions on software engineering 28, 7 (2002), 654–670

    2002

  14. [22]

    Miryung Kim, Vibha Sazawal, David Notkin, and Gail Murphy. 2005. An empirical study of code clone genealogies. In Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering ...

    2005

  15. [23]

    Seulbae Kim, Seunghoon Woo, Heejo Lee, and Hakjoo Oh. 2017. Vuddy: A scalable approach for vulnerable code clone discovery. In 2017 IEEE symposium on security and privacy (SP) . IEEE, 595–614

    2017

  16. [24]

    Raula Gaikovina Kula, Daniel M German, Ali Ouni, Takashi Ishio, and Katsuro Inoue. 2018. Do developers update their library dependencies? An empirical study on the impact of security advisories on library migration. Empirical Software Engineering 23, 1 (2018), 384–417

    2018

  17. [25]

    Yikun Li, Ting Zhang, Ratnadira Widyasari, Yan Naing Tun, Huu Hung Nguyen, Tan Bui, Ivana Clairine Irsan, Yiran Cheng, Xiang Lan, Han Wei Ang, et al. 2024. CleanVul: Automatic Function-Level Vulnerability Detection in Code Commits Using LLM Heuristics. arXiv preprint arXiv:241...

    2024 arXiv

  18. [26]

    Zhenmin Li, Shan Lu, Suvda Myagmar, and Yuanyuan Zhou. 2006. CP-Miner: Finding copy-paste and related bugs in large-scale software code. IEEE Transactions on software Engineering 32, 3 (2006), 176–192

    2006

  19. [27]

    Zhen Li, Deqing Zou, Shouhuai Xu, Hai Jin, Hanchao Qi, and Jie Hu. 2016. Vulpecker: an automated vulnerability detection system based on code similarity analysis. In Proceedings of the 32nd annual conference on computer security applications. 201–213

    2016

  20. [28]

    Zhen Li, Deqing Zou, Shouhuai Xu, Hai Jin, Yawei Zhu, and Zhaoxuan Chen. 2021. Sysevr: A framework for using deep learning to detect software vulnerabilities. IEEE Transactions on Dependable and Secure Computing 19, 4 (2021), 2244–2258

    2021

  21. [29]

    Zhen Li, Deqing Zou, Shouhuai Xu, Xinyu Ou, Hai Jin, Sujuan Wang, Zhijun Deng, and Yuyi Zhong. 2018. Vuldeepecker: A deep learning-based system for vulnerability detection. arXiv preprint arXiv:1801.01681 (2018)

    2018 arXiv

  22. [30]

    Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambrosio Blanco, Colin Clement, Dawn Drain, Daxin Jiang, Duyu Tang, et al. 2021. Codexglue: A machine learning benchmark dataset for code understanding and generation. arXiv preprint arXiv:2102.04664 (2021)

    2021 arXiv

  23. [31]

    Tung Thanh Nguyen, Hoan Anh Nguyen, Nam H Pham, Jafar M Al-Kofahi, and Tien N Nguyen. 2009. Clone-aware configuration management. In 2009 IEEE/ACM International Conference on Automated Software Engineering . IEEE, 123–134

    2009

  24. [32]

    Ivan Pashchenko, Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, and Fabio Massacci. 2020. Vuln4real: A methodology for counting actually vulnerable dependencies. IEEE Transactions on Software Engineering 48, 5 (2020), 1592–1609

    2020

  25. [33]

    Chanchal Kumar Roy and James R Cordy. 2007. A survey on software clone detection research. Queen’s School of computing TR 541, 115 (2007), 64–68

    2007

  26. [34]

    Chanchal Kumar Roy and James R Cordy. 2009. A comparison of bug finding tools for Java. In 2009 17th IEEE International Conference on Program Comprehension . IEEE, 243–252. doi:10.1109/ICPC.2009.5090030

    2009

  27. [35]

    Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, Chanchal K Roy, and Cristina V Lopes. 2016. Sourcerercc: Scaling code clone detection to big-code. In Proceedings of the 38th international conference on software engineering . 1157–1168

    2016

  28. [36]

    Saba Sturua, Isabelle Mohr, Mohammad Kalim Akram, Michael Günther, Bo Wang, Markus Krimmel, Feng Wang, Georgios Mastrapas, Andreas Koukounas, Andreas Koukounas, Nan Wang, and Han Xiao. 2024. jina-embeddings-v3: Multilingual Embeddings With Task LoRA. arXiv:2409.10173 [cs.CL] h...

    2024 arXiv

  29. [37]

    Peiqi Sui, Eamon Duede, Sophie Wu, and Richard Jean So. 2024. Confabulation: The surprising value of large language model hallucinations. arXiv preprint arXiv:2406.04175 (2024)

    2024 arXiv

  30. [38]

    Qwen Team. 2025. Qwen2.5-VL. https://qwenlm.github.io/blog/qwen2.5-vl/

    2025

  31. [39]

    Qwen Team. 2025. Qwen3 Technical Report. arXiv:2505.09388 [cs.CL] https://arxiv.org/abs/2505.09388

    2025 arXiv

  32. [40]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. 2021. Codet5: Identifier-aware unified pre-trained encoder- decoder models for code understanding and generation. arXiv preprint arXiv:2109.00859 (2021)

    2021 arXiv

  33. [41]

    Seunghoon Woo, Eunjin Choi, Heejo Lee, and Hakjoo Oh. 2023. {V1SCAN}: Discovering 1-day Vulnerabilities in Reused{C/C++} Open-source Software Components Using Code Classification Techniques. In 32nd USENIX Security Symposium (USENIX Security 23) . 6541–6556

    2023

  34. [42]

    2022.{MOVERY}: A precise approach for modified vul- nerable code clone discovery from modified{Open-Source} software components

    Seunghoon Woo, Hyunji Hong, Eunjin Choi, and Heejo Lee. 2022.{MOVERY}: A precise approach for modified vul- nerable code clone discovery from modified{Open-Source} software components. In 31st USENIX Security Symposium (USENIX Security 22). 3037–3053

    2022

  35. [43]

    2020.{MVP}: Detecting vulnerabilities using{Patch-Enhanced} vulnerability signatures

    Yang Xiao, Bihuan Chen, Chendong Yu, Zhengzi Xu, Zimu Yuan, Feng Li, Binghong Liu, Yang Liu, Wei Huo, Wei Zou, et al. 2020.{MVP}: Detecting vulnerabilities using{Patch-Enhanced} vulnerability signatures. In 29th USENIX Security Symposium (USENIX Security 20) . 1165–1182

    2020

  36. [44]

    Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks. Advances in neural information processing systems 32 (2019). , Vol. 1, No. 1, Article...

    2019

Pith tools

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