Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Vulnerability-Affected Versions Identification: How Far Are We?

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

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

Pith's one-line read No affected-version tool tops 45% accuracy

desk verdict Big new benchmark and a believable negative result, but the ground truth uses the same range model as the tracing tools, so the paradigm comparison is softer than it looks. read the letter →

arxiv 2509.03876 v2 pith:L3PU6TE5 submitted 2025-09-04 cs.SE

Xingchu Chen , Chengwei Liu , Jialun Cao , Yang Xiao , Xinyue Cai , Yeting Li , Jingyi Shi , Tianqi Sun
show 1 more author
Haiming Chen ang Wei Huo
This is my paper · ORCID
classification cs.SE
keywords vulnerability-affectedversionsSZZalgorithmC/C++vulnerabilitiesbenchmarkconstructiontoolevaluationtracing-basedmethodsmatching-basedensemblestrategies
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper asks how well automated tools can identify which released versions of a C/C++ project are affected by a known vulnerability. The authors built a manually validated benchmark of 1,128 real-world CVEs and ran 12 representative tools on it. They find that no existing tool, whether it traces the vulnerability-inducing commit or matches vulnerable code signatures, correctly predicts the full set of affected versions more than 44.9% of the time, and the best ensemble strategy reaches only 55.0%. The paper argues that this ceiling is structural, not a matter of tuning: the tools share fundamental limitations in semantic reasoning, reliance on patch heuristics, and shallow verification of whether vulnerable logic is actually present. If true, this means security teams cannot currently rely on automated version identification alone and need fundamentally new approaches.

What carries the argument

The central object is the benchmark: 1,128 CVEs from nine C/C++ projects, each annotated with a ground-truth set of affected versions following the V-SZZ methodology of labeling every version between the vulnerability-inducing commit and the fixing commit as vulnerable. The other key mechanism is the stage-based decomposition framework, which abstracts tracing workflows, statement selection, commit tracing, inducing-commit identification, affected-version inference, and matching workflows, signature construction, matching, into comparable steps. This decomposition is what lets the authors attribute false positives and false negatives to specific design choices rather than treating each tool

What would settle it

Select roughly 100 CVEs from the released benchmark where official security advisories or project logs document that the fix was backported to only some maintenance branches or applied as a partial fix. If the continuous-range labels, all versions between inducing and fixing commits, differ from the documented affected sets for a substantial fraction of those CVEs, the benchmark's ground truth is wrong for those cases. Alternatively, run a tracing tool on a known backport scenario and check whether it labels a version vulnerable that the advisory says is already patched.

Watch

Extended reading notes

Core claim

The paper establishes that current automated vulnerability-affected version identification is far from reliable. Using a newly built benchmark of 1,128 C/C++ vulnerabilities with manually validated affected-version ranges, the authors evaluate 12 tools spanning tracing-based methods, which extend SZZ to find the vulnerability-inducing commit and map it to versions, and matching-based methods, which extract code signatures from the fix and search for them in historical versions. At the vulnerability level, where a prediction is correct only if it exactly matches the ground-truth set of affected versions, the best tool achieves 44.9% accuracy. At the version level, precision and recall are hig

Load-bearing premise

The benchmark labels every released version between the vulnerability-inducing commit and the fixing commit as vulnerable, and if many real-world CVEs are backported, partially fixed, or fixed differently across branches, this ground truth does not match reality and the reported accuracy numbers are distorted.

Editorial extensions

If this is right

  • Security teams should not treat any single current tool as authoritative for deciding which versions need patching, since the best tool is wrong about the full affected set more than half the time.
  • Ensemble strategies, especially majority voting across five tools, offer a practical near-term improvement, up to 55.0% accuracy, but cannot break the 60% ceiling, so the problem needs architectural innovation, not just combination.
  • Add-only patches, which make up 21.3% of the benchmark, break most tracing tools because those tools anchor on deleted lines; future tools must handle repairs that do not delete faulty code.
  • Multi-branch development is a major failure mode for both paradigms, so cross-branch patch reuse and branch-aware version inference should be a priority for new methods.
  • LLMs help most in early-stage statement selection, but LLM-based commit selection degrades performance; the best hybrid combines LLM selection with conventional heuristic commit tracing.

Reading between the lines

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

  • The continuous-range ground truth, all versions between inducing and fixing commits are vulnerable, mirrors the internal assumption of tracing tools, so the benchmark may systematically favor tracing-based methods; annotating backported or partially fixed CVEs separately would test whether the relative ranking survives.
  • A concrete next experiment: take a sample of CVEs where official advisories document branch-specific backports, and check whether the benchmark labels match the advisories; if they disagree often, the reported accuracy numbers are distorted for a non-trivial fraction of the 1,128 cases.
  • The finding that multi-file patches inject noise suggests that patch modularization, partitioning a fix into semantic units, could be a more productive direction than improving individual matching or tracing algorithms.
  • The paper's released benchmark enables a direct test of its strongest claim: another group can re-run the same tools on a subset restricted to single-branch, deletion-based patches and check whether the 45% ceiling rises, which would confirm that the limit is tied to patch complexity rather than tool implementation quality.
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

3 major / 5 minor

Summary. The paper constructs a new benchmark of 1,128 real-world C/C++ vulnerabilities with manually annotated affected-version ranges, and uses it to evaluate 12 tools (6 tracing-based, 6 matching-based) for vulnerability-affected version identification. The evaluation is multi-dimensional: vulnerability-level accuracy, version-level precision/recall/F1, root-cause analysis of false positives/negatives, sensitivity to patch type/scope/branching, and ensemble strategies. The central conclusion is that no individual tool exceeds 45% vulnerability-level accuracy, and that even tuned ensembles remain below 60%, indicating fundamental limitations in current architectures. The authors release their benchmark and replicated tool code.

Significance. If the benchmark and evaluation are accepted, this is a valuable reference point for a practically important but under-evaluated task. The study is larger in scope than prior evaluations, includes both tracing- and matching-based tools selected via a systematic literature review, and provides a useful stage-by-stage decomposition of tracing workflows. The double annotation with Cohen's Kappa 0.83 and the public release of data and code are explicit strengths. The negative result, if robust, would be an important caution for downstream N-day risk assessment and exploit-propagation work. However, the central quantitative claim depends heavily on the ground-truth model, which is not independent of the tracing tools being evaluated; this needs to be addressed before the headline numbers can be considered reliable.

major comments (3)
  1. [III-B.3 and IV-A (Table III)] The benchmark labels every released version between the vulnerability-inducing commit and the fixing commit as vulnerable, and the manual annotation validates the inducing and fixing commits, not each intermediate release (Section III-B.3: 'All versions between the inducing-commit and patch-commit are labeled as vulnerable'). This is exactly the interval model that V-SZZ and the other tracing-based tools implement. Tracing tools are therefore rewarded by construction for emitting intervals matching the ground truth, while matching-based tools, which inspect each version's code, are penalized when an intermediate release never contained the vulnerable logic (e.g., in multi-branch development or after backported fixes). Since 6 of the 9 projects in Table II are multi-branch, and Finding 8 reports large performance drops in multi-branch settings, this is not a hypothetical concern. The main
  2. [IV-D (Table VI)] The ensemble results are obtained by searching over many tool combinations and then reporting the best-performing configuration. There is no held-out set, no cross-validation, and no correction for multiple comparisons. The reported 55.0% vulnerability-level accuracy is therefore a selection optimum, not an unbiased estimate of what a practitioner should expect from that ensemble. The observation that LLM4SZZ+ appears in all leading combinations may also be a selection artifact. Please report out-of-sample performance (e.g., leave-one-project-out or a fixed pre-specified ensemble) and provide the distribution of ensemble accuracies over the search space.
  3. [V-D.2 (Internal Validity)] The threats-to-validity section states that manual labeling may introduce error and that it was mitigated by double annotation, but it does not address the issue that the label definition itself is the continuous-range model, which is not equivalent to per-version validation. This is distinct from annotator error and should be discussed explicitly. The paper's own RQ3 results show that multi-branch development is common and degrades tools, which increases the plausibility that continuous-range labels are wrong for a non-negligible fraction of intermediate versions. Please acknowledge this as a threat and provide evidence on how often the continuous-range assumption was checked or violated.
minor comments (5)
  1. [Section III-B.3 / Table II] The text states the dataset covers '59,983 vulnerable versions,' but Table II's total is 59,187. Please reconcile.
  2. [Section IV-C Setup] The sentence 'While V-SZZ incorporates cross-branch information when identifying affected versions, the general impact of single-branch versus multi-branch patches on tool performance has not been fully explored/determined' is duplicated with minor wording changes. Keep one.
  3. [Section IV-A.2] Typo: 'accurace' should be 'accuracy'; 'Tools may yield both FNs and FNs' should be 'both FPs and FNs'.
  4. [Table I and References] The tool is inconsistently named 'SEM-SZZ' in Table I and 'Sem-SZZ' in the text/references (e.g., ref [20]). Also, LLM4SZZ is cited as an arXiv preprint rather than a peer-reviewed publication; this should be flagged in the tool-selection description.
  5. [Section IV-B.2] The manual root-cause analysis on 100 vulnerabilities reports counts such as '49 instances' and '16 of these 16 cases,' but no inter-rater agreement is reported for this qualitative coding. Given that the root-cause findings support the 'fundamental limitations' narrative, adding agreement statistics would strengthen the analysis.

Circularity Check

1 steps flagged · score 4.0 of 10

Benchmark ground truth shares the tracing tools' interval model, partially circularizing the paradigm comparison.

  1. self definitional [Section III-B.3 (Ground Truth Annotation) and Section III-C (Experimental Setup)]
    "We determine affected version ranges following the annotation methodology of V-SZZ [19]. ... All versions between the inducing-commit and patch-commit are labeled as vulnerable. ... Tracing-based tools follow V-SZZ [19], labeling versions between introducing and fixing commits as vulnerable."

    The benchmark's ground truth is constructed using the exact interval rule that defines the output of tracing-based tools: all versions between the inducing commit and the patch commit are labeled vulnerable. V-SZZ and its variants output precisely this kind of interval. Therefore, evaluating tracing tools against this ground truth measures only how well they can recover manually identified endpoints; it does not validate whether the interval model itself is correct. Matching-based tools, which inspect each version's code, are penalized for not labeling every intermediate version as vulnerable even when the vulnerable code may be absent due to backports, partial fixes, or branch divergence. The comparison between tracing and matching paradigms is thus biased by construction, and the reporte

full rationale

The central empirical claim—that no tool exceeds 45% accuracy and that tracing tools outperform matching tools—rests on the benchmark's ground truth. The benchmark labels affected versions using the same "all versions between inducing and fixing commit" interval that tracing tools (V-SZZ et al.) are designed to produce. Manual validation focuses on identifying the inducing and fixing commits, not on independently verifying each intermediate release's vulnerability status. This creates a structural advantage for tracing tools: they are rewarded for emitting the same continuous range as the ground truth, while matching tools, which examine each version's code, are marked wrong for versions that never actually contained the vulnerable code due to branch divergence or backports. Thus, the reported paradigm gap is partly a consequence of the ground truth definition. However, the paper does perform substantial manual annotation (Cohen's Kappa 0.83, two annotators plus adjudication), and even tracing tools themselves achieve only 41–45% accuracy, indicating that the central negative result is not entirely manufactured. The benchmark is also publicly released and the study includes detailed root-cause analysis independent of the ground truth model. On balance, the circularity is moderate: the benchmark definition is partially self-confirming for one tool family, but the finding of fundamental limitations is not solely an artifact of that definition. Score 4 reflects this partial methodological circularity without concluding that the whole study is circular.

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

No new entities are introduced. The only free parameters are the post hoc ensemble selection choices; the central benchmark does not fit any model parameters. The shared SZZ range model is the most consequential assumption.

free parameters (2)
  • Ensemble configuration (tool subset and voting rule) = e.g., V-SZZ, Lifetime, SEM-SZZ, Movery, LLM4SZZ+ with majority voting, accuracy 55.0%
    RQ4 searches over tool combinations on the full benchmark and reports the best-performing configuration. This selection is fitted to the evaluation data, so the reported improvement (up to 10.1%) is an in-sample optimum.
  • Tool inclusion threshold for ensembles = F1-score >= 70%
    Phase-2 of RQ4 restricts the ensemble search to ten tools with version-level F1 >= 70%. This cut-off is an arbitrary design choice that shapes the combinations explored and the resulting accuracy.
assumptions (4)
  • domain assumption Affected versions form a continuous interval between the vulnerability-inducing commit and the fixing commit.
    Used in Section III-B.3 to construct ground truth. This is the same model that tracing tools implement and may not hold for backported, partial, or branch-specific fixes.
  • domain assumption Manual annotations by two experienced annotators with a third adjudicator are correct.
    Ground truth quality rests on human judgment. Cohen's Kappa of 0.83 indicates strong agreement but does not guarantee correctness against an external oracle.
  • domain assumption The 12 selected tools are representative of the current landscape of vulnerability-affected version identification.
    Tool selection uses a systematic literature review and snowballing (Section III-A), but some available tools are excluded due to non-availability or compilation requirements, so the set may not be fully representative.
  • domain assumption Running each tool with its default settings reflects its expected real-world performance.
    Stated in Section III-C and acknowledged in the threats to validity. Default configurations may not match the settings under which each tool was originally tuned.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Vulnerability-Affected Versions Identification: How Far Are We?." pith.science (2026). https://pith.science/paper/L3PU6TE5

@misc{pith2026250903876,
  author       = {Pith},
  title        = {Pith review of: Vulnerability-Affected Versions Identification: How Far Are We?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L3PU6TE5}},
  note         = {Machine review of arXiv:2509.03876}
}
read the original abstract

Identifying which software versions are affected by a vulnerability is critical for patching, risk mitigation. Despite a growing body of tools, their real-world effectiveness remains unclear due to narrow evaluation scopes often limited to early SZZ variants, outdated techniques, and small or coarse-grained datasets. In this paper, we present the first comprehensive empirical study of vulnerability affected versions identification. We curate a high quality benchmark of 1,128 real-world C/C++ vulnerabilities and systematically evaluate 12 representative tools from both tracing and matching paradigms across four dimensions: effectiveness at both vulnerability and version levels, root causes of false positives and negatives, sensitivity to patch characteristics, and ensemble potential. Our findings reveal fundamental limitations: no tool exceeds 45.0% accuracy, with key challenges stemming from heuristic dependence, limited semantic reasoning, and rigid matching logic. Patch structures such as add-only and cross-file changes further hinder performance. Although ensemble strategies can improve results by up to 10.1%, overall accuracy remains below 60.0%, highlighting the need for fundamentally new approaches. Moreover, our study offers actionable insights to guide tool development, combination strategies, and future research in this critical area. Finally, we release the replicated code and benchmark on our website to encourage future contributions.

Figures

Figures reproduced from arXiv: 2509.03876 by the authors.

Figure 1
Figure 1. Overview of Our Study strict validation, this dataset provides fine-grained, reproducible ground truth for tool evaluation. Second, we conduct a comprehensive comparison of 12 representative tools from both tracing and matching paradigms. The evaluation spans four dimensions: (1) effectiveness at both the vulnerability and version level, (2) root cause analysis of false positives (FPs) and false negatives (FNs), (3)… view at source ↗
Figure 2
Figure 2. Impact of Patch Modification Types on Tool Performance (Add-only, Del-only, Mixed). [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Tool Performance under Varying Patch Modification Scopes. [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Performance of Different Tools under Single [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits

    cs.SE 2026-03 conditional novelty 6.0 of 10

    Java exploits transferred across library versions identify 83% of known-vulnerable versions (99.3% precision), and manual migration pushes recall to 96.1%.

Reference graph

Works this paper leans on

52 extracted references · 50 canonical work pages · cited by 1 Pith paper

  1. [1]

    Research artifact

    (2025) Vulnerable version study artifact. Research artifact. [Online]. Available: https://sites.google.com/view/vulnerable-version-study

    work page 2025

  2. [2]

    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,”Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017

    work page 2017

  3. [3]

    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,”2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE), pp. 791–802, 2024

    work page 2024

  4. [4]

    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, and R. A. Beyah, “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, vol. 21, pp. 1372–1389, 2022

    work page 2022

  5. [5]

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

    ——, “A large-scale empirical analysis of the vulnerabilities introduced by third-party components in iot firmware,”Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022

    work page 2022

  6. [6]

    Enhancing oss patch backporting with semantics,

    S. Yang, Y . Xiao, Z. Xu, C. Sun, C. Ji, and Y . Zhang, “Enhancing oss patch backporting with semantics,”Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023

    work page 2023

  7. [7]

    Automated patch backporting in linux (experience paper),

    R. Shariffdeen, X. Gao, G. J. Duck, S. H. Tan, J. L. Lawall, and A. Roychoudhury, “Automated patch backporting in linux (experience paper),”Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2021

    work page 2021

  8. [8]

    Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem,

    C. Liu, S. Chen, L. Fan, B. Chen, Y . Liu, and X. Peng, “Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem,”2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), pp. 672–684, 2022

    work page 2022

Show all 52 references
  1. [9]

    Mitigating persistence of open-source vulnerabilities in maven ecosystem,

    L. Zhang, C. Liu, S. Chen, Z. Xu, L. Fan, L. Zhao, Y . Zhang, and Y . Liu, “Mitigating persistence of open-source vulnerabilities in maven ecosystem,” 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 191–203, 2023

    2023

  2. [10]

    Understanding the threats of upstream vulnerabilities to downstream projects in the maven ecosystem,

    Y . Wu, Z. Yu, M. Wen, Q. Li, D. Zou, and H. Jin, “Understanding the threats of upstream vulnerabilities to downstream projects in the maven ecosystem,”2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pp. 1046–1058, 2023

    2023

  3. [11]

    Towards the detection of inconsistencies in public security vulnerability reports,

    Y . Dong, W. Guo, Y . Chen, X. Xing, Y . Zhang, and G. Wang, “Towards the detection of inconsistencies in public security vulnerability reports,” inUSENIX Security Symposium, 2019

    2019

  4. [12]

    Cleaning the nvd: Comprehensive quality assessment, improvements, and analyses,

    A. Anwar, A. A. Abusnaina, S. Chen, F. H. Li, and D. A. Mohaisen, “Cleaning the nvd: Comprehensive quality assessment, improvements, and analyses,”IEEE Transactions on Dependable and Secure Computing, vol. 19, pp. 4255–4269, 2020

    2020

  5. [13]

    Vision: Identifying affected library versions for open source software vulnerabilities,

    S. Wu, R. Wang, K. Huang, Y . Cao, W. Song, Z. Zhou, Y . Huang, B. Chen, and X. Peng, “Vision: Identifying affected library versions for open source software vulnerabilities,”2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 1447–1459, 2024

    2024

  6. [14]

    Colefunda: Explainable silent vulnerability fix identification,

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

    2023

  7. [15]

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

    J. Zhou, M. Pacheco, Z. Wan, X. Xia, D. Lo, Y . Wang, and A. E. Hassan, “Finding a needle in a haystack: Automated mining of silent vulnerability fixes,”2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 705–716, 2021

    2021

  8. [16]

    Strengthening supply chain security with fine-grained safe patch identification,

    C. Luo, W. Meng, and S. Wang, “Strengthening supply chain security with fine-grained safe patch identification,”2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE), pp. 1084–1095, 2024

    2024

  9. [17]

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

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

    2015

  10. [18]

    How long do vulnerabilities live in the code? a Large-Scale empirical measurement study on FOSS vulnerability lifetimes,

    N. Alexopoulos, M. Brack, J. P. Wagner, T. Grube, and M. M ¨uhlh¨auser, “How long do vulnerabilities live in the code? a Large-Scale empirical measurement study on FOSS vulnerability lifetimes,” in31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Associat...

    2022

  11. [19]

    V-szz: Automatic identification of version ranges affected by cve vulnerabilities,

    L. Bao, X. Xia, A. E. Hassan, and X. Yang, “V-szz: Automatic identification of version ranges affected by cve vulnerabilities,” in2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), 2022, pp. 2352–2364

    2022

  12. [20]

    Enhancing bug-inducing commit identification: A fine-grained semantic analysis approach,

    L. Tang, C. Ni, Q. Huang, and L. Bao, “Enhancing bug-inducing commit identification: A fine-grained semantic analysis approach,”IEEE Trans. Softw. Eng., vol. 50, no. 11, p. 3037–3052, Nov. 2024

    2024

  13. [21]

    Llm-enhanced static analysis for precise identification of vulnerable oss versions,

    Y . Cheng, L. K. Shar, T. Zhang, S. Yang, C. Dong, D. Lo, S. Lv, Z. Shi, and L. Sun, “Llm-enhanced static analysis for precise identification of vulnerable oss versions,”arXiv preprint arXiv:2408.07321, 2024

    2024 arXiv

  14. [22]

    Llm4szz: Enhancing szz algorithm with context-enhanced assessment on large language models,

    L. Tang, J. Liu, Z. Liu, X. Yang, and L. Bao, “Llm4szz: Enhancing szz algorithm with context-enhanced assessment on large language models,” arXiv preprint arXiv:2504.01404, 2025

    2025 arXiv

  15. [23]

    When do changes induce fixes?

    J. ´Sliwerski, T. Zimmermann, and A. Zeller, “When do changes induce fixes?”ACM sigsoft software engineering notes, vol. 30, no. 4, pp. 1–5, 2005

    2005

  16. [24]

    Verjava: Vulnerable version identification for java oss with a two- stage analysis,

    Q. Sun, L. Xu, Y . Xiao, F. Li, H. Su, Y . Liu, H. Huang, and W. Huo, “Verjava: Vulnerable version identification for java oss with a two- stage analysis,” in2022 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2022, pp. 329–339

    2022

  17. [25]

    Precise (un)affected version analysis for web vulnerabilities,

    Y .-Q. Shi, Y . Zhang, T. Luo, X. Mao, and M. Yang, “Precise (un)affected version analysis for web vulnerabilities,”Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022

    2022

  18. [26]

    {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,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 3037–3053

    2022

  19. [27]

    {V1SCAN}: Discovering 1-day vulnerabilities in reused {C/C++} open-source software components us- ing 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 us- ing code classification techniques,” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 6541–6556

    2023

  20. [28]

    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,” in29th USENIX Security Symposium (USENIX Security 20). USENIX Association, Aug. 2020, pp. 1165–1182

    2020

  21. [29]

    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,” in2017 IEEE symposium on security and privacy (SP). IEEE, 2017, pp. 595–614

    2017

  22. [30]

    Exploring and exploiting the correlations between bug-inducing and bug- fixing commits,

    M. Wen, R. Wu, Y . Liu, Y . Tian, X. Xie, S.-C. Cheung, and Z. Su, “Exploring and exploiting the correlations between bug-inducing and bug- fixing commits,” inProceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Founda...

    2019

  23. [31]

    Evaluating szz implementations through a developer- informed oracle,

    G. Rosa, L. Pascarella, S. Scalabrino, R. Tufano, G. Bavota, M. Lanza, and R. Oliveto, “Evaluating szz implementations through a developer- informed oracle,”2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pp. 436–447, 2021

    2021

  24. [32]

    Evaluating szz implementations: An empirical study on the linux kernel,

    Y . Lyu, H. J. Kang, R. Widyasari, J. Lawall, and D. Lo, “Evaluating szz implementations: An empirical study on the linux kernel,”IEEE Trans. Softw. Eng., vol. 50, no. 9, p. 2219–2239, Sep. 2024

    2024

  25. [33]

    Automatic identification of bug-introducing changes,

    S. Kim, T. Zimmermann, K. Pan, and E. J. J. Whitehead, “Automatic identification of bug-introducing changes,”21st IEEE/ACM International Conference on Automated Software Engineering (ASE’06), pp. 81–90, 2006

    2006

  26. [34]

    A framework for evaluating the results of the szz approach for identifying bug-introducing changes,

    D. A. Da Costa, S. McIntosh, W. Shang, U. Kulesza, R. Coelho, and A. E. Hassan, “A framework for evaluating the results of the szz approach for identifying bug-introducing changes,”IEEE Transactions on Software Engineering, vol. 43, no. 7, pp. 641–657, 2016

    2016

  27. [35]

    The impact of refactoring changes on the szz algorithm: An empirical study,

    E. C. Neto, D. A. Da Costa, and U. Kulesza, “The impact of refactoring changes on the szz algorithm: An empirical study,” in2018 IEEE 25th international conference on software analysis, evolution and reengineering (SANER). IEEE, 2018, pp. 380–390

    2018

  28. [36]

    Pr-szz: How pull requests can support the tracing of defects in software repositories,

    P. Bludau and A. Pretschner, “Pr-szz: How pull requests can support the tracing of defects in software repositories,” in2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, pp. 1–12

    2022

  29. [37]

    Neural szz algorithm,

    L. Tang, L. Bao, X. Xia, and Z. Huang, “Neural szz algorithm,” inProceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’23. IEEE Press, 2024, p. 1024–1035

    2024

  30. [38]

    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,” in2012 IEEE Symposium on Security and Privacy. IEEE, 2012, pp. 48–62

    2012

  31. [39]

    A scalable approach for vulnerability discovery based on security patches,

    H. Li, H. Kwon, J. Kwon, and H. Lee, “A scalable approach for vulnerability discovery based on security patches,” inApplications and Techniques in Information Security: 5th International Conference, ATIS 2014, Melbourne, VIC, Australia, November 26-28, 2014. Proceedings 5. Spr...

    2014

  32. [40]

    Poster: Patchgen: Towards automated patch detection and generation for 1-day vulnerabili- ties,

    T. Luo, C. Ni, Q. Han, M. Yang, J. Wu, and Y . Wu, “Poster: Patchgen: Towards automated patch detection and generation for 1-day vulnerabili- ties,” inProceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, pp. 1656–1658

    2015

  33. [41]

    Tracer: Signature-based static analysis for detecting recurring vulnerabilities,

    W. Kang, B. Son, and K. Heo, “Tracer: Signature-based static analysis for detecting recurring vulnerabilities,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’22. New York, NY , USA: Association for Computing Machinery, 2022,...

    2022

  34. [42]

    {FIRE}: Combining {Multi-Stage} filtering with taint analysis for scalable recurring vulnerability detection,

    S. Feng, Y . Wu, W. Xue, S. Pan, D. Zou, Y . Liu, and H. Jin, “ {FIRE}: Combining {Multi-Stage} filtering with taint analysis for scalable recurring vulnerability detection,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 1867–1884

    2024

  35. [43]

    Enhancing security in third-party library reuse–comprehensive detection of 1-day vulnerability through code patch analysis,

    S. Xu, J. Dong, W. Cai, J. Li, A. Shaghaghi, N. Sun, and S. Ma, “Enhancing security in third-party library reuse–comprehensive detection of 1-day vulnerability through code patch analysis,”Network and Distributed System Security (NDSS) Symposium, 2025

    2025

  36. [44]

    Vmud: Detecting recurring vulnerabilities with multiple fixing functions via function selection and semantic equivalent statement matching,

    K. Huang, C. Lu, Y . Cao, B. Chen, and X. Peng, “Vmud: Detecting recurring vulnerabilities with multiple fixing functions via function selection and semantic equivalent statement matching,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Secur...

    2024

  37. [45]

    Paten: Identifying unpatched third- party apis via fine-grained patch-enhanced ast-level signature,

    L. Lin, J. Ye, C. Wang, and R. Wu, “Paten: Identifying unpatched third- party apis via fine-grained patch-enhanced ast-level signature,”IEEE Transactions on Software Engineering, vol. 51, no. 4, pp. 990–1006, 2025

    2025

  38. [46]

    Hiddencpg: Large-scale vulnerable clone detection using subgraph isomorphism of code property graphs,

    S. Wi, S. Woo, J. J. Whang, and S. Son, “Hiddencpg: Large-scale vulnerable clone detection using subgraph isomorphism of code property graphs,” inProceedings of the ACM Web Conference 2022, ser. WWW ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 755–766

    2022

  39. [47]

    Facilitating vulnerability assessment through poc migration,

    J. Dai, Y . Zhang, H. Xu, H. Lyu, Z. Wu, X. Xing, and M. Yang, “Facilitating vulnerability assessment through poc migration,”Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021

    2021

  40. [48]

    Symbisect: Accurate bisection for fuzzer-exposed vulnerabilities,

    Z. Zhang, Y . Hao, W. Chen, X. Zou, X. Li, H. Li, Y . Zhai, Z. Qian, and B. Lau, “Symbisect: Accurate bisection for fuzzer-exposed vulnerabilities,” inUSENIX Security Symposium, 2024

    2024

  41. [49]

    The ghost commit problem when identifying fix-inducing changes: An empirical study of apache projects,

    C. Rezk, Y . Kamei, and S. McIntosh, “The ghost commit problem when identifying fix-inducing changes: An empirical study of apache projects,”IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3297–3309, 2022

    2022

  42. [50]

    Openszz: a free, open-source, web-accessible implementation of the szz algorithm,

    L. Pellegrini, V . Lenarduzzi, and D. Taibi, “Openszz: a free, open-source, web-accessible implementation of the szz algorithm,” inProceedings of the 28th International Conference on Program Comprehension, 2019, pp. 446–450

    2019

  43. [51]

    Jira — issue & project tracking software — atlassian,

    Atlassian, “Jira — issue & project tracking software — atlassian,” 2025, [Online; accessed 2025-05-31]. [Online]. Available: https: //www.atlassian.com/software/jira

    2025

  44. [52]

    Auto- matically identifying cve affected versions with patches and developer logs,

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

    2024

Pith tools

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