Attribution-Guided Prompt Optimization for Cross-CWE Vulnerability Detection

Abstract

Software vulnerability detection plays a critical role in improving software quality, system reliability, and security assurance. Prompt-based adaptation offers a lightweight alternative for vulnerability detection in low-resource Common Weakness Enumeration (CWE) settings, where labeled target-domain data are limited and model fine-tuning can be costly or unstable. This paper proposes an Integrated-Gradient-Guided Prompt Optimization (IGPO) method that uses attribution feedback to guide large language models in revising prompts for low-resource cross-CWE vulnerability detection. IGPO keeps the vulnerability detector fixed, evaluates the current prompt on target validation data, identifies false-positive and false-negative cases, computes Integrated Gradients (IG) for misclassified functions, aggregates token-level attributions into line-level feedback, and uses a large language model to diagnose error patterns and optimize the prompt. Experiments on C/C++ functions from PrimeVul, DiverseVul, and BigVul across 14 CWE categories show that, on positive-transfer source–target pairs, IGPO improves the average F1 score from 0.6780 to 0.7267 and outperforms the zero-shot baseline on 94.97% of them. These results position IGPO as an attribution-informed prompt adaptation framework that improves cross-CWE vulnerability detection without updating the detector, while highlighting the importance of backbone suitability under negative transfer. This method is particularly useful for security researchers and practitioners who need to adapt vulnerability detectors to new CWE categories with limited labeled data.

1. Introduction

Software vulnerability detection is a fundamental task for improving software quality, system reliability, and information security. As modern software systems become increasingly complex, vulnerabilities in low-level code can lead to memory corruption, privilege escalation, information leakage, denial of service, and other security risks. Traditional techniques such as static analysis, symbolic execution, and taint analysis are widely used, but they often require expert effort and may face scalability or false-alarm issues on large, diverse codebases.

Learning-based vulnerability detection has therefore attracted increasing attention. Early neural detectors learn vulnerability patterns from token sequences, program slices, abstract syntax trees, control-flow graphs (CFGs), data-flow graphs (DFGs), or graph-based representations [1], while recent pretrained code models and large language models (LLMs) provide stronger transferable representations for source-code understanding [2,3]. However, their effectiveness still depends heavily on data quality, vulnerability distribution, and evaluation protocol [4]. For many specific Common Weakness Enumeration (CWE) categories, labeled examples are limited, imbalanced, or expensive to obtain, making target-specific fine-tuning difficult in low-resource scenarios. Prompt-based adaptation provides a lightweight alternative to parameter updating [5,6]. Instead of fine-tuning a detector for every target CWE, prompts can guide a fixed model using task descriptions, CWE definitions, security checklists, output constraints, or few-shot examples [7]. This is especially relevant to low-resource cross-CWE vulnerability detection, where source-CWE knowledge may help a target CWE with limited supervision. However, transfer is not uniformly reliable: source-specific bias can harm detection when the target CWE follows different vulnerability mechanisms [4].

Existing automated prompt optimization methods usually rely on aggregate validation metrics, historical prompts, complete misclassified examples, retrieved examples, or natural-language critiques [5,8,9]. These feedback sources can indicate whether a prompt performs well, but they provide limited information about which code regions influence erroneous predictions. This limitation is important for vulnerability detection, where false positives (FPs) may be caused by superficial cues such as suspicious names, constants, macros, or security-related terms, while false negatives (FNs) may require reasoning about boundary checks, pointer lifetimes, aliasing relations, resource states, integer ranges, or exception-handling paths. Passing complete misclassified functions to an optimizer may introduce irrelevant context and obscure the regions that the detector actually relies on.

Although methods such as Optimization by PROmpting (OPRO) [8], TextGrad [10], and CodeSpeak-style approaches [11] support iterative prompt revision; they differ from Integrated-Gradient-Guided Prompt Optimization (IGPO) in the granularity and grounding of their feedback signals. Specifically, none of these methods directly grounds feedback in the detector’s token-level sensitivity to the current input, and thus may not identify the program statements that most influence erroneous decisions.

To address this feedback-granularity problem, this paper proposes IGPO method for low-resource cross-CWE vulnerability detection. IGPO keeps the detection model fixed and uses IG as a diagnostic tool for prompt optimization. For misclassified validation samples, it computes attribution scores with respect to the detector’s binary prediction preference, filters attribution to user-code tokens, and aggregates token-level scores into line-level feedback. The selected high-attribution lines, error types, labels, and validation metrics are then used by an optimizer model to diagnose error patterns and revise the prompt.

Figure 1 illustrates an example of line-level IG attribution for a cross-CWE test sample, where the detector is trained on CWE-416 and evaluated on a CWE-399 function.

The role of attribution in IGPO is intentionally limited. IG are not treated as causal explanations of vulnerabilities or definitive evidence of the detector’s reasoning. A high attribution score only indicates that a code region has a strong influence on the model output under the current prompt and input representation. In this work, attribution is used as a compact diagnostic signal to summarize recurring error patterns and guide prompt revision.

Experiments are conducted on C/C++ functions constructed from PrimeVul, DiverseVul, and BigVul. We consider 14 CWE categories and build a complete ordered cross-CWE transfer matrix with 182 non-diagonal source–target pairs. Among them, 159 pairs show positive transfer relative to the base-model zero-shot result, while 23 pairs show negative transfer. The main evaluation focuses on positive-transfer pairs, where the source-tuned detector provides a usable backbone for prompt optimization. On these pairs, IGPO achieves an average F1 score of 0.7267, improves over the source-model zero-shot baseline by 0.0487, and outperforms it on 94.97% of the positive-transfer pairs. Ablation results further indicate that attribution-based line selection, joint false-positive (FP) and false-negative (FN) feedback, concise top-k feedback, and LLM-based error diagnosis contribute to the final performance.

Figure 2 provides an overview of the prompt construction and optimization framework shared by all compared methods.

The experiments are designed to answer five research questions: the overall cross-CWE transfer behavior (RQ1), IGPO performance on positive-transfer pairs against zero-shot and automated baselines (RQ2), IGPO behavior under negative transfer (RQ3), component contributions via ablation (RQ4), and computational overhead (RQ5). Detailed definitions of these research questions are provided in Section 3.

The main contributions of this paper are as follows:

• New method: We propose IGPO, an attribution-informed prompt optimization method that converts line-level IG feedback from FP and FN validation samples into diagnostic guidance for LLM-based prompt revision. The key novelty lies in grounding prompt feedback directly in the detector’s token-level sensitivity, rather than relying on aggregate metrics, complete error samples, or language-model-generated critiques.
• Novel diagnostic design: We apply IG, originally used for model interpretability, as a lightweight diagnostic signal for iterative prompt optimization in a cross-domain transfer setting, combining it with False Positive (FP)/False Negative (FN) error typing and LLM-assisted revision.
• New empirical setting: We formulate low-resource cross-CWE vulnerability detection as a prompt-level adaptation problem and construct a 14-CWE transfer matrix with 182 non-diagonal source–target pairs from PrimeVul, DiverseVul, and BigVul, providing a systematic evaluation framework for cross-CWE prompt optimization.
• We empirically show that IGPO improves prompt optimization on positive-transfer source–target pairs, where the source-CWE fine-tuned detector remains a suitable backbone.
• We analyze the limitation of attribution-guided prompt optimization under negative transfer, emphasizing the need for backbone selection or fallback strategies.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 presents the task setting, dataset construction, IGPO method, baselines, and evaluation protocol. Section 4 reports experimental results and analyses. Section 5 discusses implications, limitations, and future directions. Section 6 concludes the paper.

2. Related Work

This section reviews research related to IGPO from four perspectives: learning-based vulnerability detection, LLM-based vulnerability detection and prompting, automated prompt optimization, and attribution-based model diagnosis.

2.1. Learning-Based Software Vulnerability Detection

Software vulnerability detection has been studied extensively in software engineering and program analysis. Traditional approaches such as static analysis, symbolic execution, and taint analysis provide strong semantic guarantees but often require expert-defined rules and face scalability limitations on large codebases [1].

With the development of deep learning, learning-based methods have been proposed to learn vulnerability patterns from source code, program slices, abstract syntax trees, control-flow graphs, data-flow graphs, and graph-based representations. Representative methods such as SySeVR and Devign combine semantic representations with neural architectures [12,13]. These approaches reduce dependence on manually crafted rules, but their performance is sensitive to data quality, label noise, project duplication, vulnerability imbalance, and distribution shifts across projects or vulnerability types [1].

Pretrained code models such as CodeBERT, CodeT5, PLBART, and UniXcoder further improve vulnerability detection by learning transferable code representations from large-scale corpora [2,3,14,15]. They provide stronger transferability than task-specific neural detectors, but target-CWE adaptation may still require labeled examples and careful evaluation. Large-scale datasets such as BigVul, DiverseVul, and PrimeVul provide broader real-world vulnerability examples and enable more realistic evaluation [4,16,17]. In this work, we construct C/C++ function-level binary classification tasks from these datasets and evaluate cross-CWE transfer across 14 CWE categories.

2.2. LLM-Based Vulnerability Detection and Prompting

LLMs have recently been applied to source-code understanding and software security because they can jointly process natural-language instructions and code. For vulnerability detection, LLMs can be adapted by parameter updating, such as fine-tuning, adapters, or LoRA-style updates, or by prompt-driven adaptation. Parameter-updating methods can improve performance when sufficient labels are available, but they introduce additional training cost and may overfit to the source vulnerability distribution.

Prompt-driven adaptation provides a lighter alternative by guiding a fixed model with task descriptions, CWE definitions, security rules, reasoning instructions, output constraints, or few-shot examples. Prior work has shown that LLMs can be adapted through prompts or task-specific instructions for vulnerability detection, insecure-code assessment, and security reasoning [7,18,19]. Prompting is especially relevant in low-resource settings because the same model can be adapted to different target CWEs with limited labeled examples, following the broader few-shot and prompt-based adaptation paradigm [20].

However, manually designed prompts depend on expert knowledge and may not generalize across CWE categories, as vulnerability mechanisms differ substantially between types. Prompts may also cause detectors to rely on superficial cues rather than reasoning over boundary conditions, pointer lifetimes, or exception-handling paths.

Recent studies and surveys also explore LLM-assisted security analysis, vulnerability repair, and static-analysis alert triage to improve reliability and reduce false positives [21,22]. IGPO is complementary to these efforts: it does not introduce a new detection agent or verifier, but focuses on prompt-level adaptation for a fixed detector under low-resource cross-CWE transfer.

2.3. Automated Prompt Optimization and Text-Based Optimization

Automated prompt optimization reduces manual prompt engineering by iteratively generating, evaluating, and revising prompts. Representative methods include APE, which searches for candidate instructions generated by language models [23]; OPRO, which uses optimization history and validation scores to propose improved prompts [8]; and ProTeGi, which introduces textual gradients based on errors and critiques [9]. Other methods use reinforcement learning, example retrieval, contrastive feedback, topic modeling, or evolutionary search under limited supervision [24,25,26,27].

Recent text-based optimization frameworks generalize this idea to broader LLM pipelines. TextGrad treats textual feedback as gradient-like signals for optimizing prompts, solutions, or intermediate reasoning traces [10], while DSPy composes and optimizes LLM pipelines through metric-driven compilation and prompt adaptation [28]. In code and vulnerability-analysis tasks, CodeSpeak-style and DLAP-style methods further use code-aware or demonstration-level feedback for prompt improvement [11,29]. These approaches show that natural-language feedback can support optimization when model parameters are fixed, but their feedback is usually based on aggregate metrics, complete examples, or language-model-generated critiques.

Program-analysis signals, including control-flow graphs (CFGs), data-flow graphs (DFGs), call graphs, taint paths, symbolic constraints, program slices, and static-analysis warnings, have also been used to support LLM-based code analysis. Such artifacts can provide explicit structural or semantic context, especially when vulnerability evidence is distributed across statements, branches, functions, or paths. IGPO does not currently incorporate these external artifacts; instead, it derives feedback from the detector’s attribution over the original input code, making the method lightweight but less semantically grounded than approaches using CFG, DFG, or taint information.

IGPO follows the iterative prompt-optimization paradigm but differs in the source, granularity, and behavioral grounding of feedback. OPRO uses historical prompts and scalar scores, TextGrad uses natural-language critiques, and CodeSpeak-style feedback is mainly constructed from code content or generated explanations. In contrast, IGPO uses IG to obtain detector-specific sensitivity signals for false-positive and false-negative cases, filters them to user-code tokens, and summarizes them as top-ranked source-code lines. Thus, IGPO provides localized, model-behavior-aware, and error-type-aware feedback, making it complementary to general prompt optimizers such as OPRO and TextGrad.

2.4. Attribution-Based Diagnosis for Code Models

Attribution methods estimate the contribution of input features to model outputs and are commonly used to analyze model behavior. Representative methods include gradient-based attribution, occlusion analysis, Local Interpretable Model-Agnostic Explanations (LIME), SHapley Additive exPlanations (SHAP), and Integrated Gradients (IG) [30,31,32]. IG estimates feature attribution by integrating gradients along a path from a baseline input to the actual input. In transformer-based code models, attribution and robustness analyses have been used to examine whether models rely on variable names, syntactic patterns, control structures, API usages, or vulnerability-related statements [33,34,35,36].

For software vulnerability detection, attribution can reveal whether a detector is sensitive to suspicious identifiers, security-related constants, memory-management functions, boundary checks, pointer operations, or return statements. Such information can help diagnose possible false-positive and false-negative patterns, but it should be interpreted carefully. A high attribution score does not prove that a token or line is the semantic cause of a vulnerability, nor does it guarantee that modifying the line would change the prediction causally. Attribution results are model-dependent and prompt-dependent, reflecting sensitivity under a chosen representation and baseline.

IGPO uses attribution in this cautious diagnostic sense. IG is not used as causal explanations of vulnerabilities or as a direct optimizer for discrete prompts. Instead, IGPO summarizes model-sensitive code regions in false-positive and false-negative validation samples and combines these line-level signals with error types and validation metrics to support LLM-based error diagnosis and prompt revision. In this way, IGPO connects attribution-based model diagnosis with automated prompt optimization for low-resource cross-CWE vulnerability detection.

3. Materials and Methods

This section describes the task setting, dataset construction, cross-CWE transfer protocol, IGPO method, baselines, and evaluation protocol. The experimental design evaluates whether attribution-informed diagnostic feedback can improve prompt-level adaptation for low-resource cross-CWE vulnerability detection, while ensuring that all optimization signals are obtained only from the validation set and that the test set remains strictly held out.

3.1. Task Setting and Dataset Construction

This study focuses on function-level binary vulnerability detection for C/C++ code under a cross-CWE transfer setting. Given different source and target Common Weakness Enumeration (CWE) categories, a model fine-tuned on the source CWE is adapted only at the prompt level for detecting vulnerabilities of the target CWE. For each input function, the detector outputs one binary label, 0 or 1, where 1 denotes a vulnerable function and 0 denotes a non-vulnerable function. Let the base model denote the original code-oriented language model before CWE-specific fine-tuning, and let the source-tuned model denote the same backbone fine-tuned on one source CWE. During prompt optimization, the target training split is not used to update model parameters. Instead, the target validation split provides low-resource supervision for few-shot selection, attribution computation, error diagnosis, intermediate evaluation, and prompt selection. During training and prompt optimization, the target test split is never accessed and is used only after final prompt selection for evaluation and retrospective stability analysis.

We construct datasets from three public vulnerability datasets: PrimeVul, DiverseVul, and BigVul. These datasets contain real-world vulnerable and non-vulnerable C/C++ functions and provide broad CWE coverage. This study considers 14 CWE categories, summarized in

Table 1. Selected CWE categories used in the experiments.

CWE	Description
CWE-284	Improper Access Control
CWE-416	Use After Free
CWE-200	Exposure of Sensitive Information
CWE-399	Resource Management Errors
CWE-264	Permissions, Privileges, and Access Controls
CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer
CWE-20	Improper Input Validation
CWE-190	Integer Overflow or Wraparound
CWE-189	Numeric Errors
CWE-362	Race Condition
CWE-787	Out-of-bounds Write
CWE-125	Out-of-bounds Read
CWE-476	NULL Pointer Dereference
CWE-703	Improper Check or Handling of Exceptional Conditions

.

Each function is assigned the first CWE label in its annotation list that intersects with the 14 target categories; for example, a function annotated as [CWE-26, CWE-20] is assigned CWE-20. Functions from PrimeVul, DiverseVul, and BigVul are then merged and deduplicated globally across all CWE categories. A function is treated as a duplicate if it matches any existing entry on either of two criteria: (i) an identical SHA-256 hash of the full function body, or (ii) an identical string formed by concatenating the first 128 characters of the function body with its CWE label. The 128-character prefix criterion is used as a near-duplicate filtering rule designed to reduce duplicate overlap before data splitting. In our merged dataset, the first 128 characters typically cover the function signature and early structural context, which provide sufficient information in many cases to identify repeated function-level records across PrimeVul, DiverseVul, and BigVul. This rule is intended to capture cross-dataset duplicate records that may not be identical at the full-body hash level due to minor differences in formatting, comments, or extraction boundaries. Although this criterion may occasionally remove functions that share the same prefix and CWE label but differ later in the code, we adopt it to prioritize reducing cross-dataset duplication and potential cross-split overlap rather than maximizing sample retention. All deduplication is performed globally before the train/validation/test split. Consequently, exact duplicates and prefix-based near-duplicates identified by these criteria cannot be assigned to different data splits. Project-, commit-, or patch-pair-level grouping is not used in the splitting procedure, because unified provenance metadata at these levels are not consistently available across the merged datasets. When duplicates are detected, the copy from the highest-priority dataset is retained (PrimeVul > DiverseVul > BigVul). This global deduplication ensures that a given function cannot appear under two different CWE categories simultaneously. The raw merged pool of 21,851 positive and 380,402 negative samples is reduced to 15,962 positive and 249,593 negative samples (27.0% reduction in positives); per-CWE statistics are reported in

Table 2. Dataset sample counts by CWE before and after deduplication.

CWE	Raw Pos	Raw Neg	Dedup Pos	Dedup Neg	Dedup Rate (%)
CWE-20	2766	49,627	1958	32,306	29.2
CWE-119	4,64	59,514	2881	35,412	30.8
CWE-125	2568	35,304	1675	23,539	34.8
CWE-189	747	14,252	516	7419	30.9
CWE-190	1081	15,013	806	10,217	25.4
CWE-200	1450	25,231	986	14,961	32.0
CWE-264	861	23,447	605	12,960	29.7
CWE-284	542	9884	437	7173	19.4
CWE-362	743	16,325	546	9477	26.5
CWE-399	1354	25,872	1008	16,851	25.6
CWE-416	1449	35,942	1141	25,159	21.3
CWE-476	1248	24,429	905	16,358	27.5
CWE-703	1004	19,247	884	15,599	11.9
CWE-787	1874	26,315	1614	22,162	13.9
Total	21,851	380,402	15,962	249,593	27.0

Dedup Rate indicates the proportion of positive samples removed.

.

To control input length and reduce length-distribution bias, functions longer than 2048 tokens are excluded. The remaining functions are grouped into 512-token length buckets. Within each CWE, positive samples are drawn according to the original length distribution until at most 400 positive samples are obtained, and the same number of negative samples is then selected with matched distributional characteristics. Each CWE dataset therefore contains up to 800 balanced samples with an approximately 1:1 positive-to-negative ratio.

Each CWE-specific dataset is split into training, validation, and test subsets using a 7:1:2 ratio. The training split is used for source-CWE fine-tuning, the validation split is used for all intermediate adaptation signals, and the test split is reserved exclusively for final evaluation. This unified validation-set access constraint is applied to all methods to avoid test-set leakage. The approximately 1:1 positive-to-negative ratio used in this study is a controlled experimental choice that facilitates balanced evaluation across CWE categories. This design choice is intended to control for the class distribution variable, enabling a clean experimental validation of IGPO’s core mechanism—whether attribution-based diagnostic feedback can effectively guide prompt optimization for cross-CWE transfer.

3.2. Cross-CWE Transfer Protocol

The 14 CWE categories form a complete ordered cross-CWE transfer matrix. Each CWE can serve as a source CWE for fine-tuning and as a target CWE for evaluation. Excluding diagonal cases, the matrix contains 182 non-diagonal source–target pairs.

For each source CWE, we fine-tune the base model on the corresponding source-CWE training split. The resulting source-tuned model is evaluated on every different target CWE. Prompt optimization methods may use only the target validation split for adaptation and prompt selection, while the target test split is used only for final reporting.

Transfer behavior is characterized by comparing the base-model zero-shot result with the source-tuned zero-shot result. A source–target pair is considered positive transfer if the source-tuned model achieves a higher F1 score than the base model on the target CWE; otherwise, it is considered negative transfer. Negative-transfer cases where the source-tuned model obtains an F1 score below 0.5 are treated as catastrophic negative-transfer cases. This protocol supports both full-matrix transfer analysis and separate evaluation under positive and negative transfer.

3.3. Integrated-Gradient-Guided Prompt Optimization

IGPO is an attribution-informed prompt optimization method for low-resource cross-CWE vulnerability detection. It keeps the detection model fixed and optimizes only the natural-language prompt. IG is used as diagnostic signals to identify code lines that strongly influence erroneous predictions, and these signals are converted into natural-language feedback for LLM-based prompt revision.

Given a current prompt, IGPO evaluates the source-tuned detector on the target validation split and collects false-positive and false-negative samples. It samples up to 10 examples from each error type, computes IG scores with respect to the predicted label logit of each erroneous decision, restricts attribution to user-code tokens, and aggregates token-level IG scores into line-level scores. The top-ranked lines are retained as compact diagnostic evidence.

The attribution feedback includes the error type, predicted label, ground-truth label, attribution-ranked source-code lines, current validation metrics, and current prompt. These signals are first provided to an optimizer model for error diagnosis. The generated diagnostic summary is then used together with the current prompt and validation metrics to produce a revised prompt. The revised prompt must preserve the binary output constraint requiring only 0 or 1. The prompt with the best validation F1 score across all rounds is selected for test evaluation.

Figure 3 illustrates the workflow of IGPO, and Algorithm 1 provides the complete step-by-step procedure, including validation evaluation, FP/FN collection, IG-based line selection, LLM-assisted diagnosis, prompt revision, and final prompt selection by validation F1 score.

Algorithm 1 Integrated-Gradient-Guided Prompt Optimization

Require:  Detection model M; target validation set $D_{\mathrm{val}}$; initial prompt $p_0$; optimizer model G; optimization rounds R Ensure:  Optimized prompt $p^{*}$ 1: Initialize prompt history $\mathcal{H}\leftarrow \left\{p_0\right\}$ 2: Set current prompt $p\leftarrow p_0$ 3: for $r=1$ to R do 4:     Evaluate M with prompt p on $D_{\mathrm{val}}$ 5:     Record validation Precision, Recall, Accuracy, and F1 score 6:     Collect false-positive and false-negative samples 7:     Sample up to 10 false-positive and 10 false-negative samples 8:     Compute IG using the predicted label logit as the scalar target 9:     Restrict attribution to code-token spans and mask non-code tokens to zero 10:     Aggregate token attributions into line-level scores and select top-k lines 11:     Ask optimizer model G to analyze error causes using attribution feedback and validation metrics 12:     Ask optimizer model G to revise the prompt using the diagnostic analysis 13:     Add revised prompt $p_{\mathrm{new}}$ to $\mathcal{H}$ and set $p\leftarrow p_{\mathrm{new}}$ 14: end for 15: Select $p^{*}$ from $\mathcal{H}$ according to the highest validation F1 score 16: return $p^{*}$

In all main experiments, IGPO runs for 10 optimization rounds without early stopping unless the validation set contains no errors. At each round, it samples up to 10 false-positive and 10 false-negative examples, constructs attribution-based evidence, performs error diagnosis and prompt revision, and retains the best prompt according to validation F1 score.

3.4. Attribution Feedback and Prompt Revision

Attribution feedback is the key component of IGPO. Its purpose is to identify code regions that strongly influence the current detector’s erroneous decisions and provide concise, model-grounded evidence for prompt revision.

IG scores are computed in the input embedding space with 16 integration steps. The scalar target is the logit of the detector’s predicted label token at the answer position, because the goal is to diagnose why the current model produced its erroneous decision. The padding-token embedding is used as the code-token baseline; when the tokenizer does not define a padding token, the end-of-sequence token embedding is used instead. The full detector input is used for forward computation, but attribution is restricted to the user-code span. Prompt tokens, special tokens, output-instruction tokens, blank lines, and comment-only lines are excluded or masked to zero before aggregation.

Token-level IG scores are converted into line-level scores by summing the absolute attribution values of all tokens belonging to the same source-code line. Unless otherwise specified, IGPO retains the top two attribution-ranked lines for each sampled error. Using both false-positive and false-negative cases allows the optimizer to address both over-reporting and missed vulnerabilities.

In the error diagnosis step, the optimizer model receives validation metrics and attribution-selected lines from sampled false-positive and false-negative cases. It summarizes likely failure patterns, such as over-reliance on superficial cues for false positives or insufficient reasoning about boundary checks, pointer lifetimes, resource states, aliasing relations, integer ranges, or exception-handling paths for false negatives. In the prompt revision step, the optimizer receives this diagnostic summary and revises the prompt by adjusting the task description, target-CWE criteria, cautionary rules, reasoning requirements, or output constraints.

The role of attribution is intentionally limited. IG is not treated as causal explanations of vulnerabilities or definitive evidence of the detector’s reasoning. A high IG score only indicates that the corresponding input region has strong influence on the detector output under the current prompt and input representation. In IGPO, attribution is used as a compact diagnostic signal for summarizing recurring error patterns and guiding prompt revision.

3.5. Models and Baselines

The detection backbone is Qwen2.5-Coder-7B. For each selected source CWE, we fine-tune the base model using LoRA on the corresponding source-CWE training split. During cross-CWE prompt optimization and final evaluation, the LoRA-adapted detector is fixed and no target-CWE parameter update is performed. The model is loaded with 4-bit NF4 quantization and float16 computation. The maximum input length is 2048 tokens, and the evaluation batch size is 4.

The optimizer model is an external OpenAI-compatible chat-completion API. We use deepseek-v4-flash (accessed via the DeepSeek API between April 2026 and June 2026) with temperature 0.0 and a maximum generation length of 1024 tokens. The optimizer model is used only to analyze validation errors and rewrite the INFO_HINT_PROMPT; it is not used to classify test samples and does not access the target test split.

The initial INFO_HINT_PROMPT is empty. Each detector input contains a fixed system role, the current INFO_HINT_PROMPT, the target C/C++ function, and a fixed output instruction requiring only 0 or 1. The prediction is obtained by comparing the logits of label tokens 0 and 1 at the answer position.

We compare IGPO with zero-shot baselines, manual prompting methods, and automated prompt optimization methods:

• Base-ZS: zero-shot prompting with the base model;
• Fine-ZS: zero-shot prompting with the source-CWE fine-tuned model;
• Fine-checklist: a checklist-style vulnerability inspection prompt;
• Fine-CWE-definition: a prompt that injects the target CWE definition;
• Fine-few-shot: a prompt with few-shot examples drawn from a validation split. There are two variants: one draws examples from the target-CWE validation split, and the other draws examples from the source-CWE validation split. The examples are selected by stratified sampling to include both vulnerable and non-vulnerable instances, and no target test-split samples are used.
• Fine-role-play: a role-based software-security-analyst prompt;
• Fine-CodeSpeak: an automated method using code-related feedback;
• Fine-DLAP-simplified: a simplified validation-feedback prompt adaptation method;
• Fine-OPRO: an optimization-by-prompting method using prompt history and validation metrics;
• Fine-TextGrad: a text-gradient-based method using natural-language error feedback;
• Fine-IGPO: the proposed attribution-informed prompt optimization method.

All fine-prefixed methods use the source-CWE fine-tuned detector. For all methods, the target test split is never used during prompt construction, prompt revision, few-shot selection, attribution computation, or intermediate evaluation. The complete detection prompt, baseline prompt templates, optimizer prompts, and IGPO prompt-optimization templates are provided in Appendix C.

Table 3. Main feedback signals used by automated prompt optimization methods.

Method	Main Feedback Signal
Fine-CodeSpeak	Code-oriented feedback generated for validation samples
Fine-DLAP-simplified	Simplified validation-based prompt adaptation feedback
Fine-OPRO	Historical prompts and validation metrics
Fine-TextGrad	Natural-language textual gradients and error feedback
Fine-IGPO	IG-selected lines, FP/FN error types, LLM error diagnosis, and validation metrics

summarizes the main feedback signals used by automated methods.

For automated baselines, we implement validation-feedback-based variants adapted to the same binary vulnerability detection setting. Specifically, Fine-OPRO uses historical prompts and metrics, Fine-TextGrad uses textual error feedback, Fine-CodeSpeak uses code-oriented feedback, and Fine-DLAP-simplified follows a simplified DLAP-style validation-feedback protocol. These are intentionally simplified re-implementations rather than full reproductions of the original systems. The simplifications are necessary because the original systems target different tasks, require components unavailable in this setting (e.g., external verifiers, task-specific retrievers, or multi-agent pipelines), or assume access to resources beyond the low-resource cross-CWE constraint. The purpose of including these baselines is to compare the quality of different feedback signals for prompt optimization under a controlled and unified setting, not to benchmark the full engineering complexity of each original system. Readers should interpret performance differences as reflecting feedback-signal effectiveness rather than system-level capability.

3.6. Evaluation Protocol and Research Questions

We report Precision, Recall, Accuracy, and positive-class F1 score. The positive class denotes vulnerable functions, and F1 score is used as the primary metric for prompt selection and final comparison. For each source–target pair, prompt optimization methods select their final prompts according to validation F1 score and are then evaluated on the held-out target test split.

In addition to the average F1 score, we report average F1 score change relative to Fine-ZS, the number and proportion of pairs where a method exceeds Fine-ZS, average rank, and prediction-degradation frequency. Prediction degradation is defined as a case where the detector predicts almost all samples as vulnerable, resulting in Recall equal to 1 and Precision no higher than 0.5. For negative-transfer analysis, we also report whether a method repairs the base-model gap, namely, whether its F1 score exceeds the corresponding Base-ZS result.

To assess statistical reliability, we perform paired Wilcoxon signed-rank tests over source–target pairs. The main statistical analysis is conducted on positive-transfer pairs, where the source-tuned model provides a usable backbone. We use one-sided tests with the alternative hypothesis that IGPO is greater than each baseline, and apply Holm correction for multiple comparisons. Statistical testing is used as supporting evidence together with average F1 score, improvement over Fine-ZS, win rate, rank, and negative-transfer behavior.

The experiments are designed to answer the following research questions:

• RQ1: What is the overall cross-CWE transfer behavior across the 14-CWE transfer matrix?
• RQ2: On positive-transfer pairs, does IGPO outperform zero-shot, manual prompting, and automated prompt optimization baselines?
• RQ3: How does IGPO behave under negative transfer, especially catastrophic negative transfer?
• RQ4: Which IGPO components contribute to performance, including attribution-line selection, FP/FN feedback, top-k line selection, and LLM-based error diagnosis?
• RQ5: What computational overhead does attribution-informed prompt optimization introduce?

4. Results

This section reports the experimental results of the proposed IGPO method. The analysis focuses primarily on positive cross-CWE transfer pairs, where the source-CWE fine-tuned model remains a usable backbone for prompt-level adaptation. We first briefly summarize the overall transfer landscape to provide context, and then compare IGPO with zero-shot, manual prompting, and automated prompt optimization baselines on positive-transfer pairs. We further report ablation results, statistical significance tests, and computational cost. Finally, we analyze negative-transfer behavior to clarify the operational boundary of IGPO, as such cases mainly reflect backbone suitability rather than prompt optimization effectiveness alone.

4.1. Cross-CWE Transfer Background

Before evaluating prompt optimization methods, we analyze the zero-shot transfer behavior of source-CWE fine-tuned models across the 14 selected CWE categories. The complete ordered transfer matrix contains 182 non-diagonal source–target pairs. Figure 4 visualizes the cross-CWE transfer performance using F1 scores. To improve readability, we remove cell-level numerical annotations from the heatmap and report the complete numerical matrix in Appendix A.

On diagonal settings, where the training CWE and testing CWE are the same, source-CWE fine-tuning obtains an average F1 score of 0.8601 with a standard deviation of 0.0508 across the 14 CWE categories. This indicates that the fine-tuned models learn useful CWE-specific vulnerability patterns under matched training and testing conditions.

For non-diagonal cross-CWE transfer, the average Precision, Recall, F1 score, and Accuracy of source-tuned zero-shot models are 0.6419, 0.7358, 0.6518, and 0.6217, respectively. Compared with the base-model zero-shot results, 159 out of 182 non-diagonal pairs show positive transfer, while 23 pairs show negative transfer. The average F1 score improvement over the base model is 0.1598 for positive-transfer pairs and −0.1075 for negative-transfer pairs.

Table 4. Summary of zero-shot cross-CWE transfer behavior over the 14-CWE transfer matrix.

Setting	Count	Average Precision	Average Recall	Average F1 Score
Diagonal source–target pairs	14	–	–	0.8601
All non-diagonal transfer pairs	182	0.6419	0.7358	0.6518
Positive-transfer pairs	159	–	–	–
Negative-transfer pairs	23	–	–	–

summarizes the zero-shot transfer statistics across all settings.

These results suggest that source-CWE fine-tuning is often helpful for related target CWEs, but it is not uniformly reliable. Therefore, the main evaluation in this section focuses on the 159 positive-transfer pairs, where the source-tuned model provides a meaningful starting point for prompt optimization.

4.2. Performance on Positive-Transfer Pairs

Table 5. Performance comparison on 159 positive-transfer pairs.

Method	Avg. F1 Score	Avg. ΔF1 vs. Fine	Exceed Fine	Exceed Ratio	Avg. Rank	Pred. Degen.
Fine-IGPO	0.7267	0.0487	151	94.97%	1.3019	6/3.77%
Fine-TextGrad	0.6975	0.0195	104	65.41%	3.8931	4/2.52%
Fine-OPRO	0.6974	0.0195	86	54.09%	4.1164	5/3.14%
Fine-role-play	0.6782	0.0007	41	25.95%	5.7468	9/5.66%
Fine-ZS	0.6780	0.0000	–	–	5.9403	9/5.66%
Fine-CWE-definition	0.6772	−0.0003	43	27.22%	5.7405	10/6.29%
Fine-checklist	0.6681	−0.0094	29	18.35%	6.3797	6/3.77%
Fine-CodeSpeak	0.6546	−0.0234	68	42.77%	6.3113	0/0.00%
Fine-few-shot †	0.6526	−0.0253	72	45.28%	6.8648	5/3.14%
Fine-few-shot ‡	0.6480	−0.0295	63	39.87%	6.7627	19/11.95%
Fine-DLAP-simplified	0.6270	−0.0510	24	15.09%	8.7484	0/0.00%

Avg. ΔF1 is computed relative to Fine-ZS. “Exceed Fine” reports the number (and proportion) of transfer pairs where a method outperforms Fine-ZS. “Pred. Degen.” reports the count (and rate) of prediction degeneration cases (recall $\ge 1$, precision $\le 0.5$). ^† Examples drawn from the target validation split. ^‡ Examples drawn from the source validation split.

reports the performance of different prompting methods on the 159 positive-transfer pairs. Fine-ZS denotes zero-shot prompting with the source-CWE fine-tuned model. All other fine-prefixed methods also use the source-tuned model as the detector backbone and use only the target validation split for prompt construction, feedback collection, or prompt optimization.

IGPO achieves the highest average F1 score of 0.7267 on positive-transfer pairs. Compared with Fine-ZS, it improves average F1 scores by 0.0487 and outperforms Fine-ZS on 151 out of 159 transfer pairs (94.97%). Its average rank of 1.3019 is the best among all compared methods.

Among the automated optimization baselines, TextGrad and OPRO obtain similar average F1 scores of 0.6975 and 0.6974, respectively. Both improve over Fine-ZS on average, but their gains are substantially smaller than those of IGPO, and their win rates (65.41% and 54.09%) are considerably lower. Manual prompting methods show limited improvement: role-play prompting is marginally above Fine-ZS (ΔF1 = 0.0007), while CWE-definition and checklist prompting yield slightly negative average deltas.

The two few-shot variants illustrate the effect of example-source selection. Fine-few-shot^† uses examples from the target-CWE validation split and achieves an average F1 score of 0.6526 with a prediction degeneration rate of 3.14%. Fine-few-shot^‡ uses examples from the source-CWE validation split, and yields a lower average F1 score of 0.6480 with a substantially higher degeneration rate of 11.95%. The comparison suggests that demonstrations drawn from the target validation distribution are more stable than those drawn from the source validation distribution, although both few-shot variants remain below Fine-ZS on average. The improvement in stability under the revised setting confirms that aligning the demonstration distribution with the optimization feedback reduces degenerate outputs. Nevertheless, both variants remain below Fine-ZS on average (ΔF1 = −0.025 and −0.030, respectively), indicating that static few-shot prompting without structured optimization is insufficient for cross-CWE transfer.

CodeSpeak and DLAP-simplified produce the lowest average F1 scores among all methods (0.6546 and 0.6270), with DLAP-simplified ranking last overall. Notably, both methods exhibit zero prediction degeneration, suggesting that their structured output constraints prevent degenerate predictions at the cost of overall discriminative performance.

The results suggest that attribution-informed feedback can provide useful diagnostic information for prompt revision when the source-tuned model already transfers positively to the target CWE. However, this should be interpreted as evidence under positive-transfer conditions rather than as a universal guarantee across all source–target CWE pairs.

To assess whether the observed improvements are statistically reliable, we further performed paired Wilcoxon signed-rank tests on the positive-transfer pairs. We used a one-sided alternative hypothesis that the evaluated method is greater than the baseline and applied Holm correction for multiple comparisons. The detailed test results are reported in Appendix B. IGPO significantly outperforms Fine-ZS after correction, with a mean F1 score gain of 0.0487, a median F1 score gain of 0.0421, a win rate of 94.97%, and an adjusted p-value of $2.53\times {10}^{-26}$ in the global comparison. IGPO also significantly outperforms the strongest automated baselines, Fine-TextGrad and Fine-OPRO, with mean F1 score gains of 0.0292 and adjusted p-values of $2.81\times {10}^{-26}$ and $6.63\times {10}^{-26}$, respectively. We acknowledge that the 159 source–target pairs are not fully independent, as 14 source and 14 target CWEs are each shared across multiple pairs. To provide a more conservative assessment, we conducted grouped Wilcoxon signed-rank tests by source and target CWE separately, treating the 14 source CWE groups and 14 target CWE groups as the units for Supplementary Analysis. IGPO significantly outperforms Fine-ZS in all 14 source CWE groups after Holm correction, with a cross-group mean ΔF1 of 0.0491, a cross-group median ΔF1 of 0.0476, and win rates ranging from 76.92% to 100%. IGPO also significantly outperforms Fine-ZS in all 14 target CWE groups after Holm correction, with a cross-group mean ΔF1 of 0.0493, a cross-group median ΔF1 of 0.0464, and win rates ranging from 80.00% to 100%. The grouped Wilcoxon test results are reported in Appendix B. These grouped analyses confirm that the observed gains are not merely an artifact of pair-level dependency.

4.3. Ablation Study

To examine the contribution of different IGPO components, we conduct an ablation study on positive-transfer pairs. The variants test whether the improvement comes from attribution-based line selection, joint false-positive and false-negative feedback, top-k line selection, and the LLM-based error diagnosis step.

All ablation variants use the same source-tuned detector, validation split, test split, optimizer model, output format, and 10-round optimization budget as the full IGPO method. Unless otherwise specified, each round samples up to 10 false-positive and 10 false-negative validation errors. The default IGPO setting uses 16 IG steps and retains the top two attribution-ranked code lines for each selected error sample.

The Full error samples without IG attribution variant sends truncated full misclassified functions to the optimizer instead of IG-selected lines. The Random two code lines variant replaces attribution-selected lines with two randomly selected source-code lines from each error sample. The FN-only and FP-only variants use only false-negative or false-positive errors, respectively. The Without LLM error diagnosis variant removes the intermediate diagnostic-analysis call and directly asks the optimizer to revise the prompt from validation metrics and FP/FN counts. The Top-4 and Top-6 variants increase the number of retained IG-selected lines per error sample.

Table 6. Ablation results on positive-transfer pairs. The best value in each column is shown in bold.

Variant	Average Precision	Average Recall	Average F1 Score
Full error samples without IG attribution	0.5794	0.7663	0.6598
Random two code lines	0.5444	0.3754	0.4243
FN-only feedback	0.5403	0.7950	0.6421
FP-only feedback	0.6443	0.5661	0.5987
Without LLM error diagnosis	0.6321	0.8059	0.7085
Top-4 IG-selected lines	0.6158	0.7211	0.6639
Top-6 IG-selected lines	0.6101	0.5230	0.5570
IGPO full	0.6664	0.8378	0.7267

reports the ablation results on positive-transfer pairs.

Replacing IG-selected lines with random code lines substantially reduces the average F1 score from 0.7267 to 0.4243. This indicates that the selected attribution lines provide more useful feedback than arbitrary code context. Passing complete error samples without IG attribution also performs worse than full IGPO, suggesting that compact IG feedback can be more effective than exposing the optimizer to long misclassified functions with potentially irrelevant context.

The FP-only and FN-only variants both underperform the full method. FN-only feedback obtains higher Recall but lower Precision, while FP-only feedback improves Precision but loses Recall. The full method achieves a better balance, indicating that combining false-positive and false-negative feedback is important for prompt revision.

The variant without LLM error diagnosis achieves an average F1 score of 0.7085, which is lower than the full IGPO result but higher than several other ablations. This suggests that validation metrics and attribution feedback already provide useful guidance, while the explicit error-diagnosis step further helps organize the feedback into more actionable prompt-revision instructions.

Increasing the number of retained IG-selected lines also reduces performance. Top-4 and top-6 IG-selected lines obtain average F1 scores of 0.6639 and 0.5570, respectively. This result suggests that overly broad IG feedback may introduce noise into the prompt optimization process. In the evaluated setting, a concise top-2 IG summary provides the best overall result.

Overall, the ablation results support three design choices of IGPO: selecting feedback lines using IG rather than random or complete context, combining FP and FN diagnostic information, and keeping IG feedback concise. The attribution signal is used as a model-behavior diagnostic cue for prompt optimization, not as a causal explanation of vulnerability semantics.

Each target CWE validation split contains a fixed 80 samples, providing a consistent optimization signal across all transfer pairs. The optimizer runs for a maximum of 10 rounds per pair, with early stopping if no validation errors remain; on average, all 10 rounds are completed (avg. rounds $=10.0$), indicating that optimization signals remain informative throughout the process.

To assess whether the prompt overfits to the validation split,

Table 7. Prompt optimization stability statistics across 182 cross-CWE transfer pairs.

Indicator	All (182)	Positive (159)	Negative (23)
Val set size (samples)	80	80	80
Avg. optimization rounds	10.0	10.0	10.0
Mean val. F1 score std across rounds	0.037	0.035	0.053
Median val. F1 score std across rounds	0.030	0.029	0.055
Avg. peak round (0-indexed)	3.58	3.45	4.48
Best prompt in first half (%)	59.3	59.7	56.5
Best prompt at final round (%)	8.8	5.7	30.4
Avg. val–test F1 score gap	0.033	0.028	0.071
Avg. val F1 score improvement ($\Delta$)	0.044	0.040	0.069

reports prompt optimization stability statistics across all 182 transfer pairs, with separate breakdowns for positive-transfer (159 pairs) and negative-transfer (23 pairs) subsets. Representative optimization trajectories illustrating these stability patterns are provided in Appendix D. The test-set F1 scores used in this stability analysis were computed retrospectively after all prompts, hyperparameters, methodological choices, and validation-based prompt selections had been finalized. They were not used during prompt optimization, prompt selection, early stopping, or method design. In the actual IGPO protocol, the final prompt is selected exclusively according to validation F1 score, and the target test split remains held out for final evaluation. The per-round test scores are reported only to diagnose whether validation-selected prompts exhibit overfitting or unstable generalization behavior. On positive-transfer pairs, the mean validation F1 score standard deviation across rounds is $0.035$ (median $0.029$), indicating that the optimization trajectory remains stable rather than fluctuating sharply. The best prompt emerges at round $3.45$ on average (0-indexed), and $59.7\%$ of positive-transfer pairs reach their best prompt within the first five rounds, suggesting that improvement saturates well before the final round. Only $5.7\%$ of positive-transfer pairs have their best prompt at the final round, further indicating that the optimizer does not systematically require the full budget to converge. The average gap between best-round validation F1 score and test F1 score at the same round is $0.028$ on positive-transfer pairs, which is consistent with normal generalization variance rather than systematic overfitting to the validation split.

Negative-transfer pairs exhibit noticeably higher instability: the mean validation F1 score standard deviation is $0.053$ (median $0.055$), the average val–test gap is $0.071$, and $30.4\%$ of pairs reach their best prompt only at the final round. These indicators suggest that when the source-tuned backbone is unsuitable for the target CWE, prompt optimization produces less stable trajectories and larger generalization gaps, consistent with the backbone-mismatch analysis in Section 4.6.

4.4. Attribution-Based Diagnostic Case Study

This section provides a qualitative case study to illustrate how IGPO uses IG feedback during prompt revision. The purpose of this analysis is not to claim that IG identifies the true semantic cause of a vulnerability. Instead, the case study shows how IG-selected lines can serve as compact diagnostic cues about the current detector’s behavior under a specific prompt and input.

We use CWE-416 Use-After-Free detection as an example. In early prompts, the detector is instructed to identify whether a function contains an unsafe use after a memory object has been freed. Such prompts can capture the general alloc–free–use pattern, but they may still produce false positives when the code contains lifetime-related names, reference-counting fields, cleanup functions, or pointer-like return values without an actual unsafe use. They may also produce false negatives when the vulnerable evidence is distributed across deallocation, alias propagation, state updates, and later pointer access.

During IGPO optimization, the current prompt is first evaluated on the validation set. IGPO then collects false-positive and false-negative samples, computes line-level IG feedback for these errors, and asks the optimizer model to summarize possible error patterns. The resulting diagnosis is then used to revise the prompt.

Table 8. Case analysis of attribution-guided prompt optimization for CWE-416.

Round	Prompt Focus	Metric	IG-Based Diagnostic Feedback
R0	Defines CWE-416 as alloc–free–use lifecycle tracing across execution paths.	F1 score: 0.5849; Precision: 0.5536; Recall: 0.6200	High-attribution regions in FP cases are often associated with names, constants, and return statements; FN cases show relatively weak attribution on lifetime-related operations.
R1	Adds positive and negative examples for direct UAF and safe reassignment after free.	F1 score: 0.8000; Precision: 0.7333; Recall: 0.8800	Recall improves substantially. The remaining FP cases still show high attribution on unrelated names, getter-like functions, and reference-counting cues.
R2	Adds a negative example where freeing followed by return is safe.	F1 score: 0.6458; Precision: 0.6739; Recall: 0.6200	The prompt becomes more conservative. In FN cases, attribution is more frequently observed around cleanup or state-update operations rather than explicit use-after-free patterns.
R3	Adds an alias-based positive example where one pointer is freed and another alias is later used.	F1 score: 0.7273; Precision: 0.5854; Recall: 0.9600	Recall increases, but precision drops. The attribution pattern suggests that the detector may be over-sensitive to pointer-like names and benign return statements.
R4	Adds a positive example where passing the address of a freed pointer is treated as unsafe use.	F1 score: 0.7218; Precision: 0.5783; Recall: 0.9600	High recall is maintained, but FP cases continue to show high attribution on surface-level tokens and benign pointer-return patterns.

IG-based diagnostic feedback should not be interpreted as causal explanations of vulnerabilities.

summarizes one prompt-evolution trace. The table reports the main focus of each prompt, validation metrics, and IG-based diagnostic feedback.

The case study suggests that IG feedback can help expose prompt-specific error tendencies. For example, when FP samples repeatedly assign high IG scores to names, constants, return statements, or reference-counting fields, the optimizer is guided to make the prompt more conservative and require stronger evidence of unsafe use after deallocation. When FN samples highlight cleanup operations, state updates, or alias-related statements, the optimizer is guided to emphasize cross-statement lifetime tracking and alias reasoning.

Table 9. IG-based attribution patterns observed during prompt evolution.

Error Type	IG Signal	Prompt Implication
FP	Surface tokens, such as names, constants, or return statements	Avoid treating superficial cues as sufficient vulnerability evidence
FP	Reference-counting or lifetime-related fields without unsafe access	Require complete alloc–free–use evidence
FN	Cleanup, nullification, or state-update operations	Track state changes after deallocation
FN	Deallocation followed by alias use	Strengthen cross-statement lifetime and alias reasoning

summarizes recurring IG-based patterns observed in this prompt-evolution process.

This case does not show that IG provides a causal explanation of CWE-416 vulnerabilities. Rather, it illustrates how line-level IG feedback can produce compact, model-specific diagnostic feedback that helps the optimizer revise prompts more explicitly. The usefulness of such feedback depends on whether the detector’s IG patterns reflect stable error tendencies on the validation set.

It is important to note that IG reflects which code tokens influence the model’s prediction, rather than where the vulnerability is located. Prior work has shown that learning-based vulnerability detectors may assign high importance to non-vulnerable lines and do not reliably localize the actual vulnerability line [37,38]. In our case study, the IG-selected lines correspond to semantically active code regions, such as pointer arithmetic and memory allocation, that are related to the model’s decision behavior, rather than necessarily matching the patch-modified line. Therefore, we use IG not as a vulnerability localizer, but as a diagnostic signal for guiding prompt optimization toward the model’s prediction behavior.

Table 10. Case study on a CWE-125 sample (rpa_read_buffer).

Line	Code Snippet	IG Score	Sem. Relevant
Sample: Vulnerable (target = 1)
IG-selected lines
12	return 0;	3.145	√ boundary logic
17	*data += 1 + len;	2.640	√ pointer arith.
Randomly selected lines
6	(empty line)	—	× no semantics
20	}	—	× no semantics
Sample: Patched (target = 0)
IG-selected lines
17	*data += 1 + len;	19.401	√ pointer arith.
14	*buffer = p_malloc(pool, len);	6.556	√ memory alloc.
Randomly selected lines
6	(empty line)	—	× no semantics
20	}	—	× no semantics

presents a case study on a CWE-125 (Out-of-Bounds Read) vulnerability in rpa_read_buffer(). Line 11 is the patch-modified line; however, consistent with prior findings on the limited line-level localization ability of learning-based vulnerability detectors [37,38], IG does not pinpoint this exact patch line. Instead, IG assigns high scores to Line 17 (*data += 1 + len;, score = 2.64 for the vulnerable version and 19.40 for the patched version) and Line 12 (return 0;), both of which are semantically relevant to CWE-125 memory-access patterns, including pointer arithmetic and boundary-return logic. In contrast, the randomly selected lines, including an empty line and a closing brace, carry no semantic information. This contrast illustrates that IG reflects the model’s computational focus rather than ground-truth vulnerability localization [38], and that IG-based feedback provides more semantically meaningful diagnostic signals for prompt refinement than random line selection.

4.5. Computational Cost

We report the approximate computational cost of automated prompt optimization methods in

Table 11. Approximate computational cost averaged over one transfer pair without caching intermediate results.

Method	Optimizer Calls	Time (s)	Main Cost Source
CodeSpeak	160 *	1536	Per-sample feedback generation
DLAP-simplified	160 *	1937	Per-sample prompt-adaptation feedback
OPRO	4	110	Iterative prompt generation and validation
TextGrad	17	180	Textual-gradient feedback and prompt revision
IGPO	17	922	Integrated-gradient computation and prompt revision

* The method calls the optimizer once per validation sample; intermediate results may be cached when the same samples are reused, but are required for each new sample in a one-pass deployment.

. The cost is averaged over one source–target transfer pair. The numbers are intended to provide an implementation-level comparison under our experimental setting rather than a hardware-independent benchmark.

All experiments are conducted on a single NVIDIA RTX 5880 Ada Generation GPU (47.5 GB VRAM) with CUDA 12.6 and PyTorch 2.7.1. The base detector model occupies 5.317 GB of GPU memory after loading; a single inference pass peaks at 5.506 GB (sequence length: 366 tokens). When IG computation is enabled (16 steps, default), peak memory reaches 7.285 GB, as each interpolation step performs an independent forward–backward pass without accumulating intermediate activations. IG computation scales linearly with the number of steps ($R^2=0.9996$, approximately 200 ms per step), confirming predictable resource usage under varying step budgets.

IGPO uses the same number of optimizer calls as TextGrad, but takes longer because it additionally computes IG scores for sampled false-positive and false-negative validation examples. This IG computation step requires forward and backward passes through the detector, making attribution computation the main source of IGPO’s overhead. In the low-resource validation setting used in this study, the overhead remains manageable while providing more targeted IG feedback for prompt optimization.

For CodeSpeak and DLAP-simplified, per-sample intermediate feedback can be cached when the same validation samples are reused in repeated experiments. However, Table 11 reports the average runtime without caching, which reflects the cost of processing fresh samples in a one-pass detection scenario.

Regarding the choice of 16 IG steps: the primary contribution of this work is to demonstrate that IG-based feedback constitutes a more informative optimization signal than metric-only feedback. The current configuration is validated as effective by our experimental results; we do not claim it to be optimal. Systematic tuning of IG hyperparameters, including step count and sampling strategy, is left as future work.

4.6. Performance on Negative-Transfer Pairs

Among the 182 cross-CWE transfer pairs evaluated, 23 pairs exhibit negative transfer, accounting for 12.6% of all evaluated pairs. In these cases, the source-CWE fine-tuned backbone underperforms the base zero-shot model on the target CWE, i.e., the Fine-ZS F1 score is lower than the Base-ZS F1 score.

Table 12. Summary of IGPO behavior on 23 negative-transfer pairs.

Outcome	Number of Pairs	Ratio (%)
Fully recovers to Base-ZS level	4	17.4
Partially stabilizes degradation	10	43.5
Marginally aggravates degradation	9	39.1
Base-ZS outperforms IGPO	19	82.6

“Fully recovers” indicates that IGPO reaches the Base-ZS level. “Partially stabilizes” indicates that IGPO improves over Fine-ZS but remains below Base-ZS. “Marginally aggravates” indicates that IGPO further decreases F1 compared with Fine-ZS.

summarizes the main observations on these negative-transfer pairs.

Negative-transfer pairs are not uniformly distributed across CWE types, as shown in

Table 13. CWE distribution in negative-transfer pairs.

CWE Type	Number of Pairs	Ratio Among Negative-Transfer Pairs (%)
CWE-787	14	60.9
CWE-703	6	–
CWE-119	5	–

A CWE may appear either as the source or target CWE in a transfer pair.

. CWE-787 appears in 14 of the 23 pairs, accounting for 60.9%, either as a source or target, followed by CWE-703 in 6 pairs and CWE-119 in 5 pairs. This concentration suggests that certain CWE types exhibit structurally low cross-CWE semantic compatibility, rather than negative transfer being a random phenomenon.

On these 23 negative-transfer pairs, IGPO fully recovers to the Base-ZS level in 4 pairs, accounting for 17.4%. It partially stabilizes the degradation in 10 pairs, accounting for 43.5%, where IGPO improves over Fine-ZS but remains below Base-ZS. In the remaining 9 pairs, accounting for 39.1%, IGPO marginally aggravates the degradation. Critically, when IGPO does aggravate performance, the average additional drop is only $\Delta =-0.012$ F1, indicating that IGPO does not catastrophically worsen an already-degraded backbone.

Nevertheless, IGPO alone cannot fully compensate for the structural mismatch introduced by fine-tuning on a semantically distant source CWE. In negative-transfer cases, the backbone’s representational capacity on the target domain is already compromised, and prompt-level optimization alone cannot compensate for this model-level deficiency.

In 19 of the 23 negative-transfer pairs, accounting for 82.6%, the unmodified base zero-shot model outperforms IGPO, with an average gap of $\Delta =+0.103$ F1 in favor of Base-ZS. We therefore recommend a simple detection heuristic: if the fine-tuned model’s zero-shot validation F1 score on the target CWE falls below the base model’s F1 score, the system should fall back to the base zero-shot model rather than applying IGPO.

This paper primarily targets positive-transfer scenarios, where IGPO consistently improves over both Fine-ZS and Base-ZS baselines. IGPO is designed and evaluated for positive-transfer settings, where the fine-tuned backbone retains reasonable generalization to the target CWE. In negative-transfer cases, which account for 12.6% of the evaluated pairs in our study, a simple and effective mitigation is to fall back to the base zero-shot model, which recovers performance in 82.6% of negative-transfer cases.

We consider this an acceptable operational boundary given that IGPO achieves consistent gains across the remaining 87.4% of transfer pairs. Addressing negative transfer fundamentally requires either source CWE selection strategies or multi-source ensemble approaches, which we leave for future work.

5. Discussion

5.1. Main Findings

The results show that IGPO is effective mainly under positive cross-CWE transfer conditions. On the 159 positive-transfer source–target pairs, IGPO obtains the highest average F1 score and improves over Fine-ZS on most pairs. This suggests that localized IG feedback can provide useful diagnostic information beyond aggregate validation metrics or complete misclassified functions.

The ablation study supports the main design choices. IG-selected lines outperform random lines and full error samples, joint FP/FN feedback performs better than using only one error type, and concise top-2 attribution feedback is more effective than broader top-k feedback. These findings suggest that IGPO benefits from focused diagnostic feedback, but the IG-selected lines should still be interpreted only as model-behavior signals rather than causal explanations of vulnerabilities.

5.2. Method-Level Limitations

IGPO depends on the quality of the source-tuned detector. When the source model transfers positively to the target CWE, IG feedback can help refine the prompt. However, under negative transfer, especially catastrophic negative transfer, the IG signal may mainly reflect source-model bias. In such cases, prompt optimization alone may not repair the backbone, and selecting another source model or falling back to the base model may be more appropriate.

A practical limitation is that IGPO requires a small set of labeled target-domain samples to serve as the validation split. This requirement is inherent to the method: attribution feedback is computed from validation errors, and the best prompt is selected according to validation F1 score. In settings where such labeled data are available, the same validation split can also be used to assess transfer direction before running IGPO—if the source-tuned model already outperforms the base-model zero-shot on the validation split, the pair is likely a positive-transfer case and IGPO can be applied; otherwise, the source backbone may not be suitable, and selecting a different source model or falling back to the base model should be considered first. However, when no labeled target-domain data are available at all, neither transfer direction nor prompt quality can be assessed, and IGPO cannot be applied. This represents a fundamental scope boundary of the current method.

IGPO also introduces extra computational cost because IG requires additional forward and backward passes on selected validation errors. This overhead is acceptable in the low-labeled-data setting used here—where the constraint is the scarcity of labeled target-domain samples rather than computational resources—but may increase with larger validation sets, longer functions, larger detector backbones, or more optimization rounds.

5.3. Study-Level Limitations

The main experiments are limited to C/C++ function-level binary vulnerability detection over 14 CWE categories. In addition, each CWE-specific dataset is constructed with an approximately balanced vulnerable-to-non-vulnerable ratio, which provides a controlled setting for comparing cross-CWE transfer behavior and isolating the effect of attribution-guided prompt optimization. However, this setting is more balanced than real-world software projects, where vulnerable functions are usually much rarer than safe functions. Therefore, the reported Precision, Recall, and F1 scores should be interpreted as results under a controlled low-resource evaluation setting, rather than as direct estimates of deployment performance under natural vulnerability prevalence. Using the original CWE-specific distributions could introduce confounding factors, because performance differences might reflect class-ratio variation or sample-count imbalance rather than genuine cross-CWE transfer effects. Therefore, the conclusions may not directly generalize to highly imbalanced real-world detection scenarios, line-level localization, multi-class CWE classification, repository-level detection, patch validation, or other programming languages. Although global exact-hash and prefix-based deduplication is applied before splitting, the current study does not enforce project-, commit-, or patch-pair-level grouping because unified provenance metadata are not consistently available across the merged datasets. Thus, the current split should be interpreted as an exact-duplicate and prefix-based near-duplicate controlled split, rather than a full provenance-level grouped split.

To provide a preliminary check of model sensitivity, we conduct a small 2-by-2 analysis on 20 randomly selected positive-transfer pairs by varying the detector backbone and optimizer model. The attribution construction, optimization budget, and prompt-selection protocol are kept unchanged.

Table 14. Preliminary sensitivity analysis on 20 positive-transfer pairs.

Detector Backbone	Optimizer Model	Pairs	Fine-ZS F1 Score	Fine-IGPO F1 Score	Avg. ΔF1	Win Rate
Qwen2.5-Coder-7B	DeepSeek-V4-Flash	20	0.6612	0.7114	0.0502	100.00%
Qwen2.5-Coder-7B	GPT-5.5	20	0.6612	0.7036	0.0424	100.00%
DeepSeek-Coder-6.7B	DeepSeek-V4-Flash	20	0.6537	0.7006	0.0469	100.00%
DeepSeek-Coder-6.7B	GPT-5.5	20	0.6537	0.7213	0.0676	100.00%

Avg. ΔF1 = Fine-IGPO F1 − Fine-ZS F1.

reports the Fine-ZS and Fine-IGPO F1 scores, average ΔF1, and win rate for each detector–optimizer combination.

The sampled results show consistent gains over Fine-ZS across the four detector–optimizer combinations. However, this is only a preliminary sensitivity check on a small subset, not a comprehensive robustness evaluation. Broader experiments across more model families, model sizes, optimizer LLMs, and random samples are still needed.

Another limitation is that IGPO does not use explicit program-analysis artifacts such as CFGs, DFGs, taint paths, or static-analysis warnings. IG can identify prediction-sensitive code regions, but it cannot replace semantic program analysis. Thus, IG feedback should be used as diagnostic guidance for prompt adaptation, not as security-auditing evidence or causal explanation.

5.4. Future Work

Future work will evaluate IGPO across more detector backbones, optimizer models, programming languages, and vulnerability-analysis tasks. Reducing IG computation cost is also important, for example, through fewer integration steps, approximate IG, representative-error sampling, or adaptive IG. Another promising direction is to combine IG feedback with program-analysis signals, which may provide stronger semantic guidance for vulnerabilities involving control flow, data flow, or interprocedural evidence.

Overall, IGPO provides useful prompt-level adaptation under positive cross-CWE transfer conditions, but its effectiveness depends on a suitable backbone detector, concise feedback construction, and cautious interpretation of IG as diagnostic rather than causal evidence.

6. Conclusions

This paper proposed IGPO, an Integrated-Gradient-Guided Prompt Optimization method for low-resource cross-CWE software vulnerability detection, which keeps the detector fixed and uses line-level IG feedback from false-positive and false-negative validation samples to support LLM-based error diagnosis and prompt revision. Experiments on C/C++ functions constructed from PrimeVul, DiverseVul, and BigVul across 14 CWE categories show that, on 159 positive-transfer source–target pairs, IGPO achieves an average F1 score of 0.7267, improves over the source-model zero-shot baseline by 0.0487, and outperforms it on 94.97% of the pairs. These results suggest that IG-informed diagnostic feedback can help prompt-level adaptation when the source-tuned detector remains a suitable backbone, while IG in this work should be interpreted as a model-behavior diagnostic signal rather than a causal explanation of vulnerabilities or model decisions. These findings may be of practical value to security researchers and vulnerability-detection tool developers who need to adapt fine-tuned detectors to new CWE categories with limited labeled data, without retraining the underlying model. Future work will evaluate IGPO on additional model backbones, programming languages, and vulnerability-analysis tasks, and explore more efficient IG computation and integration with program-analysis signals such as control-flow, data-flow, and static-analysis warnings.