To characterize the relative importance of different code lines in the program semantic structure, we introduce centrality measures on the Program Dependency Graph (PDG) and perform structural importance weighting for code slices. A PDG is a graph in which nodes correspond to statements and edges represent control and data dependencies; therefore, centrality theory from graph theory and social network analysis provides a principled way to quantify the structural roles of statements.

Unlike social networks where node attributes and relationship semantics can be open-ended and dynamically evolving, program semantics are more deterministic: statement boundaries, dependencies, and execution logic are explicit, and the structural properties of PDG nodes are accordingly well defined. In this setting, overly complex metrics that rely on rich node attributes or high-order statistics may introduce noise and additional computational overhead without yielding more robust representations. Therefore, we adopt three classical and complementary centrality measures—degree, Katz, and closeness centrality—to quantify slice importance, capturing local connectivity, multi-hop influence propagation, and global proximity, respectively, as illustrated in Fig. 4. Accordingly, we compute these three centralities as follows.

Degree Centrality evaluates the importance of a node based on the number of its direct connections to other nodes. For a given code slice i, the degree centrality xiD is defined as:(1)xiD=deg(i)N−1,where deg(i) denotes the degree of the node i, and N is the total number of nodes in the graph. A higher xiD value indicates that the code line involves more intensive data and control dependencies, suggesting it may play a more central role in the program execution flow.

Katz Centrality measures a node’s potential influence by considering not only its immediate neighbors but also the weighted influence of more distant nodes (with attenuation over distance). For a code slice i, the Katz centrality xiK is defined as:(2)xiK=α∑jAijxjK+β,where A is the adjacency matrix of the graph G with eigenvalues λ, α is a damping factor, such that α<1λmax. β is a constant that controls the initial centrality.

Closeness Centrality quantifies how close a node is to all other nodes in the graph by computing the average length of the shortest paths from that node to every other node. For a code slice i, the closeness centrality xiC is given by:(3)xiC=N−1∑j≠id(i,j),where d(i,j) is the shortest path distance between nodes i and j, and N is the total number of nodes in the graph. Nodes with high xiC reside “centrally” in the PDG, implying roles in system-wide data exchange or control coordination.

Using these three centrality measures, we obtain per-line importance scores from complementary perspectives, and use each score to reweight the corresponding line embedding, yielding three centrality-aware feature channels for downstream learning.

This study evaluates VulSCP on C/C++ function-level vulnerability detection. Our main dataset is constructed from three sources:

National Vulnerability Database (NVD) [1]: 1384 vulnerable C/C++ function samples.

We directly use the binary labels provided by the corresponding sources (vulnerable vs. non-vulnerable) without manual relabeling.

During sample collection, we first normalize code (e.g., comment removal and lexical normalization) to improve parsing robustness, and then check whether the normalized function is an exact duplicate of a previously collected sample. If an exact duplicate is found, it is discarded immediately; therefore, the sample counts reported above correspond to the final dataset used in our experiments. To mitigate data leakage, each function sample is assigned to exactly one split (training/validation/test), and all model selection is performed on the validation split only.

To examine cross-dataset generalization, we additionally evaluate on the ReVeal benchmark dataset for vulnerable function detection [48]. A summary of the dataset statistics is provided in Table 1.

The following metrics are used to evaluate the model’s performance on vulnerability detection tasks:

Accuracy: The proportion of correctly predicted samples among all samples. Higher accuracy indicates that the model’s predictions are closer to the ground truth.

We use a random function-level split of the dataset into training, validation, and test sets with a ratio of 7:2:1, rather than adopting a project-wise split. To reduce the effect of training randomness, we keep the data split fixed and repeat the training and evaluation process five times with different random seeds. Unless otherwise specified, all results in this paper are reported as mean ± standard deviation over the five independent runs under the same experimental setting.

The training batch size is set to 32, and the model is trained for 300 epochs with a learning rate of 0.001. The AdamW optimizer is used along with a cross-entropy loss function. In the sequential convolution module, we use 10 parallel convolution branches with kernel heights ranging from 1 to 10 to capture multi-scale local patterns, and set the dropout rate to 0.1 for regularization. The output hidden dimension of the sequential convolution module is set to 128 with a sequence width Wcout of 100. The parallel attention module is configured with 64 input channels ain, 8 parallel groups G, and an output dimension aout of 512. Joern is used to extract program dependency graphs from the source code, networkx is applied to compute graph centrality metrics, and sent2vec is employed to generate embeddings for code segments.

The key hardware and software configurations of the experimental environment include a 12th Gen Intel(R) Core(TM) i9-13900H 2.60 GHz CPU, an NVIDIA GeForce RTX 4060 GPU, 32 GB of RAM, and Ubuntu 22.

For a reproducible runtime comparison with the prompt-based LLM baselines, we specify their deployment environment and end-to-end timing protocol. These methods perform vulnerability detection by sending prompts to deployed large language models through an OpenAI-compatible API. The models were served on a dedicated inference server with 8× NVIDIA H20 96 GB GPUs, an Intel Xeon Platinum 8480 CPU, 64 vCPUs, 768 GB RAM, and a 4 TB NVMe SSD, running Ubuntu Server 22.04.5 LTS, NVIDIA Driver 550.54.14, Docker Engine 28.5.1, and NVIDIA Container Toolkit 1.18.0. Inference was deployed via vLLM v0.18.0. During evaluation, prompt requests were sent from a local client machine to the server, and the reported runtime includes the end-to-end overhead under this deployment setting.

The baseline methods in this study span a variety of vulnerability detection techniques, including traditional rule-based tools, deep learning-based approaches, and cutting-edge large language model (LLM) frameworks. These baselines cover recent and representative developments in vulnerability detection technology.

The rule-based tools include Checkmarx [24], Flawfinder [19], and RATS [25]. Checkmarx identifies vulnerabilities based on expert-defined rules, Flawfinder detects potential security issues using predefined patterns, and RATS performs static analysis to uncover security flaws in source code. These tools scan and analyze code by matching it against pre-established rules and patterns, offering efficient detection of common vulnerabilities.

Deep learning-based approaches include AugSliceVul [49], TokenCNN [26], VulDeePecker [6], SySeVR [8], and Devign [10]. TokenCNN converts source code into vector representations and trains a convolutional neural network (CNN) for vulnerability detection. VulDeePecker extracts code slices and utilizes a bidirectional long short-term memory (BiLSTM) network for classification. SySeVR uses control and data flow to extract program slices and applies a BiLSTM model for detection. Devign performs deep program analysis to extract comprehensive semantic graph representations and employs general-purpose graph neural networks to detect vulnerabilities. These deep learning methods enable the identification of complex code patterns and enhance detection capabilities. AugSliceVul augments the program dependency graph and leverages an optimized CodeBERT encoder to capture richer structural dependencies and semantic context for vulnerability classification.

LLM-based approaches can be classified into two categories. The first involves prompt-based detection, where APIs of cutting-edge LLMs are directly called for zero-shot vulnerability detection. The models used include the Qwen2.5 series with 14, 32, and 72B parameters, the Qwen3 series with 8, 14, and 32B parameters, the GLM4 series with 9 and 32B parameters, and DeepSeek-v3. The second category includes VulLLM [16], which integrates a multi-task learning framework with data augmentation techniques and applies low-rank adaptation (LoRA) for efficient fine-tuning. VulLLM adapts general LLMs for the vulnerability detection task through domain-specific fine-tuning. In this study, four high-performing VulLLM models are selected as baselines, namely VulLLM-CL-7B, VulLLM-CL-13B, VulLLM-SC-7B, and VulLLM-SC-15B. These are based on the CodeLlama-7B/13B and StarCoder-7B/15B architectures and have been fine-tuned with supervised training specifically for vulnerability detection.

These baselines represent a comprehensive spectrum of methodologies, ranging from traditional rule-based systems to advanced deep learning and LLM-based approaches. Comparative results suggest that VulSCP has advantages in detection accuracy, inference efficiency, and the modeling of global semantic features and complex logical dependencies in source code.

In this section, we compare VulSCP with a diverse set of baselines using multiple evaluation metrics. In our experimental setting, increasing the window size leads to larger input representations and higher memory usage. Considering the trade-off between performance and resource consumption, the window size is set to 100 code lines. Samples with lengths close to this setting are used in the experiments.

As shown in Table 2, the three rule-based tools, namely Checkmarx, Flawfinder, and RATS, exhibit limited detection performance. Their ACC values remain relatively low, ranging from 48.57% to 60.13%, with relatively high FPR and FNR, indicating that predefined rules and patterns are insufficient to cover diverse vulnerability forms in complex source code. TokenCNN achieves the lowest runtime overhead (0.22 s), but its ACC is only 72.33%, suggesting that a lightweight CNN operating on plain code representations is efficient but insufficient for reliable vulnerability detection.

VulDeePecker and SySeVR, which are both based on program slicing and bidirectional recurrent modeling, achieve better results than TokenCNN. Compared with VulDeePecker, SySeVR reduces FPR from 24.48% to 22.89% and FNR from 17.80% to 14.19%, while improving ACC from 77.75% to 80.08%. This suggests that incorporating control-flow information is beneficial. However, both methods still underperform VulSCP, whose ACC reaches 85.14%. The gap indicates that slice-based sequential modeling alone remains insufficient for capturing richer semantic dependencies in code.

Among the non-LLM deep learning baselines, AugSliceVul [49] is the strongest competitor, achieving 83.41% ACC, 20.63% FPR, and 9.03% FNR. Compared with AugSliceVul, VulSCP improves ACC by 1.73 percentage points and reduces FPR by 3.38 percentage points, while requiring substantially less runtime (1.89 vs. 9.57 s). Although AugSliceVul attains a lower FNR, the overall comparison indicates that VulSCP provides a better balance between accuracy, false-alarm control, and efficiency. Devign, as a GNN-based baseline, also achieves competitive performance with 82.63% ACC and 8.89% FNR, but its runtime reaches 10.41 s, which is more than five times that of VulSCP. This result highlights the advantage of VulSCP in achieving competitive semantic modeling capability without incurring the higher computational overhead of explicit graph neural reasoning.

Among the prompt-based LLM approaches, GLM4-9B and DeepSeek-v3 achieve 78.91% and 80.59% ACC, respectively, with runtime overheads of 1.95 and 3.21 s. The Qwen2.5 series shows runtime relatively close to that of VulSCP, but its detection metrics remain clearly lower. In contrast, the Qwen3 inference models obtain stronger FNR performance, with the best value reduced to 9.31%, indicating improved sensitivity to vulnerable samples. However, this gain is accompanied by substantially higher runtime. Compared with the evaluated LLM-based methods, VulSCP achieves the highest ACC (85.14%) and the lowest FPR (17.25%), while maintaining a low runtime overhead of 1.89 s. These results suggest that VulSCP offers a favorable balance between detection effectiveness and efficiency relative to the evaluated LLM-based methods.

For the fine-tuned LLM-based models (VulLLM series), a similar trade-off can be observed. Although these models further reduce FNR by about 5.2%–7.1% relative to VulSCP, they also exhibit higher FPR, indicating a tendency to over-predict vulnerable samples. In addition, their runtime overhead remains notably higher than that of VulSCP. Therefore, while fine-tuned LLMs show strong sensitivity to vulnerability samples, VulSCP maintains a more balanced error profile together with substantially lower computational cost.

Overall, VulSCP achieves the highest ACC and the lowest FPR among all compared methods, while keeping runtime low. These results show that the proposed framework compares favorably with traditional tools, recent and representative deep learning baselines, and the considered LLM-based approaches.

To further evaluate the classification capability of VulSCP under different decision thresholds, we additionally report the Receiver Operating Characteristic (ROC) curve and the Precision–Recall (PR) curve, as shown in Fig. 5. Based on the statistics of five independent runs, VulSCP achieves a mean AUC of 0.927±0.004 and a mean Average Precision (AP) of 0.886±0.006, indicating strong and stable overall discriminative ability. The ROC curve consistently bends toward the upper-left corner, suggesting that VulSCP can achieve a high true positive rate under a low false positive rate. The PR curve further shows that the model maintains high precision as recall increases, reflecting robust positive-class recognition. Moreover, the narrow standard-deviation bands around both curves demonstrate the stability and robustness of VulSCP across repeated experiments.

To further assess the generalization ability of VulSCP under distribution shift, we conduct cross-dataset experiments. Specifically, the model is trained on the source-domain dataset NVD+SARD+BigVul and directly tested on the target-domain dataset ReVeal, without any fine-tuning on the target domain. As summarized in Table 1, the two domains differ substantially in both scale and class distribution, making this setting a more challenging evaluation of transferability.

The cross-dataset results are summarized in Table 3.

Among all compared methods, VulSCP achieves the highest ACC (85.55%) and the lowest FPR (9.74%), while maintaining a runtime of only 1.95 s. Compared with the strongest non-LLM baseline AugSliceVul, VulSCP improves ACC from 84.95% to 85.55% and further reduces FPR from 11.02% to 9.74%, with only a slight difference in FNR (55.16% vs. 55.63%). In addition, VulSCP shows the smallest ACC variance (85.55±0.11) and a lower FPR variance (9.74±0.21) than AugSliceVul (11.02±0.31), indicating more stable performance across repeated runs. These results suggest that VulSCP maintains favorable cross-dataset generalization while preserving clear efficiency advantages.

The target domain is highly imbalanced, with only 9.16% vulnerable samples, so ACC alone is insufficient for a complete evaluation. Under this setting, some methods still obtain seemingly competitive ACC but exhibit extremely high FNR. For example, VulDeePecker and SySeVR achieve 82.07% and 78.67% ACC, respectively, yet their FNR values remain as high as 86.24% and 77.69%. This indicates that these models tend to fit the majority class and fail to adequately recognize vulnerable samples under cross-dataset distribution shift. By contrast, VulSCP attains higher ACC together with much lower FPR, indicating a more favorable error trade-off in the target domain.

The LLM-based methods are included here mainly for reference, rather than as strictly comparable cross-dataset transfer baselines, since they are not trained on NVD+SARD+BigVul and then transferred to ReVeal in the same way as the non-LLM models. Under this setting, some LLM-based methods show relatively favorable FNR performance on ReVeal, but their ACC remains clearly lower than that of VulSCP. For example, GLM4-9B achieves 68.37% ACC, while Qwen3-32B and DeepSeek-v3 reach only 60.56% and 64.02% ACC, respectively. This indicates that, although LLM-based methods may be more sensitive to vulnerable samples in this setting, their overall detection performance on ReVeal is still limited compared with VulSCP.

Although VulSCP achieves strong overall performance, several limitations should be noted. First, despite its relatively low false positive rate, the false negative rate in some settings indicates that certain vulnerability patterns may still not be fully captured by the current model. Second, although we further evaluate cross-dataset generalization, the present experimental setting is still based mainly on random data splitting and therefore cannot fully reflect real industrial deployment conditions. Third, the current study focuses on function-level vulnerability detection, which may be insufficient for vulnerabilities involving cross-function, cross-file, or cross-module semantic dependencies. These issues will be further explored in future work.

VulSCP is a vulnerability detection method built on graph-derived semantic representation, which allows visualization techniques to be used to explain detection results. In this section, we take buffer overflow vulnerabilities as an example and apply the Gradient-weighted Class Activation Mapping++ (Grad-CAM++) method to visualize the model’s prediction outcomes.

Fig. 11 illustrates the visualization results for buffer overflow vulnerability detection. Code lines 8 and 18 are highlighted in the deepest red, followed by lines 7 and 11 in a slightly lighter shade, indicating that these lines are likely to contain vulnerabilities.

In this example, line 7 allocates a character array named overflow with a size of 65,550 bytes on the stack. Given the limited stack space, this may lead to a stack overflow. At line 10, the program reads an integer from user input via scanf, assigns it to i, and subsequently to size. If the user inputs an excessively large integer (exceeding the capacity of an unsigned short int), an integer overflow may occur. Finally, the memcpy function copies data from the overflow array to the buf array without boundary checks, potentially causing a buffer overflow.

In summary, the visualization results generated by VulSCP align well with the expected outcomes of manual code analysis, thereby supporting the effectiveness of the proposed method.