## 4 Materials and Methods  
To initiate the proposed methodology, the following tuple is considered: questions (\(Q_{V}\)) derived from vulnerable source code, contexts (\(C_{V}\)) that identify the cause of the vulnerability, and answers (\(A_{V}\)) embedded within \(C_{V}\) that explain the issue and define the solution. The list below exemplifies \(Q_{V}\), \(C_{V}\), and \(A_{V}\).  
* \(Q_{V}\): _Why this code is vulnerable?_  
```
1 structfred{inti;};
2 voidfoo(){
3 structfred*ptr=newfred();
4 deleteptr;
5}
```
*\(C_{V}\): _According to CWE-476: NULL Pointer Dereference: the product dereferences a pointer that it expects to be valid, but is instead NULL._  
```
1 structfred{inti;};
2 voidfoo(){
3 structfred*ptr=newfred();
4 deleteptr;
5}
```  
*\(C_{V}\): _According to CWE-476: NULL Pointer Dereference: the product dereferences a pointer that it expects to be valid, but is instead NULL._  
```
1 structfred*ptr=newfred();
2 if(ptr){
3//Usetheallocatedmemory
4 ptr->1=10;//Examplesageftheallocatedmemory
5//Otheroperationsonptrcanbeaddedhere
6}
7 deleteptr;
8}
```  
Building on the aforementioned proposition, the methodology follows the steps delineated in Figure 1. The process begins with the generation of data sets comprising vulnerable source code from languages such as PHP, C, C++, and Java. Subsequently, these data sets are structured into tuples according to the BERT format, namely \(Q_{V}\), \(C_{V}\), and \(A_{V}\), where \(Q_{V}\) refers to questions regarding the vulnerable code, \(C_{V}\) represents the relevant contexts, and \(A_{V}\) includes the start (\(A_{V_{\text{{\sc{ISTARTI}}}}}\)) and end positions (\(A_{V_{\text{{\sc{IENDI}}}}}\)) within \(C_{V}\).  
Following this, FSL tasks are generated by partitioning the data set into a support set (\(\mathcal{S}\)) and a query set (\(\mathcal{Q}\)). In this scenario, \(\mathcal{S}\) is utilized to fine-tune the BERT-based model integrated into the Proto-MAML architecture, while \(\mathcal{Q}\) is used to evaluate its generalization capabilities on unseen examples.  
Subsequently, tokenization of the tuples in the support set \(\{Q_{V},C_{V},A_{V}\}\in\mathcal{S}\) is performed, mapping the start (\(A_{V_{\text{{\sc{ISTARTI}}}}}\)) and end positions (\(A_{V_{\text{{\sc{IENDI}}}}}\)) within \(C_{V}\).  
In the following phase, parameter thawing is executed through an internal loop, selectively unfreezing the pre-trained parameters of BERT transferred to Proto-MAML. This allows for effective adaptation across tasks \(\mathcal{T}_{i}\) over multiple episodes \(\mathcal{T}_{i+1}\), therefore refining the internal representations. During this process, prototypes \(p_{j}\) are calculated for \(\mathcal{S}\), determining the feature space of the tuples and \(A_{V}\), thus preventing parameter degradation and generating a concise version of the context.  
As the episodes progress, the query set \(\mathcal{Q}\) is evaluated by comparing its predicted logits (\(\lambda_{[\text{START}]}\) and \(\lambda_{[\text{END}]}\)) with the prototypes \(p_{j}\). Performance metrics such as the F1-score, Exact Match, and Entropy are used to quantify the effectiveness of the model in generalizing to unseen data, as well as to facilitate local meta-learning.  
Finally, the model undergoes a meta-optimization process across all \(\mathcal{T}_{i}\), minimizing the global meta-loss over \(n\) epochs in an external loop. This tactic aims to enhance its adaptability to unseen tasks, resulting in an optimized Proto-MAML model that is capable of predicting desired questions regarding vulnerable code, as well as associating the context with the response related to the vulnerable line of code and the secure code.  
Sections 4.1-4.3 delve deeper into the methodological blocks.