Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

A disclosed exploit, run unchanged against a library's version history, triggers the vulnerability on 83.0% of affected versions at 99.3% precision, contradicting the claim that exploits are version-specific.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-02 17:18 UTC pith:OJGZ6XUG

load-bearing objection Large empirical study that mostly disproves the 'exploits are version-specific' assumption; the dataset alone justifies a serious look, despite a manually built ground truth that needs an independent audit. the 4 major comments →

arxiv 2603.25997 v2 pith:OJGZ6XUG submitted 2026-03-27 cs.SE cs.CR

Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits

Zirui Chen , Qi Zhan , Jiayuan Zhou , Xing Hu , Xin Xia , Xiaohu Yang This is my paper
classification cs.SE cs.CR
keywords supply chain securityJava librariesvulnerability exploitsaffected version identificationcross-version applicabilityexploit migrationempirical software engineeringvulnerability databases
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper challenges the widely repeated claim that vulnerability exploits only work on the exact version they were written for. By executing 259 disclosed exploits against 28,150 historical versions of 128 Java libraries and comparing results to a manually verified affected-version list, the authors find that unmodified exploits identify 83.0% of affected versions (11,931 of 14,378) with 99.3% precision, outperforming most major vulnerability databases. When they manually adapt the exploits that failed, recall rises to 96.1%, and they condense those adaptations into ten reusable migration strategies. A sympathetic reader cares because exploit execution could serve as a concrete, low-false-positive complement to metadata-based vulnerable-version databases and static analysis tools.

Core claim

The central claim, on the paper's own terms, is that disclosed Java library vulnerability exploits exhibit high cross-version applicability: executing an exploit with only the library version switched reproduces the vulnerable behavior on 83.0% of truly affected versions, with a false-positive rate low enough to put it ahead of most vulnerability databases and comparable in recall to the strongest static-analysis approach while being far more precise. The paper further claims that most of the remaining failures are mechanical—breaking changes during library evolution, such as renamed methods and missing classes, and environmental mismatches such as JDK versions—and that adapting exploits usi

What carries the argument

The load-bearing mechanism is a three-stage execution-and-alignment pipeline. It starts with a set of 259 reproduced exploits, then builds a manually verified list of 14,378 affected versions by tracing the commit that patched each vulnerability back to the commit that introduced it and inspecting actual release artifacts, and finally executes every exploit across all historical versions with only the library version changed. The behavior outcomes are aligned against the manual list and categorized as aligned, build failure, exploit failure, or unexpected behavior. The migration step compares failing versions with nearby working versions using source diffs, yielding a taxonomy of ten adaptat

Load-bearing premise

The one premise the whole study leans on is that the manually built ground-truth list of 14,378 affected versions is correct: if even a few percent of those labels are wrong—versions marked vulnerable that are actually patched, or patched versions marked vulnerable—the 83% recall and 99.3% precision numbers move by the same few percent, and the comparisons with databases and tools shift.

What would settle it

Re-run the experiment on an independently constructed ground truth: take a random sample of 200 of the 14,378 affected-version labels, download the exact release artifact, and run the disclosed exploit under the paper's stated environment. If the exploit fails on many labels that were supposed to be confirmed vulnerable, or if a fresh audit of the fixing commit shows the fix was present earlier than annotated, the reported recall is inflated. The most decisive single check is whether the 796 versions the authors report as newly confirmed actually exhibit the vulnerable code path when opened.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Vulnerability databases can treat disclosed exploits as a validation tool: in this study, exploit execution identified 796 affected versions that were missing from a widely used affected-version dictionary and confirmed by the dictionary's maintainers.
  • Developers and scanners should not rely on a single metadata source; even the best database evaluated still missed over a thousand versions that exploits found, and exploits in turn miss versions that databases list.
  • Because exploit execution achieves 99.3% precision, it can cut the manual verification burden for reported affected versions.
  • Diff-guided migration resolves most failures (77.1%), suggesting that automated exploit migration is achievable by combining code-change analysis with environment adjustment.
  • Exploit-based assessment has a ceiling: after migration, 562 affected versions remain unreachable, so it supplements—not replaces—existing databases and tools.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Inference: If these Java results generalize, exploit-driven version assessment could be exported to other package ecosystems with similar release semantics; the paper's data is Java-only, so this remains a hypothesis.
  • Inference: The finding that most false negatives are mechanical suggests a practical product architecture: a continuously running regression that smoke-tests each new library release against known exploits, catching reintroduced vulnerable behavior before advisory lists update.
  • Inference: The 562 unmigratable cases—fuzzing-generated payloads and semantic logic changes—mark the research frontier; solving those is less about API renames and more about understanding intended behavior, which may require semantic program analysis or large-language-model reasoning.
  • Inference: From a security-tool user's standpoint, a failed exploit should be treated as "no evidence of exploitability," not "safe," because the false-negative rate is roughly 17% even before considering environment differences.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents the first large-scale empirical study of whether disclosed Java library vulnerability exploits can be applied across library versions. The authors construct a dataset of 259 exploits covering 128 libraries and 28,150 versions, manually annotate 14,378 affected versions, and execute each exploit against the version history. They report that unmodified exploits achieve 83.0% recall and 99.3% precision in identifying affected versions (Finding 1), outperforming most vulnerability databases and static analysis tools. They then analyze failures, propose ten manual migration strategies, and claim that migration raises recall to 96.1% (Finding 4). The paper also contributes 796 confirmed CPE-version omissions. The central claim is that the widely held 'exploits are version-specific' limitation is not valid at scale.

Significance. If the central measurement is trustworthy, the paper makes a substantial contribution: it overturns a frequent assumption about exploit version-specificity, provides the largest reproducible Java-library exploit dataset to date, and offers an externally verified contribution to CPE (796 versions). The strong points are the machine-executed cross-version reproduction protocol, the comparison against five databases, and the concrete external confirmation from the CPE Team. The main weaknesses concern the validity of the manually constructed ground truth, the reuse rather than execution of Vision/V-SZZ in the tool comparison, and several inconsistencies in the reported counts. Overall, the paper is practically relevant and the empirical design is mostly sound, but the headline numbers rest on a ground-truth construction that has not been independently audited.

major comments (4)
  1. [Section 2.2 and Section 4.2] The manual ground truth is the sole yardstick for all RQ1 metrics. Cohen's Kappa of 0.911 measures inter-rater reliability, not correctness. Stage 2 (inducing-commit tracing through refactorings and renames) and Stage 3 (judging whether each release artifact 'explicitly preserves the vulnerable logic') are both error-prone; a single wrong inducing commit can shift labels for all earlier versions of a library. Moreover, the constructed exploits in Section 2.1.2 are derived from patch tests, and the ground truth is derived from the same fix commits, so the exploit outcomes and the labels are not fully independent. The 796 CPE validations cover only 13 CVEs and confirm omissions relative to NVD, not the full 14,378-version annotation. Please provide an independent accuracy audit, e.g., an external expert review of a random sample, a second independent labeling method on a subset, or a sensi
  2. [Section 5.2 vs. Section 2.3 / Figure 2] The affected-version failure counts are internally inconsistent. Section 2.3 and Figure 2 state that the 2,447 affected versions on which exploits fail consist of 1,769 build failures and 678 reproduction failures. Section 5.2 and Sections 5.3-5.4 instead state 1,775 build-failure cases and 672 exploit-failure cases. Both pairs sum to 2,447, but the individual categories feed the root-cause percentages (e.g., 89.8% library compatibility, 27.5% exploit failure) and the migration-success rates in RQ3. The discrepancy must be reconciled, and the actual counts used for each percentage should be made explicit.
  3. [Section 4.1.2 and Table 2] The claimed comparison with state-of-the-art tools does not actually run Vision or V-SZZ. The paper reuses results from Vision's replication package on a 95-CVE overlap subset, while acknowledging the package is hard-coded for C/C++ projects. The overlap subset may be non-representative: it is filtered by the availability of Vision's published outputs and by dataset intersection. This weakens Finding 2 and the broader claim that exploits 'outperform most... assessment tools.' Please either execute Vision/V-SZZ on the same 28,150-version universe as the exploits, or explicitly restrict the conclusion to a preliminary comparison and provide evidence (CWE distribution, library categories, version counts) that the 95-CVE subset is representative.
  4. [Section 4.2, precision paragraph] The headline precision statistic is inconsistently reported. Table 1 reports 99.3% precision with 89 false positives; the text says 'Among the 12,018 versions identified as vulnerable, exploits incurred only 89 false positives, achieving a precision of 99.4%.' Given 11,931 true positives + 89 false positives = 12,020, the correct denominator yields 99.3%, not 99.4%, and the number 12,018 is unexplained. Since precision and recall are the paper's central quantitative claims, these numbers must be reconciled.
minor comments (5)
  1. [Title] The arXiv metadata title ('Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits') differs from the title on the first page ('A Large-scale Empirical Study on the Generalizability of Disclosed Java Library Vulnerability Exploits'). Use one consistent title.
  2. [References] Reference [13] refers to 'CVE-2020-2461' while the text in Section 4.2 discusses 'CVE-2020-24616'; fix the inconsistency.
  3. [Figure 2] The legend 'NotIntroduced Fixed/DisclosedVulnerable' is difficult to parse. Clarify the distinction between 'not introduced' and 'fixed/disclosed' and define the columns in the caption or text.
  4. [Section 5.1.2] The cross-review step does not report agreement counts or a Kappa for the random 20-sample validation. Please report how many labels were confirmed and how many required discussion.
  5. [Table 1] The rows 'Exploit Unique' and 'Source Unique' are not defined in the table caption or in the surrounding text. Define what 'unique' means relative to the compared data source.

Circularity Check

0 steps flagged

No circular derivation: exploit outcomes are measured against an independently constructed ground truth; only minor non-load-bearing self-citations appear.

full rationale

The paper's central result is an empirical measurement: 259 exploits are executed against 28,150 historical versions and the outcomes are compared with a manually constructed ground-truth of 14,378 affected versions (Sections 2.2 and 2.3). The ground truth is built by tracing fixing commits and vulnerability-inducing commits and by manually inspecting release artifacts for the presence of vulnerable logic; exploit execution is performed independently by switching only the library version and observing runtime behavior. No equation, definition, or fitting step makes the reported recall/precision equal to the ground truth by construction. The 96.1% post-migration recall is a post-hoc outcome of manual migration performed on the 2,447 failed cases, not a prediction derived from the migration taxonomy, so it does not reduce to a fitted input. The paper does cite prior work by some of the same authors (e.g., refs. [2], [10], [23] for V-SZZ and previously collected exploits), but these citations supply concrete methods and artifacts that are re-executed or re-applied in this study; they are not invoked as an unverified authority or uniqueness theorem that forces the conclusion. The acknowledged threats in Section 7.2 concern generalizability, exploit reproducibility, and database drift, not a circular dependency between the evaluation and the annotated labels. Therefore no circular step is identified; at most there is minor self-citation that is not load-bearing.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 0 invented entities

No free parameters or invented entities; the paper is an empirical study. The listed axioms are domain assumptions about the validity of the ground truth, the interpretation of exploit execution, and the representativeness of the corpus.

axioms (3)
  • domain assumption The manually annotated affected-version ground truth is accurate.
    All metrics (recall/precision) are computed against this ground truth; Section 2.2 notes Kappa 0.911 but this measures inter-rater consistency, not ground-truth correctness.
  • domain assumption A successfully reproduced exploit indicates the version is vulnerable, and failure indicates invulnerability.
    Section 2.3 maps execution outcomes to vulnerability status; unexpected behaviors (e.g., assertions passing on patched versions) show this mapping is imperfect.
  • domain assumption The collected exploits are representative of Java library vulnerabilities.
    The corpus is limited to publicly available, reproducible exploits; Section 7.2 acknowledges threats to generalizability beyond the 61 CWEs covered.

pith-pipeline@v1.3.0-alltime-deepseek · 20091 in / 9396 out tokens · 86461 ms · 2026-08-02T17:18:22.093720+00:00 · methodology

0 comments
read the original abstract

Open-source software supply chain security relies heavily on assessing affected versions of library vulnerabilities. While prior studies have leveraged exploits for verifying vulnerability affected versions, they point out a key limitation that exploits are version-specific and cannot be directly applied across library versions. Despite being widely acknowledged, this limitation has not been systematically validated at scale, leaving the actual applicability of exploits across versions unexplored. To fill this gap, we conduct the first large-scale empirical study on exploit applicability across library versions. We construct a comprehensive dataset consisting of 259 exploits spanning 128 Java libraries and 28,150 historical versions, covering 61 CWEs that account for 76.33% of vulnerabilities in Maven. Leveraging this dataset, we execute each exploit against the library version history and compare the execution outcomes with our manually annotated ground-truth affected versions. We further investigate the root causes of inconsistencies between exploit execution and ground truth, and explore strategies for exploit migration. Our results (RQ1) show that, even without migration, exploits achieve 83.0% recall and 99.3% precision in identifying affected versions in Java, outperforming most widely used vulnerability databases and assessment tools. Notably, this capability enables us to contribute 796 confirmed missing affected versions to the CPE dictionary. We investigate the remaining exploit failures (RQ2) and find that they mainly stem from compatibility issues introduced by library evolution and changing environmental constraints. Based on these observations, we manually migrate exploits for 1,885 versions and distill a taxonomy of 10 strategies from these successful adaptation cases (RQ3), thereby increasing the overall recall to 96.1%.

Figures

Figures reproduced from arXiv: 2603.25997 by Jiayuan Zhou, Qi Zhan, Xiaohu Yang, Xing Hu, Xin Xia, Zirui Chen.

Figure 1
Figure 1. Figure 1: Overall framework of our study. 2.1 Exploit Collection We systematically collected disclosed exploits targeting the Java Maven ecosystem. Subsequently, we conducted a reproduction pro￾cess to validate the executability of each collected exploit. 2.1.1 Vulnerability Collection. Our study targets vulnerabilities in the Maven ecosystem, which hosts over 50 million packages. All vulnerabilities in Maven are fi… view at source ↗
Figure 2
Figure 2. Figure 2: Cross-version Execution Behavior of Exploits. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Reasons for Unexpected Behaviors. library versions and environment issues due to specific configura￾tions. The causes of Exploit Failure (672 versions) are grouped into three categories: flaws or incompleteness in the payload design that prevent reproduction, payload non-compliance with version￾specific input validations, and incompatibilities between the exploit verification logic and the runtime behavior… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 2 Pith papers

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

  1. Refploit: Facilitating Exploit Construction via Code-Agent Trajectory Repair

    cs.SE 2026-07 unverdicted novelty 6.0

    Refploit repairs code-agent trajectories for Java exploit reproduction via differential validation and focused recovery constraints, achieving 80.2% success on 172 references with 64.3% relative improvement.

  2. ATTAIN: Automated Exploit Failure Analysis through Trace-Driven Diff Analysis

    cs.SE 2026-06 unverdicted novelty 6.0

    ATTAIN is a three-module trace-driven framework that combines exploit execution, LLM-guided diff search, and evidence-based judgment to identify affected library versions for CVEs, reporting 93.24% F1 on 224 CVEs acro...

Reference graph

Works this paper leans on

57 extracted references · 1 canonical work pages · cited by 2 Pith papers

  1. [1]

    Afsah Anwar, Ahmed Abusnaina, Songqing Chen, Frank Li, and David Mohaisen

  2. [2]

    Hassan, and Xiaohu Yang

    Lingfeng Bao, Xin Xia, Ahmed E. Hassan, and Xiaohu Yang. 2022. V-SZZ: au- tomatic identification of version ranges affected by CVE vulnerabilities. InPro- ceedings of the 44th International Conference on Software Engineering(Pittsburgh, Pennsylvania)(ICSE ’22). Association for Computing Machinery, New York, NY, USA, 2352–2364. doi:10.1145/3510003.3510113

    arXiv 2022

  3. [3]

    Gabriele Bavota, Gerardo Canfora, Massimiliano Di Penta, Rocco Oliveto, and Sebastiano Panichella. 2015. How the apache community upgrades dependencies: an evolutionary study.Empirical Software Engineering20 (2015), 1275–1317

    2015

  4. [4]

    Darion Cassel, Nuno Sabino, Min-Chien Hsu, Ruben Martins, and Limin Jia. 2025. NODEMEDIC-FINE: Automatic Detection and Exploit Synthesis for Node. js Vulnerabilities. InProceedings of the 2025 Network and Distributed System Security Symposium (NDSS’25). doi, Vol. 10

    2025

  5. [5]

    Haipeng Chen, Rui Liu, Noseong Park, and VS Subrahmanian. 2019. Using twitter to predict when vulnerabilities will be exploited. InProceedings of the 25th ACM SIGKDD international conference on knowledge discovery & data Mining. 3143–3152

    2019

  6. [6]

    Tianyu Chen, Lin Li, Bingjie Shan, Guangtai Liang, Ding Li, Qianxiang Wang, and Tao Xie. 2025. Identifying Affected Third-Party Java Libraries from Textual Descriptions of Vulnerabilities and Libraries.ACM Transactions on Software Engineering and Methodology34, 4 (2025), 1–27

    2025

  7. [7]

    Xingchu Chen, Chengwei Liu, Jialun Cao, Yang Xiao, Xinyue Cai, Yeting Li, Jingyi Shi, Tianqi Sun, and Haiming Chen ang Wei Huo. 2025. Vulnerability- Affected Versions Identification: How Far Are We? arXiv:2509.03876 [cs.SE] https://arxiv.org/abs/2509.03876

    Pith/arXiv arXiv 2025

  8. [8]

    Yang Chen, Andrew E Santosa, Asankhaya Sharma, and David Lo. 2020. Auto- mated identification of libraries from vulnerability data. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engi- neering in Practice. 90–99

    2020

  9. [9]

    Zirui Chen, Xing Hu, Puhua Sun, Xin Xia, and Xiaohu Yang. 2025. Generating Mit- igations for Downstream Projects to Neutralize Upstream Library Vulnerability. arXiv:2503.24273 [cs.SE] https://arxiv.org/abs/2503.24273

    Pith/arXiv arXiv 2025

  10. [10]

    Z. Chen, X. Hu, X. Xia, Y. Gao, T. Xu, D. Lo, and X. Yang. 2024. Exploiting Library Vulnerability via Migration Based Automating Test Generation. In2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). IEEE Computer Society, Los Alamitos, CA, USA, 2820–2831. doi:10.1145/3597503.3639583

    arXiv 2024

  11. [11]

    Jacob Cohen. 1960. A coefficient of agreement for nominal scales.Educational and psychological measurement20, 1 (1960), 37–46

    1960

  12. [12]

    2014.Basics of qualitative research: Techniques and procedures for developing grounded theory

    Juliet Corbin and Anselm Strauss. 2014.Basics of qualitative research: Techniques and procedures for developing grounded theory. Sage publications

    2014

  13. [13]

    Cowtowncoder. [n. d.]. Fix Commit of CVE-2020-2461. https://github.com/ FasterXML/jackson-databind/commit/3d97153

    2020

  14. [14]

    Ali Babar, and M

    Roland Croft, M. Ali Babar, and M. Mehdi Kholoosi. 2023. Data Quality for Soft- ware Vulnerability Datasets. InProceedings of the 45th International Conference on Software Engineering(Melbourne, Victoria, Australia)(ICSE ’23). IEEE Press, 121–133. doi:10.1109/ICSE48619.2023.00022

    arXiv 2023

  15. [16]

    CVE-2021-44228. [n. d.]. CVE-2021-44228 Detail. https://nvd.nist.gov/vuln/ detail/CVE-2021-44228

    2021

  16. [18]

    National Vulnerability Database. [n. d.]. CVE-2021-44228. https://nvd.nist.gov/ vuln/detail/cve-2021-44228

    2021

  17. [19]

    Ying Dong, Wenbo Guo, Yueqi Chen, Xinyu Xing, Yuqing Zhang, and Gang Wang

  18. [20]

    Susheng Wu et al. [n. d.]. Replication Package of Vision. https://vision-version. github.io/

  19. [21]

    Lukas Fruntke and Jens Krinke. 2025. Automatically Fixing Dependency Breaking Changes.Proc. ACM Softw. Eng.2, FSE, Article FSE096 (June 2025), 23 pages. doi:10.1145/3729366

    doi:10.1145/3729366 2025

  20. [22]

    Xiang Gao, Arjun Radhakrishna, Gustavo Soares, Ridwan Shariffdeen, Sumit Gulwani, and Abhik Roychoudhury. 2021. APIfix: output-oriented program synthesis for combating breaking changes in libraries.Proc. ACM Program. Lang. 5, OOPSLA, Article 161 (Oct. 2021), 27 pages. doi:10.1145/3485538

    work page doi:10.1145/3485538 2021

  21. [23]

    Yi Gao, Xing Hu, Zirui Chen, and Xiaohu Yang. 2025. Vulnerability-Triggering Test Case Generation from Third-Party Libraries. arXiv:2409.16701 [cs.SE] https: //arxiv.org/abs/2409.16701

    Pith/arXiv arXiv 2025

  22. [24]

    Hao He, Runzhi He, Haiqiao Gu, and Minghui Zhou. 2021. A large-scale empirical study on Java library migrations: prevalence, trends, and rationales. InProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering(Athens, Greece) (ESEC/FSE 2021). Association for Computing Mach...

    arXiv 2021

  23. [25]

    Runzhi He, Hao He, Yuxia Zhang, and Minghui Zhou. 2023. Automating Depen- dency Updates in Practice: An Exploratory Study on GitHub Dependabot.IEEE Trans. Softw. Eng.49, 8 (Aug. 2023), 4004–4022. doi:10.1109/TSE.2023.3278129

    arXiv 2023

  24. [26]

    Yongzhong He, Yiming Wang, Sencun Zhu, Wei Wang, Yunjia Zhang, Qiang Li, and Aimin Yu. 2024. Automatically Identifying CVE Affected Versions With Patches and Developer Logs.IEEE Transactions on Dependable and Secure Com- puting21, 2 (2024), 905–919. doi:10.1109/TDSC.2023.3264567

    arXiv 2024

  25. [27]

    Zheyue Jiang, Yuan Zhang, Jun Xu, Xinqian Sun, Zhuang Liu, and Min Yang

  26. [28]

    Hyeonseong Jo, Jinwoo Kim, Phillip Porras, Vinod Yegneswaran, and Seungwon Shin. 2021. GapFinder: Finding Inconsistency of Security Information From Unstructured Text.IEEE Transactions on Information Forensics and Security16 Conference’17, July 2017, Washington, DC, USA Zirui Chen, Qi Zhan, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang (2021), 86–99. do...

    arXiv 2021

  27. [29]

    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 Engineering23 (2018), 384–417

    2018

  28. [30]

    Siyuan Li, Yongpan Wang, Chaopeng Dong, Shouguo Yang, Hong Li, Hao Sun, Zhe Lang, Zuxin Chen, Weijie Wang, Hongsong Zhu, and Limin Sun. 2023. LibAM: An Area Matching Framework for Detecting Third-Party Libraries in Binaries.ACM Trans. Softw. Eng. Methodol.33, 2, Article 52 (Dec. 2023), 35 pages. doi:10.1145/3625294

    doi:10.1145/3625294 2023

  29. [31]

    Shuhan Liu, Jiayuan Zhou, Xing Hu, Filipe Roseiro Cogo, Xin Xia, and Xiaohu Yang. 2025. An Empirical Study on Vulnerability Disclosure Management of Open Source Software Systems.ACM Trans. Softw. Eng. Methodol.34, 7, Article 214 (Aug. 2025), 31 pages. doi:10.1145/3716822

    doi:10.1145/3716822 2025

  30. [32]

    Lucas Miranda, Cainã Figueiredo, Daniel Sadoc Menasché, and Anton Kocheturov

  31. [33]

    MITRE. [n. d.]. CWE VIEW: Research Concepts. https://cwe.mitre.org/data/ definitions/1000.html

  32. [34]

    Dongliang Mu, Alejandro Cuevas, Limin Yang, Hang Hu, Xinyu Xing, Bing Mao, and Gang Wang. 2018. Understanding the reproducibility of crowd-reported security vulnerabilities. InProceedings of the 27th USENIX Conference on Security Symposium(Baltimore, MD, USA)(SEC’18). USENIX Association, USA, 919–936

    2018

  33. [35]

    Viet Hung Nguyen and Fabio Massacci. 2013. The (un)reliability of NVD vulner- able versions data: an empirical experiment on Google Chrome vulnerabilities. InProceedings of the 8th ACM SIGSAC Symposium on Information, Computer and Communications Security(Hangzhou, China)(ASIA CCS ’13). Association for Com- puting Machinery, New York, NY, USA, 493–498. doi...

    arXiv 2013

  34. [36]

    InInternational Symposium on Cyber Security, Cryptology, and Machine Learning

    Patch or exploit? NVD assisted classification of vulnerability-related github pages. InInternational Symposium on Cyber Security, Cryptology, and Machine Learning. Springer, 511–522

  35. [37]

    Optimal. [n. d.]. Hybrid Card Sorting. https://support.optimalworkshop.com/en/ articles/2626850-choose-between-an-openclosed-or-hybrid-card-sort

    arXiv

  36. [38]

    Antonino Sabetta, Serena Elisa Ponta, Rocio Cabrera Lozoya, Michele Bezzi, Tommaso Sacchetti, Matteo Greco, Gergő Balogh, Péter Hegedűs, Rudolf Ferenc, Ranindya Paramitha, Ivan Pashchenko, Aurora Papotti, Ákos Milánkovich, and Fabio Massacci. 2024. Known Vulnerabilities of Open Source Projects: Where Are the Fixes?IEEE Security & Privacy22, 2 (2024), 49–5...

    arXiv 2024

  37. [39]

    Youkun Shi, Yuan Zhang, Tianhan Luo, Xiangyu Mao, and Min Yang. 2023. Precise (Un)Affected Version Analysis for Web Vulnerabilities. InProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering(Rochester, MI, USA)(ASE ’22). Association for Computing Machinery, New York, NY, USA, Article 76, 13 pages. doi:10.1145/3551349.3556933

    arXiv 2023

  38. [40]

    Santosa, Asankhaya Sharma, and Ming Yi Ang

    Giang Nguyen-Truong, Hong Jin Kang, David Lo, Abhishek Sharma, Andrew E. Santosa, Asankhaya Sharma, and Ming Yi Ang. 2022. HERMES: Using Commit- Issue Linking to Detect Vulnerability-Fixing Commits. In2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). 51–62. doi:10.1109/SANER53432.2022.00018

    arXiv 2022

  39. [41]

    Xin Tan, Yuan Zhang, Chenyuan Mi, Jiajun Cao, Kun Sun, Yifan Lin, and Min Yang. 2021. Locating the Security Patches for Disclosed OSS Vulnerabilities with Vulnerability-Commit Correlation Ranking. InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security(Virtual Event, Republic of Korea)(CCS ’21). Association for Computing Ma...

    arXiv 2021

  40. [42]

    Susheng Wu, Wenyan Song, Kaifeng Huang, Bihuan Chen, and Xin Peng. 2024. Identifying Affected Libraries and Their Ecosystems for Open Source Software Vulnerabilities. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering(Lisbon, Portugal)(ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 162, 12 pages...

    doi:10.1145/3597503 2024

  41. [44]

    Synopsys. [n. d.]. OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT

  42. [45]

    https://www.synopsys.com/software-integrity/resources/analyst-reports/ open-source-security-risk-analysis.html

  43. [46]

    XWiki. [n. d.]. XWiki Platform. https://github.com/xwiki/xwiki-platform

  44. [47]

    Songtao Yang, Yubo He, Kaixiang Chen, Zheyu Ma, Xiapu Luo, Yong Xie, Jianjun Chen, and Chao Zhang. 2023. 1dFuzz: Reproduce 1-Day Vulnerabilities with Directed Differential Fuzzing. InProceedings of the 32nd ACM SIGSOFT Interna- tional Symposium on Software Testing and Analysis(Seattle, WA, USA)(ISSTA 2023). Association for Computing Machinery, New York, N...

    arXiv 2023

  45. [48]

    Lyuye Zhang, Jiahui Wu, Chengwei Liu, Kaixuan Li, Xiaoyu Sun, Lida Zhao, Chong Wang, and Yang Liu. 2025. Fixing Outside the Box: Uncovering Tactics for Open-Source Security Issue Management.Proc. ACM Softw. Eng.2, ISSTA, Article ISSTA100 (June 2025), 23 pages. doi:10.1145/3728977

    doi:10.1145/3728977 2025

  46. [49]

    Julia Wunder, Andreas Kurtz, Christian Eichenmüller, Freya Gassmann, and Zinaida Benenson. 2024. Shedding light on CVSS scoring inconsistencies: A user-centric study on evaluating widespread security vulnerabilities. In2024 IEEE Symposium on Security and Privacy (SP). IEEE, 1102–1121

    2024

  47. [50]

    Congying Xu, Bihuan Chen, Chenhao Lu, Kaifeng Huang, Xin Peng, and Yang Liu

  48. [51]

    InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering(Singapore, Singapore)(ESEC/FSE 2022)

    Tracking patches for open source software vulnerabilities. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering(Singapore, Singapore)(ESEC/FSE 2022). Association for Computing Machinery, New York, NY, USA, 860–871. doi:10.1145/3540250.3549125

    arXiv 2022

  49. [52]

    Xiaochen Zou, Yu Hao, Zheng Zhang, Juefei Pu, Weiteng Chen, and Zhiyun Qian

  50. [55]

    Zheng Zhang, Yu Hao, Weiteng Chen, Xiaochen Zou, Xingyu Li, Haonan Li, Yizhuo Zhai, Zhiyun Qian, and Billy Lau. 2024. SymBisect: accurate bisection for fuzzer-exposed vulnerabilities. InProceedings of the 33rd USENIX Conference on Security Symposium(Philadelphia, PA, USA)(SEC ’24). USENIX Association, USA, Article 140, 18 pages

    2024

  51. [56]

    Zhuotong Zhou, Yongzhuo Yang, Susheng Wu, Yiheng Huang, Bihuan Chen, and Xin Peng. 2024. Magneto: A Step-Wise Approach to Exploit Vulnerabilities in Dependent Libraries via LLM-Empowered Directed Fuzzing. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (Sacramento, CA, USA)(ASE ’24). Association for Computing ...

    arXiv 2024

  52. [57]

    Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel

  53. [58]

    In28th USENIX Security Symposium (USENIX Security 19)

    Small World with High Risks: A Study of Security Threats in the npm Ecosystem. In28th USENIX Security Symposium (USENIX Security 19). USENIX Association, Santa Clara, CA, 995–1010

  54. [2019]

    InProceedings of the 28th USENIX Conference on Security Symposium (Santa Clara, CA, USA)(SEC’19)

    Towards the detection of inconsistencies in public security vulnerability reports. InProceedings of the 28th USENIX Conference on Security Symposium (Santa Clara, CA, USA)(SEC’19). USENIX Association, USA, 869–885

  55. [2022]

    doi:10.1109/TDSC.2021.3125270

    Cleaning the NVD: Comprehensive Quality Assessment, Improvements, and Analyses.IEEE Transactions on Dependable and Secure Computing19, 6 (2022), 4255–4269. doi:10.1109/TDSC.2021.3125270

    arXiv 2022

  56. [2023]

    In2023 IEEE Symposium on Security and Privacy (SP)

    AEM: Facilitating Cross-Version Exploitability Assessment of Linux Kernel Vulnerabilities. In2023 IEEE Symposium on Security and Privacy (SP). 2122–2137. doi:10.1109/SP46215.2023.10179286

    arXiv 2023

  57. [2024]

    doi:10.14722/ndss.2024.24926

    SyzBridge: Bridging the Gap in Exploitability Assessment of Linux Kernel Bugs in the Linux Ecosystem.NDSS(2024). doi:10.14722/ndss.2024.24926

    arXiv 2024