UntrustVul: Trustworthiness in ML Vulnerability Detection

• UntrustVul is an automated method that identifies untrustworthy alerts by detecting when ML vulnerability detectors highlight code lines unrelated to the actual flaw.
• It combines line-level syntactic assessment with program dependence graph analysis to evaluate whether suspicious lines are semantically linked to vulnerabilities.
• Empirical results show that UntrustVul improves accuracy, AUC, and F1 scores over baselines, reducing misleading reviews and flawed patching in vulnerability detection.

Searching arXiv for the primary paper and closely related work on trustworthiness in ML-based vulnerability detection. {"queries":[{"q":"arXiv (Tung et al., 19 Mar 2025) UntrustVul","max_results":5},{"q":"CausalVul vulnerability detection causal learning arXiv","max_results":5},{"q":"Rahman ICSE 2024 perturbation vulnerability detection arXiv","max_results":5}]} Search results located for the primary paper and related literature on causal learning and perturbation-based trustworthiness checks in vulnerability detection. Looking up the arXiv identifier for CausalVul to support the related-work discussion. {"queries":[{"q":"CausalVul arXiv vulnerability detection causal learning","max_results":10}]} UntrustVul is an automated method for identifying untrustworthy alerts in machine-learning vulnerability detection, introduced to address a specific failure mode of explainable vulnerability detectors: a model may correctly flag a vulnerable function while highlighting lines that are largely unrelated to the true flaw. In the formulation of the paper, such predictions are untrustworthy because they are correct for the wrong reasons, and their local interpretations can mislead developers during review and repair (Tung et al., 19 Mar 2025). The method targets this gap by simulating developer rationales during inference, combining learned line-level syntactic assessment with program-dependence-based reachability analysis to determine whether the suspicious lines emphasized by a detector are vulnerability-unrelated.

1. Concept and motivation

UntrustVul is motivated by a limitation in ML-based vulnerability detection that is orthogonal to function-level accuracy. Prior studies, as summarized by the paper, show that transformers and GNN-based detectors often learn spurious correlations such as identifiers, comments, or coding style. As a result, a detector may assign the correct vulnerable label to a function while its highlighted suspicious lines do not correspond to the actual vulnerability. The paper defines these cases as untrustworthy predictions (Tung et al., 19 Mar 2025).

The operational concern is not merely interpretability quality in the abstract. The paper identifies three concrete costs. First, misleading manual assessment: developers inspect highlighted lines that are irrelevant to the real flaw, which makes root-cause discovery harder and slower. Second, flawed patches: repairs guided by irrelevant lines may fail to remove the vulnerability or may introduce new vulnerabilities. Third, triage burden: many alerts are high-confidence yet untrustworthy, so model confidence alone is not a reliable proxy for whether a prediction should be trusted (Tung et al., 19 Mar 2025).

The paper therefore reframes vulnerability detection trustworthiness as a post-inference verification problem. Rather than asking only whether a model labeled a function correctly, UntrustVul asks whether the suspicious lines supplied by the model’s explanation are semantically aligned with vulnerability-relevant code. This shifts emphasis from prediction correctness to the decision process itself.

2. Formalization of untrustworthy predictions

The input to UntrustVul is a function-level vulnerability prediction together with a local interpretation consisting of suspicious lines and per-line importance scores:

$E = \{\langle l_i, s_i\rangle\},$

where $l_i$ is a line and $s_i$ its importance (Tung et al., 19 Mar 2025).

The central target notion is defined as follows: an untrustworthy prediction correctly flags a vulnerable function but highlights vulnerability-unrelated lines. To determine whether a suspicious line is vulnerability-unrelated, the method combines two conditions.

The first condition is benign syntax. A line is treated as a syntax-benign candidate if it does not match the syntactic patterns of historical vulnerable lines according to an ensemble of learned line-level classifiers. The intuition given in the paper is that such lines “cannot trigger vulnerabilities by themselves.”

The second condition is no vulnerable reachability. Using a Program Dependence Graph with control and data dependencies, a syntax-benign line is considered vulnerability-unrelated if it has no meaningful dependency path to a line that is not syntax-benign. The dependence analysis is restricted by rule-based criteria intended to retain only vulnerable dependencies (Tung et al., 19 Mar 2025).

The paper gives a strict predicate over the suspicious set $S$:

$$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$

This formalizes the strongest case: every highlighted line is benign and cannot reach any potentially vulnerability-related line through meaningful dependencies.

In practice, UntrustVul operationalizes this reasoning with a trustworthiness score. Let $M_{\mathrm{ens}}(l)=1$ if the ensemble classifies line $l$ as benign, and $0$ otherwise. Let $r(l_1,l_n,G)$ denote the length of the shortest path from $l_1$ to $l_i$0 using only vulnerable dependencies, with $l_i$1 if no such path exists. For each benign candidate $l_i$2, the method defines

$l_i$3

where $l_i$4 is the nearest suspicious line with $l_i$5. The trustworthiness score is then

$l_i$6

Lower $l_i$7 indicates that the suspicious mass is concentrated on benign lines that are far from, or disconnected from, non-benign lines. At inference time, UntrustVul classifies a prediction as untrustworthy if $l_i$8, where $l_i$9 is tuned on validation data (Tung et al., 19 Mar 2025).

3. Method architecture and analysis pipeline

UntrustVul simulates developer rationales in three stages. The first stage is code parsing and PDG construction. Given a model prediction, function source code, and suspicious lines with importance scores, the method uses Joern to build a function-level PDG with control and data dependencies. Nodes are merged per line to obtain a line-level PDG, and suspicious-line importance scores are attached as node weights (Tung et al., 19 Mar 2025).

The second stage is line-level syntactic assessment. Historical vulnerability knowledge is derived from BigVul commit-level diffs linked to CVE fixes. Positive examples are lines deleted or modified in vulnerability-fixing commits after removing comments, blank lines, and delimiters. Negative examples are randomly sampled from non-vulnerable functions and filtered by lexical similarity, keeping only lines with BLEU $s_i$0 against the positive pool. All lines are normalized to a consistent coding convention to reduce stylistic bias (Tung et al., 19 Mar 2025).

Each single line is represented by a transformer-based code encoder—CodeBERT, GraphCodeBERT, or UniXcoder—and a binary classifier is trained to predict whether the line is benign. The ensemble decision rule is

$s_i$1

This stage captures syntactic constructs such as operators, API usage fragments, and control tokens without requiring full function context.

The third stage is dependency-level assessment. For an edge $s_i$2 in the PDG to count as a vulnerable dependency, three rules are applied: there must exist a path from $s_i$3 to some $s_i$4; $s_i$5 must not be a benign candidate; and, for data dependencies, the edge must manipulate a variable involved at $s_i$6. This rule-based filtering is intended to avoid spurious flows through unrelated variables and to keep only paths potentially capable of affecting vulnerable behavior (Tung et al., 19 Mar 2025).

The resulting output is both classificatory and explanatory. UntrustVul returns a binary decision, the score $s_i$7, and a rationale consisting of the suspicious lines judged syntax-benign, the nearest reachable non-benign lines if any, and the distances. Lines with infinite distance are explicitly marked as completely vulnerability-unrelated.

The paper also states asymptotic costs. PDG construction is $s_i$8 at function scope. Line-level classification over $s_i$9 highlighted lines is $S$0. For each benign line, shortest-path search on the vulnerable-dependency subgraph is $S$1 in the worst case, for a total of $S$2, where $S$3 is the number of benign candidates (Tung et al., 19 Mar 2025).

4. Training data, detectors, and evaluation protocol

The empirical study covers 155K function-level vulnerability predictions from four detectors across three C/C++ datasets with line-level vulnerability information (Tung et al., 19 Mar 2025).

Category	Instances	Role
Datasets	BigVul, MegaVul, SARD	Intra- and cross-project evaluation
Detectors	LineVul, SVulD, IVDetect, ReVeal	Sources of predictions and suspicious lines
Explanations	Attention, GNNExplainer	Extraction of suspicious lines

BigVul serves both as the intra-project evaluation dataset and the training source for line-level benignity classifiers. MegaVul and SARD are used for cross-project evaluation. Suspicious lines are extracted from built-in attention for transformer models and from GNNExplainer for graph-based models. Joern is used both for IVDetect and ReVeal preprocessing and for UntrustVul’s PDG construction (Tung et al., 19 Mar 2025).

Ground-truth trustworthiness labels are defined through the Intersection over Union between highlighted lines $S$4 and ground-truth vulnerable lines $S$5:

$S$6

The default labeling threshold is $S$7. Standard metrics include Precision, Recall, F1, Accuracy, AUC, Specificity, and G-mean:

$S$8

$S$9

The baselines are a confidence-only rule and perturbation-based methods from Rahman et al. The confidence baseline labels a prediction untrustworthy when model confidence is below a threshold tuned to maximize G-mean. The perturbation baselines are PerturbVar, PerturbAPI, and PerturbJoint, which relabel a prediction as untrustworthy if it flips under variable-renaming, API-injection, or combined perturbation (Tung et al., 19 Mar 2025).

The prevalence numbers reported in the paper underscore why a dedicated trustworthiness filter is needed. At $$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$0, the fraction of untrustworthy alerts is 81%, 90%, and 87% for LineVul on BigVul, MegaVul, and SARD; 93%, 88%, and 91% for SVulD; 64%, 92%, and 89% for IVDetect; and 80%, 90%, and 90% for ReVeal (Tung et al., 19 Mar 2025).

5. Empirical results and diagnostic case studies

Across intra-project and cross-project settings, UntrustVul detects untrustworthy predictions with an F1-score of 82%–94% (Tung et al., 19 Mar 2025). On BigVul, the method achieves Accuracy of 74%–84%, AUC of 77%–86%, F1 of 82%–91%, and G-mean of 78%–80% across LineVul, SVulD, IVDetect, and ReVeal. Relative to the confidence baseline, it improves Accuracy by 16%–52%, AUC by 17%–54%, F1 by 13%–45%, and G-mean by 22%–41%. Relative to perturbation baselines, the gains are 29%–79% in Accuracy, 21%–59% in AUC, 28%–90% in F1, and 27%–72% in G-mean (Tung et al., 19 Mar 2025).

Cross-project results on MegaVul and SARD show similar superiority, with improvements over baselines of 4%–82% in Accuracy, 6%–59% in AUC, 1%–92% in F1, and 13%–67% in G-mean. The paper also reports monotonic metric increases as the IoU threshold becomes stricter, while retaining superiority to baselines across thresholds except for Specificity, where PerturbJoint tends to classify many alerts as trustworthy (Tung et al., 19 Mar 2025).

Efficiency is presented as compatible with deployment as a post-processor. Average per-function processing time is 1.02–1.47 seconds, including Joern PDG construction and multiple line encoders, whereas perturbation baselines require about 0.51–0.58 seconds. The reported overhead is attributed mainly to PDG construction and the number of line encoders; replacing the ensemble with a single encoder reduces roughly 0.50–0.75 seconds per function (Tung et al., 19 Mar 2025).

Ablation results show that both stages are necessary. Removing either the line-level or dependency-level assessment reduces Accuracy by 11%–42%, AUC by 3%–42%, F1 by 1%–37%, and G-mean by 4%–42%. Replacing the ensemble with any single encoder reduces G-mean by up to 3%, indicating small but consistent gains from ensembling (Tung et al., 19 Mar 2025).

The paper’s vrrp_print_data case study illustrates the intended diagnostic role. LineVul correctly predicts the function as vulnerable, with the actual vulnerable line at line 7 (CWE-59). However, its top suspicious lines are line 5 with 27%, line 4 with 18%, the function signature line 1 with 13%, and line 8 with 19%, while the truly vulnerable line 7 receives only about 8%. UntrustVul marks lines 4–5 and 8 as syntax-benign and shows that they do not reach the vulnerable line through vulnerable dependencies, yielding $$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$1 and a low trustworthiness score. The interpretation is therefore classified as untrustworthy, even though the function-level label is correct (Tung et al., 19 Mar 2025).

6. Downstream use, positioning, and limitations

UntrustVul is not only a post-hoc filter. The paper reuses the untrustworthy alerts it identifies to improve detectors through causal retraining. Following the causal learning paradigm used by CausalVul, the method injects vulnerability-unrelated lines identified by UntrustVul as dead code during retraining, discouraging reliance on spurious features. On CodeBERT, GraphCodeBERT, and UniXcoder backbones, this retraining improves intra-project function-level F1 by up to 8%, cross-project generalization by up to 321% in F1, and trustworthiness by reported gains of up to 100% (Tung et al., 19 Mar 2025).

The intended deployment model is as a post-processor or filter in CI or an IDE. The system consumes a model prediction, source code, and suspicious lines with importance scores, and returns both a binary trustworthy/untrustworthy decision and a rationale. The paper recommends triaging alerts by $$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$2, prioritizing high-$$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$3 alerts for quick action while routing low-$$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$4 alerts for careful manual review or corroboration by static analysis and tests. It also recommends avoiding patches based solely on low-$$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$5 highlighted lines and periodically retraining detectors with UntrustVul-derived negative cues (Tung et al., 19 Mar 2025).

In related-work terms, UntrustVul is positioned against three strands. Explainable vulnerability detection previously focused on generating fine-grained interpretations, such as attention or GNNExplainer outputs, without checking whether those interpretations were semantically aligned with real vulnerabilities. Spurious-feature mitigation work, including perturbation-based methods and causal learning, targeted narrower confounders such as identifiers or APIs. Trustworthiness assessment often relied on human vetting or model confidence. UntrustVul’s claimed novelty is that it is the first automated oracle specialized for ML vulnerability detectors that combines learned syntactic benignity with PDG-based meaningful reachability (Tung et al., 19 Mar 2025).

The paper also states several limitations. PDGs generated by Joern may miss complex constructs or fail on some snippets, and such samples were discarded. Historical vulnerability labels derived from commit diffs may contain refactorings or comments despite regex filtering. Pretrained code encoders inherit training biases. The evaluation is restricted to C/C++, and extension to other languages requires PDG support and retraining. Interprocedural flows, library behavior, and incomplete code context remain challenging for static reachability analysis. Finally, performance depends on thresholds such as $$\mathrm{Untrust}(S) = [\forall l \in S: Benign(l) \land \neg ReachVul(l)].$$6 and the IoU criterion used to derive ground-truth trustworthiness labels (Tung et al., 19 Mar 2025).

UntrustVul’s broader significance lies in making trustworthiness a first-class property of vulnerability detection. Rather than treating explanation as ancillary to classification, it treats explanation quality as part of the security judgment itself: an alert is useful only if the suspicious lines it emphasizes are related, by syntax and execution flow, to the vulnerability that the model claims to have found (Tung et al., 19 Mar 2025).