A warehouse-level vulnerability detection method and system based on evidence-aware contextual distillation

Abstract

The application discloses a warehouse-level vulnerability detection method and system based on evidence-aware context distillation, which comprises warehouse-level selective vulnerability evidence graph construction, sensitive API-based CWE candidate vulnerability type screening, structure-knowledge-semantic three-way candidate evidence enhancement, multi-round evidence-preserving context distillation, and large language model vulnerability judgment and report generation based on evidence closure. The scheme organizes and distills the warehouse-level context around the role of vulnerability evidence, can retain the minimum evidence set required for vulnerability judgment under limited budget, and suppresses repeated evidence and irrelevant context, thereby improving the evidence density and judgment stability of the large language model input context. At the same time, through sensitive API-based CWE candidate vulnerability type screening, the accuracy, explainability and reviewability of vulnerability judgment are improved. Through candidate evidence enhancement, false positives caused by judgment based only on code surface text or sensitive function names can be reduced.

Description

Technical Field

[0001] This invention belongs to the field of software security and intelligent code auditing, specifically relating to a repository-level vulnerability detection method and system based on evidence-aware context distillation. Background Technology

[0002] As software systems continue to grow in scale, modern applications typically consist of numerous source code files, third-party dependencies, configuration files, build scripts, and cross-module call relationships. Actual vulnerabilities rarely exist in isolation within a single function or file; rather, they arise from combinations of external input, cross-function data propagation, type conversion, configuration constraints, security checks, and sensitive operations. For example, user input might enter the system through an entry function, be processed by multiple business functions, utility functions, or configuration items, and ultimately flow into sensitive APIs such as command execution, SQL execution, file access, deserialization, template rendering, or memory operations. These vulnerabilities exhibit clear repository-level characteristics; analysis relying solely on local function code or single-file context makes it difficult to fully reconstruct the vulnerability trigger path, defense logic, and counter-evidence.

[0003] Existing vulnerability detection technologies mainly include traditional static analysis methods, vulnerability detection methods based on machine learning or deep learning, and vulnerability detection methods based on large language models. Traditional static analysis methods typically use abstract syntax trees, control flow graphs, data flow graphs, call graphs, or program dependency graphs to analyze dangerous APIs, taint propagation paths, boundary checks, and security rules. These methods have the advantages of controllable rules and relatively interpretable results, but they still have certain limitations in large-scale real-world repositories. On the one hand, static analysis is prone to problems such as missing call edges, spurious dependency edges, or incomplete context when dealing with polymorphic calls, reflection calls, function pointers, callback functions, dynamic dispatch, macro expansion, and complex configuration dependencies. On the other hand, traditional rules usually rely on manual maintenance, making it difficult to cover framework-specific security semantics, business logic vulnerabilities, cross-function state constraints, and complex defense effectiveness judgments, thus easily leading to false positives and false negatives in actual code audits.

[0004] Machine learning or deep learning-based vulnerability detection methods typically represent code as token sequences, function fragments, code slices, abstract syntax trees, or program dependency graphs, and learn vulnerability patterns through models. These methods can alleviate the problem of insufficient coverage by manual rules to some extent, but they usually rely on high-quality labeled data and primarily analyze function-level or fragment-level samples. Existing learning methods often struggle to fully utilize cross-file call chains, global configurations, type definitions, dependency versions, patch differences, and internal security check logic in real-world code repositories. Furthermore, model outputs typically present "vulnerable" or "no-vulnerability" classification results, lacking structured descriptions of external input sources, sensitive sinks, propagation paths, defense checks, and counter-evidence information, making it difficult to meet the requirements of vulnerability root cause localization, evidence tracing, and manual review in actual code auditing.

[0005] In recent years, large language models have demonstrated strong capabilities in code understanding, code generation, and security analysis tasks. Existing methods attempt to input source code, vulnerability knowledge, program structure information, or retrieved context into large language models for vulnerability identification and interpretation. While these methods possess good semantic understanding and natural language interpretation capabilities, they still face significant challenges in repository-level vulnerability detection scenarios. First, complete code repositories contain a large amount of business logic, log statements, boilerplate code, test code, and configuration content irrelevant to vulnerability identification. Directly inputting a large amount of context can easily distract the model, causing critical vulnerability evidence to be buried under irrelevant information. Second, common retrieval enhancement methods often select context based on semantic similarity, keyword matching, or function call relationships, but cannot guarantee the complete preservation of crucial evidentiary roles such as source, sink, propagation, check, type / config, diff, and counter-evidence necessary for vulnerability identification. Third, large language models are easily influenced by superficial features such as function names, variable names, comments, and sensitive APIs, misinterpreting "the existence of sensitive operations" as "the existence of a real exploitable vulnerability," or generating false positives while ignoring effective security checks and counter-evidence.

[0006] In actual code auditing, security personnel determine whether a vulnerability exists not simply by checking if a dangerous function is present. Instead, they need to comprehensively verify whether external inputs are controllable, whether a reachable propagation path to the sensitive endpoint exists, whether effective filtering or validation occurs during propagation, whether the type and configuration conditions meet the vulnerability triggering conditions, and whether there is counter-evidence that can prove the code is secure. Therefore, the key to repository-level vulnerability detection is not just retrieving more code, but how to identify, organize, and retain sufficient key evidence to support vulnerability judgment within the entire code repository, ensuring that the model can still obtain a complete, compact, and verifiable chain of vulnerability evidence within a limited context window.

[0007] In summary, existing methods often focus on single functions, single files, or similar code snippets, making it difficult to comprehensively capture evidence such as external input sources, cross-function propagation paths, sensitive sinks, security checks, type constraints, configuration conditions, and counter-evidence. Directly inputting large amounts of repository code into a large language model can easily introduce irrelevant code interference, burying crucial evidence that truly affects the validity of a vulnerability. Furthermore, relying solely on sensitive APIs or dangerous functions for vulnerability assessment fails to effectively distinguish between "the existence of sensitive operations" and "the existence of a genuinely exploitable vulnerability," easily leading to false positives or false negatives. It is evident that a repository-level context organization and distillation mechanism tailored to the role of vulnerability evidence is still lacking, making it difficult to simultaneously ensure contextual integrity, input compactness, and interpretability of the judgment. Summary of the Invention

[0008] To address the problems of incomplete context, redundant long contexts, missing key vulnerability evidence, and insufficient interpretability of model judgments in existing repository-level vulnerability detection methods in real-world code auditing scenarios, this invention provides a repository-level vulnerability detection method and system based on evidence-aware context distillation. First, the code repository to be analyzed undergoes static analysis to construct a selective vulnerability evidence graph containing information such as functions, statements, variables, types, configurations, call relationships, control flow, data flow, and patch differences. Then, using sensitive APIs, dangerous functions, or user-specified audit targets as vulnerability analysis anchors, CWE candidate vulnerability type filtering is performed to generate one or more candidate vulnerability hypotheses. For each candidate vulnerability hypothesis, the system supplements the candidate vulnerability evidence from three levels: structural context, knowledge context, and semantic context, and labels the candidate evidence blocks with evidence roles such as source, sink, propagation, check, type / config, diff, and counter-evidence. Based on this, the system performs evidence-aware context distillation under a limited token budget, according to the importance of evidence, evidence coverage, and context redundancy. It prioritizes retaining the minimum set of evidence necessary for vulnerability judgment, and finally inputs the distilled evidence context into a large language model for structured vulnerability judgment, root cause analysis, and remediation suggestion generation.

[0009] The specific technical solution for achieving the objective of this invention is as follows:

[0010] A repository-level vulnerability detection method based on evidence-aware context distillation includes the following steps:

[0011] Step 1: Construct a repository-level selective vulnerability evidence graph;

[0012] Step 2: Screening of CWE candidate vulnerability types based on sensitive APIs;

[0013] Step 3: Enhance candidate evidence through three approaches: structure, knowledge, and semantics;

[0014] Step 4: Multi-round evidence-preserving contextual distillation;

[0015] Step 5: Vulnerability assessment and report generation based on the large language model of evidence closure.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0017] The solution of this invention no longer relies on single function code, simple semantic similarity retrieval, or the free understanding of long code by a large language model. Instead, it organizes and distills the repository-level context around the role of vulnerability evidence, which can more completely capture the vulnerability propagation chain and defense logic across files, functions, and configurations.

[0018] Meanwhile, this invention uses sensitive APIs only as candidate analysis entry points, rather than directly as vulnerability conclusions. It improves the accuracy, interpretability, and verifiability of vulnerability assessment through CWE candidate vulnerability type filtering, evidence role retention, evidence closure verification, and counter-evidence constraints. Through structure-knowledge-semantic three-way candidate evidence enhancement, this invention can supplement program structure evidence, vulnerability type knowledge, and code functional semantics before candidate vulnerability assessment, reducing false positives caused by judging solely based on surface text or sensitive function names. Through multi-round evidence-preserving context distillation, this invention can retain the minimum set of evidence required for vulnerability assessment under a limited token budget, and suppress duplicate evidence and irrelevant context, thereby improving the evidence density and judgment stability of the large language model input context.

[0019] In addition, the final output of this solution includes not only whether the vulnerability exists, but also the vulnerability type, risk location, propagation path, defense effectiveness, root cause analysis, and remediation recommendations, which can better meet the needs of actual code auditing, enterprise-level security testing, and software supply chain security governance.

[0020] The present invention will be further described below with reference to specific embodiments. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the evidence-aware context distillation method for warehouse-level vulnerability detection in this solution. Detailed Implementation

[0022] Example

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0025] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application. It should also be understood that, for ease of description, the dimensions of the various parts shown in the drawings are not drawn to actual scale. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0026] Combination Figure 1 A repository-level vulnerability detection method based on evidence-aware context distillation includes the following steps:

[0027] Step 1: Constructing a repository-level selective vulnerability evidence graph:

[0028] Step 1-1: Analyze the code repository Static parsing is performed to extract code entities from the repository. These code entities include file entities, function or method entities, statement entities, variable entities, parameter entities, field entities, return value entities, type entities, configuration item entities, dependency declaration entities, and permission declaration entities. Type entities can include classes, structs, enumerations, macro definitions, type aliases, or generic types. Configuration item entities can include environment variables, framework configurations, permission configurations, and third-party dependency version information.

[0029] Based on this, a repository-level selective vulnerability evidence graph was constructed. :

[0030]

[0031] Among them, code repository In Represents a collection of source code files. This represents a set of third-party dependency declarations. Represents a collection of configuration files. This indicates the construction of a script collection. Represents a set of optional patch differences, commit differences, or version differences; repository-level selective vulnerability evidence graph. In This represents a set of nodes, which includes at least file nodes, function nodes, statement nodes, variable nodes, type nodes, configuration nodes, input source nodes, sensitive sink nodes, security check nodes, patch difference nodes, and external interface nodes. A set of edges represents at least the following relationships: containment, function call, control flow, data flow, type reference, alias, configuration reference, and patch difference. Containment relationships represent hierarchical structures between files, classes, functions, and statements; function call relationships represent cross-function or cross-file calls; control flow relationships represent branching, looping, and execution order; data flow relationships represent variable definition, assignment, parameter passing, and return value propagation; type reference relationships represent the association between type declarations and code entities; alias relationships represent pointers, references, object fields, or variable aliases; configuration reference relationships represent dependencies between code entities and configuration items; and patch difference relationships represent code difference mappings between vulnerable versions and patched versions. Represents the node feature matrix, Represents the edge weight matrix. Represents the security evidence label corresponding to a node or edge;

[0032] Steps 1-2: For repository-level selective vulnerability evidence diagrams any edge in Assign it a confidence weight This is used to describe the reliability of the program relationship corresponding to the edge. Edges obtained from deterministic static analysis have high weights, edges supplemented based on heuristic rules or semantic inference have medium weights, and edges that cannot be fully confirmed but may affect vulnerability judgment are marked as uncertain edges. In this way, the system does not require complete and accurate recovery of all program dependencies, but explicitly models the uncertainty of dependencies and increases the retention priority of uncertain regions in the subsequent context distillation stage.

[0033] For any node Given vulnerability analysis anchor points and candidate vulnerability types Define the relevance of vulnerability evidence to a node:

[0034]

[0035] in Represents a node With vulnerability analysis anchor points In the evidence diagram, the closer the distance, the higher the correlation. Represents a node Is it located at an external input source? To the vulnerability anchor point On the reachable path; Indicates the node in the candidate vulnerability type The strength of the security evidence role undertaken by the subordinate; Indicates whether the node is located in the patch difference region; Indicates whether there are uncertain edges or uncertain regions in static analysis around the node; Indicates whether a node contains security checks, defense logic, or counter-evidence information; Configurable weights;

[0036] If node If the relevance of the vulnerability evidence meets a preset threshold, it will be retained for the detection unit. The selective vulnerability evidence subgraph; otherwise, it is compressed into a summary node or filtered from the current detection context, thus obtaining:

[0037]

[0038] in, This represents the set of evidence nodes that have been preserved. Indicates vulnerability analysis anchor points and candidate vulnerability types Selective vulnerability evidence subgraph, This represents the node retention threshold.

[0039] By employing the above methods, this solution retains cross-file, cross-function, cross-configuration, and cross-type evidence related to vulnerability assessment at the repository level, while filtering out ordinary business logic, log statements, boilerplate code, irrelevant utility functions, and low-risk branches, thereby reducing noise in the subsequent large language model input context.

[0040] Step 2: Screening CWE candidate vulnerability types based on sensitive APIs:

[0041] In the selective vulnerability evidence graph G, the system identifies vulnerability analysis anchor points. These anchor points can be sensitive APIs, dangerous functions, external input entry points, permission boundary interfaces, file access functions, command execution functions, SQL execution functions, deserialization functions, template rendering functions, memory read / write functions, or user-defined audit targets.

[0042] In this implementation, sensitive APIs serve only as entry points for vulnerability analysis and are not directly used as the basis for vulnerability determination. That is, after the system identifies a sensitive API or dangerous function, it does not immediately determine that a vulnerability exists there. Instead, based on the API semantics, code context, data propagation path, configuration conditions, and historical vulnerability information of that anchor point, it first filters one or more potentially related CWE candidate vulnerability types to form candidate vulnerability hypotheses, specifically including:

[0043] Step 2-1: For any vulnerability analysis anchor point and candidate vulnerability types Calculate the matching score between the two:

[0044]

[0045] in, This represents the rule mapping score between the sensitive API and the CWE type; This indicates the semantic similarity between the anchor context and the CWE description, vulnerability example, and remediation example. This indicates whether there is a source-sink path in the current evidence graph that matches the CWE triggering pattern; This indicates the degree to which the repository's historical vulnerabilities, commit information, patch differences, and the CWE match. Indicates whether configuration items, permission declarations, dependency versions, or environment variables enhance the CWE hypothesis; These are the weighting coefficients;

[0046] Step 2-2: Sort the candidate CWE types according to the matching score, and select several candidate vulnerability types with the highest scores that exceed a preset threshold to form a candidate set:

[0047]

[0048] in, Indicates anchor points for vulnerability analysis The corresponding set of candidate CWE types, This indicates that the top k candidate types with the highest scores are selected. This indicates the threshold for retaining candidate types.

[0049] For each candidate vulnerability type in the candidate set The system will As an independent vulnerability detection unit, it constructs corresponding structural, knowledge, and semantic contexts in subsequent steps. This design avoids evidence confusion between different vulnerability types, enabling the system to determine the validity of different candidate vulnerability hypotheses separately.

[0050] It should be noted that the CWE candidate vulnerability type screening outputs candidate vulnerability hypotheses, not final vulnerability conclusions. Whether a vulnerability ultimately exists still requires a comprehensive judgment based on evidence such as whether the source is controllable, whether the sink is dangerous, whether the propagation path is reachable, whether defense checks are effective, and whether type constraints and configuration conditions are met.

[0051] For example, the same file access API may correspond to different candidate vulnerability types such as path traversal, arbitrary file reading, arbitrary file writing, or privilege escalation; template rendering API may correspond to cross-site scripting, template injection, or expression injection; command execution API may correspond to command injection, parameter injection, or privilege abuse. The system uses CWE candidate vulnerability type filtering to determine the direction of subsequent analysis, rather than directly equating the appearance of a sensitive API with the existence of a vulnerability.

[0052] Step 3: Enhancement of candidate evidence through three pathways: structure, knowledge, and semantics. That is, for each detection unit... Three complementary contexts are constructed: structural context, knowledge context, and semantic context. The structural context provides code facts and program dependencies; the knowledge context provides security prior knowledge of candidate vulnerability types; and the semantic context assists in understanding the functional behavior of candidate code segments. These three contexts complement each other, jointly forming an evidentiary context for candidate vulnerability hypotheses, including:

[0053] Step 3-1: Structural context generation, used to describe program structure information related to candidate vulnerabilities, including function call relationships, control flow relationships, data flow relationships, type constraints, configuration references, patch differences, and uncertain dependency areas, i.e., for the selective vulnerability evidence subgraph. Extract structural evidence related to the current vulnerability analysis anchor and candidate vulnerability types, and select structural information of different granularities based on context budget and vulnerability type;

[0054] In this implementation, a multi-granularity filtering strategy can be adopted. When the context budget is small or the evidence is relatively concentrated, the system prioritizes retaining high-level structural information such as function calls, branch conditions, return statements, input sources, and sensitive APIs. When it is necessary to further determine whether the data is controllable or to check its validity, the system continues to retain assignment statements, key variables, parameter passing relationships, conditional expressions, and security check statements. When the candidate vulnerability type is closely related to the type definition, configuration item, or dependency version, the system further retains type declarations, global variables, configuration items, macro definitions, dependency versions, patch differences, and context near uncertain edges.

[0055] In the manner described above, the structural context can include at least the call chain context, data flow context, control flow context, type constraint context, configuration context, and patch difference context. Specifically, the call chain context describes the call relationships between external inputs, business functions, utility functions, and sensitive APIs; the data flow context describes the variable definition, assignment, parameter passing, and return value propagation processes; the control flow context describes branching, looping, exception handling, and reachability conditions; the type constraint context describes object types, field access, type conversion, and alias relationships; the configuration context describes how code behavior is affected by configuration items, permission declarations, or dependency versions; and the patch difference context describes key changes between the vulnerability version and the patched version.

[0056] Step 3-2: Knowledge context generation, used to provide external security knowledge for candidate vulnerability types:

[0057] Let the vulnerability knowledge base be... Each knowledge entry This includes the CWE number, vulnerability name, vulnerability description, dangerous API, triggering conditions, vulnerability example, remediation example, effective defense methods, and common error defense methods;

[0058] Constructing a search query:

[0059]

[0060] in, This indicates the anchor point for vulnerability analysis. and candidate vulnerability types The structural context extracted from the selective vulnerability evidence subgraph includes at least one of function call relationships, control flow relationships, data flow relationships, type constraints, configuration references, patch differences, security checks, and uncertain dependency regions. This means that vulnerability analysis anchors, candidate vulnerability types, and corresponding structural contexts are encoded into knowledge retrieval queries.

[0061] The similarity between the query and the knowledge item is calculated using a dense-sparse hybrid retrieval method.

[0062]

[0063] in, Represents dense semantic encoding, This represents the weighted encoding of sparse terms. The fusion coefficient is represented by the top-M knowledge items with the highest similarity, which are selected as the selective vulnerability evidence subgraph. Knowledge context:

[0064]

[0065] The knowledge context is only used to constrain and assist in subsequent vulnerability judgments, and does not directly determine the vulnerability conclusion. In other words, even if a certain sensitive API is highly related to a certain CWE type, the system still needs to combine the external input sources, propagation paths, defense checks and counter-evidence information in the actual code to determine whether the vulnerability exists.

[0066] Step 3-3: Semantic context generation, used to denoise and summarize the functional behavior of candidate code snippets.

[0067] First, a semantic summary is generated based on the original code and structural context:

[0068]

[0069] in, Indicates vulnerability analysis anchor point The original candidate code fragments extracted from the code repository are centered on the anchor point. The original candidate code fragments include the code statement corresponding to the anchor point, the function where the anchor point is located, and at least one of the following related to the anchor point: variable definition, parameter passing, condition judgment, and security check. This represents a semantic summarization operation that combines structural context to denoise and summarize the functional behavior of the original candidate code snippets; Indicates anchor points for vulnerability analysis and candidate vulnerability types The corresponding semantic context;

[0070] Steps 3-4: Contextualize the three candidate evidence streams—structure, knowledge, and semantics—to form a candidate evidence context.

[0071]

[0072] Wherein, ⊕ represents splicing, alignment, summary fusion, or structured recombination operations.

[0073] Step 4: Multi-round evidence-preserving context distillation. After structural, knowledge, and semantic enhancements, the input may still exceed the effective input window of a large language model. Therefore, this implementation proposes a multi-round evidence-preserving context distillation mechanism. This mechanism does not truncate based on code length, nor does it filter solely based on semantic similarity; instead, it preserves evidence according to the roles required for vulnerability assessment.

[0074] Step 4-1: Context of candidate evidence The evidence is divided into several evidence blocks, and each evidence block is assigned a role. An importance score is calculated for each evidence block. The importance of an evidence block depends not only on its relevance to the candidate vulnerability type, but also on whether it is located on the source-sink path, whether it contains security checks, whether it contains counter-evidence, whether it is located in the patch difference area, and whether it is close to the static analysis uncertainty area.

[0075]

[0076] in, Indicates evidence block Character strength, Indicates evidence block Is it located on the source-sink path? express Degree of match with candidate CWE types express Is it located in the patch difference area? express Does it include defense checks? express Does it include security counter-evidence? express Whether it is close to the edge of an uncertain relationship or the uncertain region of static analysis;

[0077] The role labeling types of the evidence blocks include external input source, sensitive sink, propagation path, security check, type constraint, configuration evidence, patch difference, vulnerability knowledge, and security counter, etc.

[0078] To prevent critical evidence from being mistakenly deleted during compression, a mandatory retention constraint is set. Specifically, when the role label type of an evidence block is external input source, sensitive sink, propagation path, security check, type constraint, patch difference, or security counter, its retention ratio must not be lower than a preset threshold. .

[0079] Step 4-2: Under the premise of satisfying the system token budget constraint, perform context distillation on the evidence block to maximize evidence importance and coverage while reducing context redundancy. The objective function is defined as follows:

[0080]

[0081]

[0082]

[0083] The constraints are:

[0084]

[0085] in, Indicates evidence block The original token length, Indicates the total token budget. Indicates a pre-defined evidence block The retention ratio, ; Indicates the coverage of evidence. Indicates context redundancy. Indicates the coverage reward weight. Indicates the redundancy penalty weight; This represents the set of key evidence role types. This indicates the weight of different evidentiary roles. Indicates an indicator function; This represents the semantic similarity, code similarity, or graph proximity similarity between two blocks of evidence. Indicates evidence block The corresponding set of evidence role tags;

[0086] Solve the objective function to obtain the optimal retention ratio vector for each evidence block. And perform deletion, digest compression or full retention operations on each evidence block according to the optimal retention ratio to obtain a set of distilled evidence blocks that satisfy the total token budget constraint;

[0087] Step 4-3: After multiple rounds of evidence-preserving context distillation, if the current context already covers the minimum set of evidence required for vulnerability determination, or if the remaining token budget is insufficient to continue preserving new valid evidence, then the distillation process is stopped, and the distilled candidate evidence context is obtained:

[0088]

[0089] The context of the distilled candidate evidence should satisfy the minimum indeterminate condition:

[0090]

[0091] in, This represents the evidence role coverage determination function, used to determine whether the distilled candidate evidence context contains sufficient information to support the evidence role. The evidence for determination; when the context of the distilled candidate evidence contains at least one element related to the role of the evidence. When there is a corresponding reserved evidence block, or when there is equivalent role evidence consisting of multiple reserved evidence blocks and their summaries, ,otherwise, ; This indicates that external input source evidence is covered. This indicates that evidence regarding sensitive remittance points has been covered. This indicates that evidence of the propagation path from the external input source to the sensitive sink is covered. This means that sufficient evidence to determine the existence and effectiveness of security checks along the transmission path is covered; in particular, confirmation that no relevant security checks exist is also considered as security check status being covered.

[0092] For certain vulnerability types, further requirements are also specified:

[0093]

[0094] In addition, in each iteration of the multi-round evidence-preserving context distillation, the maximum marginal relevance score is calculated for the candidate evidence blocks that have not yet been selected, and the evidence blocks to be selected in the current round are determined based on the maximum marginal relevance score, so as to achieve a balance between relevance, importance, evidence diversity and key evidence role coverage.

[0095] No. Evidence Block in Wheel The maximum marginal correlation score is:

[0096]

[0097] Then, select the evidence block with the highest maximum marginal relevance score and satisfying the remaining token budget constraint from the set of candidate evidence blocks that have not yet been selected:

[0098]

[0099] Add the selected evidence block to the currently selected evidence block set, and update the covered evidence roles, remaining token budget and evidence memory status, and enter the next iteration until the minimum evidence judgment condition is met or the remaining token budget is insufficient;

[0100] in, Indicates the first The set of candidate evidence blocks that have not yet been selected in the round. Indicates the first The set of evidence blocks already selected at the start of the round; This indicates a vulnerability analysis query constructed based on the current vulnerability analysis anchor and candidate vulnerability types; Indicates evidence block With vulnerability analysis and query The degree of relevance; Indicates evidence block Importance rating; Indicates evidence block With the selected evidence block Semantic similarity, code similarity, or graph proximity similarity between them; Indicates the selection of evidence blocks The latter is relative to the currently selected evidence.

[0101] To prevent critical evidence from being mistakenly deleted during compression, the system sets a mandatory retention constraint. When an evidence block contains critical evidence roles such as source, sink, propagation, check, type, diff, or counter, its retention rate must not be lower than a preset threshold z_min. This constraint is used to prevent critical vulnerability evidence from being mistakenly deleted during compression. Conversely, log statements, ordinary business branches, repetitive utility functions, boilerplate code, test code, or context unrelated to the candidate vulnerability type can be summarized or directly filtered.

[0102] In addition, during the context distillation process, after each round of distillation, the next round of evidence block selection strategy is adjusted based on the retained evidence, the covered evidence roles, the remaining token budget, and the key evidence roles that have not yet been covered, and the evidence memory state is maintained:

[0103]

[0104] in, Indicates the first Post-cycle evidence memory state Denotes the set of evidence blocks processed in round t. This represents the retention strategy in round t. This indicates the summary information for the current round. This indicates the content of the evidence retained in the current round;

[0105] In the During the cycle, the state of memory is based on evidence. Increase the selection priority of candidate evidence blocks that can supplement key evidence roles that are not yet covered, decrease the selection priority of candidate evidence blocks that overlap with the accumulated retained evidence, and determine the retention ratio of candidate evidence blocks based on the remaining token budget.

[0106] Step 5: Vulnerability assessment and report generation based on a large language model with evidence closure:

[0107] Distilled candidate evidence context Candidate vulnerability types Knowledge Context The evidence and role information are organized into structured prompts, which are then input into a large language model for vulnerability assessment.

[0108] The large language model judgment function is:

[0109]

[0110] in, 1 indicates that candidate vulnerability type c is at the anchor point 0 indicates that the statement is true, and 0 indicates that it is false.

[0111] To avoid the model making judgments based solely on sensitive APIs, dangerous function names, or vulnerability knowledge, the large language model outputs structured vulnerability analysis results, including vulnerability conclusions, external input sources, sensitive sinks, propagation paths, existing security checks, security counter-evidence, root causes of vulnerabilities, confidence levels, and remediation recommendations.

[0112] The conclusions of this scheme do not accept simple classifications of "vulnerable" or "not vulnerable". Instead, the model is required to provide specific evidence on which the vulnerability is established or not.

[0113] Subsequently, evidence closure verification is performed on the model output. For a vulnerability establishment conclusion, the system requires that the model output must correspond to the actual code facts in the distillation context or selective vulnerability evidence graph, and at least explain the following: whether the external input is controllable, whether the sensitive sink exists, whether the external input can reach the sensitive sink along the propagation path, and whether there is a lack of effective security checks that can block the current candidate vulnerability type during propagation. If the model cannot provide complete source, sink, and propagation evidence, or if existing security checks can effectively block the candidate vulnerability type, then a confirmed vulnerability will not be directly output.

[0114] For conclusions that a vulnerability is not established, the system requires the model to provide effective security checks or counter-evidence. Effective security checks may include defensive logic capable of blocking the triggering conditions of candidate vulnerabilities, such as whitelist verification, parameterized calls, boundary checks, permission verification, encoding escaping, type constraints, configuration restrictions, or resource access control. If the model relies solely on non-evidence-based descriptions such as "no obvious problems were found" or "the code appears safe," the system will not directly output a confirmed security result, but will instead mark the detection unit as a suspected result or place it in a manual review queue.

[0115] After the evidence closure verification, the system further calculates the overall confidence level:

[0116]

[0117] in, Indicates the confidence level of CWE routing. Indicates the source-sink path strength. Indicates the coverage of evidence. Indicates the effectiveness score of the defense inspection. This indicates the consistency between the model output and the actual code. This indicates the degree of conflict between evidence of vulnerabilities and evidence of security rebuttal.

[0118] If the overall confidence level reaches a preset threshold, and the chain of evidence required for the vulnerability to be established is complete, and there are no effective security checks that can block the candidate vulnerability type, then the system outputs a confirmed vulnerability. If the overall confidence level reaches a preset threshold, and there are effective security checks or security counter-evidence that can cover the current candidate vulnerability type, then the system outputs a confirmed security. If the evidence coverage is insufficient, the model output is inconsistent with the code facts, or there is an irreconcilable conflict between the vulnerability evidence and the security counter-evidence, then the system outputs a suspected vulnerability and enters the manual review queue.

[0119] When vulnerability evidence conflicts with security counter-evidence, the system resolves the conflict based on the strength of the vulnerability evidence and the strength of the security counter-evidence. If the strength of the vulnerability evidence is significantly higher than the strength of the security counter-evidence, the system outputs that the vulnerability is valid; if the strength of the security counter-evidence is significantly higher than the strength of the vulnerability evidence, the system outputs that the vulnerability is invalid; if the difference between the two is insufficient to support automatic judgment, the system outputs the result of manual review.

[0120] Finally, a vulnerability analysis report is generated. The report includes whether the vulnerability exists, the CWE type, the risk level, the code location, the source location, the sink location, the propagation path, defense checks and their effectiveness, counter-evidence, root cause explanation, confidence level, and remediation recommendations.

[0121] In addition, this solution also provides a repository-level vulnerability detection system based on evidence-aware context distillation, including the following modules:

[0122] Selective Vulnerability Evidence Graph Module: Used for constructing repository-level selective vulnerability evidence graphs;

[0123] Vulnerability type filtering module: used for filtering CWE candidate vulnerability types based on sensitive APIs;

[0124] Candidate evidence enhancement and distillation module: used to enhance candidate evidence in three directions: structure, knowledge, and semantics, and to perform multi-round evidence-preserving context distillation;

[0125] Results generation module: Used for vulnerability assessment and report generation based on a large language model with evidence closure.

[0126] The embodiments described above are merely one implementation method of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A repository-level vulnerability detection method based on evidence-aware context distillation, characterized in that, Includes the following steps: Step 1: Construct a repository-level selective vulnerability evidence graph; Step 2: Screening of CWE candidate vulnerability types based on sensitive APIs; Step 3: Enhance candidate evidence through three approaches: structure, knowledge, and semantics; Step 4: Multi-round evidence-preserving contextual distillation; Step 5: Vulnerability assessment and report generation based on the large language model of evidence closure.

2. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 1, characterized in that, The repository-level selective vulnerability evidence graph construction in step 1 specifically involves: Step 1-1: Analyze the code repository Static analysis is performed to extract code entities from the repository and construct a repository-level selective vulnerability evidence graph. : ； Among them, code repository In Represents a collection of source code files. This represents a set of third-party dependency declarations. Represents a collection of configuration files. This indicates the construction of a script collection. Represents a set of optional patch differences, commit differences, or version differences; repository-level selective vulnerability evidence graph. In Represents a set of nodes. Denotes the set of edges. Represents the node feature matrix, Represents the edge weight matrix. Represents the security evidence label corresponding to a node or edge; Steps 1-2: For repository-level selective vulnerability evidence diagrams any edge in Assign it a confidence weight This is used to describe the reliability of the program relationship corresponding to the edge; For any node Given vulnerability analysis anchor points and candidate vulnerability types Define the relevance of vulnerability evidence to a node: ； in Represents a node With vulnerability analysis anchor points In the evidence diagram, the closer the distance, the higher the correlation. Represents a node Is it located at an external input source? To the vulnerability anchor point On the reachable path; Indicates the node in the candidate vulnerability type The strength of the security evidence role undertaken by the subordinate; Indicates whether the node is located in the patch difference region; Indicates whether there are uncertain edges or uncertain regions in static analysis around the node; Indicates whether a node contains security checks, defense logic, or counter-evidence information; Configurable weights; If node If the relevance of the vulnerability evidence meets a preset threshold, it will be retained for the detection unit. The selective vulnerability evidence subgraph; otherwise, it is compressed into a summary node or filtered from the current detection context, thus obtaining: ； in, This represents the set of evidence nodes that have been preserved. Indicates vulnerability analysis anchor points and candidate vulnerability types Selective vulnerability evidence subgraph, This represents the node retention threshold.

3. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 2, characterized in that, The CWE candidate vulnerability type screening in step 2 is specifically as follows: Step 2-1: For any vulnerability analysis anchor point and candidate vulnerability types Calculate the matching score between the two: ； in, This represents the rule mapping score between the sensitive API and the CWE type; This indicates the semantic similarity between the anchor context and the CWE description, vulnerability example, and remediation example. This indicates whether there is a source-sink path in the current evidence graph that matches the CWE triggering pattern; This indicates the degree to which the repository's historical vulnerabilities, commit information, patch differences, and the CWE match. Indicates whether configuration items, permission declarations, dependency versions, or environment variables enhance the CWE hypothesis; These are the weighting coefficients; Step 2-2: Sort the candidate CWE types according to the matching score, and select several candidate vulnerability types with the highest scores that exceed a preset threshold to form a candidate set: ； in, Indicates anchor points for vulnerability analysis The corresponding set of candidate CWE types, This indicates selecting the top k candidate types with the highest scores. This indicates the threshold for retaining candidate types.

4. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 2, characterized in that, The structural-knowledge-semantic three-way candidate evidence enhancement in step 3 refers to the enhancement of each detection unit. Construct three types of complementary contexts, including: Step 3-1: Structural context generation, used to describe program structure information related to candidate vulnerabilities, including function call relationships, control flow relationships, data flow relationships, type constraints, configuration references, patch differences, and uncertain dependency areas, i.e., for the selective vulnerability evidence subgraph. Extract structural evidence related to the current vulnerability analysis anchor and candidate vulnerability types, and select structural information of different granularities based on context budget and vulnerability type; Step 3-2: Knowledge context generation, used to provide external security knowledge for candidate vulnerability types: Let the vulnerability knowledge base be... Each knowledge entry This includes the CWE number, vulnerability name, vulnerability description, dangerous API, triggering conditions, vulnerability example, remediation example, effective defense methods, and common error defense methods; Constructing a search query: ； in, This indicates the anchor point for vulnerability analysis. and candidate vulnerability types The structural context extracted from the selective vulnerability evidence subgraph includes at least one of function call relationships, control flow relationships, data flow relationships, type constraints, configuration references, patch differences, security checks, and uncertain dependency regions. This means that vulnerability analysis anchors, candidate vulnerability types, and corresponding structural contexts are encoded into knowledge retrieval queries. The similarity between the query and the knowledge item is calculated using a dense-sparse hybrid retrieval method. ； in, Represents dense semantic encoding, This represents the weighted encoding of sparse terms. The fusion coefficient is represented by the top-M knowledge items with the highest similarity, which are selected as the selective vulnerability evidence subgraph. Knowledge context: ； Step 3-3: Semantic context generation, used to denoise and summarize the functional behavior of candidate code snippets. First, a semantic summary is generated based on the original code and structural context: ； in, Indicates vulnerability analysis anchor point The original candidate code fragments extracted from the code repository are centered on the anchor point. The original candidate code fragments include the code statement corresponding to the anchor point, the function where the anchor point is located, and at least one of the following related to the anchor point: variable definition, parameter passing, condition judgment, and security check. This represents a semantic summarization operation that combines structural context to denoise and summarize the functional behavior of the original candidate code snippets; Indicates anchor points for vulnerability analysis and candidate vulnerability types The corresponding semantic context; Steps 3-4: Contextualize the three candidate evidence streams (structure, knowledge, and semantics) to form a candidate evidence context. ； Wherein, ⊕ represents splicing, alignment, summary fusion, or structured recombination operations.

5. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 2, characterized in that, The multi-round evidence-preserving context distillation in step 4 specifically includes: Step 4-1: Context of candidate evidence The evidence is divided into several blocks, and each block is assigned a role. An importance score is then calculated for each block. ； in, Indicates evidence block Character strength, Indicates evidence block Is it located on the source-sink path? express Degree of match with candidate CWE types express Is it located in the patch difference area? express Does it include defense checks? express Does it include security counter-evidence? express Whether it is close to the edge of an uncertain relationship or the uncertain region of static analysis; Step 4-2: Under the premise of satisfying the system token budget constraint, perform context distillation on the evidence block to maximize evidence importance and coverage while reducing context redundancy. The objective function is defined as follows: ； ； ； The constraints are: ； in, Indicates evidence block The original token length, Indicates the total token budget. Indicates a pre-defined evidence block The retention ratio, ; Indicates the coverage of evidence. Indicates context redundancy. Indicates the coverage reward weight. Indicates the redundancy penalty weight; This represents the set of key evidence role types. This indicates the weight of different evidentiary roles. Indicates an indicator function; This represents the semantic similarity, code similarity, or graph proximity similarity between two blocks of evidence. Indicates evidence block The corresponding set of evidence role tags; Solve the objective function to obtain the optimal retention ratio vector for each evidence block. And perform deletion, digest compression or full retention operations on each evidence block according to the optimal retention ratio to obtain a set of distilled evidence blocks that satisfy the total token budget constraint; Step 4-3: After multiple rounds of evidence-preserving context distillation, if the current context already covers the minimum set of evidence required for vulnerability determination, or if the remaining token budget is insufficient to continue preserving new valid evidence, then the distillation process is stopped, and the distilled candidate evidence context is obtained: ； The context of the distilled candidate evidence should satisfy the minimum indeterminate condition: ； in, This represents the evidence role coverage determination function, used to determine whether the distilled candidate evidence context contains sufficient information to support the evidence role. The evidence for determination; when the context of the distilled candidate evidence contains at least one element related to the role of the evidence. When there is a corresponding reserved evidence block, or when there is equivalent role evidence consisting of multiple reserved evidence blocks and their summaries, ,otherwise, ; This indicates that external input source evidence is covered. This indicates that evidence regarding sensitive remittance points has been covered. This indicates that evidence of the propagation path from the external input source to the sensitive sink has been covered. This means that sufficient evidence to determine the existence and effectiveness of security checks along the transmission path is covered; in particular, confirmation that no relevant security checks exist is also considered as security check status being covered. For certain vulnerability types, further requirements are also specified:

6. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 5, characterized in that, In each iteration of the multi-round evidence-preserving context distillation, the maximum marginal relevance score is calculated for candidate evidence blocks that have not yet been selected, and the evidence blocks to be selected in the current round are determined based on the maximum marginal relevance score, so as to achieve a balance between relevance, importance, evidence diversity and key evidence role coverage. No. Evidence Block in Wheel The maximum marginal correlation score is: ； And select the evidence block with the highest maximum marginal relevance score and satisfying the remaining token budget constraint from the set of candidate evidence blocks that have not yet been selected: ； Add the selected evidence block to the currently selected evidence block set, and update the covered evidence roles, remaining token budget and evidence memory status, and enter the next iteration until the minimum evidence judgment condition is met or the remaining token budget is insufficient; in, Indicates the first The set of candidate evidence blocks that have not yet been selected in the round. Indicates the first The set of evidence blocks already selected at the start of the round; This indicates a vulnerability analysis query constructed based on the current vulnerability analysis anchor and candidate vulnerability types; Indicates evidence block With vulnerability analysis and query The degree of relevance; Indicates evidence block Importance rating; Indicates evidence block With the selected evidence block Semantic similarity, code similarity, or graph proximity similarity between them; Indicates the selection of evidence blocks The latter is relative to the currently selected evidence.

7. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 5, characterized in that, The role labeling types of the evidence blocks include external input source, sensitive sink, propagation path, security check, type constraint, configuration evidence, patch difference, vulnerability knowledge, and security counter. To prevent critical evidence from being mistakenly deleted during compression, a mandatory retention constraint is set. Specifically, when the role label type of an evidence block is external input source, sensitive sink, propagation path, security check, type constraint, patch difference, or security counter, its retention ratio must not be lower than a preset threshold. .

8. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 5, characterized in that, In step 4, during the context distillation process, after each round of distillation, the evidence block selection strategy for the next round is adjusted to maintain the evidence memory state based on the retained evidence, the covered evidence roles, the remaining token budget, and the key evidence roles that have not yet been covered. ； in, Indicates the first Post-cycle evidence memory state Denotes the set of evidence blocks processed in round t. This represents the retention strategy in round t. This indicates the summary information for the current round. This indicates the content of the evidence retained in the current round; In the During the cycle, the state of memory is based on evidence. Increase the selection priority of candidate evidence blocks that can supplement key evidence roles that are not yet covered, decrease the selection priority of candidate evidence blocks that overlap with the accumulated retained evidence, and determine the retention ratio of candidate evidence blocks based on the remaining token budget.

9. The evidence-aware context distillation method for repository-level vulnerability detection according to claim 2, characterized in that, The vulnerability assessment and report generation in step 5 are specifically as follows: Distilled candidate evidence context Candidate vulnerability types Knowledge Context The evidence and role information are organized into structured prompts, which are then input into a large language model for vulnerability assessment. The large language model judgment function is: ； in, 1 indicates that candidate vulnerability type c is at the anchor point 0 indicates that the statement is true, and 0 indicates that it is false. The large language model outputs structured vulnerability analysis results, including vulnerability conclusions, external input sources, sensitive sinks, propagation paths, existing security checks, security counter-evidence, root causes of vulnerabilities, confidence levels, and remediation recommendations.

10. A repository-level vulnerability detection system based on evidence-aware context distillation, characterized in that, Includes the following modules: Selective Vulnerability Evidence Graph Module: Used for constructing repository-level selective vulnerability evidence graphs; Vulnerability type filtering module: used for filtering CWE candidate vulnerability types based on sensitive APIs; Candidate evidence enhancement and distillation module: used to enhance candidate evidence in three directions: structure, knowledge, and semantics, and to perform multi-round evidence-preserving context distillation; Results generation module: Used for vulnerability assessment and report generation based on a large language model with evidence closure.

Images