Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
16
datasets available to search
ShareScore release 0.9.0
Dataset results
16 results for “software vulnerabilities”
A collection of datasets for software vulnerability detection
<p>This is a collection of datasets that are used for AI-based software vulnerability detection. All the datasets are in the .csv format and each row represents a sample. Each dataset includes a set of functions written in C and the target of each function is either 0 (non-vulnerable) or 1 (vulnerable).</p> <ol> <li><strong>data_C_Lin2017_test.csv:</strong> <ul> <li>Reference paper: <a href="https://dl.acm.org/doi/10.1145/3133956.3138840">Vulnerability Discovery with Function Representation Learning from Unlabeled Projects</a>, 2017.</li> <li>Data source on GitHub: <a href="https://github.com/DanielLin1986/function_representation_learning">https://github.com/DanielLin1986/function_representation_learning</a></li> <li>This dataset includes 44 vulnerable and 577 non-vulnerable functions from the LibPNG project.</li> </ul> </li> <li><strong>data_C_LineVul_test.csv:</strong> <ul> <li>Reference paper: <a href="https://ieeexplore.ieee.org/document/9796256">LineVul: A Transformer-based Line-Level Vulnerability Prediction</a>, 2022.</li> <li>Data source on Hugging Face: <a href="https://huggingface.co/datasets/Partha117/LineVul_Test_Dataset">https://huggingface.co/datasets/Partha117/LineVul_Test_Dataset</a></li> <li>This dataset includes 1055 vulnerable and 17809 non-vulnerable functions.</li> </ul> </li> <li><strong>data_C_PrimeVul_test.csv:</strong> <ul> <li>Reference paper: <a href="https://arxiv.org/abs/2403.18624">Vulnerability Detection with Code Language</a><br><a href="https://arxiv.org/abs/2403.18624">Models: How Far Are We?</a> 2024.</li> <li>Data source on GitHub: <a href="https://github.com/DLVulDet/PrimeVul">https://github.com/DLVulDet/PrimeVul</a></li> <li>From the data source, the primevul_test.jsonl was used to created this dataset.</li> <li>This dataset includes 695 vulnerable and 25213 non-vulnerable functions.</li> </ul> </li> <li><strong>data_C_Choi2017_test.csv:</strong> <ul> <li>Reference paper: <a href="https://www.ijcai.org/proceedings/2017/0214.pdf">End-to-End Prediction of Buffer Overruns from Raw Source Code</a><br><a href="https://www.ijcai.org/proceedings/2017/0214.pdf">via Neural Memory Networks</a>, 2017.</li> <li>Data source on GitHub: <a href="https://github.com/mjc92/buffer_overrun_memory_networks">https://github.com/mjc92/buffer_overrun_memory_networks</a></li> <li>From GitHub, all the data in trainnig_100.txt, test_1_100.txt, test_2_100.txt,test_3_100.txt,test_4_100.txt, and corresponding _labels.txt files are combined to create this dataset.</li> <li>This dataset includes 7054 vulnerable and 6946 non-vulnerable functions.</li> </ul> </li> <li><strong>data_C_Devign_test.csv:</strong> <ul> <li>Reference paper: <a href="https://proceedings.neurips.cc/paper_files/paper/2019/file/49265d2447bc3bbfe9e76306ce40a31f-Paper.pdf">Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks</a>, 2019</li> <li>Data source on Hugging Face: <a href="https://huggingface.co/datasets/claudios/code_x_glue_devign">https://huggingface.co/datasets/claudios/code_x_glue_devign</a></li> <li>From Hugging Face, all the data in train, validation, and test are combined to create this dataset.</li> <li>This dataset includes 12460 vulnerable and 14858 non-vulnerable functions.</li> </ul> </li> <li><strong>data_C_Ours_{train,test}.csv:</strong> <ul> <li>This dataset is manually collected from projects on GitHub that have registered CVEs into NVD from 2002 to 2023. The 6,766 non-vulnerable code functions are extracted from the <a href="https://dl.acm.org/doi/10.1145/3607199.3607242">DiverseVul dataset</a> to increase the code diversity. </li> <li>This training set includes 5413 vulnerable and 5413 non-vulnerable functions.</li> <li>The test set includes 1353 vulnerable and 1353 non-vulnerable functions.</li> </ul> </li> </ol>
Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction [dataset]
<p>This dataset contains the extension of a publicly available dataset that was published initially by Ferenc et al. in their paper:</p> <p><em>“Ferenc, R.; Hegedus, P.; Gyimesi, P.; Antal, G.; Bán, D.; Gyimóthy, T. Challenging machine learning algorithms in predicting vulnerable javascript functions. 2019 IEEE/ACM 7th InternationalWorkshop on Realizing Artificial Intelligence Synergies in Software Engineering (RAISE). IEEE, 2019, pp. 8–14.”</em></p> <p>The dataset contained software metrics for source code functions written in JavaScript (JS) programming language. Each function was labeled as vulnerable or clean. The authors gathered vulnerabilities from publicly available vulnerability databases.</p> <p>In our paper entitled: “<strong>Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction</strong>” and cited as:</p> <p><em>“Kalouptsoglou I, Siavvas M, Kehagias D, Chatzigeorgiou A, Ampatzoglou A. Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction. Entropy. 2022; 24(5):651. <a href="https://doi.org/10.3390/e24050651">https://doi.org/10.3390/e24050651</a>”</em></p> <p>, we presented an extended version of the dataset by extracting textual features for the labeled JS functions. In particular, we got the dataset provided by Ferenc et al. in CSV format and then we gathered all the GitHub URLs of the dataset's functions (i.e., methods). Using these URLs, we collected the source code of the corresponding JS files from GitHub. Subsequently, by utilizing the start and end line information for every function, we cut off the code of the functions. Each function was then tokenized to construct a list of tokens per function.</p> <p>To extract text features, we used a text mining technique called sequences of tokens. As a result, we created a repository with all methods' source code, the token sequences of each method, and their labels. To boost the generalizability of type-specific tokens, all comments were eliminated, as well as all integers and strings, which were replaced with two unique IDs.</p> <p>The dataset contains 12,106 JavaScript functions, from which 1,493 are considered vulnerable.</p> <p>This dataset was created and utilized during the Vulnerability Prediction Task of the Horizon2020 IoTAC Project as training and evaluation data for the construction of vulnerability prediction models. The dataset is provided in the csv format. Each row of the csv file has the following parts:</p> <ul> <li>Label: Flag with values ‘1’ for vulnerable and ‘0’ for non-vulnerable methods</li> <li>Name: The name of the JavaScript method</li> <li>Longname: The longname of the JavaScript method</li> <li>Path: The path of the file of the method in the repository</li> <li>Full_repo_path: The GitHub URL of the file of the method</li> <li>TokenX: Each next row corresponds to each token included in the method</li> </ul>
Software vulnerability detection datasets - function/method level
<p>This dataset is for software vulnerability detection and includes source code in eight programming languages (C, C++, Java, JavaScript, Go, PHP, Ruby, Python). All data is collected from GitHub.</p><p>data<i>{programming language}_vul.json: a set of vulnerable code samples in a certain programming language.</i></p><p>data<i>{programming language}_patch.json: a set of patching code samples in a certain programming language.</i></p><p> </p><p>Each source code sample includes the following 16 properties: </p><p><strong>index</strong>: index of code. If is_vulnerable==False, this index indicates that this code is a patch of the indexing vulnerable code.</p><p><strong>code</strong>: raw source code (may include comments).</p><p><strong>is_vulnerable</strong>: the code is vulnerable (<strong>True</strong>) or a patch (<strong>False</strong>).</p><p><strong>programming_language</strong>: programming language of the code.</p><p><strong>method_name</strong>: name of the method.</p><p><strong>file_name</strong>: name of the file where the source code is extracted.</p><p><strong>repo_url</strong>: url of the project repository.</p><p><strong>repo_owner</strong>: owner of the repository.</p><p><strong>committer</strong>: developer who pushed the commit.</p><p><strong>committer_date</strong>: date when the commit was pushed.</p><p><strong>commit_msg</strong>: the commit message.</p><p><strong>cwe_id</strong>: If is_vulnerable==True, the CWE id; otherwise None.</p><p><strong>cwe_name</strong>: If is_vulnerable==True, the name of corresponding CWE; otherwise None.</p><p><strong>cwe_description</strong>: If is_vulnerable==True, the description of corresponding CWE; otherwise None.</p><p><strong>cwe_url</strong>: If is_vulnerable==True, the url to obtain more details of corresponding CWE; otherwise None.</p><p><strong>cve_id</strong>: If is_vulnerable==True, the CVE id; otherwise None.</p>
Replication Package for the Paper Titled "How Well Do Software Practitioners Fix Code Vulnerabilities with Different Types of Explanations?"
<p>This is a replication package for the article 'How Well Do Software Practitioners Fix Code Vulnerabilities with Different Types of Explanations?'. The survey questions can be found here, and we encourage the survey to be re-used.</p> <p>We also include survey data (with demographic data and qualitative responses removed for anonymity reasons).</p> <p>The project team consists of Tracy Hall, Emily Winter, Fahad Al Debeyan (Lancaster University) and Lech Madeyski (Wroclaw University of Science and Technology). If you have any questions about the re-use of this survey, feel free to contact Fahad at <a href="mailto:e.winter@lancaster.ac.uk">f.aldebeyan@lancaster.ac.uk</a>.</p>
Replication Package for the Paper Titled "Emerging Results in Using Explainable AI to Improve Software Vulnerability Prediction"
<p>This is a replication package for the paper titled "Emerging Results in Using Explainable AI to Improve Software Vulnerability Prediction".</p>
The Secret Life of Software Vulnerabilities: A Large-Scale Empirical Study
<p>Online appendix of the paper entitled: "The Secret Life of Software Vulnerabilities: A Large-Scale Empirical Study". It contains all scripts and data required to replicate the four research questions of the study.</p> <p>Abstract: Software vulnerabilities are weaknesses in source code that can be potentially exploited to cause loss or harm. While researchers have been devising a number of methods to deal with vulnerabilities, there is still a noticeable lack of knowledge on their software engineering life cycle, for example how vulnerabilities are introduced and removed by developers. This information can be exploited to design more effective methods for vulnerability prevention and detection, as well as to understand the granularity that these methods should aim at. To investigate the life cycle of software vulnerabilities, we focus on how, when, and under which circumstances vulnerabilities are introduced in software projects, as well as whether, after how long, and how they are removed. We consider 4,097 vulnerabilities with public patches from the National Vulnerability Database—pertaining to 1,163 open-source software projects on GITHUB—and define a six-step process that involves both automated parts (e.g., using the SZZ algorithm to find the vulnerability-inducing commits) and manual analyses (e.g., how vulnerabilities were fixed). The investigated vulnerabilities can be classified in 148 categories, take on average 4.19 commits before being introduced, and remain unfixed for a median of 1,506.50 commits and 691.50 days. Most of them are introduced by developers with high workload, often when doing maintenance activities, and removed with mostly with the addition of new source code aiming at implementing further checks on inputs. We conclude by distilling practical implications on when and how vulnerability detectors should work to better assist developers in early detecting these issues.</p>
CVEfixes Dataset: Automatically Collected Vulnerabilities and Their Fixes from Open-Source Software
<p><em>CVEfixes</em> is a comprehensive vulnerability dataset that is automatically collected and curated from Common Vulnerabilities and Exposures (CVE) records in the public <a href="https://nvd.nist.gov/">U.S. National Vulnerability Database (NVD)</a>. The goal is to support data-driven security research based on source code and source code metrics related to fixes for CVEs in the NVD by providing detailed information at different interlinked levels of abstraction, such as the commit-, file-, and method level, as well as the repository- and CVE level.</p> <p>This release, v1.0.8, covers all published CVEs up to 23 July 2024. All open-source projects that were reported in CVE records in the NVD in this time frame _and_ had publicly available git repositories were fetched and considered for the construction of this vulnerability dataset. The dataset is organized as a relational database and covers 12107 vulnerability fixing commits in 4249 open source projects for a total of 11873 CVEs in 272 different Common Weakness Enumeration (CWE) types. The dataset includes the source code before and after changing 51342 files and 138974 functions. The collection took 48 hours with 4 workers (AMD EPYC Genoa-X 9684X).</p> <p>This repository includes the SQL dump of the dataset, as well as the JSON for the CVEs and XML of the CWEs at the time of collection. The complete process has been documented in the paper <em>"CVEfixes: Automated Collection of Vulnerabilities and Their Fixes from Open-Source Software"</em>, which is published in the Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE '21). You will find a copy of the paper in the Doc folder. </p> <p><em><strong>Citation and Zenodo links</strong></em></p> <p>Please cite this work by referring to the published paper:</p> <ul> <li>Guru Bhandari, Amara Naseer, and Leon Moonen. 2021. CVEfixes: Automated Collection of Vulnerabilities and Their Fixes from Open-Source Software. In Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE '21). ACM, 10 pages. <a href="https://doi.org/10.1145/3475960.3475985">https://doi.org/10.1145/3475960.3475985</a></li> </ul> <pre><code>@inproceedings{bhandari2021:cvefixes, title = {{CVEfixes: Automated Collection of Vulnerabilities and Their Fixes from Open-Source Software}}, booktitle = {{Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE '21)}}, author = {Bhandari, Guru and Naseer, Amara and Moonen, Leon}, year = {2021}, pages = {10}, publisher = {{ACM}}, doi = {10.1145/3475960.3475985}, copyright = {Open Access}, isbn = {978-1-4503-8680-7}, language = {en} }</code></pre> <p>The dataset has been released on Zenodo with DOI:<a href="https://doi.org/10.5281/zenodo.4476563">10.5281/zenodo.4476563</a>. The GitHub repository containing the code to automatically collect the dataset can be found at <a href="https://github.com/secureIT-project/CVEfixes">https://github.com/secureIT-project/CVEfixes</a>, released with DOI:<a href="https://doi.org/10.5281/zenodo.5111494">10.5281/zenodo.5111494</a>.</p>
Unveil the Mystery of Critical Software Vulnerabilities - Dataset
<p>This repository contains the dataset and the scripts used to collect the dataset in our paper</p> <p> </p> <p><strong>Unveil the Mystery of Critical Software Vulnerabilities</strong><br><br>Shengyi Pan, Lingfeng Bao, Jiayuan Zhou, Xing Hu, Xin Xia, Shanping Li</p> <p>FSE 2024 (industry)</p> <p> </p> <p>We provide a <strong>README.md</strong> that explains the usage of each file and the dataset format.</p>
Current state of vulnerability handling from the perspective of software operators and developers: semi-structured interviews
<p>This archive contains the transcripts of semi-structured interviews, conducted as part of the study "Leveraging Fine-grained Telemetry Data for the Detection and Prevention of Vulnerability Exploits" by Konrad Ponichtera and Sebastian Proksch. The goal of the interviews was to collect insights about the current state of vulnerability handling in the software engineering industry and identify improvement possibilities from the perspective of the system operator.</p> <p>The interviews have been conducted with ten software engineers with system administration/operation backgrounds, meaning that either they perform system administration/operation as part of their responsibilities, or used to do so in the past. Each participant has been assigned an identifier from P1 to P10. Their roles and industry experience have been disclosed in the attached CSV file with the questionnaire responses.</p> <h1>Interview structure</h1> <p>The interviews were conducted online, and transcribed to the text file, which was then reviewed and pseudonymized. Each interview took approximately one hour. During each interview, the participants were asked to look into a problem of system vulnerabilities from the perspective of a system operator, who can configure and monitor the infrastructure, as well as deploy the applications. The participants were also informed that the operator cannot modify the applications' source code and artifacts. Then the participants were asked seven open questions about the status quo of vulnerability handling in software engineering and its three aspects of awareness, impact, and mitigation. The interviewees responded in accordance with their knowledge and experience.</p> <p>Afterwards, the researcher guiding the session introduced the proposed system to the interviewees, by describing its goal and functionality. To avoid the moderator acceptance bias, we explained that the system was designed within the Software Engineering Research Group of Delft University of Technology. The mitigation of social desirability bias has been achieved by describing the actions taken by an imaginary operator named Albert.</p> <p>After going through the wireframes of the operator's dashboard interface and describing the content of each screen, the participants were asked to follow a supervised walkthrough, where they played the role of an operator. They were presented with a hypothetical situation, where a critical vulnerability, similar to the <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2021-44228" target="_blank" rel="noopener">Log4Shell</a> appears on the dashboard. During this part, the guiding researcher was streaming the window of a wireframe editor. The interviewees were then asked to follow a think-aloud protocol, and indicate their actions as they "use" the system. Meanwhile, the researcher made changes to the wireframes to simulate the effect of the participants' actions.</p> <p>After the walkthrough, participants filled out a System Usability Scale (SUS) questionnaire and were asked additional questions about the impact the proposed system would have on their vulnerability awareness, impact analysis, and mitigation capability.</p> <h1>Files</h1> <p>The archive contains three types of artifacts from the interview: pseudonymized transcripts, the questionnaire and the wireframes.</p> <h2>Transcripts</h2> <p>The <em>transcripts</em> directory contains ten text files with pseudonymized interview transcripts. In each file, the parts spoken by the interviewing researcher have been prepended with "R:", while the parts spoken by the interviewee have been prepended by the interviewee's identifier.</p> <h2>Questionnaire</h2> <p>The CSV file contains the answers participants gave at the start of the interview. <br>Each participant was asked to provide their current job title and how many years they worked in the software engineering industry. They were also asked to specify which DevOps tools and technologies they used, and what system operator tasks they had a chance to do during their career. The goal of these questions was to estabilsh the interviewee's system operation background. Finally, after the prototype walkthrough, participants filled out SUS questionnaires, the results of which are included in the PDF.</p> <h2>Wireframes</h2> <p>The <em>wireframes</em> directory contains diagrams in DrawIO format (also exported to PDF), used during the interview.<br>The vision GUI wireframes were used to introduce participants to what the envisioned system would look like.<br>The walkthrough wireframes were used during the semi-supervised walkthrough scenario, where the interviewing researcher modified them following the participants' actions.</p>
What if Smart Contracts Could Whisper their Weaknesses: From Software Metrics to Vulnerability Classification
<p>This repository contains the code and data associated with our submission to FSE 2025, entitled 'What if Smart Contracts Could Whisper their Weaknesses: From Software Metrics to Vulnerability Classification'. If the paper is accepted for publication, the authors' information and affiliations will be made publicly available in accordance with the conference proceedings.</p>
Dataset: Automatic Derivation of Vulnerability Models for Software Architectures
<p>Dataset for our publication "<em>Automatic Derivation of Vulnerability Models for Software Architectures</em>"</p>
Habit Building Software Application to Increase Engagement of Vulnerable Populations in the National Diabetes Prevention Program (NDPP) Lifestyle Change Program (LCP)
ClinicalTrials.gov study NCT06656273. IPD Sharing: NO. Countries: 1. Publications: 0.
Reality Check: Assessing The Limits of GPT-4 in Fixing Real-World Software Vulnerabilities [Online Appendix]
<p>Online appendix for the paper entitled "Reality Check: Assessing The Limits of GPT-4 in Fixing Real-World Software Vulnerabilities"</p><p>This package includes</p><ul><li>The used prompts in our prompt engineering workflow.</li><li>Detailed results of our pilot evaluation</li><li>Results from the paper</li></ul>
Dataset for software vulnerability detection
<ol><li>raw_C.csv<ul><li>Raw (it may includes comments) source code in C.</li><li>Attributes:<ul><li>cwe_id</li><li>name: method name</li><li>repo_name: repository name</li><li>repo_url: repository url</li><li>old_path</li><li>file_change_id: used as a key in SQLite</li><li>method_change_id: used as a key in SQLite</li><li>code: source code</li><li>before_change: indicates whether the code is vulnerable (1) or not (0)</li></ul></li></ul></li><li>clean_C.csv<ul><li>Pre-processed (removed comments) source code in C.</li><li>Attributes (the same as raw_C.csv).</li></ul></li></ol>
Supplementary materials of the paper entitled: "Advanced Vulnerability Scanning for Open Source Software: Detection and Mitigation of Log4j Vulnerabilities"
<p>Evaluation dataset across 140 scans of 28 open-source repositories.</p>
Data from: A Socio-technical Perspective on Software Vulnerabilities: A Causal Analysis
<p>This data package contains supplemental material data for the under review TSE submission: A Socio-technical Perspective on Software Vulnerabilities: A Causal Analysis. The restricted access requirement will be lifted upon approval of the manuscript.</p> <p>The comprehensive explanation of this dataset can be found at: https://sailuh.github.io/causal_commit_flow_docs</p> <p>The following briefly describes the contents of the folders. The analysis presented in the manuscript requires the following:</p> <ul> <li>Git Log </li> <li>Mailing List</li> <li>Software Vulnerabilities (NVD Feed)</li> </ul> <p>This data is provided to a mining software repository tool, Kaiaulu. The data specifications and configuration parameters are defined in the OpenSSL project configuration file (.yml), also included in this package. </p> <p>An R notebook in Kaiaulu, taking the dataset above + project configuration file, can then perform the first analysis step:</p> <p>https://github.com/sailuh/kaiaulu/blob/master/vignettes/issue_social_smell_showcase.Rmd</p> <p>The file 1_openssl_social_smells_timeline.csv is generated as an output of this R Notebook, and included in the causal_model folder of this package. The following files in this folder numbered 2 through 16, describe transformation steps using Excel, Python scripts, and Tetrad (also an open source tool). These are described conceptually in the manuscript, but in more detail in the comprehensive explanation of this dataset linked at the start. </p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.