Recovering Vulnerability Conditions from Multi-Source Evidence: Repair Semantics and Uncertainty-Aware Reasoning for Open-Source Components

Abstract

Open-source vulnerability evidence is distributed across vulnerability databases, project advisories, version records, code repositories, issue/PR threads, proofs of concept, and tests. These artifacts may share upstream sources, apply to different scopes, or contain inconsistent conclusions, while security fixes may evolve through backports, follow-up fixes, bypass fixes, and cross-branch variants. This paper investigates a multi-source evidence-driven framework for representing and recovering vulnerability conditions in open-source components. The method normalizes heterogeneous artifacts into provenance-, time-, and scope-anchored atomic claims, constructs patch families to recover scope-aware fix invariants, and applies temporal–scope constraints to model evolutionary supersession, alternative triggers, and genuine conflicts while preserving Unknown or Conflict states. We conduct a mechanism-oriented evaluation on 75 real vulnerabilities with traceable project-side evidence from the Maven, PyPI, and Go ecosystems. The complete framework does not outperform simpler baselines on overall condition recovery or demonstrate a consistent advantage in fix-invariant recovery. On cases containing Unknown conditions, abstention reduces Unknown-to-Known errors at the cost of determinate coverage; patch-relation and genuine-Conflict recovery remain unsuccessful in the present evaluation. The results characterize the limits of the current framework and identify specific trade-offs and unresolved requirements for evidence-grounded repair and uncertainty reasoning.

1. Introduction

Public information about open-source component vulnerabilities is commonly distributed across vulnerability databases, project advisories, version records, code repositories, issue/PR threads, repair commits, PoCs, and test cases. Public vulnerability records provide basic information about components, versions, and security impacts, but they may omit or disagree on root causes, attack conditions, and affected ranges [1,2]. For practical analysis, knowing only that a particular component version is affected is insufficient; analysts also need to determine the relevant code location, trigger conditions, runtime constraints, and security consequences, together with the evidence supporting each conclusion.

Existing studies have improved the completeness and traceability of vulnerability information through vulnerability-intelligence aggregation, affected-version identification, repair-commit localization, and code-patch analysis. Their outputs, however, are typically vulnerability attributes, version ranges, repair commits, or code associations. When multiple sources describe the same vulnerability, analysts must still determine whether records derive from the same root source, whether fixes on different versions or branches express the same security semantics, and whether apparently contradictory descriptions are genuine conflicts or instead arise from differences in time, version, configuration, or trigger entry. Existing outputs are therefore difficult to compose directly into a vulnerability-condition specification with explicit scope and evidence states.

Three issues make this problem difficult. First, multiple vulnerability records may depend on the same advisory, so counting sources directly can duplicate evidence; the records may also apply to different versions, branches, and environments. Second, a security fix is not always completed by a single commit: an initial fix may be backported to maintenance branches or incrementally strengthened by follow-up and bypass fixes, so examining only one fix commit can miss stable security constraints. Third, the same vulnerability may have multiple valid scenarios because of differences in version, platform, configuration, or input entry. Early conclusions, later corrections, alternative trigger routes, and genuinely incompatible claims must therefore be treated differently. Vulnerability-condition recovery cannot be reduced to multi-source field merging or to selecting a single conclusion using a fixed source priority.

We study how to recover traceable vulnerability-condition specifications with explicit scope and uncertainty states from interdependent, evolving, and potentially incomplete public evidence. For a vulnerability v, different validity scenarios are organized into a scenario-based vulnerability fingerprint set $VFS\left(v\right)$. Each scenario describes the component, version, vulnerable location, preconditions, runtime environment, and security consequence, together with supporting evidence and a Known, Conflict, Unknown, or N/A state. The method converts structured records, natural-language descriptions, code changes, and test artifacts into atomic claims annotated with provenance, time, and scope; resolves provenance dependencies and aligns entities and versions; organizes Primary Fix, Backport, Follow-up Fix, Bypass Fix, and Equivalent Fix instances into patch families and recovers relatively stable security constraints from different repair implementations; and applies temporal–scope constraints to model evolutionary supersession, alternative triggers, and genuine conflicts while preserving uncertainty when evidence is insufficient. The study recovers vulnerability-side condition specifications only and does not determine whether a vulnerability is actually present or exploitable in a specific target system.

The study develops an evidence representation and two associated recovery mechanisms:

1.

An evidence representation for vulnerability-condition recovery. Vulnerability facts are represented as atomic claims containing content, provenance, time, and scope, together with provenance dependencies and knowledge states. The representation makes the source dependencies, applicable scopes, and evidence states of each conclusion explicit.

2.

A patch-family-driven method for fix-invariant recovery. A single repair commit is extended to a patch family with temporal, branch, and semantic relations. The method attempts to recover relatively stable security constraints by comparing the security effects of primary fixes, backports, follow-up fixes, bypass fixes, and equivalent fixes. The evaluation compares this design with single-patch and flat multi-patch analysis.

3.

A temporal–scope-constrained, uncertainty-aware multi-scenario reasoning method. Temporal and scope comparability are checked before competing claims are compared; explicit relations are defined for evolutionary supersession, alternative triggers, and genuine conflicts; and fields retain Unknown or Conflict when the evidence is insufficient or competing conclusions remain unresolved.

We evaluate the framework on 75 real open-source component vulnerabilities with traceable project-side evidence from Maven, PyPI, and Go. Fifteen vulnerabilities are used for development and 60 for held-out evaluation. Controlled comparisons examine condition recovery, repair semantics, and uncertainty handling. The complete framework has no overall advantage over the simpler baselines; abstention produces fewer Unknown-to-Known errors with lower determinate coverage, while patch-relation and Conflict recovery remain unsuccessful. These results delimit the demonstrated behavior of the proposed mechanisms.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 presents the problem formulation, proposed method, and experimental design. Section 4 reports the experimental results. Section 5 discusses applicability, limitations, and threats to validity. Section 6 concludes the paper.

2. Related Work

Structured vulnerability representations and multi-source datasets provide a foundation for linking vulnerability information. The Open Source Vulnerability (OSV) format links open-source vulnerabilities with packages, versions, and commits in a machine-readable representation of affected ranges [3]. NIST Vulntology uses scenario-based structures to describe attack actions, barriers, security impacts, and product configurations and allows one vulnerability to contain multiple scenarios [4]. Prior studies have also reported quality problems in public vulnerability records, including products, versions, and vulnerability attributes [5]. Datasets such as CVEfixes, VulZoo, ReposVul, PatchDB, and Vul4J further link vulnerability records to code commits, patches, tests, and other project-side artifacts, improving completeness and code-level traceability [6,7,8,9,10]. These efforts primarily address vulnerability-fact representation, data quality, and cross-source association; they provide less explicit modeling of whether multiple records share the same root source or whether different conclusions are comparable under the same version or environment scope.

Affected-version identification and security-patch analysis further exploit code history to recover vulnerability states. He et al. [11] combine security patches and development history to identify actually affected versions; V0Finder traces vulnerability origins through code reuse [12]; and Shi et al. [13] and Vision [14] use patch logic, vulnerability-related methods, and inter-version program information to identify affected versions. SPI identifies security patches from commit messages and code changes [15], while MOVERY constructs signatures from vulnerable and repaired code to detect modified vulnerable-code clones [16]. These studies show that patches provide both repair locations and vulnerability-semantics cues. Security fixes, however, may continue to evolve across maintenance phases and branches [17], so a single repair commit may not capture all constraints revealed by backports, follow-up fixes, and bypass fixes. VulGenie further extracts violated security constraints and defensive changes from Java security patches and derives security-sensitive API rules [18], demonstrating the feasibility of abstracting higher-level security semantics from concrete patches.

Multi-source vulnerability artifacts may also contain mutually supporting or competing conclusions. Dung’s abstract argumentation framework models competing arguments through attack relations [19], while Prakken [20] further studies structured argumentation and preference relations. These frameworks provide a foundation for handling inconsistent knowledge. Vulnerability evidence nevertheless has strong temporal and scope characteristics: mutually exclusive descriptions that apply to different versions, maintenance branches, or runtime environments do not necessarily conflict; early conclusions and later patches may represent state evolution; and different input entries may form alternative trigger routes. NIST Vulntology can describe multiple scenarios for one vulnerability [4], but its emphasis is structured expression, while general argumentation frameworks do not specifically address version, branch, patch-evolution, and alternative-trigger relations in vulnerability evidence.

These lines of work respectively address vulnerability representation and association, affected-range and patch analysis, and reasoning over inconsistent knowledge, but a semantic gap remains across them. Multi-source facts lack a unified representation that carries provenance and scope; evolving patches are not systematically transformed into stable vulnerability-level security constraints; and competing claims from different times and scopes are difficult to compose into multiple validity scenarios. This work studies the recovery of scenario-based vulnerability-condition specifications from multi-source evidence, with emphasis on provenance dependencies, repair evolution, and evidence uncertainty.

Baseline Selection and Task Comparability

Published systems overlap with different subtasks of condition recovery. He et al., Shi et al., and Vision recover affected versions and therefore overlap with the ver field; a shared evaluation would require aligned package coordinates, version populations, and reference units [11,13,14]. MOVERY detects modified vulnerable-code clones [16], whereas VulGenie extracts Java API security rules whose granularity differs from the scope-aware FI used here [18]. OSV provides structured affected-range evidence rather than an end-to-end recovery algorithm [3]. These output differences prevent direct comparison of their published scores with six-field Scene F1. The experiments in this paper use internal baselines to compare evidence-utilization choices; comparative effectiveness against published systems remains unevaluated.

3. Materials and Methods

3.1. Problem Formulation and Research Scope

Given an open-source component vulnerability v and its multi-source evidence set $D\left(v\right)$, where the evidence may include vulnerability database records, project advisories, release information, code commits, repair patches, issue/PR discussions, PoCs, and test cases, we study how to recover evidence-supported vulnerability-condition specifications under source retelling, incomplete content, conflicting conclusions, and evolving patches. Valid scenarios under different versions, branches, environments, and trigger routes are organized into a structured vulnerability fingerprint set (Equation (1)):

$$\mathrm{Recover}\left(D\right(v\left)\right)\to VFS\left(v\right)$$

(1)

where Equation (2) defines the set of scenarios:

$$VFS\left(v\right)=\{V{F}_i\left(v\right)\mid 1\le i\le k\}$$

(2)

Each scenario-based vulnerability fingerprint is defined in Equation (3) as

$$V{F}_i\left(v\right)=⟨id,com{p}_i,ve{r}_i,sin{k}_i,pr{e}_i,en{v}_i,pos{t}_i,ev{d}_i⟩$$

(3)

Here, $id$ denotes the vulnerability identifier; $com{p}_i$ denotes the component and package coordinates; $ve{r}_i$ denotes the applicable version, commit, or maintenance branch; $sin{k}_i$ denotes the vulnerable function, hazardous operation, or location where a security constraint is violated; $pr{e}_i$ denotes trigger conditions such as input, invocation, and data-flow requirements; $en{v}_i$ denotes runtime constraints such as platform, configuration, privileges, and feature state; $pos{t}_i$ denotes the security consequence or verifiable observation after the vulnerability is triggered; and $ev{d}_i$ records the corresponding evidence, time, scope, and evidence state.

For an atomic claim, candidate condition, or fingerprint field x, the evidence-state function is defined in Equation (4) as

$$Q\left(x\right)\in \{\mathrm{Known},\mathrm{Conflict},\mathrm{Unknown},\mathrm{N}/\mathrm{A}\}$$

(4)

Known indicates that the available evidence supports a determinate conclusion and that no unresolved scope-compatible competing claim remains. Conflict indicates unresolved competing conclusions that are comparable in scope. Unknown indicates insufficient evidence for a determinate judgment. N/A indicates that the field does not apply to the current scenario.

$VFS\left(v\right)$ is a vulnerability-side condition specification and does not imply that a particular target software system satisfies these conditions. Component presence, patch status, path reachability, and dynamic behavior in target software are outside the scope of this study, and the method does not output target-side vulnerability presence, exploitability, or risk levels.

3.2. Overall Framework

The proposed method contains three modules: multi-source evidence normalization, patch-family-driven vulnerability-condition semantic recovery, and temporal–scope-constrained multi-scenario reasoning. The overall workflow is shown in Figure 1.

Figure 1. Evidence-driven workflow for recovering vulnerability conditions in open-source components.

The first module transforms structured records, natural language, code, and test artifacts into atomic claims anchored by provenance, time, and scope. It identifies citation and retelling relations among sources and aligns components, project repositories, versions, commits, and maintenance branches, yielding the normalized claim set $A^{*}\left(v\right)$ and provenance dependency graph $G_{prov}\left(v\right)$.

The second module starts from confirmed security fixes, links primary fixes, backports, follow-up fixes, bypass fixes, and equivalent fixes, and constructs a patch-family graph $PFG\left(v\right)$. By comparing the security effects of different patches, it recovers fix invariants $FI\left(v\right)$ with explicit scopes.

The third module combines normalized claims, fix invariants, PoCs, and test evidence to build a candidate vulnerability-condition graph $CG\left(v\right)$. Temporal and scope constraints are used to identify support, competition, evolutionary supersession, and alternative-trigger relations. The resulting scenario set $S\left(v\right)$ is then mapped to the final $VFS\left(v\right)$.

Atomic claims establish the evidence basis for the downstream modules. Patch families organize repair evolution, and FI summarizes the supported protective constraints within an explicit scope. Candidate-condition construction combines these repair constraints with advisory, PoC, and test claims; temporal–scope reasoning then determines which conclusions can be combined, which require separate scenarios, and which remain uncertain. Thus FI is an additional evidence input to scenario reasoning, rather than an independent exploitability decision. If repair evidence is insufficient, FI may remain Unknown, while other evidence still supports some scenario fields. Figure 1 places candidate-condition construction at the interface between semantic recovery and final reasoning; Section 3.5 details that interface and the subsequent scenario generation.

3.3. Multi-Source Evidence Normalization

The analysis first freezes the publicly available artifacts related to each vulnerability, including vulnerability database records, project advisories, version information, Git repositories, issue/PR threads, release notes, PoCs, and test cases. Web pages and API responses are stored with retrieval timestamps, content hashes, and field locations; code artifacts are stored with repository, commit, parent commit, tag, and branch information; and PoC and test artifacts record applicable versions, execution entries, and security observations. These snapshots make subsequent conclusions traceable to fixed evidence.

Composite materials are decomposed into atomic claims that can be judged independently (Equation (5)):

$$a=⟨subject,predicate,object,scope,time,provenance⟩$$

(5)

The $subject$, $predicate$, and $object$ describe the content of the claim; $scope$ limits the applicable component, version, branch, platform, or configuration; $time$ records the advisory, commit, or version stage; and $provenance$ points to the supporting field, text span, code location, and citation chain.

Atomic claims are extracted jointly by rules, program analysis, and a large language model. Structured items such as components, versions, identifiers, and references are parsed by deterministic rules. Code artifacts are first localized through diffs and then analyzed with abstract syntax trees (ASTs) and control/data dependencies to extract functions, conditional checks, data transformations, and hazardous operations. PoC and test artifacts provide execution entries, inputs, and security observations. Configuration restrictions, privilege requirements, trigger modes, and impact descriptions in natural language are converted into candidate claims by the language model. Model-generated claims must have directly locatable evidence anchors, cannot expand the scope of the source evidence, and cannot add information unsupported by the available artifacts. Components, versions, commits, and program entities in candidate claims must also align to parsed objects; when entities or scope cannot be established, the corresponding conclusion remains Unknown.

Multiple vulnerability records may retell the same root source. To avoid treating duplicated propagation as independent support, we construct a provenance dependency graph $G_{prov}\left(v\right)$ and classify relations as ConfirmedDependent, ConfirmedIndependent, PotentiallyDependent, or UnknownDependency. ConfirmedDependent denotes explicit citation, retelling, mirroring, or a shared root source. ConfirmedIndependent requires evidence of an independent analysis or validation process. PotentiallyDependent denotes indications of dependence without sufficient confirmation. UnknownDependency indicates that the available information is insufficient to decide. Only ConfirmedIndependent increases the count of independent root sources; the absence of an observed citation does not by itself imply independence.

Provenance dependence is determined primarily from explicit references, common root links, and mirroring relations. Independent code analysis, testing, or reproduction can support ConfirmedIndependent, while indirect signals such as similar text or close publication times retain the PotentiallyDependent state.

After provenance analysis, the method aligns project repositories, package coordinates, release versions, tagged commits, and maintenance branches. Version scope is determined from actual release sequences, tag-to-commit mappings, branch topology, and patch-propagation status rather than only from natural-language version ranges in vulnerability records. The result is the normalized atomic claim set $A^{*}\left(v\right)$ and provenance dependency graph $G_{prov}\left(v\right)$.

For example, when a project advisory simultaneously describes an affected version range, a vulnerability entry, and a security impact, the description is decomposed into atomic claims that share a provenance anchor but use different predicates. If two vulnerability databases both cite that advisory, the corresponding claims share the same root source. Version records are then mapped to concrete versions and branch scopes using release sequences and tag-to-commit relations.

3.4. Patch Families and Fix-Invariant Recovery

3.4.1. Patch Family Construction

A vulnerability fix may be distributed across multiple commits and maintenance branches. The initial fix may cover only part of the attack surface, later commits may add missing boundary checks or close bypasses, and different maintenance branches may use different code forms with equivalent security effects. We therefore construct a patch-family graph with explicit evolutionary relations and scopes (Equation (6)):

$$PFG\left(v\right)=⟨P,R_P,\tau ,\sigma ⟩$$

(6)

P is the candidate patch set, $R_P$ represents evolutionary and semantic relations between patches, $\tau \left(p\right)$ denotes the patch role, and $\sigma \left(p\right)$ denotes its version, branch, and platform scope.

Patch roles include Primary Fix, Backport, Follow-up Fix, Bypass Fix, Equivalent Fix, and Unrelated Candidate. A Primary Fix is the initial or main security repair. A Backport propagates an established repair to an older maintenance branch. A Follow-up Fix complements an initial repair by covering a missing entry or boundary condition. A Bypass Fix adds a restriction against a known way of bypassing an existing repair. An Equivalent Fix uses a different code form on another branch to enforce the same security constraint. An Unrelated Candidate is superficially associated with the vulnerability but does not change the relevant security behavior.

Seed patches are obtained from vulnerability records, official advisories, issue/PR threads, release notes, and existing fix mappings. Candidate discovery then expands along commit references, cherry-pick relations, maintenance branches, modified locations, tests, and code history. Expansion is repeated until these relations yield no new candidate commits. Shared vulnerability identifiers, textual similarity, or nearby modified locations are used only for candidate discovery and do not by themselves prove patch-family membership. A candidate must be traceably related to the vulnerability, must change its trigger, hazardous operation, or protective constraint, and must have a component/version/branch scope compatible with the vulnerability. Commits containing only formatting changes, variable renaming, logging, or unrelated functional repairs are excluded. Candidates with insufficient evidence or competing interpretations retain Unknown or Conflict states.

The role of each valid candidate is determined from commit time and topology, branch-propagation relations, and security-behavior changes. A commit that establishes the principal protective constraint is marked as a Primary Fix; one that propagates an existing protection to a maintenance branch is a Backport; one that adds a previously missing entry or boundary constraint is a Follow-up Fix; and one that closes a known bypass path is a Bypass Fix. When different implementations normalize to the same security constraint in Section 3.4.2, an Equivalent relation is recorded.

For example, suppose the main repair first adds an input-boundary check on the primary branch, the same constraint is then backported to an older maintenance branch, and a later commit adds a previously missing check for encoded input. These commits become Primary Fix, Backport, and Follow-up/Bypass candidates, respectively, and their final roles are determined from branch relations and security effects.

3.4.2. Fix-Invariant Recovery and Validation

Patch families capture how repairs evolve, but implementations on different branches are still difficult to compare directly. The method first separates changes that directly alter vulnerability-relevant security behavior from tests, refactoring, logging, and compatibility edits and then normalizes security-relevant changes into security change units. Each unit contains Entry, Object, Operation, Transform, Guard, Outcome, and Scope.

The process contains three steps: security-change disentanglement, semantic normalization, and invariant validation.

First, newly introduced or modified Guard, Transform, and Operation elements are used as starting points. Control dependencies determine whether a protective condition governs a hazardous operation, while data dependencies determine whether transformations, guards, and operations act on the same input or security object. Refactoring, logging, and test edits that do not lie on the relevant security-behavior chain are separated from repair semantics; test results are retained as later behavioral validation evidence.

For different code implementations, variables and helper functions, semantically equivalent APIs, and control structures are normalized while preserving data-processing order and differences in entry, version, and branch. Variables and helper functions are mapped to the corresponding security object through program entities and data dependencies. APIs with equivalent functions are mapped to common operation categories, and guards expressed through different control structures are converted to normalized security predicates. Transform order is preserved because a check before decoding, normalization, or type conversion may have a different security effect from a check performed afterward.

Normalized change units are clustered by protected object, hazardous operation, protective predicate, and security outcome. Two units are placed in the same semantic cluster only when they target the same or mappable security object, constrain the same category of hazardous operation, map their guards to the same security predicate, and exhibit post-fix tests, PoC behavior, or code behavior consistent with that predicate. Code location and textual similarity are used only as candidate-matching signals. A later patch that repairs a new entry, transformation stage, or bypass condition forms a new semantic cluster.

Each semantic cluster yields a fix invariant with an explicit scope and evidence chain (Equation (7)):

$$FI\left(v\right)=\{⟨{\varphi }_j,scop{e}_j,E_j^{+},E_j^{-}⟩\mid 1\le j\le m\}$$

(7)

Here, ${\varphi }_j$ is an implementation-independent security constraint, $scop{e}_j$ denotes its applicable entry, version, and branch, and $E_j^{+}$ and $E_j^{-}$ record supporting and competing/counterexample evidence, respectively. A candidate invariant is marked Known only when pre-fix code violates the constraint, post-fix code satisfies it, and tests, PoCs, or code history support the corresponding behavioral change. Candidates whose semantic equivalence or behavioral change cannot be established remain Unknown.

Validation is performed on local program paths relevant to the vulnerability. The pre-fix path should exhibit behavior that violates the candidate constraint, whereas the corresponding post-fix path should establish the protection. Tests, PoCs, or commit history are used to confirm the behavioral change. If locatable evidence is missing on either side of the repair, the invariant remains Unknown.

For example, consider a path-traversal repair that checks whether a canonicalized target path remains within an allowed base directory. One branch may use a directory-containment predicate, while another uses an equivalent helper function. These changes can support the same scoped invariant when their handling of path components, canonicalization, and boundary cases is equivalent. A string-prefix comparison alone is insufficient because it can also accept a sibling path with the same prefix. If a later patch adds decoding or normalization before the containment check, the transformation order becomes part of the protective constraint and must be represented explicitly.

3.5. Temporal–Scope-Constrained Multi-Scenario Evidence Reasoning

3.5.1. Candidate Conditions and Relation Construction

Normalized claims and fix invariants may describe different parts of a vulnerability. The method combines $A^{*}\left(v\right)$, $FI\left(v\right)$, PoC steps, and test assertions to extract candidate nodes for components, versions, vulnerable locations, preconditions, environmental constraints, and security consequences and then constructs a candidate vulnerability-condition graph $CG\left(v\right)$.

Four relation types are used among candidate conditions. Must denotes conditions that must jointly hold within a particular scenario. Alternative denotes condition groups that can independently form trigger routes. Block denotes a protection that can stop a specific trigger route. Post links trigger conditions and vulnerable states to security consequences.

Relations are created from evidence chains. Conditions that must co-occur on the same path from an entry to a hazardous operation are connected by Must. Different condition groups that independently form entry-hazard-consequence chains are connected by Alternative. A fix invariant or other protection that can block a specific path establishes Block. Security outcomes supported by PoC results, test assertions, or advisories establish Post.

The scope of Must is limited to the corresponding candidate scenario. For example, if a network request and a malicious local configuration can independently reach the same vulnerable parser, they form two Alternative routes rather than two simultaneously required entries. Block removes a candidate scenario only when evidence confirms that the protection is actually present and effective in the relevant version, branch, and environment; otherwise, the related condition is retained or marked Unknown.

3.5.2. Temporal–Scope Constraints and Conflict Resolution

To represent genuine conflicts, temporal evolution, and scope differences, we define a temporal–scope constrained multi-scenario evidence reasoning model (Equation (8)):

$$F_v=⟨A,R_{sup},R_{att},R_{alt},R_{evo},\mathrm{\Gamma },\succ ⟩$$

(8)

A is the set of arguments formed by atomic claims and candidate conditions; $R_{sup}$ is the support relation; $R_{att}$ is the attack relation; $R_{alt}$ is the alternative-trigger relation; $R_{evo}$ is the evolutionary-supersession relation; $\mathrm{\Gamma }$ contains temporal and scope comparability constraints; and ≻ denotes a local evidence-quality preference.

An attack relation is created only when two claims are semantically contradictory, their scopes overlap, and their temporal states are comparable (Equation (9)):

$$(a_i,a_j)\in R_{att}\iff Contradict(a_i,a_j)\wedge Overlap(scop{e}_i,scop{e}_j)\wedge Comparable(tim{e}_i,tim{e}_j)$$

(9)

Overlap is evaluated using the component, version, branch, platform, and configuration scopes aligned in Section 3.3. If known scope dimensions are mutually exclusive, the two claims are placed in different scenarios; if critical scope information cannot be established, a determinate attack relation is not created. Mutually exclusive descriptions that apply to different versions, maintenance branches, platforms, or configurations are therefore retained in different scenarios rather than treated as direct conflicts. A later advisory, patch, or test establishes $R_{evo}$ only when it explicitly corrects an earlier conclusion and the scopes overlap. Evolutionary supersession applies only to the overlapping range, so an earlier conclusion may remain valid in uncovered versions or historical stages.

Genuine conflicts that remain after temporal and scope constraints are compared locally along six evidence-quality dimensions: directness, root-source independence, scope specificity, temporal validity, reproducibility, and consistency with code history. Let $D_{ij}$ be the subset of quality dimensions for which both $a_i$ and $a_j$ have determinate values. A Pareto partial order is used (Equation (10)):

$$a_i\succ a_j\iff [\forall d\in D_{ij},q_d\left(a_i\right)\ge q_d\left(a_j\right)]\wedge [\exists d\in D_{ij},q_d\left(a_i\right)>q_d\left(a_j\right)]$$

(10)

A preference is established only when one claim is no weaker on every comparable dimension and stronger on at least one. Unknown quality values provide no advantage. If the claims are mutually non-dominating, the result remains Conflict. This preference is applied only to genuine conflicts already established within the same temporal and scope context; it does not globally rank different scenarios.

For example, two affected-version conclusions that apply to different maintenance branches are retained in separate scenarios. If a later advisory explicitly corrects an earlier affected range and the scopes overlap, evolutionary supersession is established. Only claims with overlapping scopes, comparable temporal states, and incompatible content enter the Pareto comparison.

3.5.3. Scenario Generation and State Propagation

Scenario generation first partitions candidate conditions into compatible scopes according to component, version, branch, platform, and configuration. Within each scope, evolutionary-supersession relations are applied, genuine conflicts are processed, Alternative expands independent trigger routes, and the corresponding Must conditions are added. Block removes a route only when its actual blocking effect is supported by evidence. Scope-incompatible combinations are removed, and inclusion relations are used to eliminate redundant scenarios.

The procedure is executed in the following order:

1.

Partition candidate conditions into compatible scopes by component, version, branch, platform, and configuration.

2.

Apply $R_{evo}$ within each scope to update conclusions superseded by later evidence.

3.

Identify genuine conflicts using Equation (9) and perform local resolution using Equation (10).

4.

Expand independent trigger routes according to Alternative and add the corresponding Must conditions.

5.

Check Block and remove routes with explicit blocking evidence.

6.

Remove scope-incompatible and subsumed redundant scenarios.

Alternative is expanded only within compatible scopes. Block and inclusion relations are applied during generation to prune invalid condition combinations.

For each generated scenario, field states are determined from the remaining evidence. A unique acceptable conclusion with a compatible scope and no unresolved competitor is marked Known. Mutually incompatible, scope-compatible, and non-dominated competing conclusions are marked Conflict. A field required by the scenario but lacking sufficient evidence is marked Unknown, and a field that does not logically apply is marked N/A. Conditions without sufficient evidence remain Unknown, and unresolved competing claims remain Conflict.

Finally, each acceptable scenario is mapped to $V{F}_i\left(v\right)$ as defined in Equation (3), and all scenarios together form $VFS\left(v\right)$.

3.6. Experimental Design

The evaluation addresses vulnerability-condition recovery, repair-semantics recovery, and uncertainty handling. Development-time configuration is separated from held-out evaluation. Performance is measured against the finalized reference, GOLD_FINAL. Supplementary analyses characterize evidence availability and annotation states in an earlier adjudication-rebuilt reference export. The two versions have different purposes and are distinguished below.

3.6.1. Research Questions

The evaluation addresses three research questions.

1.

RQ1: How do different evidence-utilization strategies affect vulnerability-condition recovery? We compare single-source analysis, direct multi-source merging, fixed source priority, and the proposed method on condition fields and scenario recovery.

2.

RQ2: What roles do patch families and fix invariants play in repair-semantics recovery? We compare single-patch analysis, flat multi-patch analysis, and ablated variants on patch identification, fix-invariant recovery, and complex patch-evolution semantics.

3.

RQ3: How does uncertainty-aware reasoning affect erroneous determinations and result coverage? By removing temporal–scope constraints, Alternative relations, and abstention, we analyze multi-scenario recovery and the reliability-coverage trade-off.

3.6.2. Dataset and Reference Results

The experimental samples are selected from 150 real CVEs pre-collected from the Maven, PyPI, and Go ecosystems. A candidate vulnerability must be reliably mapped to an open-source project or package and must have traceable project-side evidence such as version information, project advisories, code repositories, issue/PR threads, repair commits, PoCs, or tests. Samples with unreliable project mappings or insufficient material to construct at least one traceable reference scenario are excluded, leaving 75 formal experimental samples. This exclusion does not require every field to be determinate: included vulnerabilities may still contain field-level or scenario-level Unknown states when the available evidence is insufficient for a specific condition. The dataset is not intended to estimate the prevalence of specific vulnerability patterns across the three ecosystems; instead, it serves as a mechanism-oriented evaluation set for vulnerability-condition recovery under traceable multi-source evidence, patch evolution, and uncertainty.

The finalized dataset contains 15 development and 60 test vulnerabilities. CVEs sharing a root cause, code module, repair commit, or highly similar patch pattern are assigned to the same partition to reduce leakage. The finalization records identify five development and 52 test family groups. Partition grouping for leakage control is conceptually distinct from aggregating dependent observations for statistical inference.

RQ1 uses all 60 test vulnerabilities. RQ2-A contains 23 vulnerabilities with evaluable repair semantics; four have relatively clear multi-patch evolutionary structures and form RQ2-B. RQ3 contains 21 vulnerabilities with multiple scenarios, temporal–scope differences, or uncertain conditions. These task subsets may overlap. Their membership lists are provided in the per-CVE scoring records. Supplementary object counts use the adjudication-rebuilt reference and retain its own partition membership.

Reference Construction

Reference construction combines program-assisted evidence indexing and candidate organization with human adjudication. The adjudication record contains 577 candidate-object decisions: 158 ACCEPT, 227 REJECT, 145 UNKNOWN, 11 CONFLICT, and 36 MODIFY. These decisions are not independent annotator pairs or individual scene-field labels. Database fixed/last_affected values and release commits are treated as clues; accepting a security repair requires evidence of a relevant behavioral change. Known requires locatable supporting evidence, Unknown denotes insufficient support, and Conflict denotes unresolved scope-comparable competition. Reference reliability is therefore supported by evidence-based adjudication rather than a quantified measure of independent annotator agreement. Independent paired annotation is needed to assess label reproducibility.

Reference Versions and Analysis Populations

The adjudication-rebuilt reference was generated on 9 August 2026 at 02:43 UTC and contains 75 CVEs, 107 scenarios, 705 atomic claims, 65 patch-family objects, and 90 FI objects (37 Known, 52 Unknown, and one Conflict). GOLD_FINAL was frozen at 02:49 UTC and contains the same numbers of CVEs, scenarios, and FI objects, but 69 patch-family objects (51 Known and 18 Unknown) and FI states of 40 Known, 49 Unknown, and one Conflict. The finalization report records 33 changes: four additions, eight modifications, four downgrades, one drop, 15 resolutions to Unknown, and one supporting-evidence update. It also moves CVE-2016-4437 from development to test and CVE-2022-22963 in the opposite direction. Thus identical 15/60 partition totals do not imply identical membership.

The frozen evaluation configuration and scoring manifest identify GOLD_FINAL by the same SHA-256 digest, 8436148d…f8f4c2cc. The RQ1, RQ2, and RQ3 performance evaluations use this finalized reference and the v3 scoring implementation. The supplementary field-state and Conflict-label distributions, the FI-state and commit-evidence counts, and the case studies use the adjudication-rebuilt reference. Its recorded canonical content digest is 893eb963…521e6b0, which identifies reference content rather than the byte representation of an export wrapper. The two references are analyzed separately and are not interchangeable scoring inputs.

The supplementary evidence analysis checks both whether an evidence identifier resolves and whether the associated content matches its recorded digest. Content-matching copies are available for all 707 entries in its evidence manifest. This establishes traceability to fixed artifacts; it does not independently establish the semantic correctness of every reference label.

3.6.3. Experimental Settings and Evaluation Metrics

Baselines

The internally constructed baselines and ablations for each research question are summarized in Table 1. They isolate evidence and reasoning choices within a shared evaluation interface. They are not implementations of published end-to-end systems, so the present evaluation cannot establish comparative performance against such systems.

Table 1. Baseline configurations.

RQ	Method	Main Characteristics
RQ1	AdvisoryOnly	Uses only vulnerability databases and project advisories
RQ1	MultiSourceMerge	Directly aligns and merges multi-source evidence
RQ1	FixedPriority	Resolves competing claims using a fixed source priority
RQ1	Proposed	Complete method
RQ2	LatestFixOnly	Analyzes only one primary repair
RQ2	AllPatchesFlat	Uses multiple patches without modeling evolutionary relations
RQ2	Proposed w/o FI	Retains patch families but removes fix invariants
RQ2	Proposed	Complete method
RQ3	MultiSourceMerge/FixedPriority	Multi-source merging and fixed-priority baselines
RQ3	w/o Temporal–Scope	Removes temporal–scope constraints
RQ3	w/o Alternative	Removes alternative-trigger relations
RQ3	w/o Abstention	Disallows Unknown abstention
RQ3	Proposed	Complete method

All methods using a large language model adopt DeepSeek deepseek-v4-pro and the same structured-output framework, with thinking mode enabled, high reasoning effort, temperature 0, top-p 1.0, and a maximum output length of 4096 tokens. The scenario-matching threshold is frozen at $\tau =1$. Development tuning evaluated integer thresholds 1–6 and selected 1, with a mean field-count F1 of 0.390491 over available per-CVE development predictions from the four RQ1 methods. This tuning used the earlier field-count scoring objective, rather than Scene F1 under the final Known-only content rule. The v3 evaluation reuses the frozen threshold without retuning. The final test results are conditional on this frozen threshold; assessing robustness under the final scoring rule requires a dedicated threshold-sensitivity analysis.

Operational Definition of Field Macro-F1 and Scene F1

The evaluation uses the v3 scoring implementation, which restricts content credit to Known/Known field pairs. Let $\mathcal{F}=\{\mathrm{comp},\mathrm{ver},\mathrm{sink},\mathrm{pre},\mathrm{env},\mathrm{post}\}$. For predicted scenario p and reference scenario g, define the field and scenario scores in Equation (11)

$$\begin{array}{cc}\hfill b_f(p,g)& =\mathbf{1}\left[state\left(p_f\right)=state\left(g_f\right)=\mathrm{Known}\right]·\mathbf{1}\left[J(p_f,g_f)\ge 0.3\vee R(p_f,g_f)\ge 0.4\right],\hfill \\ \hfill S(p,g)& =\sum _{f\in \mathcal{F}}{b}_f(p,g).\hfill \end{array}$$

(11)

Here $\mathbf{1}[·]$ denotes the indicator function, J is keyword-set Jaccard similarity, and R is Python 3.11.1 SequenceMatcher.ratio on normalized field values. Normalization lowercases and trims strings, collapses whitespace, and removes characters outside the specified word/punctuation set. Keyword extraction splits on the retained delimiters, removes the fixed stopword set, and retains tokens longer than two characters. Jaccard is 1 for two empty keyword sets and 0 when only one is empty; this implementation detail can give content credit to lexically empty values when both states are Known. The supplementary scoring code specifies the exact normalization expression and stopword set. Missing fields default to Unknown. Unknown, Conflict, and N/A pairs receive no scene-similarity credit, and all six fields have equal weight. Therefore $S\in \{0,1,\dots ,6\}$; it is a count of matched Known field values, not a normalized whole-scene similarity.

For each CVE, candidate edges are filtered by $S(p,g)\ge \tau$ before assignment. An exact maximum-weight one-to-one matcher is used to maximize the sum of the retained edge weights, allowing either side to remain unmatched. Its dynamic-programming implementation breaks equal-total-weight ties deterministically by lexicographic order of the index triples; it does not add a maximum-cardinality tie-break. With the frozen $\tau =1$, one matched Known field is sufficient to admit an edge. In particular, a component-only match can contribute a scene true positive even when other fields differ. Thus Scene F1 measures permissively aligned scenario recovery and must be read together with Field Macro-F1; it does not mean that every field of a recovered scenario is correct.

For a CVE v, let $P_v$, $G_v$, and $M_v$ be its predicted scenarios, reference scenarios, and matched pairs. Equation (12) defines Scene F1:

$$\begin{array}{cc}\hfill T{P}_v& = |M_v|,F{P}_v= |P_v| - |M_v|,F{N}_v= |G_v| - |M_v|,\hfill \\ \hfill \mathrm{SceneF}1\left(v\right)& ={\displaystyle \frac{2T{P}_v}{2T{P}_v+F{P}_v+F{N}_v}}.\hfill \end{array}$$

(12)

The score is zero when the denominator is zero, including when both sets are empty; matching is empty when either set is empty. Reported Scene F1 is the arithmetic mean of these per-CVE F1 values over the specified task subset, rather than a pooled micro F1 or the harmonic mean of macro precision and recall. Field Macro-F1 is likewise computed per CVE: a matched Known/Known content match is a true positive; a wrong Known value contributes FP and FN; a predicted Known value without a reference Known value contributes FP; and an unrecovered reference Known value contributes FN. Known values in unmatched scenarios also contribute FP or FN. The six per-field F1 values are averaged, followed by averaging over CVEs, with the same zero-denominator rule.

Other Evaluation Metrics and Interpretation

RQ2-A uses Patch ID F1 and Fix Invariant F1. RQ2-B additionally reports Patch Role Macro-F1 and Patch Relation F1. Proposed w/o FI does not generate fix invariants and is therefore excluded from Fix Invariant F1 comparisons. Because RQ2-B contains only four vulnerabilities, its results are reported descriptively.

RQ3 uses Scene F1, the Unknown-to-Known Error Rate (UKER), and determinate coverage (Coverage). UKER measures only determinate predictions made for Gold-Unknown conditions and must not be interpreted as an all-category error rate. As an auxiliary diagnostic metric, Conflict F1 is also computed for conditions labeled Conflict to assess whether scope-compatible competing claims are correctly retained as Conflict. For vulnerability v, let $U_v$ be the number of Gold-Unknown conditions and $E_v^{UK}$ the number of these conditions output as Known. UKER is defined in Equation (13):

$$UKER\left(v\right)={\displaystyle \frac{E_v^{UK}}{U_v}},U_v>0$$

(13)

when $U_v=0$, UKER is N/A and excluded from the macro average. In total, 10 of the 21 RQ3 vulnerabilities have a nonzero denominator and contribute to reported UKER. Coverage uses all 21 RQ3 vulnerabilities. Let $K_v$ count Known predictions on matched reference fields and $A_v$ count applicable reference conditions, including fields in unmatched reference scenarios but excluding reference N/A fields. Unmatched predictions do not enter this reference-aligned numerator. Coverage is defined in Equation (14):

$$Coverage\left(v\right)={\displaystyle \frac{K_v}{A_v}}$$

(14)

Method comparisons are interpreted as descriptive CVE-level point estimates, with conclusions restricted to the observed evaluation set. Family grouping can reduce dependence between related vulnerabilities, but many singleton groups limit the distinction between group-level and CVE-level analysis. Robustness to aggregation choices requires comparison of both levels in future evaluations.

4. Results

• Analysis scope

Performance tables summarize predictions against GOLD_FINAL using the metrics in Section 3.6.3. The reference-state distributions and cases characterize the separate adjudication-rebuilt snapshot. They describe evidence availability and annotation decisions, rather than additional performance observations, and do not increase the task-specific sample sizes.

4.1. RQ1: Vulnerability-Condition Recovery

Table 2 reports the overall results on the 60 held-out test vulnerabilities.

Table 2. Vulnerability-condition recovery results.

Method	Field Macro-F1	Scene F1
AdvisoryOnly	0.369	0.841
MultiSourceMerge	0.382	0.808
FixedPriority	0.368	0.785
Proposed	0.351	0.769

MultiSourceMerge achieves the highest Field Macro-F1 (0.382), while AdvisoryOnly obtains the highest Scene F1 (0.841). Proposed scores 0.351 and 0.769, respectively. The complete method therefore has no aggregate advantage on this evaluation set. The low threshold permits a scene match with only one Known field in common, which helps explain why Scene F1 is substantially higher than Field Macro-F1. These descriptive comparisons do not establish statistical equivalence or a population-level ordering.

Component information and security consequences are often directly stated in advisories, whereas vulnerable locations, preconditions, and runtime constraints may require project-side evidence. The reference-state distribution below characterizes these evidence differences. It provides context for recovery difficulty but does not attribute individual prediction errors to particular reasoning stages.

Supplementary Reference-Field Observability Analysis

To characterize the evidence available for condition recovery independently of method predictions, we count the six field states in the adjudication-rebuilt reference. Table 3 reports all 84 scenarios in the 60-CVE test split (multiple scenarios may belong to one CVE). The most frequent Gold-Unknown fields are vulnerable location (sink: 20/84) and environment (env: 17/84), whereas component and consequence are Known in all 84 test scenarios. Six version fields in five CVEs have a Conflict state. These distributions describe the reference evidence and are not the proposed method’s accuracy, error rates, or the task-specific RQ3 scoring population.

Table 3. Field-level evidence states in the adjudication-rebuilt test reference (84 scenarios).

Field	Known	Unknown	Conflict	N/A
comp	84	0	0	0
ver	77	1	6	0
sink	64	20	0	0
pre	81	3	0	0
env	65	17	0	2
post	84	0	0	0

4.2. RQ2: Repair-Semantics Recovery

Table 4 presents the RQ2-A results.

Table 4. Repair-semantics recovery results.

Method	Patch ID F1	Fix Invariant F1
LatestFixOnly	0.565	0.609
AllPatchesFlat	0.658	0.203
Proposed w/o FI	0.617	N/A
Proposed	0.632	0.551

AllPatchesFlat obtains the highest Patch ID F1 (0.658), followed by Proposed (0.632), Proposed w/o FI (0.617), and LatestFixOnly (0.565). Broader candidate inclusion is associated with higher patch identification scores in this comparison, although the design does not isolate a causal benefit from candidate expansion or patch-family modeling.

FI recovery has a different ordering. LatestFixOnly obtains the highest FI F1 (0.609), followed by Proposed (0.551) and AllPatchesFlat (0.203). Identifying more patch candidates therefore does not coincide with better invariant recovery in these results. The comparison distinguishes patch identification from semantic constraint recovery, without establishing that flat aggregation causes weaker FI recovery or that the proposed family model improves on single-patch analysis.

RQ2-B contains only four vulnerabilities. AllPatchesFlat and Proposed obtain Patch Role Macro-F1 values of 0.313 and 0.333, respectively, while all methods obtain a Patch Relation F1 of 0. These descriptive results suggest that patch roles can be recovered to some extent, but fine-grained patch-relation recovery remains a weakness of the current method.

Supplementary Repair-Evidence Granularity and Case Analysis

The supplementary evidence archive contains 187 commit records: 181 file-level name-status records and six records labeled fetched-full. Only three contain unified diff hunks. A changed-file listing or retrieval label alone is therefore insufficient to establish line-level repair semantics. This availability analysis concerns the supplementary archive, rather than the complete inputs accessed by each evaluated method. The adjudication-rebuilt reference contains 90 FI objects (37 Known, 52 Unknown, one Conflict), including 72 test objects (27 Known, 44 Unknown, one Conflict). These object counts have a different reference version and population from the 23-CVE RQ2-A performance evaluation.

Two development examples illustrate the reference decision rule. CVE-2017-12629 has a primary fix, two backports, and an XML-parser constraint supported by code and regression tests, while an invariant for a separate command-execution route remains Unknown. For CVE-2016-3081, the archived candidate commit changes release preparation rather than establishing a security repair. Section 4.4 describes the evidence anchors. These examples illustrate scope-specific reference decisions and are separate from the four test cases in RQ2-B.

4.3. RQ3: Uncertainty Handling and Multi-Scenario Reasoning

RQ3 uses 21 test vulnerabilities, 10 of which contain Gold-Unknown conditions for which UKER can be computed. The results are shown in Table 5.

Table 5. Uncertainty and multi-scenario reasoning results.

Method	Scene F1	UKER	Coverage
MultiSourceMerge	0.672	0.483	0.532
FixedPriority	0.625	0.450	0.536
w/o Temporal–Scope	0.634	0.533	0.528
w/o Alternative	0.563	0.450	0.476
w/o Abstention	0.672	0.583	0.571
Proposed	0.593	0.283	0.480

Proposed obtains a Scene F1 of 0.593, below MultiSourceMerge (0.672), FixedPriority (0.625), and the variants without temporal–scope constraints (0.634) or abstention (0.672). Removing Alternative relations yields a lower score of 0.563. The complete framework does not provide a consistent advantage in scenario recovery.

The abstention-related uncertainty metrics show a different pattern. On the 10 samples containing Gold-Unknown conditions, the complete method obtains the lowest reported UKER (0.283). Removing abstention raises UKER to 0.583 while increasing Coverage from 0.480 to 0.571. Removing temporal–scope constraints also produces a higher UKER. These observations characterize abstention behavior; they do not on their own isolate a gain from temporal–scope reasoning at equal coverage. Outputting more determinate conclusions can therefore increase coverage and, in some configurations, Scene F1, but it also increases the risk of converting evidence-insufficient conditions into determinate claims. The observed behavior is therefore a trade-off between a specific Unknown-to-Known error measure and coverage. Lower UKER is not a measure of overall accuracy. Equal-coverage comparisons are needed to distinguish the effects of reasoning from those of abstention.

The current method fails to recover genuine Conflict states under the reported evaluation: Conflict F1 is 0 for all major methods in RQ3. This result does not support an effectiveness claim for automatic Conflict detection, even though the output representation can encode Conflict. Explicit retention and recovery of competing evidence therefore remains an important direction for improvement.

Supplementary Conflict-Level Evidence Analysis

Conflict labels occur at distinct annotation layers in the adjudication-rebuilt reference (Table 6). Six test scenario-field instances occur in version fields across five CVEs; seven test atomic claims and one test FI are also labeled Conflict. These layers can overlap by CVE and cannot be combined into a single recall denominator. CVE-2024-39907 has a supported allowlist-related FI alongside an unresolved version boundary. CVE-2020-17526 has a Conflict-labeled invariant with uncertain repair interpretation. Temporal and scope comparability must be checked before interpreting such labels as logical contradictions. These counts describe reference annotations; identifying the stage responsible for zero automatic Conflict recovery requires intermediate method outputs.

Table 6. Conflict-labeled objects by annotation layer in the adjudication-rebuilt reference.

Object Layer	Development	Test
Scenario fields	3	6
Atomic claims	3	7
Fix invariants	0	1

4.4. Case Studies and Evidence Boundaries

The case studies examine reference decisions and supporting project evidence. CVE-2017-12629 and CVE-2016-3081 are development examples; CVE-2024-39907 and CVE-2020-17526 are test examples. The case analysis is confined to reference decisions and project evidence; it supports interpretation of evidence scope but cannot establish method-specific success or failure without case-level predictions and intermediate reasoning outputs. The cases are illustrative and do not extend the performance evaluation. Evidence identifiers such as ev_005 are local to each CVE and refer to the supplementary artifact inventory.

4.4.1. CVE-2017-12629: Repair-Path-Specific Support

In Apache Solr (https://github.com/apache/lucene-solr (accessed on 20 October 2026)), the primary repair 3bba9113 and backports f9fd6e9e and d8000bee are linked to XML parsing. Evidence ev_005–ev_007 records secure-processing and external-entity rejection changes together with DOCTYPE/ENTITY regression tests. The reference marks the XML-parser FI Known. The separate Config API/RunExecutableListener FI remains Unknown because comparable code, test, or PoC evidence does not support its repair path. This distinction illustrates the scope of invariant support: evidence confirming one repair route does not confirm another. Recognizing a backport in the reference also differs from demonstrating automatic patch-relation recovery.

4.4.2. CVE-2016-3081: A Release Boundary Is Insufficient

Advisories ev_001–ev_003 describe chained-expression execution through the Struts 2 (https://github.com/apache/struts (accessed on 20 October 2026)) method: prefix with Dynamic Method Invocation enabled. Candidate commit ev_005 concerns release preparation in pom.xml; the archived material does not establish a security-behavior change or a before/after test. The reference contains no accepted patch-family object for this CVE and retains its FI as Unknown. An advertised fixed release alone is insufficient to identify a supported repair constraint. This evidence limitation does not imply that no security fix exists elsewhere in the project history.

4.4.3. CVE-2024-39907: Local FI Support and a Version Conflict Label

For 1Panel (https://github.com/1Panel-dev/1Panel (accessed on 20 October 2026)), the reference accepts commit ff549a47 and a sorting-parameter allowlist FI for GORM ORDER BY. Evidence ev_002/ev_004 includes an advisory and PoC, while ev_003/ev_007 links the fix and changed files. Another version-boundary commit, 16a35141, concerns front-end multilingual validation and is excluded as a repair for the SQL-injection behavior. The affected-version boundary remains labeled Conflict. The security commit is represented by file-level evidence without complete diff hunks or regression tests covering every reported injection point. The reference decision therefore supports a local constraint while leaving version interpretation and complete endpoint coverage unresolved.

4.4.4. CVE-2020-17526: Unresolved Repair Interpretation

The archive links Airflow (https://github.com/apache/airflow (accessed on 20 October 2026)) SECRET_KEY-related commits 2f3b1c78, 97b2735d, and 6b065840 to code or default-configuration changes (ev_008–ev_010). Other version-boundary evidence points to an unrelated commit and a later fixed release. The FI is labeled Conflict, and the relevant repair identities remain uncertain. A commit preceding a release does not itself imply contradictory security behavior; backporting or delayed release can explain that chronology. Resolving the interpretation requires comparison within the same branch, configuration, affected range, and security behavior. The available archive lacks sufficient diff hunks, regression tests, and verified PoC evidence for that comparison, so the label remains an unresolved reference interpretation.

The cases illustrate three distinct evidence requirements: identifying a candidate repair, supporting its protective semantics, and comparing competing interpretations within compatible scopes. Missing evidence at any of these levels can prevent a determinate reference decision. The cases do not quantify the prevalence or causal contribution of individual algorithmic failure stages.

5. Discussion

5.1. Applicability and Limitations

The evaluation shows that adding repair-family organization and temporal–scope reasoning does not yield an overall recovery advantage over simpler evidence-utilization strategies. AdvisoryOnly performs best on Scene F1 in RQ1, LatestFixOnly performs best on FI F1 in RQ2-A, and automatic patch-relation and Conflict recovery remain unsuccessful. The proposed representation makes repair scopes and uncertainty states explicit, but its additional reasoning mechanisms require stronger validation before their performance benefits can be established.

The method depends on public project-side evidence. When actual repair commits, code diffs, tests, or PoCs are missing, code-level vulnerable locations and fix invariants may remain Unknown. When security fixes are entangled with large-scale refactoring, functional migration, or dependency upgrades, patch disentanglement and semantic alignment become more difficult. Current results also show zero Patch Relation F1 on the four RQ2-B cases; the proposed relation modeling has not demonstrated effective automatic recovery in that subset. Abstention reduces the risk of making determinate claims from insufficient evidence but correspondingly reduces result coverage.

$VFS\left(v\right)$ is a vulnerability-side condition specification and does not imply that a specific target system satisfies these conditions. Component presence, patch status, path reachability, and runtime environment in target software still require further confirmation. The current experiments cover the Maven, PyPI, and Go ecosystems; differences among ecosystems in version conventions, branch maintenance, and code organization may affect method performance, and applicability to other ecosystems requires further validation.

5.2. Threats to Validity

Construct validity. The six fields comp, ver, sink, pre, env, and post describe the component, version, code location, trigger conditions, runtime environment, and security consequence. Complex protocol states, concurrent behavior, or hardware constraints may require an extended representation. Lexical content matching approximates semantic equivalence and can be affected by paraphrases, sparse keywords, and empty keyword sets. Scene F1 accepts pairs sharing one Known field and therefore does not measure complete six-field correctness. The threshold was selected with an earlier field-count objective and reused under the final scoring rule, making the reported results conditional on that choice. Future evaluations should assess threshold sensitivity under the final metric definition.

Internal validity. Reference construction involves human semantic judgment. Reliance on adjudication without a quantified independent-agreement measure limits assessment of label reproducibility. Evidence anchors and frozen artifacts support traceability but cannot by themselves establish label correctness or inter-annotator agreement. GOLD_FINAL and the adjudication-rebuilt reference have different object states and partition membership. Their scoring and descriptive uses are kept separate to avoid conflating populations; incomplete object-level provenance between versions limits independent verification of the conversion. The language model may also contain prior knowledge of public vulnerabilities. Requiring locatable evidence limits unsupported claims, while human judgment and model priors remain possible sources of bias.

External validity. The dataset covers Maven, PyPI, and Go and selects vulnerabilities with sufficient traceable project-side evidence. The conclusions therefore primarily apply to open-source component vulnerabilities with traceable evidence. The dataset should be interpreted as an evaluation set for the proposed recovery mechanisms rather than as a statistically representative sample of vulnerability populations in Maven, PyPI, or Go. Other software ecosystems and vulnerabilities with non-public repair histories require further validation. The comparative evaluation is restricted to internal baselines under a shared interface, which limits conclusions relative to published systems. Future evaluations should implement comparable shared subtasks against such systems; task-comparability analysis alone cannot establish relative performance. Complex-feature subsets such as RQ2-B (four vulnerabilities) are too small to establish robust performance claims, and UKER in RQ3 is defined for only 10 test vulnerabilities. Accordingly, observations about these mechanisms are descriptive and require validation on additional independent instances.

Conclusion validity. The results are descriptive within-study comparisons. Small task subsets, especially the four RQ2-B cases and the ten cases contributing to UKER, limit the stability of method differences. Many singleton family groups also limit the additional information obtainable from group-level aggregation. The reported comparisons depend on the selected CVE aggregation, frozen threshold, and operating coverage. Future studies should assess stability across aggregation levels and scoring thresholds, and compare methods at equal coverage. Aggregate metrics and reference cases cannot establish causal contributions of individual modules, population-level performance, or the first failing stage of Conflict recovery.

6. Conclusions

This paper presents a framework for recovering open-source component vulnerability conditions from multi-source public evidence. Atomic claims capture provenance, time, and scope; patch families organize repair evolution and support scoped fix invariants; and temporal–scope reasoning separates supersession, alternative triggers, and comparable competing claims. The output is a scenario-based vulnerability fingerprint set with explicit evidence states.

Evaluation on 75 vulnerabilities from Maven, PyPI, and Go, with 15 development and 60 test cases, shows no overall advantage for the complete framework. Flat multi-patch analysis obtains the highest patch identification score, while single-patch analysis obtains the highest FI score. Proposed has the lowest Unknown-to-Known error rate on the eligible RQ3 cases, accompanied by lower determinate coverage; automatic patch-relation and Conflict recovery remain unsuccessful. Reference-state distributions and evidence cases characterize the gaps in repair support and the ambiguity of scope-compatible comparisons.

The findings identify evidence completeness, repair semantics, and uncertainty handling as central constraints on automatic condition recovery. The framework describes vulnerability-side conditions and does not determine vulnerability presence or exploitability in a specific target system. Further work should evaluate shared subtasks against published systems, quantify independent annotation agreement, test robustness to scoring thresholds and aggregation choices, and improve patch-relation and competing-evidence recovery before extending the evaluation to additional ecosystems and target-side confirmation.