Pith. sign in

REVIEW 4 major objections 5 minor 57 references

Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits

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

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

Pith's one-line read 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.

desk verdict 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. read the letter →

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

Zirui Chen , Qi Zhan , Jiayuan Zhou , Xing Hu , Xin Xia , Xiaohu Yang This is my paper · ORCID
classification cs.SEcs.CR
keywords supplychainsecurityJavalibrariesvulnerabilityexploitsaffectedversionidentificationcross-versionapplicabilityexploitmigrationempiricalsoftwareengineeringdatabases
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 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.

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

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

Extended reading notes

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

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.

Editorial extensions

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.

Reading between the lines

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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 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 · score 1.0 of 10

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.

Assumptions & free parameters 0 free parameters · 3 assumptions · 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.

assumptions (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.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits." pith.science (2026). https://pith.science/paper/OJGZ6XUG

@misc{pith2026260325997,
  author       = {Pith},
  title        = {Pith review of: Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OJGZ6XUG}},
  note         = {Machine review of arXiv:2603.25997}
}
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 the authors.

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 filtered acc… view at source ↗
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. 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 of the li… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 1 canonical work pages

  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

    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

Show all 57 references
  1. [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

    2025 arXiv

  2. [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–28...

    2024

  3. [11]

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

    1960

  4. [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

  5. [13]

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

    2020

  6. [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

    2023

  7. [16]

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

    2021

  8. [18]

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

    2021

  9. [19]

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

  10. [20]

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

  11. [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

    2025 doi

  12. [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.1...

    2021 doi

  13. [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

    2025 arXiv

  14. [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 Soft...

    2021

  15. [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

    2023

  16. [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

    2024

  17. [27]

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

  18. [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 ...

    2021

  19. [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

  20. [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 (De...

    2023 doi

  21. [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

    2025 doi

  22. [32]

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

  23. [33]

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

  24. [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 A...

    2018

  25. [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 ...

    2013

  26. [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

  27. [37]

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

  28. [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 Ope...

    2024

  29. [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 Comp...

    2023

  30. [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 Reeng...

    2022

  31. [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 S...

    2021

  32. [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...

    2024 doi

  33. [44]

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

  34. [45]

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

  35. [46]

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

  36. [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...

    2023

  37. [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

    2025 doi

  38. [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

  39. [50]

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

  40. [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,...

    2022

  41. [52]

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

  42. [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 ...

    2024

  43. [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...

    2024

  44. [57]

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

  45. [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

  46. [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

  47. [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

    2022

  48. [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

    2023

  49. [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

    2024

Pith tools

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