Pith. sign in

REVIEW 4 major objections 5 minor 141 references

Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub

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

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

Pith's one-line read One Node.js code pattern exposes 1,756 open-source projects to path traversal.

desk verdict A solid, honest measurement study with a genuinely end-to-end pipeline and dynamic exploit confirmation; the '1,756 vulnerable projects' headline should read 'exploitable code instances' until deployment context is quantified, but that is a framing fix, not a fatal flaw. read the letter →

arxiv 2505.20186 v1 pith:KVY3AO62 submitted 2025-05-26 cs.CR

Jafar Akhoundali , Hamidreza Hamidi , Kristian Rietveld , Olga Gadyatskaya This is my paper
classification cs.CR
keywords pathtraversalCWE-22open-sourcesecurityNode.jsautomatedvulnerabilitydetectionLLMcodegenerationresponsibledisclosureGitHubsearch
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that a single copy-pasted code pattern in Node.js static file servers — extracting the URL pathname and joining it to the public directory without normalizing away `..` — has spread across GitHub and leaves more than 1,750 open-source projects exploitable by path traversal (CWE-22). To show this, the authors built an automated pipeline that searches GitHub code, filters with static taint analysis, runs each candidate in a Docker container, confirms the attack by retrieving a planted `/flag.txt` file, computes CVSS scores, and generates patches with GPT-4. They report a median CVSS score of 9.1, 1,600 generated and validated patches, and 63 projects publicly fixed after responsible disclosure. They also trace the pattern back to a 2010 gist and show that popular LLM chatbots reproduce the insecure code even when told to write secure code. If correct, the paper demonstrates that one recurring vulnerable snippet, not dozens of independent bugs, accounts for a large share of real-world path traversal exposure and that the full detect–exploit–patch–disclose cycle can be automated.

What carries the argument

The load-bearing object is the code pattern itself: a minimal Node.js HTTP server built with `http.createServer` that parses `req.url`, applies `path.join` to the requested pathname and the intended public directory, then `fs.readFile`s and serves the result. Because `join` normalizes the concatenation, `..` sequences escape the public directory. The argument is carried by an automated pipeline whose stages act as filters: recursive GitHub Code Search keyword refinement to exceed the 1,000-result API limit; SemGrep taint analysis to prune false positives; a Docker-based Runner that installs dependencies and starts the file; an Exploiter that sends path traversal payloads to a planted `/flag.txt`; a GPT-4-based Patcher that adds a 'drop requests containing `..`' sanitizer, validated by four automated checks including a CodeQL rule; and a Reporter that computes CVSS and stages disclosures to maintainers.

What would settle it

Take a random sample of the 1,756 reported projects, attempt to deploy each with its documented setup, and check (a) whether the vulnerable file actually starts and listens in that deployment, and (b) whether a standard unnormalized HTTP request from a non-normalizing client can read a file outside the served directory. If the majority are never deployed, unreachable, or never boot the vulnerable code path, the headline '1,756 vulnerable projects' overstates the exploitable attack surface. A cheaper proxy: the paper itself notes maintainers of some rejected pull requests said the code was dev/test-only, so quantifying that fraction would settle how much the count overstates production risk.

Watch

Extended reading notes

Core claim

The central discovery is the ubiquity and persistence of one vulnerable pattern: a Node.js static file server that does `path.join(publicDir, urlPathname)` and serves the file, letting an unauthenticated request like `GET /../../../../flag.txt` read arbitrary files, with a denial-of-service variant that loads `/dev/urandom` into memory. The pipeline confirmed 1,756 exploitable instances out of 40,546 candidate projects, with most vulnerabilities rated critical (CVSS 9.1 median) because they are remotely exploitable, require no privileges, and affect confidentiality and availability. The paper further claims that the pattern has clear root causes: it appeared in a popular 2010 gist, migrated to StackOverflow answers and Node.js tutorials, survived repeated security challenges from commenters, and has since contaminated LLMs, which generate it in 70–95% of tested prompts depending on scenario.

Load-bearing premise

The count of 1,756 exploitable projects assumes that running the vulnerable Node.js file in a Docker container with a reachable port and a planted `/flag.txt` is a faithful proxy for real-world exposure, so projects that are only run in development or test mode still count as vulnerable.

Editorial extensions

If this is right

  • A single recurring code pattern, not many independent bugs, explains a substantial share of path traversal exposure in Node.js open source; fixing the pattern at its sources (the gist, StackOverflow answers, tutorials) would remove a large class of vulnerabilities at once.
  • The end-to-end automation is feasible: detection, exploit confirmation, CVSS scoring, patch generation, and disclosure can run at GitHub scale on one server in about three weeks, so similar pipelines can be bootstrapped for other vulnerability patterns.
  • The small patches (median 5 added lines) are acceptable enough to maintainers that remediation reached 42% for the most popular projects, though only 14% overall among fully notified projects, showing notification strategy matters as much as patch quality.
  • LLM code generators are contaminated by this pattern and produce path-traversal-vulnerable static file servers even when asked for secure code, so training-data sanitation is now part of vulnerability eradication.
  • The true incidence on GitHub is likely higher than 1,756 because the Code Search API caps queries at 1,000 results, forks were not individually probed, and the Runner failed to start 3,908 candidates.

Reading between the lines

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

  • If the pipeline's exploit confirmation was done only inside Docker with a root `/flag.txt`, then the real-world fraction of the 1,756 projects that are production-reachable is likely lower; a deployment-aware confirmation step would tighten the estimate.
  • The same recursive keyword-search technique could be adapted to find other copy-paste vulnerabilities (e.g., dangerous `eval`, SQL string concatenation) and, combined with LLM patch generation, could turn GitHub-wide pattern hunting into a routine maintenance service rather than a one-off study.
  • Since LLMs trained on this vulnerable pattern reproduce it, a testable extension is to fine-tune or prompt LLMs with the 'drop `..`' sanitizer shown here and measure whether the rate of vulnerable generations falls below 10%.
  • Because the pipeline intentionally favored zero false positives over completeness, the paper's headline number is a lower bound; the gap between 1,756 and the true count could be large, which matters for anyone sizing the overall open-source attack surface.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper studies a specific Node.js path traversal pattern (path.join applied to a user-supplied URL pathname) across GitHub. It builds an automated pipeline: keyword-based GitHub Code Search, SemGrep taint analysis, Docker-based project execution, exploit confirmation with path traversal and denial-of-service payloads, GPT-4 patch generation with behavioral validation, CVSS severity estimation, and responsible disclosure to maintainers. The authors report 1,756 successfully exploited samples, 1,600 generated and validated patches, and 63 remediated projects after disclosure. They also trace the root cause of the pattern to a 2010 GitHub Gist, StackOverflow, and MDN resources, and run experiments suggesting that popular LLM chatbots frequently generate vulnerable versions of the pattern even when asked for secure code. The central claim is that a single vulnerable code pattern is widespread and critical across open-source projects, with many instances scoring above 9.0 on CVSS.

Significance. If the findings as stated were fully supported, the paper would be a notable empirical contribution: an end-to-end automated vulnerability-management pipeline, dynamic exploit confirmation (stronger than static-only studies), a large-scale measurement of a recurring CWE-22 pattern, evidence of LLM contamination, and a responsible disclosure campaign. The strengths are the dynamic exploitation step, the patch validation against behavioral criteria, and the root-cause and LLM experiments. However, the headline prevalence and severity claims are currently calibrated at the level of executable code instances in containers, not deployed projects; the paper's own data (36 repositories with two vulnerable files; maintainers describing dev/test-only code) show that the project-level interpretation is not established. The paper is therefore worth publishing after the claims are reframed or re-measured, but the central quantitative claims need adjustment.

major comments (4)
  1. [§3, Table 1, §7.2] The headline '1,756 vulnerable open-source projects' is not supported by the unit reported in Table 1. Section 3 states 'Among 1,756 vulnerable files', and Section 7.2 reports 36 repositories each containing two vulnerable files, so the number of distinct vulnerable repositories is at most 1,720 and could be lower after accounting for forks and duplicates. The abstract and introduction should consistently use 'vulnerable code instances' or report a deduplicated project-level count.
  2. [§2.6, §2.7, §7.2] The exploit confirmation executes the vulnerable file directly or via npm start inside a Docker container and treats an open container port as sufficient evidence. This does not establish that the file is the production entry point, is wired into a deployed service, or is reachable in a real deployment. Section 4 reports maintainers saying the code was for development/testing only, and Section 7.2 acknowledges course material and unmaintained projects. Since the abstract and conclusions make project-level and network-exposure claims ('1,756 vulnerable open-source projects', 'critical', remotely exploitable), the paper must either quantify how many exploited samples are dev/test examples, course code, or unused code, or explicitly reframe the claims as exploitability of code instances under containerized execution.
  3. [§2.7.2, §2.9.3, Appendix A] The denial-of-service confirmation uses a 1 GB Docker memory cap and binds /dev/urandom as the flag file; a process crash under this condition is then mapped to CVSS Availability=High. This conflates a container-enforced resource limit with production availability impact. On a host with more memory or a process supervisor, the same code may not cause a full denial of service, so the CVSS distribution (median 9.1) likely overstates severity for the DoS component. This directly affects the 'critical (CVSS score higher than 9.0)' claim and should be re-justified or softened.
  4. [§7.2, 'Pipeline'] The statement that 'The projects identified as vulnerable by confirming exploitation are vulnerable (no false positives)' is only defensible at the level of code exploitability in the test environment. It does not address deployment-context false positives, such as dev-only or test-only code, which the paper's own maintainer feedback in §4 documents. The sentence should be qualified to say 'no false positives relative to the containerized exploit test' rather than claiming project-level vulnerability without deployment context.
minor comments (5)
  1. [§2.4] The tf-idf keyword refinement and the 'at least 100 results' threshold are not fully justified; since these choices directly control which repositories are retrieved, the final count depends on them. Please provide a precise description of the algorithm or a sensitivity analysis.
  2. [§2.8.3] The fourth patch-validation criterion counts invocations of the includes method before and after patching. This is a weak proxy for correct sanitizer placement; a patch could add an includes call in the wrong location and still pass this check. Please acknowledge this limitation or replace the check with a more semantic validation.
  3. [Footnote 2, §2.8.2] The text says the pipeline is 'released open-source', but the repository is scheduled to be published only after the conference presentation. Please clarify the availability timeline so that the empirical numbers can be verified by reviewers and readers.
  4. [Figure 3 and §2.8.4] The text refers to 'as shown in Fig. 3 in the appendix', but the figure appears in Section 2.8. Please correct the cross-reference.
  5. [Table 3, Appendix A] The note 'Repeated patterns truncated for readability' makes it impossible to know how many payload variants were actually tried and how many succeeded beyond the three listed counts. Please provide the full payload list or a clear aggregation method.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports an empirical measurement produced by running a pipeline, not a derivation that assumes its own conclusion.

full rationale

The paper's central claims are counts and outcomes of an automated pipeline: 40,546 candidate repositories scraped, 8,397 SAST-flagged samples, 1,756 successfully exploited files, 1,600 valid patches, and 63 fixed repositories. These numbers are generated by executing the pipeline (GitHub search, SemGrep, Docker runner, exploit payloads, GPT-4 patching, patch validation), not by fitting parameters or by transforming an input into an output through an equation that already contains the result. The CVSS scores are computed from the standardized CVSS v3 formula after the Exploiter step determines the attack vector and availability impact empirically; the statement that many vulnerabilities are critical (CVSS > 9.0) follows from the documented metric choices (AV:N, AC:L, PR:N, UI:N, S:U, C:H, A:H), but those choices are explained and tied to observed unauthenticated remote exploitation and demonstrated denial-of-service behavior, so this is application of a scoring standard rather than a circular prediction. The only self-citation, reference [1], appears in Section 7.3 as an example source for mining vulnerability datasets in a future-work discussion and is not load-bearing for the paper's empirical results. Maintainer feedback that some affected code is development-only or unmaintained is a limitation on the real-world attack-surface interpretation of the 1,756-project count; it concerns external validity and overstatement risk, not circularity of the derivation. No step was found where a prediction reduces by construction to its input, and no load-bearing argument rests on a self-citation or an imported uniqueness claim.

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

The central claim is a measurement, so the ledger is dominated by choices that shape the measurement: the search keywords, the tf-idf cutoff, the Docker memory and timeout thresholds, and the patch retry budget. No new physical or conceptual entities are introduced; the pipeline composes existing tools (Semgrep, Docker, GPT-4, CodeQL).

free parameters (6)
  • Manual keyword set for GitHub search = http.createServer, fs, read, URL, path
    Chosen in Step A to bootstrap the search; recall of the whole pipeline depends on these keywords.
  • tf-idf keyword frequency threshold = at least 100 results
    Section 2.4: keywords with fewer than 100 results are excluded to avoid wasted API queries, which changes which repositories are discovered.
  • Docker memory cap for DoS detection = 1 GB
    Section 2.7.2: setting the limit to 1 GB defines what counts as a memory-exhaustion denial of service.
  • DoS crash timeout = 10 seconds
    Section 2.7.2: a process exiting within 10 seconds of the exploit counts as a crash; a different timeout changes the DoS label.
  • LLM patch retry budget = 20 attempts
    Section 2.8: if the generated patch fails validation, the pipeline retries up to 20 times before giving up, which affects how many of the 1,756 projects receive patches.
  • GPT-4 temperature = 1.2
    Section 2.8.4: chosen to balance patch diversity against reproducibility; affects patch generation.
assumptions (4)
  • domain assumption GitHub Code Search API, together with the recursive tf-idf keyword refinement, returns a sufficiently representative sample of repositories containing the pattern.
    Section 2.4 and Section 7.2: the 1,756 count is a lower bound conditioned on this assumption.
  • domain assumption Running the vulnerable file directly in a Docker container and detecting an open port accurately recreates the conditions under which the path traversal can be exploited.
    Sections 2.6 and 2.7: this converts keyword and static-analysis candidates into confirmed exploits.
  • domain assumption Semgrep's public taint rule has a tolerable false negative rate for this pattern.
    Sections 2.5 and 7.2: false negatives would mean missed vulnerable projects; the authors only manually spot-checked about 30 high-star samples.
  • domain assumption The four patch validation checks (unchanged run method, unchanged root status code, exploit blocked, includes-method count increased) are sufficient evidence that an LLM patch does not break the application.
    Section 2.8.3: the authors themselves state full correctness cannot be guaranteed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub." pith.science (2026). https://pith.science/paper/KVY3AO62

@misc{pith2026250520186,
  author       = {Pith},
  title        = {Pith review of: Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KVY3AO62}},
  note         = {Machine review of arXiv:2505.20186}
}
read the original abstract

Vulnerabilities in open-source software can cause cascading effects in the modern digital ecosystem. It is especially worrying if these vulnerabilities repeat across many projects, as once the adversaries find one of them, they can scale up the attack very easily. Unfortunately, since developers frequently reuse code from their own or external code resources, some nearly identical vulnerabilities exist across many open-source projects. We conducted a study to examine the prevalence of a particular vulnerable code pattern that enables path traversal attacks (CWE-22) across open-source GitHub projects. To handle this study at the GitHub scale, we developed an automated pipeline that scans GitHub for the targeted vulnerable pattern, confirms the vulnerability by first running a static analysis and then exploiting the vulnerability in the context of the studied project, assesses its impact by calculating the CVSS score, generates a patch using GPT-4, and reports the vulnerability to the maintainers. Using our pipeline, we identified 1,756 vulnerable open-source projects, some of which are very influential. For many of the affected projects, the vulnerability is critical (CVSS score higher than 9.0), as it can be exploited remotely without any privileges and critically impact the confidentiality and availability of the system. We have responsibly disclosed the vulnerability to the maintainers, and 14\% of the reported vulnerabilities have been remediated. We also investigated the root causes of the vulnerable code pattern and assessed the side effects of the large number of copies of this vulnerable pattern that seem to have poisoned several popular LLMs. Our study highlights the urgent need to help secure the open-source ecosystem by leveraging scalable automated vulnerability management solutions and raising awareness among developers.

Figures

Figures reproduced from arXiv: 2505.20186 by the authors.

Figure 1
Figure 1. Overall flowchart of the proposed pipeline. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Simplified JavaScript (Node.js) code vulnerable to the path traversal attack. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Sample patch (in green) generated using GPT-4 with [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Distribution of verified exploited samples per year. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Distribution of vulnerable code snippets generated by LLMs in different scenarios: (A) scenario 1, step 1; (B) scenario 1, [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Popularity distribution of vulnerable projects (in [PITH_FULL_IMAGE:figures/full_fig_p016_6.png]
Figure 7
Figure 7. Figure 7: Automatically computed CVSS scores for exploited [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]
Figure 10
Figure 10. Figure 10: Heatmap of ratings for different parts of the report. [PITH_FULL_IMAGE:figures/full_fig_p017_10.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

141 extracted references · 56 canonical work pages

  1. [1]

    Jafar Akhoundali, Sajad Rahim Nouri, Kristian Rietveld, and Olga Gadyatskaya

  2. [2]

    Vishwanath Akuthota, Raghunandan Kasula, Sabiha Tasnim Sumona, Masud Mohiuddin, Md Tanzim Reza, and Md Mizanur Rahman. 2023. Vulnerability detection and monitoring using llm. In 2023 IEEE 9th International Women in Engineering (WIE) Conference on Electrical and Computer Engineering (WIECON- ECE). IEEE, 309–314

    2023

  3. [3]

    Ali Al-Kaswan and Maliheh Izadi. 2023. The (ab) use of open source code to train large language models. In 2023 IEEE/ACM 2nd International Workshop on Natural Language-Based Software Engineering (NLBSE) . IEEE, 9–10

    2023

  4. [4]

    Thanassis Avgerinos, Sang Kil Cha, Alexandre Rebert, Edward J Schwartz, Mav- erick Woo, and David Brumley. 2014. Automatic exploit generation. Commun. ACM 57, 2 (2014), 74–84. Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub

    2014

  5. [5]

    Jessy Ayala, Yu-Jye Tung, and Joshua Garcia. 2024. A mixed-methods study of open-source software maintainers on vulnerability management and platform security features. arXiv preprint arXiv:2409.07669 (2024)

    work page Pith review arXiv 2024

  6. [6]

    Michael Bailey, David Dittrich, Erin Kenneally, and Doug Maughan. 2012. The Menlo report. IEEE Security & Privacy 10, 2 (2012), 71–75

    2012

  7. [7]

    Vinuri Bandara, Thisura Rathnayake, Nipuna Weerasekara, Charitha Elvitigala, Kenneth Thilakarathna, Primal Wijesekera, and Chamath Keppitiyagama. 2020. Fix that Fix Commit: A real-world remediation analysis of JavaScript projects. In 2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 198–202

    2020

  8. [8]

    Ohad Barzilay and Cathy Urquhart. 2014. Understanding reuse of software examples: A case study of prejudice in a community of practice. Information and Software Technology 56, 12 (2014), 1613–1628

    2014

Show all 141 references
  1. [9]

    Gareth Bennett, Tracy Hall, Emily Winter, and Steve Counsell. 2024. Semgrep*: Improving the Limited Performance of Static Application Security Testing (SAST) Tools. In Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering . 614–623

    2024

  2. [10]

    Souphiane Bensalim, David Klein, Thomas Barber, and Martin Johns. 2021. Talking about my generation: Targeted dom-based xss exploit generation using dynamic data flow analysis. In Proceedings of the 14th European Workshop on Systems Security. 27–33

    2021

  3. [11]

    Guru Bhandari, Amara Naseer, and Leon Moonen. 2021. CVEfixes: automated collection of vulnerabilities and their fixes from open-source software. In Pro- ceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering. 30–39

    2021

  4. [12]

    Blackduck. 2024. 2024 Open Source Security and Risk Analysis Re- port. https://www.blackduck.com/resources/analyst-reports/open-source- security-risk-analysis.html

    2024

  5. [13]

    Knut Blind, Mirko Böhm, Paula Grzegorzewska, Andrew Katz, Sachiko Muto, Sivan Pätsch, and Torben Schubert. 2021. The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. Final Study Report. European Commis...

    2021

  6. [14]

    Islem Bouzenia and Michael Pradel. 2024. You name it, I run it: An LLM agent to execute tests of arbitrary projects. arXiv preprint arXiv:2412.10133 (2024)

    2024 arXiv

  7. [15]

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

    2020

  8. [16]

    David Brumley, Pongsin Poosankam, Dawn Song, and Jiang Zheng. 2008. Auto- matic patch-based exploit generation is possible: Techniques and implications. In 2008 IEEE Symposium on Security and Privacy (sp 2008) . IEEE, 143–157

    2008

  9. [17]

    Quang-Cuong Bui, Ranindya Paramitha, Duc-Ly Vu, Fabio Massacci, and Ric- cardo Scandariato. 2024. APR4Vul: An empirical study of automatic program repair techniques on real-world Java vulnerabilities. Empirical software engi- neering 29, 1 (2024), 18

    2024

  10. [18]

    Darion Cassel, Nuno Sabino, Ruben Martins, and Limin Jia. 2024. NODEMEDIC- FINE: Automatic Detection and Exploit Synthesis for Node. js Vulnerabilities

    2024

  11. [19]

    Darion Cassel, Wai Tuck Wong, and Limin Jia. 2023. Nodemedic: End-to-end analysis of node. js vulnerabilities with provenance graphs. In 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P) . IEEE, 1101–1127

    2023

  12. [20]

    Hasan Cavusoglu, Huseyin Cavusoglu, and Srinivasan Raghunathan. 2005. Emerging Issues in Responsible Vulnerability Disclosure.. In WEIS

    2005

  13. [21]

    FO Çetin, Carlos Ganan, Maciej Korczynski, and Michel Van Eeten. 2017. Make notifications great again: learning how to notify in the age of large-scale vul- nerability scanning. In WEIS 2017. 1–23

    2017

  14. [22]

    Saikat Chakraborty, Rahul Krishna, Yangruibo Ding, and Baishakhi Ray. 2021. Deep learning based vulnerability detection: Are we there yet?IEEE Transactions on Software Engineering 48, 9 (2021), 3280–3296

    2021

  15. [23]

    Xiangping Chen, Furen Xu, Yuan Huang, Xiaocong Zhou, and Zibin Zheng

  16. [24]

    Yuxiao Chen, Jingzheng Wu, Xiang Ling, Changjiang Li, Zhiqing Rui, Tianyue Luo, and Yanjun Wu. 2024. When Large Language Models Confront Repository- Level Automatic Program Repair: How Well They Done?. InProceedings of the 2024 IEEE/ACM 46th International Conference on Softwar...

    2024

  17. [25]

    Journal of Systems and Software 210 (2024), 111964

    An empirical study of code reuse between GitHub and stack overflow during software development. Journal of Systems and Software 210 (2024), 111964

    2024

  18. [26]

    Domenico Cotroneo, Cristina Improta, Pietro Liguori, and Roberto Natella

  19. [27]

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

    2011

  20. [28]

    Ozren Dabic, Emad Aghajani, and Gabriele Bavota. 2021. Sampling projects in github for MSR studies. In 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR) . IEEE, 560–564

    2021

  21. [29]

    In Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension

    Vulnerabilities in AI code generators: Exploring targeted data poisoning attacks. In Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension. 280–292

  22. [30]

    Leuson Da Silva, Jordan Samhi, and Foutse Khomh. 2024. ChatGPT vs LLaMA: Impact, Reliability, and Challenges in Stack Overflow Discussions.arXiv preprint arXiv:2402.08801 (2024)

    2024 arXiv

  23. [31]

    Chongzhou Fang, Ning Miao, Shaurya Srivastav, Jialin Liu, Ruoyu Zhang, Ruijie Fang, Ryan Tsang, Najmeh Nazari, Han Wang, Houman Homayoun, et al. 2024. Large Language Models for Code Analysis: Do LLMs Really Do Their Job?. In 33rd USENIX Security Symposium . 829–846

    2024

  24. [32]

    Karine Even-Mendoza, Arindam Sharma, Alastair F Donaldson, and Cristian Cadar. 2023. GrayC: Greybox fuzzing of compilers and analysers for C. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1219–1231

    2023

  25. [33]

    Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang. 2023. Large language models for software engineer- ing: Survey and open problems. In 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Enginee...

    2023

  26. [34]

    Zhiwei Fei, Jidong Ge, Chuanyi Li, Tianqi Wang, Yuning Li, Haodong Zhang, LiGuo Huang, and Bin Luo. 2025. Patch Correctness Assessment: A Survey. ACM Transactions on Software Engineering and Methodology 34, 2 (2025), 1–50

    2025

  27. [35]

    Richard Fang, Rohan Bindu, Akul Gupta, and Daniel Kang. 2024. Llm agents can autonomously exploit one-day vulnerabilities. arXiv preprint arXiv:2404.08144 (2024)

    2024 arXiv

  28. [36]

    Richard Fang, Rohan Bindu, Akul Gupta, Qiusi Zhan, and Daniel Kang. 2024. Llm agents can autonomously hack websites. arXiv preprint arXiv:2402.06664 (2024)

    2024 arXiv

  29. [37]

    Felix Fischer, Konstantin Böttinger, Huang Xiao, Christian Stransky, Yasemin Acar, Michael Backes, and Sascha Fahl. 2017. StackOverflow considered harm- ful? The impact of copy&paste on Android application security. In 2017 IEEE symposium on security and privacy (SP) . IEEE, 121–136

    2017

  30. [38]

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

    2024

  31. [39]

    FIRST.Org, Inc. 2015. Common Vulnerability Scoring System v3.0: Specification Document. https://www.first.org/cvss/v3.0/specification-document. Accessed: 2025-05-20

    2015

  32. [40]

    GitHub. 2025. CodeQL: Semantic Code Analysis Engine. https://codeql.github. com/. Accessed: 2025-05-20

    2025

  33. [41]

    Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. 2022. VulRepair: a T5-based automated software vulnerability repair. In Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineer...

    2022

  34. [42]

    GH Archive Project. 2024. GH Archive. https://www.gharchive.org/

    2024

  35. [43]

    Ken Russel Go, Sruthi Soundarapandian, Aparupa Mitra, Melina Vidoni, and Nicolás E Díaz Ferreyra. 2023. Simple stupid insecure practices and GitHub’s code search: A looming threat? Journal of Systems and Software 202 (2023), 111698

    2023

  36. [44]

    GitHub. 2025. GitHub Search: Public Repositories. https://github.com/search? q=is%3Apublic&type=repositories. Accessed: 2025-05-20

    2025

  37. [45]

    GitHub Community. 2022. Only 100 results? https://github.com/orgs/ community/discussions/9868. Accessed: 2025-05-20

    2022

  38. [46]

    Sivana Hamer, Marcelo d’Amorim, and Laurie Williams. 2024. Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers. In 2024 IEEE Security and Privacy Workshops (SPW). IEEE, 87–94

    2024

  39. [47]

    Google. 2024. From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. https://googleprojectzero.blogspot. com/2024/10/from-naptime-to-big-sleep.html

    2024

  40. [48]

    Georgios Gousios. 2013. The GHTorent dataset and tool suite. In 2013 10th Working Conference on Mining Software Repositories (MSR) . IEEE, 233–236

    2013

  41. [49]

    Ruida Hu, Chao Peng, Xinchen Wang, and Cuiyun Gao. 2025. An LLM- based Agent for Reliable Docker Environment Configuration. arXiv preprint arXiv:2502.13681 (2025)

    2025

  42. [50]

    Nikolay Harutyunyan. 2020. Managing your open source supply chain – why and how? Computer 53, 6 (2020), 77–81

    2020

  43. [51]

    Hong Hu, Zheng Leong Chua, Sendroiu Adrian, Prateek Saxena, and Zhenkai Liang. 2015. Automatic Generation of Data-Oriented Exploits. In 24th USENIX Security Symposium (USENIX Security 15) . 177–192

    2015

  44. [52]

    Mingqing Kang, Yichao Xu, Song Li, Rigel Gjomemo, Jianwei Hou, VN Venkatakrishnan, and Yinzhi Cao. 2023. Scaling javascript abstract interpreta- tion to detect and exploit node. js taint-style vulnerability. In 2023 IEEE Sympo- sium on Security and Privacy (SP) . IEEE, 1059–1076

    2023

  45. [53]

    Junjie Huang and Quanyan Zhu. 2024. PenHeal: A Two-Stage LLM Frame- work for Automated Pentesting and Optimal Remediation. arXiv preprint arXiv:2407.17788 (2024)

    2024 arXiv

  46. [54]

    Matthew Jin, Syed Shahriar, Michele Tufano, Xin Shi, Shuai Lu, Neel Sundaresan, and Alexey Svyatkovskiy. 2023. Inferfix: End-to-end program repair with llms. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Softw...

    2023

  47. [55]

    Raphaël Khoury, Anderson R Avila, Jacob Brunelle, and Baba Mamadou Camara

  48. [56]

    Harjot Kaur, Sabrina Amft, Daniel Votipka, Yasemin Acar, and Sascha Fahl. 2022. Where to recruit for security development studies: Comparing six software Jafar Akhoundali, Hamidreza Hamidi, Kristian Rietveld, and Olga Gadyatskaya developer samples. In 31st USENIX Security Symp...

    2022

  49. [57]

    Erin Kenneally and David Dittrich. 2012. The Menlo report: Ethical principles guiding information and communication technology research. A vailable at SSRN 2445102 (2012)

    2012

  50. [58]

    Denis Kocetkov, Raymond Li, Loubna Ben Allal, Jia Li, Chenghao Mou, Car- los Muñoz Ferrandis, Yacine Jernite, Margaret Mitchell, Sean Hughes, Thomas Wolf, et al. 2022. The stack: 3 tb of permissively licensed source code. arXiv preprint arXiv:2211.15533 (2022)

    2022 arXiv

  51. [59]

    Ummay Kulsum, Haotian Zhu, Bowen Xu, and Marcelo d’Amorim. 2024. A Case Study of LLM for Automated Vulnerability Repair: Assessing Impact of Reasoning and Patch Validation Feedback. In Proceedings of the 1st ACM International Conference on AI-Powered Software . 103–111

    2024

  52. [60]

    Kyungtae Kim, Dae R Jeong, Chung Hwan Kim, Yeongjin Jang, Insik Shin, and Byoungyoung Lee. 2020. HFL: Hybrid Fuzzing on the Linux Kernel. In Proceedings of NDSS

    2020

  53. [61]

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

    2017

  54. [62]

    J. Leon. 2024. LLMs are Teaching Developers to Hardcode API Keys. https:// trufflesecurity.com/blog/llms-are-teaching-developers-to-hardcode-api-keys

    2024

  55. [63]

    LGTM. 2025. LGTM Code Search. https://lgtm.com. Accessed: 2025-05-20

    2025

  56. [64]

    Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. 2023. Sok: Taxonomy of attacks on open-source software supply chains. In 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 1509–1526

    2023

  57. [65]

    Jonathan Leitschuh and Patrick Way. 2022. Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All. Black Hat USA

    2022

  58. [66]

    Xuetao Li, Yuxia Zhang, Cailean Osborne, Minghui Zhou, Zhi Jin, and Hui Liu

  59. [67]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2024. Is your code generated by ChatGPT really correct? rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems 36 (2024)

    2024

  60. [68]

    Peiyu Liu, Junming Liu, Lirong Fu, Kangjie Lu, Yifan Xia, Xuhong Zhang, Wenzhi Chen, Haiqin Weng, Shouling Ji, and Wenhai Wang. 2024. Exploring ChatGPT’s Capabilities on Vulnerability Management. In 33rd USENIX Security Symposium. 811–828

    2024

  61. [69]

    H Li, D He, X Zhu, and S Chan. 2022. P1OVD: Patch-Based 1-Day Out-of- Bounds Vulnerabilities Detection Tool for Downstream Binaries. Electronics (2022), 143

    2022

  62. [70]

    Song Li, Mingqing Kang, Jianwei Hou, and Yinzhi Cao. 2021. Detecting Node. js prototype pollution vulnerabilities via object lookup analysis. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software E...

    2021

  63. [71]

    Guilong Lu, Xiaolin Ju, Xiang Chen, Wenlong Pei, and Zhilong Cai. 2024. GRACE: Empowering LLM-based software vulnerability detection with graph structure and in-context learning. Journal of Systems and Software 212 (2024), 112031

    2024

  64. [72]

    ACM Transactions on Software Engineering and Methodology (2024)

    Systematic literature review of commercial participation in open source software. ACM Transactions on Software Engineering and Methodology (2024)

    2024

  65. [73]

    Sanoop Mallissery and Yu-Sung Wu. 2023. Demystify the fuzzing methods: A comprehensive survey. Comput. Surveys 56, 3 (2023), 1–38

    2023

  66. [74]

    Tina Marjanov, Ivan Pashchenko, and Fabio Massacci. 2022. Machine learning for source code vulnerability detection: What works and what isn’t there yet. IEEE Security & Privacy 20, 5 (2022), 60–76

    2022

  67. [75]

    Peng Liu, He Wang, Chen Zheng, and Yuqing Zhang. 2024. Prompt Fix: Vul- nerability Automatic Repair Technology Based on Prompt Engineering. In 2024 International Conference on Computing, Networking and Communications (ICNC). IEEE, 116–120

    2024

  68. [76]

    Cristina V Lopes, Petr Maj, Pedro Martins, Vaibhav Saini, Di Yang, Jakub Zitny, Hitesh Sajnani, and Jan Vitek. 2017. DéjàVu: a map of code duplicates on GitHub. Proceedings of the ACM on Programming Languages 1, OOPSLA (2017), 1–28

    2017

  69. [77]

    MITRE. 2024. 2024 CWE Top 25 Most Dangerous Software Weaknesses. https: //cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html. Accessed: 2025-05- 20

    2024

  70. [78]

    Kevin Macnish and Jeroen Van der Ham. 2020. Ethics in cybersecurity research and practice. Technology in society 63 (2020), 101382

    2020

  71. [79]

    Mohammad Mahdi Mohajer, Reem Aleithan, Nima Shiri Harzevili, Moshi Wei, Alvine Boaye Belle, Hung Viet Pham, and Song Wang. 2024. Effectiveness of ChatGPT for Static Analysis: How Far Are We?. In Proceedings of the 1st ACM International Conference on AI-Powered Software (Porto ...

    2024

  72. [80]

    Azadeh Mokhberi, Tiffany Quon, and Konstantin Beznosov. 2021. What makes security-related code examples different. In SOUPS Workshop on Security Infor- mation Workers (WSIW). USENIX Association

    2021

  73. [81]

    Dan McInerney and Marcello Salvati. 2024. Vulnhuntr: Autonomous AI Finds First 0-Day Vulnerabilities in Wild. https://protectai.com/threat-research/ vulnhuntr-first-0-day-vulnerabilities

    2024

  74. [82]

    MITRE. 2024. 2024 CWE Top 10 KEV Weaknesses. https://cwe.mitre.org/top25/ archive/2024/2024_kev_list.html. Accessed: 2025-05-20

    2024

  75. [83]

    Yu Nong, Haoran Yang, Long Cheng, Hongxin Hu, and Haipeng Cai. 2024. Automated Software Vulnerability Patching using Large Language Models. arXiv:2408.13597 [cs.CR] https://arxiv.org/abs/2408.13597

    2024 arXiv

  76. [84]

    MITRE. 2024. CWE-22: Improper Limitation of a Pathname to a Restricted Directory (’Path Traversal’). https://cwe.mitre.org/data/definitions/22.html. Accessed: 2025-05-20

    2024

  77. [85]

    Online. 2010. https://gist.github.com/ryanflorence/701407/revisions

    2010

  78. [86]

    Online. 2011. . https://stackoverflow.com/questions/7268033/basic-static-file- server-in-nodejs

    2011

  79. [87]

    Giovane CM Moura and John Heidemann. 2023. Vulnerability Disclosure Considered Stressful. ACM SIGCOMM Computer Communication Review 53, 2 (2023), 2–10

    2023

  80. [88]

    Zahra Mousavi, Chadni Islam, Kristen Moore, Alsharif Abuadbba, and M Ali Babar. 2024. An Investigation into Misuse of Java Security APIs by Large Language Models. In Proceedings of the 19th ACM Asia Conference on Computer and Communications Security. 1299–1315

    2024

  81. [89]

    Online. 2017. https://github.com/ARVILab/CourseAI

    2017

  82. [90]

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstab- ber’s knife collection: A review of open source software supply chain attacks. In Detection of Intrusions and Malware, and Vulnerability Assessment: 17th Inter- national Conference, DIMV A 2020, Lisbon,...

    2020

  83. [91]

    Online. 2024. https://github.com/mdn/content/commit/ eb79c92ae89e15a7dbc996150abd7f9930f3e5af

    2024

  84. [92]

    Online. 2024. https://github.com/MichaelGustavsson/nodejs-course

    2024

  85. [93]

    Online. 2015. . https://stackoverflow.com/a/29046869

    2015

  86. [94]

    Online. 2017. https://github.com/iproduct/course-node-express-react

    2017

  87. [95]

    Sunnyeo Park, Daejun Kim, Suman Jana, and Sooel Son. 2022. FUGIO: Automatic Exploit Generation for PHP Object Injection Vulnerabilities. In 31st USENIX Security Symposium (USENIX Security 22) . 197–214

    2022

  88. [96]

    Online. 2019. https://github.com/bradtraversy/node_crash_course

    2019

  89. [97]

    Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Bren- dan Dolan-Gavitt. 2023. Examining zero-shot vulnerability repair with large language models. In 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 2339–2356

    2023

  90. [98]

    Jiaqi Peng, Feng Li, Bingchang Liu, Lili Xu, Binghong Liu, Kai Chen, and Wei Huo. 2019. 1dvul: Discovering 1-day vulnerabilities through binary patches. In 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 605–616

    2019

  91. [99]

    Online. 2025. https://data.stackexchange.com/stackoverflow/query/1854595/ most-viewed-questions-for-specific-tag

    2025

  92. [100]

    Inian Parameshwaran, Enrico Budianto, Shweta Shinde, Hung Dang, Atul Sadhu, and Prateek Saxena. 2015. DexterJS: Robust testing platform for DOM-based XSS vulnerabilities. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. 946–949

    2015

  93. [101]

    David Reid, Mahmoud Jahanshahi, and Audris Mockus. 2022. The extent of orphan vulnerabilities from code reuse in open source software. In Proceedings of the 44th International Conference on Software Engineering . 2104–2115

    2022

  94. [102]

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 754–768

    2022

  95. [103]

    Rebecca Russell, Louis Kim, Lei Hamilton, Tomo Lazovich, Jacob Harer, Onur Ozdemir, Paul Ellingwood, and Marc McConley. 2018. Automated vulnerability detection in source code using deep representation learning. In 2018 17th IEEE international conference on machine learning and...

    2018

  96. [104]

    Zoltán Ságodi, Gábor Antal, Bence Bogenfürst, Martin Isztin, Péter Hegedun- defineds, and Rudolf Ferenc. 2024. Reality Check: Assessing GPT-4 in Fixing Real-World Software Vulnerabilities. In Proceedings of the 28th International Conference on Evaluation and Assessment in Soft...

    2024

  97. [105]

    Eduard Pinconschi, Rui Abreu, and Pedro Adão. 2021. A comparative study of automatic program repair techniques for security vulnerabilities. In 2021 IEEE 32nd international symposium on software reliability engineering (ISSRE) . IEEE, 196–207

    2021

  98. [106]

    Md Rayhanur Rahman, Akond Rahman, and Laurie Williams. 2019. Share, but be aware: Security smells in Python gists. In 2019 IEEE International conference on software maintenance and evolution (ICSME) . IEEE, 536–540

    2019

  99. [107]

    Aadit M Shah. [n. d.]. Why do people fork reposito- ries on GitHub? Software Engineering Stack Exchange. arXiv:https://softwareengineering.stackexchange.com/q/200663 https://softwareengineering.stackexchange.com/q/200663 URL:https://softwareengineering.stackexchange.com/q/2006...

    2013

  100. [108]

    Simone Romano, Maria Caulo, Matteo Buompastore, Leonardo Guerra, Anas Mounsif, Michele Telesca, Maria Teresa Baldassarre, and Giuseppe Scanniello

  101. [109]

    Zhidong Shen and Si Chen. 2020. A survey of automatic software vulnerabil- ity detection, program repair, and defect prediction techniques. Security and Communication Networks 2020, 1 (2020), 8858010

    2020

  102. [110]

    Ze Sheng, Fenghua Wu, Xiangwu Zuo, Chao Li, Yuxin Qiao, and Lei Hang

  103. [111]

    Edward Smith, Robert Loftin, Emerson Murphy-Hill, Christian Bird, and Thomas Zimmermann. 2013. Improving developer participation rates in surveys. In 2013 6th International workshop on cooperative and human aspects of software engineering (CHASE). IEEE, 89–92

    2013

  104. [112]

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

    2016

  105. [113]

    Semgrep, Inc. 2025. Semgrep: Static Analysis for Modern Development. https: //semgrep.dev/. Accessed: 2025-05-20

    2025

  106. [114]

    Shangwen Wang, Ming Wen, Bo Lin, Hongjun Wu, Yihao Qin, Deqing Zou, Xiaoguang Mao, and Hai Jin. 2020. Automated patch correctness assessment: How far are we?. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. 968–980

    2020

  107. [115]

    Mikhail Shcherbakov, Musard Balliu, and Cristian-Alexandru Staicu. 2023. Silent spring: Prototype pollution leads to remote code execution in Node. js. In 32nd USENIX Security Symposium (USENIX Security 23) . 5521–5538

    2023

  108. [116]

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

    2023

  109. [117]

    Seunghoon Woo, Hyunji Hong, Eunjin Choi, and Heejo Lee. 2022. MOVERY: A Precise Approach for Modified Vulnerable Code Clone Discovery from Modi- fied Open-Source Software Components. In 31st USENIX Security Symposium (USENIX Security 22). 3037–3053

    2022

  110. [118]

    arXiv preprint arXiv:2411.06493 (2024)

    Lprotector: An llm-driven vulnerability detection system. arXiv preprint arXiv:2411.06493 (2024)

    2024 arXiv

  111. [119]

    Benlong Wu, Guoqiang Chen, Kejiang Chen, Xiuwei Shang, Jiapeng Han, Yanru He, Weiming Zhang, and Nenghai Yu. 2024. AutoPT: How Far Are We from the End2End Automated Web Penetration Testing? arXiv preprint arXiv:2411.01236 (2024)

    2024 arXiv

  112. [120]

    Morteza Verdi, Ashkan Sami, Jafar Akhondali, Foutse Khomh, Gias Uddin, and Alireza Karami Motlagh. 2020. An empirical study of C++ vulnerabilities in crowd-sourced code examples. IEEE Transactions on Software Engineering 48, 5 (2020), 1497–1514

    2020

  113. [121]

    Jin Wang, Zishan Huang, Hengli Liu, Nianyi Yang, and Yinhao Xiao. 2023. Defecthunter: A novel llm-driven boosted-conformer-based code vulnerability detection mechanism. arXiv preprint arXiv:2309.15324 (2023)

    2023 arXiv

  114. [122]

    Jiacen Xu, Jack W Stokes, Geoff McDonald, Xuesong Bai, David Marshall, Siyue Wang, Adith Swaminathan, and Zhou Li. 2024. Autoattacker: A large language model guided system to implement automatic cyber-attacks. arXiv preprint arXiv:2403.01038 (2024)

    2024 arXiv

  115. [123]

    Emily Winter, David Bowes, Steve Counsell, Tracy Hall, Sæmundur Haraldsson, Vesna Nowack, and John Woodward. 2022. How do developers really feel about bug fixing? Directions for automatic program repair. IEEE Transactions on Software Engineering (2022)

    2022

  116. [124]

    Zhou Yang, Zhipeng Zhao, Chenyu Wang, Jieke Shi, Dongsun Kim, Donggyun Han, and David Lo. 2024. Gotcha! This model uses my code! evaluating mem- bership leakage risks in code models. IEEE Transactions on Software Engineering (2024)

    2024

  117. [125]

    Burak Yetiştiren, Işık Özsoy, Miray Ayerdem, and Eray Tüzün. 2023. Eval- uating the code quality of ai-assisted code generation tools: An empirical study on github copilot, amazon codewhisperer, and chatgpt. arXiv preprint arXiv:2304.10778 (2023)

    2023 arXiv

  118. [126]

    Seunghoon Woo, Dongwook Lee, Sunghan Park, Heejo Lee, and Sven Dietrich

  119. [127]

    In 30th USENIX Security Symposium (USENIX Security 21)

    V0Finder: Discovering the Correct Origin of Publicly Reported Software Vulnerabilities. In 30th USENIX Security Symposium (USENIX Security 21) . 3041– 3058

  120. [128]

    Xin Zhou, Sicong Cao, Xiaobing Sun, and David Lo. 2024. Large Language Model for Vulnerability Detection and Repair: Literature Review and Roadmap. arXiv preprint arXiv:2404.02525 (2024)

    2024 arXiv

  121. [129]

    Yi Wu, Nan Jiang, Hung Viet Pham, Thibaud Lutellier, Jordan Davis, Lin Tan, Petr Babkin, and Sameena Shah. 2023. How effective are neural networks for fixing security vulnerabilities. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analys...

    2023

  122. [130]

    Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated pro- gram repair in the era of large pre-trained language models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 1482–1494

    2023

  123. [131]

    Yuxuan Zhu, Antony Kellermann, Akul Gupta, Philip Li, Richard Fang, Ro- han Bindu, and Daniel Kang. 2024. Teams of llm agents can exploit zero-day vulnerabilities. arXiv preprint arXiv:2406.01637 (2024)

    2024 arXiv

  124. [132]

    Dapeng Yan, Yuqing Niu, Kui Liu, Zhe Liu, Zhiming Liu, and Tegawendé F Bissyandé. 2021. Estimating the attack surface from residual vulnerabilities in open source software supply chain. In 2021 IEEE 21st International Conference on Software Quality, Reliability and Security (Q...

    2021

  125. [135]

    Haibo Zhang and Kouichi Sakurai. 2021. A survey of software clone detection from security perspective. IEEE Access 9 (2021), 48157–48173

    2021

  126. [136]

    Jie Zhang, Haoyu Bu, Hui Wen, Yongji Liu, Haiqiang Fei, Rongrong Xi, Lun Li, Yun Yang, Hongsong Zhu, and Dan Meng. 2025. When llms meet cybersecurity: A systematic literature review. Cybersecurity 8, 1 (2025), 1–41

    2025

  127. [138]

    Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: a survey for roadmap. ACM Computing Surveys (CSUR) 54, 11s (2022), 1–36

    2022

  128. [139]

    Yuxuan Zhu, Antony Kellermann, Dylan Bowman, Philip Li, Akul Gupta, Adarsh Danda, Richard Fang, Conner Jensen, Eric Ihli, Jason Benn, et al. 2025. CVE- Bench: A Benchmark for AI Agents’ Ability to Exploit Real-World Web Appli- cation Vulnerabilities. arXiv preprint arXiv:2503....

    2025 arXiv

  129. [141]

    Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. 2019. Small world with high risks: A study of security threats in the npm ecosystem. In 28th USENIX Security symposium (USENIX security 19) . 995–1010. A More Detailed Pipeline Results In this section...

    2019

  130. [2021]

    In 2021 IEEE Interna- tional Conference on Software Analysis, Evolution and Reengineering (SANER)

    G-Repo: A tool to support MSR studies on GitHub. In 2021 IEEE Interna- tional Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 551–555

    2021

  131. [2022]

    https://www.blackhat.com/us-22/briefings/schedule/#scaling-the- security-researcher-to-eliminate-oss-vulnerabilities-once-and-for-all-27131 Presentation at Black Hat USA 2022, Las Vegas, NV, August 2022

    2022

  132. [2023]

    In 2023 IEEE International Conference on Systems, Man, and Cybernetics (SMC)

    How secure is code generated by chatgpt?. In 2023 IEEE International Conference on Systems, Man, and Cybernetics (SMC) . IEEE, 2445–2451

    2023

  133. [2024]

    InProceedings of the 20th International Conference on Predictive Models and Data Analytics in Software Engineering

    MoreFixes: A Large-Scale Dataset of CVE Fix Commits Mined through En- hanced Repository Discovery. InProceedings of the 20th International Conference on Predictive Models and Data Analytics in Software Engineering . 42–51

Pith tools

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