# Go Source Code Vulnerability Detection Method Based on Graph Neural Network
## 3 Preliminaries
### Graph-Level Features  
To comprehensively extract graph-level features and global structures, we apply the following operations during the preprocessing stage before extracting graph-level features.  
(1) Identify potential concurrent functions and generate slicing sequences: Due to Go's concurrency features, vulnerabilities in Go programs are often concurrency-related. We perform precise control flow and data flow analysis on the AST to determine control dependencies and data dependencies, allowing us to identify concurrency patterns in the program. These slicing sequences help capture execution paths while significantly reducing code size.  
(2) Generate sliced code based on slicing sequences: The Go language provides interfaces and type systems, which facilitate module interaction. However, existing slicing methods often disrupt source code structure, altering semantic dependencies and affecting vulnerability detection accuracy. To address this, we design a Go program pruning method that ensures structural integrity. This method performs differential analysis (diff operation) between the slice and the original source code, supplementing the sliced code structure based on the source code structure. As a result, the pruned code maintains semantic completeness.  
(3) Standardize variable naming: To improve the accuracy and consistency of program analysis, we perform standardized renaming of user-defined variables and functions. This step facilitates better comprehension and modeling of source code, significantly reduces the token count, and enhances the efficiency of neural network training, as well as the precision of automated vulnerability detection tools. Specifically, we adopt a one-to-one mapping strategy by replacing user-defined variables with symbolic names (e.g., \"VAR1\", \"VAR2\") and renaming functions similarly (e.g., \"FUN1\", \"FUN2\"). Variable renaming is performed with respect to lexical scope and lifetime information to ensure that variables with the same name in different scopes are not mistakenly conflated, thereby avoiding semantic ambiguity. Moreover, given that Go supports closures, goroutines, and cross-file function calls, we carefully model inter-procedural variables. We track the propagation and scope transitions of such variables across functions to ensure their original semantic context is maintained throughout the abstraction and renaming process.  
(4) Complete sliced code structures to ensure independent execution: For Go programs, we need to restore goroutines, their corresponding channels, and deferred function calls to maintain logical consistency. Algorithm 1 illustrates the process, where the SliceCode \(S\) is derived through Steps 1, 2, and 3.  
```
Input: SliceCode S; Output: CompletedCode C;
1\(C\leftarrow[]\);
2 hasMain\(\leftarrow\) fasle;
3 foreach line l in Sdo
4 append l to C;
5 ifisMainStart(l)then
6\(hasMain\leftarrow\) true;
7
8 end if
9
10 end for
11
12 forach line l in Sdo
13 ifisGoStmt(l)then
14\(gName\gets extractGroutineName(l)\);
15 ifnot hasRecvStmt(C,gName)then
16 append genRecvStmt(gName) to C;
17
18 end if
19
20 end for
21
22 end for
23
24 end for
25
26 return C;
```  
**Algorithm 1**Go graph-level feature sliced code completion algorithm.