## 3 Dataset Creation Process
### Filtering Results Through Keywords  
We collected commits from GitHub via BigQuery from 366,231 projects. Given the vast amount of information involved in such a large-scale tracking task, we filtered out commits that were clearly unrelated to security by applying a set of regular expression rules. When it comes to creating regular expressions for this research, we drew inspiration from a previous study [23], where the keywords used served as a starting point for our work. Considering the potential for generating false positives to the best of our knowledge, we removed certain keywords and added others that we identified as missing to enhance coverage. This process resulted in a more efficient list of keywords. To ensure comprehensive coverage of potential vulnerabilities, our regular expression rules encompass a wide range of expressions and keywords related to security issues, including terms like vulnerability, CVE, SQLi (SQL Injection), and XSS (Cross-Site Scripting) (refer to Table 2 for a portion of the rule set). As a result, we created a dataset of GitHub commits. Furthermore, it is shared that some of the CVEs that are fixed and critical vulnerabilities are covered in this dataset (refer to Table 3). Table 2 illustrates some sets of examples of regular expressions designed to identify and filter vulnerable commits in source code repositories. These expressions target specific keywords and patterns commonly associated with software vulnerabilities. By systemat \begin{table}
\begin{tabular}{l l} \hline
**Rule** & **Regular Expression** \\ \hline \multirow{7}{*}{vulnerabilities} & (?i)(denal.of.service \(\mid\)\(\backslash\)bXCE\(\setminus\)b\(\mid\) remote.code.execution \(\mid\)\(\backslash\)bopen.redirect \(\mid\)OSVDB\(\mid\)\(\backslash\)bvn\(\mid\)\(\setminus\)bCVE \\  & \(\setminus\)b\(\mid\)\(\setminus\)bCWE\(\setminus\)b\(\mid\)\(\setminus\)bXSS\(\setminus\)b\(\mid\)\(\setminus\)bReDoS\(\setminus\)b\(\mid\)\(\setminus\)bNVD\(\setminus\)b\(\mid\)\(\times\)frame\(-\)options \(\mid\)vulner[a-z]+ \(\mid\)cross.site \\  & exploit \(\mid\) malicious \(\mid\)directory.travarsal \(\mid\)bRCE\(\setminus\)b\(\mid\)\(\setminus\)bDoS\(\setminus\)b\(\mid\)\(\setminus\)bDoS\(\setminus\)b\(\mid\)\(\setminus\)bXSRF\(\setminus\)b\(\mid\)\(\setminus\)bCSRF\(\setminus\)b\(\mid\)\(\setminus\)bXSS\(\setminus\)b\(\mid\) clickjack \(\mid\)session. Aviation \(\mid\)hijack \(\mid\)\(\setminus\)bausecure \(\mid\)\(\setminus\)bcross\(-\)origin\(\setminus\) \\  & b \(\mid\) unauthor[z \(\mid\)s]ed \(\mid\) infinite.loop \(\mid\) authenticat(?e \(\mid\)ed \(\mid\)ion) \(\mid\)\(\setminus\)b(in)?secur(e \(\mid\)ity) \(\mid\)race.condition \(\mid\) \\  & dead.code \(\mid\)deadlock \(\mid\) infinite.loop \(\mid\) uncaught.exception \(\mid\) divide.by.zero \(\mid\) null.pointer.dereference \(\mid\) \\  & double.free \(\mid\) buffer.overflow \(\mid\) sql.injection \(\mid\) off-by-one.error \(\mid\) encoding.error \(\mid\)\(\setminus\)bcsrf\(\setminus\)b\(\mid\) \\  & incorrect.synchronization \(\mid\) incorrect.calculation \(\mid\) deserialization.of.untrusted.data \(\mid\) \\  & leftover.debug.code \(\mid\) missing.handler)’) \\ \hline \multirow{3}{*}{mobile} & (?i)(information.exposure \(\mid\) sensitive.(?:information \(\mid\) data \(\mid\) communication) \(\mid\) unnecessary.privileges \(\mid\) \\  & improper.(?:validation \(\mid\) verification \(\mid\) export \(\mid\) authorization) \(\mid\) cleartext \(\mid\) private.personal.information \(\mid\) \\ \cline{1-1}  & private.information \(\mid\) personal.information \(\mid\) shared.resource \(\mid\) logic.bomb \(\mid\) time.bomb \(\mid\) hard[- \\ \cline{1-1}  & ]coded.credentials \(\mid\) hard[- \(\mid\)coded \(\mid\) access.control)’) \\ \hline \end{tabular}
\end{table} 
Table 2: Examples of regular expressions used to filter vulnerable commits.