## 4 Materials and Methods
### Inputs
Denoting vulnerability descriptions in SARD as \(D_{V}\) and those from the OWASP Top 10 as \(D_{OWASP}\), the TF-IDF is calculated according to Equation (1):  
\[\text{tf-idf}(D_{V},D_{OWASP})=\text{tf}(D_{V},D_{OWASP})\times\log\frac{N}{ \text{df}(D_{OWASP})}, \tag{1}\]  
where \(\text{tf}(D_{V},D_{OWASP})\) represents the term frequency in \(D_{V}\), \(N\) is the total number of vulnerability descriptions, and \(\text{df}(D_{OWASP})\) is the number of occurrences of each term in \(D_{OWASP}\). After extracting key terms using TF-IDF from both data sets, cosine similarity was applied (as expressed in Equation (2)) in order to calculate the average similarity score between \(D_{V}\) and \(D_{OWASP}\), yielding a result of 65.7%. \[\cos(\theta)=\frac{\vec{D_{V}}\cdot D_{OWASP}}{\|\vec{D_{V}}\|\|D_{OWASP}\|}, \tag{2}\]  
where \(\vec{D_{V}}\) and \(D_{OWASP}\) are the TF-IDF vectors, and \(\|\vec{D_{V}}\|\) and \(\|D_{OWASP}\|\) are their respective norms. Vulnerabilities with similarity scores below this threshold were discarded, being considered to be redundant or obsolete. Following this process, 9867 vulnerable code fragments for PHP, 4677 for Java, 5019 for C, and 4038 for C++ were collected. Figure 2 illustrates the final number of CWEs associated with each programming language. To structure the data set under the QA architecture of BERT, the code samples for each programming language were organized into tuples \(Q_{V},C_{V},A_{V}\). For \(Q_{V}\), each vulnerable code fragment was aligned with its respective programming language and reformulated into an argumentative format, integrating both the question and the code fragment into a unified query. \(C_{V}\) was constructed as a single context string by concatenating the vulnerable code, the remediation or mitigation description provided by SARD based on the CWE, and the reconstructed secure code. To enhance \(C_{V}\), the static code analysis tool SonarQube [45] was employed. Using its web API, vulnerable code fragments from the SARD data set were analyzed to detect known patterns across the supported programming languages (PHP, Java, C++, and C). Customized detection rules were designed to ensure the precise identification of CWE patterns within the data set. The functionality provided by SonarQube allowed for efficient filtering of relevant code fragments. For each sample, only the lines directly associated with the identified vulnerability were retained and incorporated into \(C_{V}\). This process included the vulnerable line, a detailed remediation description, and the reconstructed secure code. Extraneous elements unrelated to the vulnerability were excluded to maintain clarity and precision. When SonarQube could not identify or reconstruct the secure version of the code, its approximations served as a foundation for further manual analysis. Adhering to the OWASP Top 10 and SANS Top 25 security standards, experts manually reviewed and reconstructed secure code for cases involving complex patterns or when SonarQube failed to detect insecure fragments. The final composition of \(C_{V}\) combined both the vulnerable code and the reconstructed secure code, accompanied by detailed remediation instructions. Similarly, \(A_{V}\) was derived by extracting the remediation description from \(C_{V}\), providing an actionable response to the identified vulnerability. The indices \(A_{V_{[\text{START}]}}\) and \(A_{V_{[\text{END}]}}\) were included to indicate the  
Figure 2: Number of CWEs associated with each programming language. The total exceeds the number of samples per language, as SARD frequently links multiple weaknesses to a single vulnerability (with up to six identified in one case). exact location within \(C_{V}\) where the description, remediation, or mitigation details of the code are presented.