Pith. sign in

REVIEW 5 major objections 5 minor 1 cited by

Enhancing Security in Third-Party Library Reuse -- Comprehensive Detection of 1-day Vulnerability through Code Patch Analysis

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

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

Pith's one-line read VULTURE claims to catch 1-day vulnerabilities in both exact and custom third-party library reuse with higher accuracy and lower cost than existing academic and commercial tools, reporting F1 at 95.8% on a 200-case benchmark and 175…

desk verdict Solid systems paper with a genuinely new chunk-based approach to custom TPL reuse, but the headline F1 is in-sample and the tuned thresholds make the numbers upper bounds until out-of-sample validation. read the letter →

arxiv 2411.19648 v1 pith:4HG4BB4U submitted 2024-11-29 cs.SE

Shangzhi Xu , Jialiang Dong , Weiting Cai , Juanru Li , Arash Shaghaghi , Nan Sun , Siqi Ma This is my paper · ORCID
classification cs.SE
keywords third-partylibraryreuse1-dayvulnerabilitydetectioncustomcodepatchanalysischunk-basedlocality-sensitivehashingLLM-assistedmapping
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that 1-day vulnerabilities from third-party library (TPL) reuse can be detected reliably even when developers modify the reused code, and that a combined pipeline—platform-specific database construction, LLM-guided CVE-to-patch mapping, hashing-based TPL identification, and chunk-based comparison of vulnerable versus patched code—does so with higher accuracy and lower cost than existing academic and commercial tools. On a manually built benchmark of 200 vulnerable function reuses, the tool VULTURE reports F1 at 95.8% versus 66.7% for V1SCAN, and in 10 real-world IoT projects it reports 175 confirmed vulnerabilities compared with 111 for SNYK and 13 for V1SCAN. A sympathetic reader would care because the paper also finds that custom reuse represents about 55% of TPL reuse, which is exactly the regime where prior tools miss the most.

What carries the argument

The load-bearing mechanism is chunk-based analysis of the patch diff. After normalizing code, VULTURE computes diffs between target, vulnerable, and patched code, treats each changed line as a unit, and merges units via a disjoint-set union when they belong to the same control block or share variables. The resulting chunk preserves semantic and contextual information about the patch, allowing a vulnerability to be counted as patched only if all patch lines or operations appear in the target's diff against the vulnerable code and disappear from the diff against the patched code. This chunk abstraction is what lets VULTURE recognize a custom patch whose statement layout differs from the official one.

What would settle it

An independent benchmark of custom TPL reuse, labeled without input from the authors and run with fixed thresholds, would settle the claim: if VULTURE's F1 on it does not clearly exceed V1SCAN's, or if small threshold changes move it from above 90% to below 70%, the central claim of superior custom-reuse detection fails.

Watch

Extended reading notes

Core claim

VULTURE's central discovery is that exact reuse and custom reuse need separate detection mechanisms, and that custom reuse can be captured by comparing the patch diff at the granularity of semantic chunks rather than whole functions or lines. For exact reuse it uses version-based matching: function hashes of the target are compared with vulnerable and patched versions of TPL functions, and a vulnerability is confirmed when a vulnerable function appears without the patch. For custom reuse it builds chunks from the diff between vulnerable and patched code, merging modified lines that share variables or control structures, then checks whether the target program's modifications contain the patch's lines or operations. The paper claims this design catches custom patches that line-matching tools like V1SCAN would report as false positives, and that the LLM-based patch commit mapping in TPLFILTER reduces manual database construction effort.

Load-bearing premise

The gains over other tools rest on a manually labeled benchmark and on similarity thresholds tuned on that same evaluation set, so if real-world custom reuse differs from these 200 cases, the reported F1 and vulnerability counts would not transfer.

Editorial extensions

If this is right

  • If custom reuse is as common as the study indicates, tools that match only exact code will miss a majority of 1-day vulnerabilities.
  • Developers can act on VULTURE's reports directly, because each finding includes the CVE ID, the patch commit URL, and the exact code locations that need changing.
  • The TPL database can be rebuilt for a new platform using the same keyword-plus-LLM pipeline, so the approach is transferable beyond IoT.
  • Because version-based analysis distinguishes unused TPL functions from actually reused ones, detection accuracy is not diluted by the rest of the library.
  • The study's finding that many vulnerable reuses stem from outdated TPLs suggests that keeping the vulnerability database current is as important as the detection algorithm itself.

Reading between the lines

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

  • A corollary the authors leave implicit: if custom reuse truly accounts for about 55% of reuses, then conventional vulnerability scanners that rely on version matching under-report the 1-day exposure of real codebases by roughly a factor of two.
  • The chunk construction rule—that lines sharing a variable or control block form one unit—amounts to a testable hypothesis about patch semantics: fix semantics are carried by variable co-occurrence and control nesting, not by statement text. Replacing chunk merging with a dataflow slicer on the same diffs would reveal where that approximation breaks.
  • Since the pipeline depends on CVE descriptions naming files, functions, or variables, its ceiling tracks the information quality of CVE/NVD entries; on CVEs with vague descriptions the LLM mapping has nothing to anchor to, so an information-rich benchmark would show higher scores than a realistic one.
  • The reported thresholds THhash=30 and THsim=10% were tuned on the evaluation set, so a natural hardening step would be a threshold-free variant that learns decision boundaries to verify stability across platforms.
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

5 major / 5 minor

Summary. The paper presents VULTURE, a tool for detecting 1-day vulnerabilities introduced through third-party library (TPL) reuse in C/C++ software. It comprises TPLFILTER, an LLM-assisted database construction method; an LSH-based TPL reuse identification stage; and a dual analysis stage that uses version-based matching for exact reuse and chunk-based analysis for custom reuse. The authors evaluate VULTURE on a manually constructed benchmark of 200 vulnerable function reuse cases, reporting an F1 score of 95.8% compared with V1SCAN's 66.7%, and on 10 real-world IoT projects, where VULTURE reportedly found 175 confirmed vulnerabilities from 178 reused TPLs, outperforming SNYK (111) and V1SCAN (13). The paper also evaluates TPLFILTER's database quality and the security patch mapping component against VFCFinder and other baselines.

Significance. If the reported results are generalizable, VULTURE would be a meaningful advance over existing tools because it addresses custom TPL reuse, which is known to be difficult, and it integrates database construction, patch mapping, and vulnerability detection into one maintainable pipeline. The paper has several strengths: it compares against both academic and commercial tools, it reports a 5-fold group validation for the patch mapping component, it includes a detailed error analysis, and it states that the source code and datasets are publicly available. These are valuable features for a systems paper. However, the central accuracy claims rest on an evaluation that is largely in-sample: the similarity thresholds were tuned on the same benchmark used for reporting F1, the ground truth was manually labeled by the authors, and the wild detections were confirmed by the same group. As a result, the quantitative superiority over V1SCAN and SNYK should be treated as promising but not yet established.

major comments (5)
  1. [Section V-A and Section V-C] The headline F1 score of 95.8% is obtained under in-sample threshold tuning. Section V-A states that THhash = 30 and THsim = 10% were set 'after manual testing to achieve optimal detection results,' and the benchmark used for the F1 evaluation (Section V-C) was manually constructed and labeled by the authors. No held-out set, cross-validation, or sensitivity analysis is reported for the vulnerability detection benchmark, in contrast to the 5-fold group validation used for patch mapping in Section V-B-2. Because the same thresholds are then applied in the wild experiment (Section V-D), the 175 confirmed vulnerabilities inherit the same overfitting risk. The paper should provide an out-of-sample evaluation using a separate tuning/validation split, k-fold validation on the 200 cases, or a pre-committed threshold setting, and it should report precision-recall and F1 over a range of threshold values.
  2. [Section V-C] The manually constructed benchmark is described only at a high level: it comprises 200 vulnerable function reuse cases covering 66 CVEs, with 45% patched and 64% custom reuse. The paper does not state how the cases were selected, how many distinct projects were involved, what exact definition of 'vulnerable function reuse' was used, or how labels were assigned and validated (e.g., one annotator or multiple annotators, and what inter-annotator agreement was achieved). Moreover, all 200 cases appear to be positive (vulnerable) cases; there is no clear negative class of non-vulnerable reused functions. Consequently, the reported F1 measures the tool's ability to distinguish patched from unpatched vulnerable functions rather than its ability to distinguish vulnerable code from clean code. The authors should clarify whether non-vulnerable cases were included and, if not, add a negative-case set or explicitly re-frame the metric as a patched/unpatched classification problem.
  3. [Section V-D] The claim of 175 confirmed vulnerabilities in 10 real-world projects is weakened by the same self-referential evaluation loop: the same group built the database, tuned the thresholds, and manually confirmed every detected vulnerability. The paper does not report how many potentially vulnerable TPLs were not detected (false negatives) because no full ground truth is available for the wild projects, and the manual confirmation is not independently audited. I ask the authors to provide either an independent validation (e.g., by external annotators or a separate research group) or a more cautious reporting format: for example, report precision as 'confirmed out of detected' with a confidence interval, and discuss how manual confirmation could be biased by knowledge of the tool's outputs. This is particularly important because the paper's conclusion states that VULTURE 'successfully identified 175 vulnerabilities' without such caveats.
  4. [Table III] The F1 values in Table III appear inconsistent with the reported Detected and Confirmed counts. For VFCFinder Top-1, if 158 detections were made and 79 were confirmed, precision and recall are each 79/158 = 0.5, giving an F1 score of 50.0%, not the reported 61.69%. For VFCFinder Top-5, the corresponding F1 would be 62.0%, not 71.53%. Similar arithmetic issues may affect the other schemes. The paper should either define exactly how F1 is computed (e.g., whether 'Detected' counts CVEs with at least one candidate, or counts individual commits) or correct the table. This is load-bearing because the patch mapping result is one of the paper's main claimed improvements.
  5. [Section V-E / Limitation] The limitation section already acknowledges that 'the settings of similarity thresholds THhash need to be adjusted to match various databases and accommodate different application scenarios.' This is in tension with the paper's use of the fixed thresholds THhash = 30 and THsim = 10% as if they were generally applicable in the wild evaluation. Since the thresholds are explicit free parameters, the paper should provide a sensitivity analysis showing how F1 and the number of detected wild vulnerabilities vary with different threshold values, and discuss how a user should choose thresholds for a new platform or database without access to the original benchmark.
minor comments (5)
  1. [Figure 2 caption] The caption contains a typo: 'libjepg-turbo' should be 'libjpeg-turbo'.
  2. [Appendix references] The text in Sections IV-A-3 and V-B-1 refers to 'Appendix ??' twice, but the appendix is not numbered or linked in the manuscript. The references should be resolved before publication.
  3. [Section IV-A-3] The notation for the LLM is inconsistent: the text says 'GPT4.0' in one place and 'GPT-4.0' elsewhere. This should be unified.
  4. [Section IV-B-1] When multiple TPL versions have the same number of similar function pairs, the paper states that VULTURE 'randomly selects one version.' This may make results non-reproducible; a deterministic tie-breaking rule (e.g., choose the most recent version or the one with the earliest birth time) would be preferable.
  5. [Table VIII] The table reports a dash for V1SCAN's 1-day detection on Tasmota, while Section V-D-3 explains that V1SCAN timed out. The dash should be labeled as 'timeout' or 'no result' to avoid ambiguity.

Circularity Check

1 steps flagged · score 5.0 of 10

The reported 95.8% F1 is computed with thresholds tuned on the same manually labeled benchmark, making the headline accuracy partly in-sample; the claim is not a logical tautology, but it is not externally anchored.

  1. fitted input called prediction [Section V-A (Experiment Setup) and Section V-C (Benchmark Vulnerability Detection)]
    "For similarity comparison, we set THhash = 30 and THsim = 10% after manual testing to achieve optimal detection results. ... Overall, V ULTURE achieved a 95.8% F1 score, significantly outperforming V1SCAN, which achieved only a 66.7% F1 score."

    The detection thresholds THhash and THsim are selected 'after manual testing' on the same 200-case benchmark that is later used to report the headline F1. These thresholds determine whether a function pair is considered similar and whether a TPL is treated as reused, so the benchmark detection outcomes are partly produced by parameters fitted to that benchmark. No held-out set or cross-validation is reported for the vulnerability detection benchmark, in contrast to the 5-fold group validation used for patch mapping in Section V-B-2. The 95.8% versus 66.7% advantage is therefore an in-sample performance estimate, not an out-of-sample prediction.

full rationale

The main circularity concern is concentrated in the vulnerability detection evaluation. The paper tunes THhash=30 and THsim=10% on the manually constructed 200-case benchmark and then reports F1 on that same benchmark, so the headline accuracy is partly a fitted result rather than a prediction. This fits the 'fitted input called prediction' pattern: the thresholds are parameters fitted to the evaluation data, and the reported F1 is the closely related quantity being claimed as a result. The ground-truth labels were also produced manually by the authors, and the detection outcomes were manually confirmed by the same group, which further reduces external anchoring. However, the tool's outputs are not literally derived from the labels by construction: the hashing, chunk extraction, and patch-mapping logic are independent algorithms applied to code, so this is not a full logical tautology. The patch-mapping evaluation does use 5-fold group validation and compares against VFCFinder with an external commit benchmark, which is independent content. No load-bearing self-citation or imported-uniqueness circularity was found. The appropriate score is moderate: the central accuracy claim is partially in-sample, but the system has independent algorithmic content and some separately validated components.

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

The central claim rests on several free parameters tuned on the evaluation data, a manually labeled benchmark, and domain assumptions about TLSH similarity, diff-based patch semantics, LLM reliability, git birth times, and NVD data quality. The chunk abstraction is an internal analysis mechanism without independent falsifiable support. These items together mean the reported performance is not grounded in an external, author-independent standard.

free parameters (6)
  • THhash = 30
    TLSH similarity threshold for function matching; set after manual testing to achieve optimal detection results (Section V-A).
  • THsim = 10%
    Similarity ratio threshold for confirming TPL reuse; set after manual testing (Section V-A).
  • k (commit slice size) = 20
    Number of commits per slice in slice-based commit filtering (Section IV-A3, Section V-A).
  • Keyword list for TPL selection = not enumerated
    Manually created keyword list used to filter platform-specific TPLs from GitHub repositories (Section IV-A1).
  • 40 regular expressions for chunk extraction = not listed
    Manually predefined regexes covering statement types for variable and operation extraction (Section IV-C2).
  • Ground-truth labels (200 cases) = 200 vulnerable function reuses
    Manually constructed by the authors; this is the benchmark against which F1 is measured (Section V-C).
assumptions (5)
  • domain assumption TLSH similarity scores remain meaningful after custom code modifications and can identify reused functions.
    Used throughout TPL reuse identification (Section IV-B1). No evidence is provided that TLSH behaves correctly for the modification regimes tested.
  • domain assumption The diff between vulnerable and patched versions fully captures vulnerability-relevant changes, and patch presence can be determined by line/operation matching without compilation.
    Core of chunk-based analysis (Section IV-C2). The paper itself notes dataflow restrictions and information loss in the Limitations section.
  • domain assumption LLM (GPT-3.5 and GPT-4.0) outputs correctly identify vulnerable elements and confirm patch commits.
    Used in LLM-based description parsing and patch commit mapping (Section IV-A). The paper acknowledges dependence on LLM performance and recommends manual verification.
  • domain assumption Birth time from git history identifies the original source function and can resolve TPL inheritance.
    Used in identification optimization (Section IV-B2). This idea is borrowed from prior work such as TPLite.
  • domain assumption NVD CPE and CVE descriptions are sufficiently accurate for determining vulnerable versions and patch time ranges.
    Used to build the vulnerability segment (Section IV-A3). The paper cites CPE errors in [24] and notes some reports are informal.
invented entities (1)
  • code chunk (analysis abstraction)
    purpose: Groups patch lines by control structure and shared variables to decide whether a custom-modified function still contains the vulnerable behavior.
    New abstraction introduced by this paper. It is an analysis structure, not a physical entity, and carries no externally falsifiable prediction.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Enhancing Security in Third-Party Library Reuse -- Comprehensive Detection of 1-day Vulnerability through Code Patch Analysis." pith.science (2026). https://pith.science/paper/4HG4BB4U

@misc{pith2026241119648,
  author       = {Pith},
  title        = {Pith review of: Enhancing Security in Third-Party Library Reuse -- Comprehensive Detection of 1-day Vulnerability through Code Patch Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4HG4BB4U}},
  note         = {Machine review of arXiv:2411.19648}
}
read the original abstract

Nowadays, software development progresses rapidly to incorporate new features. To facilitate such growth and provide convenience for developers when creating and updating software, reusing open-source software (i.e., thirdparty library reuses) has become one of the most effective and efficient methods. Unfortunately, the practice of reusing third-party libraries (TPLs) can also introduce vulnerabilities (known as 1-day vulnerabilities) because of the low maintenance of TPLs, resulting in many vulnerable versions remaining in use. If the software incorporating these TPLs fails to detect the introduced vulnerabilities and leads to delayed updates, it will exacerbate the security risks. However, the complicated code dependencies and flexibility of TPL reuses make the detection of 1-day vulnerability a challenging task. To support developers in securely reusing TPLs during software development, we design and implement VULTURE, an effective and efficient detection tool, aiming at identifying 1-day vulnerabilities that arise from the reuse of vulnerable TPLs. It first executes a database creation method, TPLFILTER, which leverages the Large Language Model (LLM) to automatically build a unique database for the targeted platform. Instead of relying on code-level similarity comparison, VULTURE employs hashing-based comparison to explore the dependencies among the collected TPLs and identify the similarities between the TPLs and the target projects. Recognizing that developers have the flexibility to reuse TPLs exactly or in a custom manner, VULTURE separately conducts version-based comparison and chunk-based analysis to capture fine-grained semantic features at the function levels. We applied VULTURE to 10 real-world projects to assess its effectiveness and efficiency in detecting 1-day vulnerabilities. VULTURE successfully identified 175 vulnerabilities from 178 reused TPLs.

Figures

Figures reproduced from arXiv: 2411.19648 by the authors.

Figure 1
Figure 1. Example of zlib Maintenance and Reuse • Comprehensive: TPLs that are commonly invoked within the targeted platform must be included. • Specific: Different platforms may have unique libraries that cannot be used by the other platforms. To avoid false alarms, libraries specific to other platforms, unnecessary for the targeted platform, or projects not used as libraries must be excluded during the detection process. • … view at source ↗
Figure 2
Figure 2. ReactOS patching of CVE-2018-14498 and CVE-2017-14032. Due to custom reuse, the ReactOS patch differs from the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Workflow of VULTURE start and end versions that fall within the specific vulnerable version interval. Unfortunately, we inspected that some vulnerability reports are informally written, thus these vulnerabilities might be over￾looked by keyword searches and CPE matching. To address such issues, VULTURE extracts additional vulnerability reports from public databases including SNYK [12] and the official websites of TP… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Chunk extraction and match one the right side). This scenario of custom patch may lead to false positives in other systems like V1SCAN, but VULTURE can accurately identify the patch. After processing all potential vulnerabilities for the tar￾get program through version…
Figure 5
Figure 5. Figure 5: Correlation between the number of candidate commits [PITH_FULL_IMAGE:figures/full_fig_p011_5.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. Revisiting Third-Party Library Detection: A Ground Truth Dataset and Its Implications Across Security Tasks

    cs.CR 2025-09 conditional novelty 6.0 of 10

    A new 6,055-app Android benchmark with version-level third-party library labels shows ten existing detection tools top out at 60% F1, with many far lower, exposing R8-era fragility and weak version resolution.

Reference graph

Works this paper leans on

64 extracted references · 61 canonical work pages · cited by 1 Pith paper

  1. [1]

    awesome-android-libraries,

    “awesome-android-libraries,” accessed: 2024-06-03. [Online]. Avail- able: https://github.com/wasabeef/awesome-android-libraries

    work page 2024

  2. [2]

    Cocoamqtt,

    “Cocoamqtt,” accessed: 2024-06-03. [Online]. Available: https://github. com/emqx/CocoaMQTT

    work page 2024

  3. [3]

    coremqtt,

    “coremqtt,” accessed: 2024-06-03. [Online]. Avail- able: https://freertos.org/Documentation/api-ref/coreMQTT/docs/ doxygen/output/html/index.html

    work page 2024

  4. [4]

    curl cve doc,

    “curl cve doc,” accessed: 2024-06-03. [Online]. Available: https: //curl.se/docs/security.html

    work page 2024

  5. [5]

    [Online]

    “Cve,” accessed: 2024-06-03. [Online]. Available: https://cve.mitre.org/

    work page 2024

  6. [6]

    Cve-2024-2398,

    “Cve-2024-2398,” accessed: 2024-06-03. [Online]. Available: https: //nvd.nist.gov/vuln/detail/CVE-2024-2398

    work page 2024

  7. [7]

    ffmpeg security,

    “ffmpeg security,” accessed: 2024-06-03. [Online]. Available: https: //ffmpeg.org/security.html

    work page 2024

  8. [8]

    [Online]

    “Nvd,” accessed: 2024-06-03. [Online]. Available: https://www.nist.gov/

    work page 2024

Show all 64 references
  1. [9]

    openwrt,

    “openwrt,” accessed: 2024-06-03. [Online]. Available: https://openwrt. org/packages/index/libraries

    2024

  2. [10]

    paho.mqtt.android

    “paho.mqtt.android.” [Online]. Available: https://github.com/eclipse/ paho.mqtt.android

  3. [11]

    paho.mqtt.embedded-c,

    “paho.mqtt.embedded-c,” accessed: 2024-06-03. [Online]. Available: https://github.com/eclipse/paho.mqtt.embedded-c

    2024

  4. [12]

    Snyk vulnerability database,

    “Snyk vulnerability database,” accessed: 2024-06-03. [Online]. Available: https://security.snyk.io/

    2024

  5. [13]

    Gpt-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al. , “Gpt-4 technical report,” arXiv preprint arXiv:2303.08774 , 2023

    2023 arXiv

  6. [14]

    Reliable third-party library detec- tion in android and its security applications,

    M. Backes, S. Bugiel, and E. Derr, “Reliable third-party library detec- tion in android and its security applications,” in Proceedings of the 23rd ACM SIGSAC conference on computer and communications security (CCS), 2016, pp. 356–367

    2016

  7. [15]

    Cvefixes: Automated col- lection of vulnerabilities and their fixes from open-source software,

    G. Bhandari, A. Naseer, and L. Moonen, “Cvefixes: Automated col- lection of vulnerabilities and their fixes from open-source software,” in Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE) , 2021, pp. 30–39

    2021

  8. [16]

    Holmes: Efficient distribution testing for secure collaborative learning,

    I. Chang, K. Sotiraki, W. Chen, M. Kantarcioglu, and R. Popa, “Holmes: Efficient distribution testing for secure collaborative learning,” in 32nd USENIX Security Symposium (USENIX Security 23) , 2023, pp. 4823– 4840

    2023

  9. [17]

    Xgboost: A scalable tree boosting system,

    T. Chen and C. Guestrin, “Xgboost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD) , 2016, pp. 785–794

    2016

  10. [18]

    Libvdiff: Library version difference guided oss version identification in binaries,

    C. Dong, S. Li, S. Yang, Y . Xiao, Y . Wang, H. Li, Z. Li, and L. Sun, “Libvdiff: Library version difference guided oss version identification in binaries,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE) , 2024, pp. 1–12

    2024

  11. [19]

    Identifying open- source license violation and 1-day security risk at large scale,

    R. Duan, A. Bijlani, M. Xu, T. Kim, and W. Lee, “Identifying open- source license violation and 1-day security risk at large scale,” in Proceedings of the 24th ACM SIGSAC Conference on computer and communications security (CCS) , 2017, pp. 2169–2185

    2017

  12. [20]

    Vfcfinder: Pairing security advisories and patches,

    T. Dunlap, E. Lin, W. Enck, and B. Reaves, “Vfcfinder: Pairing security advisories and patches,” in Proceedings of the ACM 19th ASIA Conference on Computer and Communications Security (AsiaCCS) , 2024

    2024

  13. [21]

    State of dependency management,

    Endor Labs, “State of dependency management,” 2023, accessed: 2024-07-09. [Online]. Available: https://www.endorlabs.com/learn/ state-of-dependency-management

    2023

  14. [22]

    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 et al., “Codebert: A pre-trained model for programming and natural languages,” in Findings of the ACL Conference on Empirical Methods in Natural Language Processing (EMNLP) , 2020, pp. 1536– 1547

    2020

  15. [23]

    ilibscope: Reliable third-party library detection for ios mobile apps,

    J. Guo, M. Zheng, Y . Zhou, H. Wang, L. Wu, X. Luo, and K. Ren, “ilibscope: Reliable third-party library detection for ios mobile apps,” arXiv preprint arXiv:2207.01837 , 2022

    2022 arXiv

  16. [24]

    Automatically identifying cve affected versions with patches and devel- oper logs,

    Y . He, Y . Wang, S. Zhu, W. Wang, Y . Zhang, Q. Li, and A. Yu, “Automatically identifying cve affected versions with patches and devel- oper logs,” IEEE Transactions on Dependable and Secure Computing , vol. 21, no. 2, pp. 905–919, 2024

    2024

  17. [25]

    A survey on locality sensitive hashing algorithms and their applications,

    O. Jafari, P. Maurya, P. Nagarkar, K. M. Islam, and C. Crushev, “A survey on locality sensitive hashing algorithms and their applications,” arXiv preprint arXiv:2102.08942 , 2021

    2021 arXiv

  18. [26]

    Redebug: Finding unpatched code clones in entire os distributions,

    J. Jang, A. Agrawal, and D. Brumley, “Redebug: Finding unpatched code clones in entire os distributions,” in IEEE 33rd Symposium on Security and Privacy (S&P) , 2012, pp. 48–62

    2012

  19. [27]

    Third-party library dependency for large-scale sca in the c/c++ ecosystem: How far are we?

    L. Jiang, H. Yuan, Q. Tang, S. Nie, S. Wu, and Y . Zhang, “Third-party library dependency for large-scale sca in the c/c++ ecosystem: How far are we?” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA) , 2023, pp. 1383– 1395

    2023

  20. [28]

    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 IEEE 38th Symposium on Security and Privacy (S&P) , 2017, pp. 595–614

    2017

  21. [29]

    Gradient-based learning applied to document recognition,

    Y . LeCun, L. Bottou, Y . Bengio, and P. Haffner, “Gradient-based learning applied to document recognition,” Proceedings of the IEEE , vol. 86, no. 11, pp. 2278–2324, 1998

    1998

  22. [30]

    Libd: Scalable and precise third-party library detection in android markets,

    M. Li, W. Wang, P. Wang, S. Wang, D. Wu, J. Liu, R. Xue, and W. Huo, “Libd: Scalable and precise third-party library detection in android markets,” in IEEE/ACM 39th International Conference on Software Engineering (ICSE), 2017, pp. 335–346

    2017

  23. [31]

    Libam: An area matching framework for de- tecting third-party libraries in binaries,

    S. Li, Y . Wang, C. Dong, S. Yang, H. Li, H. Sun, Z. Lang, Z. Chen, W. Wang, H. Zhu et al., “Libam: An area matching framework for de- tecting third-party libraries in binaries,” ACM Transactions on Software Engineering and Methodology , vol. 33, no. 2, pp. 1–35, 2023

    2023

  24. [32]

    D ´ej`avu: A map of code duplicates on github,

    C. V . Lopes, P. Maj, P. Martins, V . Saini, D. Yang, J. Zitny, H. Sajnani, and J. Vitek, “D ´ej`avu: A map of code duplicates on github,” in Proceedings of the ACM on Programming Languages (OOPSLA), vol. 1, 2017, pp. 1–28

    2017

  25. [33]

    Libradar: Fast and accurate detection of third-party libraries in android apps,

    Z. Ma, H. Wang, Y . Guo, and X. Chen, “Libradar: Fast and accurate detection of third-party libraries in android apps,” in Proceedings of the 38th International Conference on Software Engineering Companion (ICSE-Companion), 2016, pp. 653–656

    2016

  26. [34]

    Using of jaccard coefficient for keywords similarity,

    S. Niwattanakul, J. Singthongchai, E. Naenudorn, and S. Wanapu, “Using of jaccard coefficient for keywords similarity,” inProceedings of the International Multiconference of Engineers and Computer Scientists (IMECS), vol. 1, no. 6, 2013, pp. 380–384

    2013

  27. [35]

    MOVEit Transfer Critical Vulnerability CVE-2023-35036,

    Progress, “MOVEit Transfer Critical Vulnerability CVE-2023-35036,” 2023, accessed: 2024-07-09. [Online]. Available: https://community.progress.com/s/article/ MOVEit-Transfer-Critical-Vulnerability-CVE-2023-35036-June-9-2023

    2023

  28. [36]

    Known vulnerabilities of open source projects: Where are the fixes?

    A. Sabetta, S. E. Ponta, R. C. Lozoya, M. Bezzi, T. Sacchetti, M. Greco, G. Balogh, P. Heged ˝us, R. Ferenc, R. Paramitha et al. , “Known vulnerabilities of open source projects: Where are the fixes?” IEEE Security & Privacy , 2024

    2024

  29. [37]

    Sourcerercc: Scaling code clone detection to big-code,

    H. Sajnani, V . Saini, J. Svajlenko, C. K. Roy, and C. V . Lopes, “Sourcerercc: Scaling code clone detection to big-code,” in Proceedings of the 38th International Conference on Software Engineering (ICSE) , 2016, pp. 1157–1168

    2016

  30. [38]

    Patchmatch: A tool for locating patches of open source project vulnerabilities,

    K. Shen, Y . Zhang, L. Bao, Z. Wan, Z. Li, and M. Wu, “Patchmatch: A tool for locating patches of open source project vulnerabilities,” in IEEE/ACM 45th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion) , 2023, pp. 175–179

    2023

  31. [39]

    Recurscan: Detecting recurring vulnerabilities in php web applications,

    Y . Shi, Y . Zhang, T. Bai, L. Zhang, X. Tan, and M. Yang, “Recurscan: Detecting recurring vulnerabilities in php web applications,” in Pro- ceedings of the ACM on Web Conference 2024 , 2024, pp. 1746–1755

    2024

  32. [40]

    Uncovering cwe- 15 cve-cpe relations with threat knowledge graphs,

    Z. Shi, N. Matyunin, K. Graffi, and D. Starobinski, “Uncovering cwe- 15 cve-cpe relations with threat knowledge graphs,” ACM Transactions on Privacy and Security , vol. 27, no. 1, pp. 1–26, 2024

    2024

  33. [41]

    Locating the security patches for disclosed oss vulnerabilities with vulnerability- commit correlation ranking,

    X. Tan, Y . Zhang, C. Mi, J. Cao, K. Sun, Y . Lin, and M. Yang, “Locating the security patches for disclosed oss vulnerabilities with vulnerability- commit correlation ranking,” in Proceedings of the 28th ACM SIGSAC Conference on Computer and Communications Security (CCS) , 20...

    2021

  34. [42]

    Bcfinder: A lightweight and platform- independent tool to find third-party components in binaries,

    W. Tang, D. Chen, and P. Luo, “Bcfinder: A lightweight and platform- independent tool to find third-party components in binaries,” in 25th Asia-Pacific Software Engineering Conference (APSEC) . IEEE, 2018, pp. 288–297

    2018

  35. [43]

    Towards understanding third-party library dependency in c/c++ ecosys- tem,

    W. Tang, Z. Xu, C. Liu, J. Wu, S. Yang, Y . Li, P. Luo, and Y . Liu, “Towards understanding third-party library dependency in c/c++ ecosys- tem,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE) , 2022, pp. 1–12

    2022

  36. [44]

    Ccaligner: A token based large-gap clone detector,

    P. Wang, J. Svajlenko, Y . Wu, Y . Xu, and C. K. Roy, “Ccaligner: A token based large-gap clone detector,” inProceedings of the 40th International Conference on Software Engineering (ICSE) , 2018, pp. 1066–1077

    2018

  37. [45]

    Vcmatch: A ranking- based approach for automatic security patches localization for oss vulnerabilities,

    S. Wang, Y . Zhang, L. Bao, X. Xia, and M. Wu, “Vcmatch: A ranking- based approach for automatic security patches localization for oss vulnerabilities,” in IEEE 29th International Conference on Software Analysis, Evolution and Reengineering (SANER) , 2022, pp. 589–600

    2022

  38. [46]

    V1scan: Discovering 1-day vulnerabilities in reused c/c++ open-source software components using code classification techniques,

    S. Woo, E. Choi, H. Lee, and H. Oh, “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) , 2023, pp. 6541–6556

    2023

  39. [47]

    Movery: A precise approach for modified vulnerable code clone discovery from modified open-source software components,

    S. Woo, H. Hong, E. Choi, and H. Lee, “Movery: A precise approach for modified vulnerable code clone discovery from modified open-source software components,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 3037–3053

    2022

  40. [48]

    Centris: A precise and scalable approach for identifying modified open-source software reuse,

    S. Woo, S. Park, S. Kim, H. Lee, and H. Oh, “Centris: A precise and scalable approach for identifying modified open-source software reuse,” in IEEE/ACM 43rd International Conference on Software Engineering (ICSE), 2021, pp. 860–872

    2021

  41. [49]

    Ossfp: Precise and scalable c/c++ third-party library de- tection using fingerprinting functions,

    J. Wu, Z. Xu, W. Tang, L. Zhang, Y . Wu, C. Liu, K. Sun, L. Zhao, and Y . Liu, “Ossfp: Precise and scalable c/c++ third-party library de- tection using fingerprinting functions,” in IEEE/ACM 45th International Conference on Software Engineering (ICSE) , 2023, pp. 270–282

    2023

  42. [50]

    Libscan: Towards more precise third-party library identification for android applications,

    Y . Wu, C. Sun, D. Zeng, G. Tan, S. Ma, and P. Wang, “Libscan: Towards more precise third-party library identification for android applications,” in 32nd USENIX Security Symposium (USENIX Security 23) , 2023, pp. 3385–3402

    2023

  43. [51]

    MVP: Detecting vulnerabilities using Patch-Enhanced vulnerability signatures,

    Y . Xiao, B. Chen, C. Yu, Z. Xu, Z. Yuan, F. Li, B. Liu, Y . Liu, W. Huo, W. Zou, and W. Shi, “MVP: Detecting vulnerabilities using Patch-Enhanced vulnerability signatures,” in 29th USENIX Security Symposium (USENIX Security 20) , 2020, pp. 1165–1182

    2020

  44. [52]

    Tracking patches for open source software vvlnerabilities,

    C. Xu, B. Chen, C. Lu, K. Huang, X. Peng, and Y . Liu, “Tracking patches for open source software vvlnerabilities,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) , 2022, pp. 860–871

    2022

  45. [53]

    Neural network- based graph embedding for cross-platform binary code similarity detec- tion,

    X. Xu, C. Liu, Q. Feng, H. Yin, L. Song, and D. Song, “Neural network- based graph embedding for cross-platform binary code similarity detec- tion,” in Proceedings of the 24th ACM SIGSAC Conference on Computer and Communications Security (CCS) , 2017, pp. 363–376

    2017

  46. [54]

    A survey of third- party library security research in application software,

    J. Zeng, D. Han, Y . Zhu, Y . Wang, and F. Weng, “A survey of third- party library security research in application software,” arXiv preprint arXiv:2404.17955, 2024

    2024 arXiv

  47. [55]

    Atvhunter: Reliable version detection of third-party libraries for vulnerability identification in android applications,

    X. Zhan, L. Fan, S. Chen, F. We, T. Liu, X. Luo, and Y . Liu, “Atvhunter: Reliable version detection of third-party libraries for vulnerability identification in android applications,” in IEEE/ACM 43rd International Conference on Software Engineering (ICSE) , 2021, pp. 1695–1707

    2021

  48. [56]

    Automated third-party library detection for android ap- plications: Are we there yet?

    X. Zhan, L. Fan, T. Liu, S. Chen, L. Li, H. Wang, Y . Xu, X. Luo, and Y . Liu, “Automated third-party library detection for android ap- plications: Are we there yet?” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (ASE) , 2020, p...

    2020

  49. [57]

    Precise and accurate patch presence test for binaries,

    H. Zhang and Z. Qian, “Precise and accurate patch presence test for binaries,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 887–902

    2018

  50. [58]

    A large-scale empirical analysis of the vul- nerabilities introduced by third-party components in iot firmware,

    B. Zhao, S. Ji, J. Xu, Y . Tian, Q. Wei, Q. Wang, C. Lyu, X. Zhang, C. Lin, J. Wu et al. , “A large-scale empirical analysis of the vul- nerabilities introduced by third-party components in iot firmware,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Softwa...

    2022

  51. [59]

    One bad apple spoils the barrel: Understanding the security risks introduced by third-party components in iot firmware,

    B. Zhao, S. Ji, J. Xu, Y . Tian, Q. Wei, Q. Wang, C. Lyu, X. Zhang, C. Lin, J. Wu et al. , “One bad apple spoils the barrel: Understanding the security risks introduced by third-party components in iot firmware,” IEEE Transactions on Dependable and Secure Computing , 2023

    2023

  52. [60]

    Uvscan: Detecting third-party component usage violations in iot firmware,

    B. Zhao, S. Ji, X. Zhang, Y . Tian, Q. Wang, Y . Pu, C. Lyu, and R. Beyah, “Uvscan: Detecting third-party component usage violations in iot firmware,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 3421–3438. APPENDIX A. Appendix A In this section, we presen...

    2023

  53. [61]

    VULTURE analyzes the CVE description to parse vulnera- ble elements

    LLM-based description parsing. VULTURE analyzes the CVE description to parse vulnera- ble elements. The parsing results are as follows: • File: packet-assa r3.c • Function: dissect r3 upstreamcommand queryconfig • Variable: None

  54. [62]

    First, V ULTURE performs date-specific commit slicing to pinpoint the date range which contains the patch commit

    Slice-based commit filtering. First, V ULTURE performs date-specific commit slicing to pinpoint the date range which contains the patch commit. According to CVE/NVD, ”wireshark-1.8.7” is the last vul- nerable version and ”wireshark-1.8.8” is the fixed version, narrowing the ti...

    2013

  55. [63]

    VULTURE sequentially analyzes the 20 commits within the candidate slice, selecting the commit that genuinely modifies the vulnerable elements as the candidate commit

    Candidate commit selection. VULTURE sequentially analyzes the 20 commits within the candidate slice, selecting the commit that genuinely modifies the vulnerable elements as the candidate commit. Only the commit with the hash 779d28d39039ada8970c910d8350fc2eb05cf00a is identifi...

  56. [64]

    LLM-based patch commit mapping. 16 By combining the CVE description with the candi- date commit, V ULTURE employs feature engineering to in- voke an LLM (GPT-4.0) for analyzing whether the can- didate commit serves as the patch for the vulnerabil- ity. Finally, V ULTURE succes...

    2013

Pith tools

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