# Detection of Software Security Weakness Using Cross-Language Source Code Representation (CLaSCoRe)
## 4 Experimental Results
### Dataset Processing  
The NIST dataset with \"vulnerable\" and \"not vulnerable\" code written in C, C++, Java, and C# was sanitized, and all comments and pre-processing directives were removed. We isolated \"vulnerable\" functions and \"not vulnerable\" functions per CWE, for the four programming languages, making use of NIST developers' convention to name \"vulnerable\" functions with \"GOOD\" and \"not vulnerable\" functions with \"BAD\". Examples \begin{table}
\begin{tabular}{c c c} \hline \hline
**Scenario** & **Training Dataset** & **Testing Dataset** \\ \hline C\# to C\# & C\# code snippets & C\# code snippets \\ Other to C\# & C, C++, Java code snippets & C\# code snippets \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Training scenarios on the NIST dataset with “vulnerable” and “not vulnerable” code. of \"vulnerable\" functions written in Java and C# are displayed in Table 2. We observe similar programming behavior in writing two pieces of code in C# and Java, specifically in the order of operations and usage of instructions, despite the lexical differences between these two programming languages. The processing units in the learning process represent functions or methods, as they are defined to include the entire context of vulnerabilities, a characteristic of the NIST suite. In addition, the clustering of the word vectors resulting from the Word2 Vec word embedding process adds a layer of abstraction to the source code written in different programming languages, preserving the semantic meaning. We observe in Table 2 that the token name \"Runtime\" in the Java code snippets and the token named \"Process\" in the C# code of a CWE 78 vulnerable function, are part of the same cluster, which means they will have the same value in the CLaSCoRe representation, as they would represent the same keyword. The clustering of the word vector is, in this way, reducing to some extent the dependency on the programming language. We have identified 50 CWEs, out of the 178 CWEs in the NIST Software Assurance Reference Dataset (SARD) suite, supported with code in all four programming languages, and only 8 CWEs for which we can sum up a number of more than 1500 samples written in C, C++, and Java, with at least 250 samples per each of the four programming languages. The CWE 134 vulnerability samples have also been excluded, as they behave as outliers for all previous [8; 35; 36] and current experiments, producing low-performance results. The list of remaining CWEs included in the experiments and their associated numbers of vulnerable samples are illustrated in Table 5.  
For each programming language, we selected the methods and functions named \"GOOD\" in the NIST dataset and labeled them as \"not vulnerable\". The number of \"not vulnerable\" samples, after being represented in a CLaSCoRe format and removing duplicated entries, are represented in Table 6. The \"not vulnerable\" functions contain secure versions of all the vulnerable code snippets, meaning that, in the training dataset used for a specific CWE, we included the \"vulnerable\" code snippets to the respective CWE, and secured code snippets that were highly relevant to the respective CWE (fixing that vulnerability) and code which were not related to the CWE, but were free of other CWEs present in the NIST suite. For the learning scenarios presented below, we retained a randomized 80% of the dataset samples for learning and the rest of the 20% for testing. Cross-validation using 5 groups of samples, with similar sizes, from the training set was enabled to support the calculation of accuracy means and standard deviations in both scenarios.