# Machine Learning-Based Security Pattern Recognition Techniques for Code Developers
## 2 Proposed Architecture  
For organizations with mature and well-organized software development teams, the patterns of writing source code are in general maintained from an application to another, or from a release to another release of the same application. In addition, developers follow periodic programming trainings, where they learn how to implement different functions or workflows in code.  
The inherited culture of programming workflows opens an important opportunity for innovation in CWE patterns identification in source code, by creating a dataset of vulnerable and not-vulnerable pieces of software created by an organization or community of developers, which can be used to predict if newly developed code is vulnerable. When developers omit to write securely a similar piece of code, the method presented in this research is able to indicate the vulnerabilities without using SAST technologies at large scale, thus reducing the commercial tools expenses.  
Highly abstract code provided by different developers are less prone to preserving programmers' cultural patterns inherited within specific communities and may need additional samples in the training datasets, to produce valuable outcomes.  
We are enhancing and expanding the experiments on our multi-language CWE scanner [11; 12] to the entire database with vulnerable source code in C/C++ and Java, provided by NIST, and provide the developers community a solution to identify vulnerabilities in source code written virtually in any programming language, as long as they can use their previous code as a sample dataset for training the classifiers based on machine learning algorithms.  
The NIST reference datasets include vulnerable and non-vulnerable code snippets, as follows:  
* 64,099 test cases for C/C++, covering 118 different CWEs,
* 28,881 test cases for Java, covering 112 CWEs.  
The following architecture is intended to represent source code written in various programming languages (e.g., C/C++, Java) into an unitary conceptualized format, named Intermediate Representation (IR) by convention, less dependent on the lexical structure of each specific language. The IR must still preserve the technical vulnerability patterns(CWEs) as to be detected by machine learning-based classifiers, despite being less dependent on the lexical and semantical structure defined for the programming languages used to write the code.  
The proposed architecture for the multi-language CWE scanner, as presented in Figure 1, is based on a parser able to tokenize the source code in two sections: control flow and data flow. The control flow section maintains the reserved and predefined keywords, functions, classes, methods for the programming language (e.g., if, else, void). The data flow contains all other identifiers from the source code (e.g., names of variables).  
The vocabulary of control flow tokens is selected as indicated in the Section 2.1. The tokenizer creates the control flow section by selecting only the tokens included in the vocabulary, in their order of appearance. The control flow section is represented by a vector of tokens, of size 250. The remaining vector elements, after all tokens in the source code snippet were parsed by the tokenizer, are padded with \"0\".  
The data flow section is represented by a vector of size 250, built as indicated in Section 2.3. The remaining vector elements, after all words not being part of the tokens' vocabulary in the source code snippet received by the tokenizer were parsed, are padded with \"0\".