Vulnerability identification method and device, electronic equipment and storage medium

Abstract

The invention provides a vulnerability identification method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a vulnerability file, and carrying out the analysis of the vulnerability file through a layering strategy, and obtaining a target analysis result; evidence chain reconstruction is carried out based on the target analysis result, a target evidence chain and a marking result are obtained, and the marking result is used for indicating the integrity of the target evidence chain; generating an evidence graph based on the target evidence chain, and performing interpretable scoring based on the evidence graph and the marking result to obtain a scoring result; performing quality diagnosis based on the evidence graph and the scoring result to obtain a quality diagnosis result, and generating a traceability graph and a vulnerability analysis report based on the target analysis result, the evidence graph, the scoring result and the quality diagnosis result; wherein in the execution process of the steps, state management is carried out, and a state management log is generated. Therefore, the anti-illusion effect is realized, and the vulnerability detection efficiency and the vulnerability detection result accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to vulnerability identification methods, apparatus, electronic devices and storage media. Background Technology

[0002] Automated task execution and content generation systems built around LLM (Large Language Model) have been widely applied in the field of vulnerability detection. Related technologies employ multi-agent workflow architectures, using state machines and message queues to organize the step-by-step execution and context passing of the LLM; alternatively, they use RAG (Retrieval-Augmented Generation) technology to inject external knowledge fragments retrieved from vector databases into the LLM's generation context to reduce factual errors; or they use dynamic tool invocation protocols to give the LLM the ability to call external APIs (Application Programming Interfaces) such as search engines and code interpreters, thereby expanding its functional boundaries. Furthermore, the system also introduces quality assessment and illusion detection mechanisms in the output stage, such as performing consistency checks or fact-checking.

[0003] However, the process of generating vulnerability detection results in related technologies is disconnected from evidence collection. This prevents the technology from achieving end-to-end constraints through a closed loop, making the output results untraceable; it also makes it impossible to manage the workflow status, resulting in easy error propagation and difficulty in rollback; it relies on calling a single tool, leading to low analysis efficiency and single-point dependency risks; and quality assessment cannot locate problems and guide recovery. Therefore, this reduces the efficiency and accuracy of vulnerability detection results. Summary of the Invention

[0004] This application proposes a vulnerability identification method, apparatus, electronic device, and storage medium.

[0005] One embodiment of this application proposes a vulnerability identification method, which includes: acquiring a vulnerability file and analyzing the vulnerability file using a layered strategy to obtain a target analysis result; reconstructing an evidence chain based on the target analysis result to obtain a target evidence chain and a labeling result, wherein the labeling result is used to indicate the completeness of the target evidence chain; generating an evidence graph based on the target evidence chain and performing interpretable scoring based on the evidence graph and the labeling result to obtain a scoring result; performing quality diagnosis based on the evidence graph and the scoring result to obtain a quality diagnosis result, and generating a source tracing map and a vulnerability analysis report based on the target analysis result, the evidence graph, the scoring result, and the quality diagnosis result; wherein, state management is performed during the execution of the above steps, and a state management log is generated.

[0006] The vulnerability identification method in this application achieves anti-illusion effects through an end-to-end constrained process of layered strategy, evidence chain reconstruction, interpretable scoring, state management, and vulnerability analysis reporting. The layered strategy automatically and orderly switches to alternative tool solutions, reducing the time spent on a single analysis and minimizing overall failures due to single-point dependency failures. Structured verification and quantifiable diagnosis through evidence chain reconstruction and interpretable scoring enable precise location and closed-loop resolution of quality issues. State management throughout the process automatically verifies key constraints after each state transition, throwing exceptions and automatically rolling back upon violation, thereby achieving immediate error blocking and proactive defense to prevent contamination of subsequent states. Therefore, the vulnerability identification method proposed in this application achieves anti-illusion effects and improves vulnerability detection efficiency and accuracy.

[0007] Another embodiment of this application proposes a vulnerability identification device, comprising: an analysis module for acquiring a vulnerability file and analyzing the vulnerability file using a hierarchical strategy to obtain a target analysis result; an evidence chain reconstruction module for reconstructing an evidence chain based on the target analysis result to obtain a target evidence chain and a labeling result, wherein the labeling result is used to indicate the completeness of the target evidence chain; a scoring module for generating an evidence graph based on the target evidence chain and performing interpretable scoring based on the evidence graph and the labeling result to obtain a scoring result; a generation module for performing quality diagnosis based on the evidence graph and the scoring result to obtain a quality diagnosis result, and generating a source tracing map and a vulnerability analysis report based on the target analysis result, the evidence graph, the scoring result, and the quality diagnosis result; and a state management module for performing state management during the execution of the above modules and executing an exception handling and recovery strategy when an interruption occurs.

[0008] The vulnerability identification device in this application achieves an anti-illusion effect through a layered strategy, evidence chain reconstruction, interpretable scoring, state management, and an end-to-end constrained process for vulnerability analysis reports. The layered strategy automatically and orderly switches to alternative tool solutions, reducing the time spent on a single analysis and minimizing overall failures due to single-point dependency failures. Structured verification and quantifiable diagnosis through evidence chain reconstruction and interpretable scoring enable precise location and closed-loop resolution of quality issues. State management throughout the process automatically verifies key constraints after each state transition, throwing exceptions and automatically rolling back upon violation, thereby achieving immediate error blocking and proactive defense to prevent contamination of subsequent states. Therefore, the vulnerability identification device proposed in this application achieves an anti-illusion effect, improving vulnerability detection efficiency and the accuracy of vulnerability detection results.

[0009] Another embodiment of this application proposes an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the vulnerability identification method of the embodiments of this application.

[0010] Another embodiment of this application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vulnerability identification method disclosed in the embodiments of this application.

[0011] Another embodiment of this application proposes a computer program product that, when executed by an instruction processor in the computer program product, implements the vulnerability identification method in the embodiments of this application.

[0012] Other effects of the above-mentioned alternative methods will be described below in conjunction with specific embodiments. Attached Figure Description

[0013] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein:

[0014] Figure 1 This is a flowchart illustrating a vulnerability identification method according to an embodiment of this application; Figure 2 This is a flowchart illustrating a vulnerability identification method according to another embodiment of this application; Figure 3 This is a schematic diagram of the decision rules for a layered strategy according to another embodiment of this application; Figure 4 This is a flowchart illustrating a vulnerability identification method according to another embodiment of this application; Figure 5 This is a flowchart illustrating a vulnerability identification method according to another embodiment of this application; Figure 6 This is a flowchart illustrating a vulnerability identification method according to another embodiment of this application; Figure 7 This is a flowchart illustrating a vulnerability identification method according to another embodiment of this application; Figure 8 This is a schematic diagram of the structure of a vulnerability identification device according to an embodiment of this application; Figure 9 This is a block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0015] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0016] The vulnerability identification method, apparatus, electronic device, and storage medium of this application are described below with reference to the accompanying drawings.

[0017] Figure 1 This is a flowchart illustrating a vulnerability identification method according to an embodiment of this application. It should be noted that the execution entity of the vulnerability identification method provided in this embodiment is a vulnerability identification device, which can be implemented by software and / or hardware. In this embodiment, the vulnerability identification device can be an electronic device, or it can be configured in an electronic device to enable the electronic device to have an abnormal access detection function.

[0018] In this embodiment, the electronic device may include, but is not limited to, terminal devices and servers, etc. This embodiment does not specifically limit the electronic device.

[0019] like Figure 1 As shown, the vulnerability identification method may include: Step 101: Obtain the vulnerability file and analyze it using a layered strategy to obtain the target analysis results.

[0020] This includes obtaining vulnerability files uploaded by users through the front-end page.

[0021] In some embodiments, after obtaining the vulnerability file, the vulnerability file can be analyzed using a layered strategy to obtain the target analysis results.

[0022] In some embodiments, analyzing vulnerability files using general tools (search / RAG) cannot provide precise code-level evidence. For example, it can only obtain a vague description such as "WebView has an XSS risk," and cannot extract the precise call to "MainActivity.onNewIntent() → loadUrl()". Furthermore, LLMs may infer vulnerabilities based on attack patterns in training data, increasing the false positive rate. Therefore, a layered strategy is needed to automatically and systematically switch to corresponding alternative tool solutions to provide precise code-level evidence.

[0023] In some embodiments, the above-described layering strategy may include a five-layer tool layering strategy. Specifically, the L0 layer is the built-in tool layer, which can perform JSON parsing, text processing, and mathematical calculations; the other layers can be used directly without selection. The L1 layer is the local retrieval tool layer, which can perform RAG vector search. The L2 layer is the dedicated tool layer, which can perform static analysis of APKs (Android Package Kits), including but not limited to inheritance chain extraction, manifest parsing, call graph generation, and taint analysis. The L3 layer is the general search tool layer, which can perform web search. The L4 layer is the external tool layer, which can dynamically load external tools through the MCP (Model Context Protocol).

[0024] In some embodiments, the execution rules of the above-mentioned layered strategy are as follows: if the vulnerability type identifier of the vulnerability file belongs to the preset APK vulnerability type set, then enter the APK analysis branch and inject the dedicated tool in the L2 layer to obtain the target analysis result; otherwise, enter the general analysis branch. If there are local knowledge resources, then inject the local retrieval tool in the L1 layer and generate analysis prompt words containing priority call instructions to obtain the target analysis result; if there are no local knowledge resources, then obtain the target analysis result through the general search tool in the L3 layer and the external tool in the L4 layer.

[0025] In some real-time examples, the above target analysis results can be structured data results. Specifically, the target analysis results can be structured data including triples of {entry, parsing, sink}.

[0026] In some embodiments, the hierarchical strategy described above can automatically and systematically switch to alternative tool solutions, reducing the time required for a single analysis and minimizing overall failures caused by single-point dependency failures.

[0027] Step 102: Reconstruct the evidence chain based on the target analysis results to obtain the target evidence chain and labeling results.

[0028] In some embodiments, after obtaining the target analysis results through the above steps, the evidence chain can be reconstructed based on the target analysis results to obtain the target evidence chain and the labeling results, thereby performing structured verification.

[0029] In some embodiments, the aforementioned evidence chain reconstruction can be a five-layer progressive reconstruction pattern. This five-layer progressive reconstruction pattern includes L1 direct chain, L2 ring reconstruction, L3 flow parsing, L4 Ring pattern verification, and L5 intelligent inference. Based on this, the evidence chain of the target analysis results can be reconstructed through L1 direct chain, L2 ring reconstruction, L3 flow parsing, L4 Ring pattern verification, and L5 intelligent inference to obtain the target evidence chain and the labeled results.

[0030] In some embodiments, the target evidence chain obtained through the above steps can be intent processing -> URI resolution -> view loading.

[0031] In some embodiments, the target evidence chain described above may also include specific execution steps for each step.

[0032] In some embodiments, the above-described marking results can be used to indicate the completeness of the target chain of evidence. In some embodiments, the marking result can be a complete chain of evidence or a reconstructed chain of evidence. Furthermore, in some embodiments, when the marking result is a reconstructed chain of evidence, it indicates that evidence may be missing.

[0033] Step 103: Generate an evidence graph based on the target evidence chain, and perform interpretable scoring based on the evidence graph and the labeling results to obtain the scoring results.

[0034] In some embodiments, the role (executing entity), content (specific action and result), tool_calls (tools used), and evidence_ids (associated evidence node IDs) of each step of the execution are obtained from the target evidence chain.

[0035] In some embodiments, the EvidenceNode in the evidence graph is defined to include the fields derived_from and supports. Both derived_from and supports are designed as a list of evidence node IDs to associate node relationships.

[0036] In some embodiments, if the current evidence node is derived from one or more upstream evidence nodes, the upstream evidence node ID is filled into the derived_from field of the current evidence node; if the current evidence node can support the downstream conclusion, the downstream evidence node ID is filled into the supports field of the current evidence node.

[0037] In some embodiments, an evidence graph is constructed using the derived_from and supports fields, wherein the evidence graph is a directed acyclic graph, thereby realizing the traceability link of evidence.

[0038] In some embodiments, after obtaining the evidence map through the above steps, interpretable scoring can be performed based on the evidence map and the labeling results to obtain the scoring results, so that the scoring is traceable, reviewable and improveable.

[0039] In some embodiments, an interpretable score can be obtained by using a five-dimensional interpretable scoring model based on the evidence graph and the labeling results. In some embodiments, the five-dimensional interpretable scoring model may include an evidence integrity score, a pattern conformity score, a source reliability score, a protection mechanism score, and a logical consistency score, and the score result is determined based on a preset base score, a first evidence integrity score / second evidence integrity score, a pattern conformity score, a source reliability score, and a protection mechanism score.

[0040] In some embodiments, the method for determining the scoring result based on a preset base score, a first evidence integrity score / second evidence integrity score, a pattern conformity score, a source reliability score, and a protection mechanism score may include: summing the preset base score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, and the protection mechanism score to obtain an initial score, and determining the result of truncating the initial score within a preset interval as the final scoring result. In some embodiments, the preset interval may be (0, 1).

[0041] In some embodiments, each of the above scores has corresponding specific evidence or test results, and the low scores can be used to directly pinpoint areas for improvement, and different weight configurations for A / B testing are supported.

[0042] For example, in some embodiments, the scoring result is:

[0043] Step 104: Based on the evidence map and scoring results, perform quality diagnosis to obtain quality diagnosis results, and based on the target analysis results, evidence map, scoring results and quality diagnosis results, generate a source tracing map and a vulnerability analysis report.

[0044] In some embodiments, after obtaining the evidence map and scoring results through the above steps, quality diagnosis can be performed based on the evidence map and scoring results to obtain quality diagnosis results, thereby determining the accuracy of the evidence map.

[0045] In some embodiments, the evidence graph and scoring results can be detected based on preset multi-dimensional quality indicators to obtain detection results. If the detection results include quality problem types, at least one executable target recovery strategy is generated and executed. The evidence graph and scoring results are updated based on the execution results, and a quality diagnosis result is determined. Otherwise, a quality diagnosis result is determined based on the detection results. In some embodiments, if the detection results include quality problem types, the quality diagnosis result may include the quality problem types and the specific process of the recovery strategy executed on the quality problem types. If the detection results do not include quality problem types, the quality diagnosis result may be no quality problem.

[0046] In some embodiments, a source map can be generated based on the evidence map, where the source map can be a Mermaid graph. Furthermore, in some embodiments, each node in the source map also needs to be labeled with its corresponding source type, such as fact (objective fact) / inference (reasoning conclusion) / tool_output (original output) type and its corresponding confidence level. In some embodiments, the confidence level is a quantitative score of the credibility of the content of the evidence node, with a value range of (0, 1), and a higher confidence level indicates greater credibility. The sources of confidence levels corresponding to different source types may be different. Specifically, in some embodiments, the confidence level of the tool_output type can inherit the inherent credibility of the calling tool; the confidence level of the fact type can inherit the inherent credibility of the calling tool; and the confidence level of the inference type can be calculated based on a weighted average of the confidence levels of upstream evidence.

[0047] In some embodiments, a vulnerability analysis report can be generated based on the target analysis results, evidence graphs, scoring results, and quality diagnostic results. In some embodiments, a vulnerability analysis report template can be automatically obtained, and the target analysis results, evidence graphs, scoring results, and quality diagnostic results can be embedded into the report template to obtain the vulnerability analysis report.

[0048] In some embodiments, state management is also performed during the execution of steps 101 to 104 above, and a state management log is generated to automatically verify key constraints after each state transition, and throw exceptions and automatically roll back when violations are made, thereby realizing immediate blocking and proactive defense of errors and preventing pollution of subsequent states.

[0049] In some embodiments, the method for performing state management and generating state management logs may include: in response to triggering a state transition, creating a checkpoint for the current state before executing the state transition logic; after executing the state transition logic, verifying the transitioned state according to a preset set of state invariant rules; if the verification passes, generating the corresponding state management log; otherwise, rolling back the state to the checkpoint and generating state error information.

[0050] It should be noted that, in some embodiments, when generating a vulnerability analysis report, it is also necessary to obtain the state management logs throughout the entire analysis process, so as to embed the state management logs into the vulnerability analysis report template and generate the vulnerability analysis report, thereby clarifying the state transition process.

[0051] The vulnerability identification method in this application achieves anti-illusion effects through an end-to-end constrained process of layered strategy, evidence chain reconstruction, interpretable scoring, state management, and vulnerability analysis reporting. The layered strategy automatically and orderly switches to alternative tool solutions, reducing the time spent on a single analysis and minimizing overall failures due to single-point dependency failures. Structured verification and quantifiable diagnosis through evidence chain reconstruction and interpretable scoring enable precise location and closed-loop resolution of quality issues. State management throughout the process automatically verifies key constraints after each state transition, throwing exceptions and automatically rolling back upon violation, thereby achieving immediate error blocking and proactive defense to prevent contamination of subsequent states. Therefore, this application achieves anti-illusion effects, improving vulnerability detection efficiency and the accuracy of vulnerability detection results.

[0052] This embodiment is a detailed explanation of step 101 in the aforementioned embodiments, such as... Figure 2 As shown, it may also include: Step 201: Obtain the vulnerability file and the vulnerability type identifier in the vulnerability file.

[0053] In some embodiments, the content of the field corresponding to apk_vuln_json.vuln_type in the vulnerability file can be extracted and the content of this field can be determined as the vulnerability type identifier.

[0054] Step 202: If the vulnerability type identifier belongs to the preset APK vulnerability type set, then proceed to the APK analysis branch; otherwise, proceed to the general analysis branch.

[0055] In some embodiments, the aforementioned set of preset APK vulnerability types may include {IntentBridge, DeepLink}.

[0056] In some embodiments, if the vulnerability type identifier belongs to a preset APK vulnerability type set, it indicates that it is an APK vulnerability and the APK analysis branch can be entered; otherwise, it indicates that it may not be an APK vulnerability and the general analysis branch can be entered.

[0057] Step 203: If it is determined that the APK analysis branch has been entered, and if it is determined that the dedicated tool is available, the vulnerability file is analyzed based on the dedicated tool to obtain the target analysis results.

[0058] In some embodiments, after entering the APK analysis branch, it can be determined whether the L2 layer dedicated tool is available. If it is determined that the dedicated tool is available, the vulnerability file can be analyzed based on the dedicated tool to obtain the target analysis results.

[0059] In some embodiments, the aforementioned specialized tool can be an APK static analyzer. Furthermore, in some embodiments, the target analysis results obtained by analyzing vulnerable files using an APK static analyzer may include structured data of {entry, parsing, sink} triples, as well as the accessibility of components in the external manifest (Android manifest file) and the tainted path of data from dangerous inputs to dangerous outputs, thereby addressing the problem of inaccurate data from general tools and reducing the false positive rate.

[0060] In some embodiments, the aforementioned specialized tools can also perform code analysis, such as AST parsing, symbolic execution, and dependency analysis; and financial analysis, such as financial statement parsing and indicator calculation.

[0061] In some embodiments, if it is determined that the dedicated tool is unavailable, step 204 is executed to enter the general analysis branch. In some embodiments, a problem log, such as "APK dedicated tool unavailable, resulting in reduced reliability," may also be generated at this time.

[0062] Step 204: If it is determined that the general analysis branch is entered, then determine whether there are any related local knowledge resources.

[0063] In some embodiments, if it is determined that a general analysis branch is entered, it is then determined whether an associated local knowledge resource exists. In some embodiments, the existence of an associated local knowledge resource can be determined based on a vulnerability type identifier. In some embodiments, the aforementioned local knowledge resource can be local knowledge data.

[0064] Step 205: If local knowledge resources exist, generate analysis hint words containing priority call instructions, and analyze the vulnerability file using a local search tool based on the analysis hint words to obtain the target analysis results.

[0065] In some embodiments, if local knowledge resources exist, analysis prompts containing priority invocation instructions are generated, and the vulnerability file is analyzed using a local search tool based on the analysis prompts to obtain the target analysis results. In some implementations, the analysis prompts may include "call local_search_tool first" to force the use of the L1 layer local search tool.

[0066] In some embodiments, before invoking the local search tool, it can be determined whether the local search tool is available. If the local search tool is available, the vulnerability file can be analyzed based on the local search tool to obtain the target analysis results. If the local search tool is unavailable, an L3 search tool can be injected.

[0067] In some embodiments, the above method may further include: if no local knowledge resource exists, an L3 search tool may be injected. In some embodiments, the method for injecting an L3 search tool may include the following steps: Step 206: Determine whether to configure the MCP (Model Context Protocol) server.

[0068] Step 207: If the MCP server is configured, load the external tools filtered by the whitelist from the MCP server, and analyze the vulnerability files based on the external tools to obtain the target analysis results.

[0069] In some embodiments, the aforementioned external tools can be L4 layer external tools. In some embodiments, the aforementioned L4 layer external tools need to be explicitly declared in the enabled_tools configuration.

[0070] Step 208: If it is determined that the MCP server is not configured, the tools already injected in the toolchain to be executed are deduplicated to obtain the target tool list, and the decision log of the target tool list construction process is recorded.

[0071] Step 209: Analyze the vulnerable files based on the target tool list to obtain the target analysis results.

[0072] In some embodiments, the method for detecting whether a corresponding tool is available may include determining whether the tool is available through tool response time, error rate, and availability probes. In some embodiments, availability probes may be performed using lightweight ping or empty queries; if no response is received after a first preset timeout, the tool is determined to be unavailable. In some embodiments, the first preset timeout may be set as needed, such as 2 seconds.

[0073] In some embodiments, the obtained detection results can be cached for a second preset time to avoid frequent detection. In some embodiments, the second preset time can be set as needed, such as 5 minutes.

[0074] In some embodiments, if all tools in the tiered strategy are unavailable, a ToolChainFailure exception is output.

[0075] Figure 3 This is a schematic diagram of the decision rules for a hierarchical strategy proposed in this embodiment. Figure 3As shown, determine the scenario type (i.e., step 201 above); if it belongs to APK vulnerability analysis, enter APK mode (i.e., enter the APK analysis branch above), inject an L2 layer dedicated tool (such as an APK static analyzer), and perform a health check on the L2 layer dedicated tool. If the check determines that the L2 layer dedicated tool is available, then perform analysis through the L2 layer dedicated tool; if the check determines that the L2 layer dedicated tool is unavailable, then downgrade to the L3 layer general search tool (i.e., execute step 204 above); if it does not belong to APK vulnerability analysis, enter general mode (i.e., enter the general analysis branch above), determine whether there are local resources (i.e., step 204 above), if local resources are found to exist, inject an L1 layer local retrieval tool, if the L1 layer local retrieval tool is found to exist, then perform analysis through the L1 layer local retrieval tool. If the search tool is available, a forced priority use prompt is generated (i.e., the analysis prompt words in the above steps), and analysis is performed through the L1 layer local search tool (i.e., step 205 above). If the L1 layer local search tool is unavailable or there is no local resource, the L3 layer web search tool is injected, and it is determined whether the MCP server is configured (i.e., step 206 above). If the MCP server is configured, the L4 layer external tools filtered through the whitelist are loaded (i.e., step 207 above). If the MCP server is not configured, the tools injected in the toolchain to be executed are deduplicated to obtain the target tool list, and the decision log of the target tool list construction process is recorded (i.e., step 208 above), and analysis is performed through the target tool list.

[0076] The vulnerability identification method provided in this application obtains a vulnerability type identifier from a vulnerability file. If the vulnerability type identifier belongs to a preset APK vulnerability type set, the method enters the APK analysis branch; otherwise, it enters the general analysis branch. If the method enters the APK analysis branch, and if a dedicated tool is available, the vulnerability file is analyzed using that tool to obtain the target analysis result. If the method enters the general analysis branch, it determines whether there are any associated local knowledge resources. If local knowledge resources exist, it generates analysis prompts containing priority call instructions and analyzes the vulnerability file using a local retrieval tool based on these prompts to obtain the target analysis result. Thus, by automatically and orderly switching to alternative tool solutions through a layered strategy, the time consumed in a single analysis is reduced, and overall failures due to single-point dependency failures are minimized.

[0077] This embodiment is a detailed explanation of step 102 in the aforementioned embodiments, such as... Figure 4 As shown, it may also include: Step 401: Extract explicit function call or event sequences from the target analysis results according to the time series to generate a linear call chain.

[0078] In some embodiments, explicit function call or event sequences can be extracted in time series to generate a linear call chain. In some embodiments, function types or event types relevant to the vulnerability, such as function_call, can be retained while other irrelevant functions, such as lifecycle functions, are filtered out, thus eliminating the need to analyze irrelevant functions. For example, the generated linear call chain is Activity.onNewIntent() → Uri.getQueryParameter() → WebView.loadUrl().

[0079] In some embodiments, step 401 above can be executed via an L1 layer direct chain.

[0080] Step 402: Based on preset domain knowledge, divide the linear call chain into multiple semantic rings.

[0081] In some embodiments, multiple semantic rings may include Ring 0: Application Entry, Ring 1: Intent Handling, Ring 2: URI Parsing, and Ring 3: Dangerous Sink.

[0082] In some embodiments, Ring1 may include getIntent / onNewIntent; Ring2 may include parseUri / getQueryParameter; and Ring3 may include loadUrl / startActivity.

[0083] In some embodiments, step 402 above can be performed via L2 layer ring reconstruction.

[0084] Step 403: Determine the propagation path of the data in the semantic ring, remove technical noise in the propagation path, and obtain the target evidence chain.

[0085] In some embodiments, the propagation path of data from the entry in Ring0 to the sink in Ring3 can be traced, and technical noise in the registers / offsets in the propagation path can be removed to obtain the target evidence chain, thereby simplifying the data flow graph.

[0086] For example, the target evidence chain is intent_data → uri_param → webview_load (intermediate variables such as v1 / v2 / v3 have been removed).

[0087] In some embodiments, step 403 above can be executed via L3 layer flow parsing.

[0088] Step 404: Determine if the target evidence chain matches the target pattern in the predefined pattern registry, and determine the compliance score based on the target pattern.

[0089] In some embodiments, after obtaining the target evidence chain through the above steps, it can be determined that the target evidence chain matches the target pattern in the predefined pattern registry, and a compliance score can be determined based on the matched target pattern.

[0090] In some embodiments, the above-mentioned predefined mode registry may include the following vulnerability types: DeepLink includes Ring1 corresponding to getIntent / onNewIntent, Ring2 corresponding to getQueryParameter / parseUri, and Ring3 corresponding to loadUrl / startActivity; and IntentBridge includes Ring1 corresponding to onReceive, Ring2 corresponding to getExtras / getStringExtra, and Ring3 corresponding to sendBroadcast.

[0091] In some embodiments, the compliance score can be obtained by dividing the number of rings hit by the total number of rings, where the total number of rings is 3. For example, assuming that Ring1, Ring2, and Ring3 are all hit, the compliance score = 3 / 3 = 1.0; assuming that Ring1 and Ring2 are hit, the compliance score = 2 / 3 = 0.66.

[0092] In some embodiments, step 404 can define the corresponding API for the Ring mode based on the vulnerability type, as a hard quality constraint.

[0093] In some embodiments, step 403 above can be performed through L4 layer Ring mode verification.

[0094] Step 405: Based on the conformity score, determine the labeling result of the target evidence chain.

[0095] In some embodiments, after obtaining the conformity score through the above steps, the labeling result corresponding to the target evidence chain can be determined based on the conformity score.

[0096] In some embodiments, if the compliance score is greater than or equal to 0.7, the target evidence chain is marked as a complete evidence chain; if the compliance score is less than 0.7, a conservative inference is made, and the target evidence chain is marked as an incomplete evidence chain.

[0097] In some embodiments, the process of making conservative inferences described above involves supplementing the logic without fabricating facts. Specifically, in some embodiments, reasonable gaps in the chain of evidence can be filled based on domain knowledge, but the inferred parts need to be clearly marked to avoid false evidence.

[0098] For example, assuming the compliance score (hitting Ring 1 + Ring 2, missing Ring 3) is 0.67 < 0.7, the existing target evidence chain in L3 is onNewIntent → getQueryParameter. It lacks the hit API for Ring 3 (loadUrl / startActivity), and the domain knowledge indicates that the complete chain of the DeepLink vulnerability is entry point → parsing → dangerous call. The URI parameter parsed by getQueryParameter will flow to WebView.loadUrl 90% of the time. Based on this, the existing target evidence chain onNewIntent → getQueryParameter is retained; based on the common flow of URI parameters, loadUrl is added; the reconstructed target evidence chain is: onNewIntent → getQueryParameter → loadUrl.

[0099] In some embodiments, the process of reconstructing the chain of evidence described above may include: Target analysis results ↓ [L1: Direct Chain Extraction] Extracting function call sequences ↓ Entry: onNewIntent() Parsing: getQueryParameter() Sink: loadUrl() ↓ [L2: Ring Reconstruction] Segmented by domain knowledge ↓ Ring1: [onNewIntent, getIntent] Ring2: [getQueryParameter, parseUri] Ring3: [loadUrl, startActivity] ↓ [L3: Stream parsing] Tracking the data propagation path ↓ intent_data → uri_param → webview_url (technical details removed) ↓ [L4: Ring Mode Verification] Loading mode registry ↓ Checking if Ring1 mode hits onNewIntent Checking Ring2 mode hit getQueryParameter Checking Ring3 mode hit loadUrl ↓ The compliance score is calculated as follows: 3 / 3 = 1.0 ↓ [L5: Intelligent Inference] Accuracy score >= 0.7? ↓ ├─→ [Yes] → Mark "Complete Chain of Evidence" No need to infer └─→ [No] → Use domain knowledge to make inferences, and mark "Reconstruct the chain of evidence" ↓ Target evidence chain output The vulnerability identification method provided in this application extracts explicit function calls or event sequences from the target analysis results according to the time sequence, generating a linear call chain; based on preset domain knowledge, the linear call chain is divided into multiple semantic rings; the propagation path of data in the semantic rings is determined, and technical noise in the propagation path is removed to obtain the target evidence chain; it is determined that the target evidence chain matches the target pattern in the predefined pattern registry, and a compliance score is determined based on the target pattern; based on the compliance score, the labeling result of the target evidence chain is determined. This application enables structured verification and quantifiable diagnosis through evidence chain reconstruction, achieving precise location and closed-loop resolution of quality problems.

[0100] This embodiment is a detailed explanation of step 103 in the aforementioned embodiments, such as... Figure 5 As shown, it may also include: Step 501: Obtain the preset basic score and determine whether there is missing evidence based on the evidence diagram. If it is determined that there is missing evidence, determine the first evidence integrity score; otherwise, determine the second evidence integrity score based on the marking results.

[0101] In some embodiments, the preset base score can be set as needed, such as 0.2.

[0102] In some embodiments, it can be determined whether there is missing evidence based on the evidence graph. If it is determined that there is missing evidence, the first evidence integrity score is determined to be -0.10; if it is determined that there is no missing evidence, the second evidence integrity score is +0.30 if the marking result is a complete evidence chain; and the second evidence integrity score is +0.15 if the marking result is a reconstructed evidence chain.

[0103] In some embodiments, if the required APIs within a Ring are missing in the above evidence diagram, such as Ring2 lacking parseUri / getQueryParameter, then it is determined that evidence is missing.

[0104] Step 502: Determine the matching result between the evidence diagram and the preset vulnerability pattern, and determine the pattern conformity score based on the matching result and the first preset weight.

[0105] In some embodiments, the aforementioned preset vulnerability mode can be the API mode corresponding to different Rings.

[0106] In some embodiments, a conformity score can be determined based on the matching results, and the result of multiplying the conformity score by a first preset weight can be determined as the pattern conformity score.

[0107] In some embodiments, the first preset weight can be set as needed, such as 0.25.

[0108] For example, assuming the conformity score is 1.0, then the pattern conformity score = 1.0 × 0.25 = 0.25.

[0109] Step 503: Determine the average reliability score based on the tool source type and corresponding preset reliability score in the evidence diagram, and determine the source reliability score based on the average reliability score and the second preset weight.

[0110] In some embodiments, different preset reliability scores correspond to different tool source types. In some embodiments, the preset reliability score corresponding to a tool source type can be determined using a source score table.

[0111] In some embodiments, the source score table may include tool type and reliability score. Table 1 is a source score table proposed in this embodiment.

[0112] Table 1

[0113] In some embodiments, if the evidence graph includes multiple tool source types, the average of each tool source type and its corresponding reliability score can be determined as the average reliability score.

[0114] In some embodiments, the second preset weight can be set as needed, such as 0.20.

[0115] In some embodiments, after obtaining the second preset weight and the average reliability score through the above steps, the product of the second preset weight and the average reliability score can be determined as the source reliability score.

[0116] Step 504: If a security protection mechanism is detected in the evidence graph, then determine the protection mechanism score.

[0117] In some embodiments, the existence of a security protection mechanism can be determined based on the evidence graph. If a security protection mechanism is detected in the evidence graph, a protection mechanism score is determined.

[0118] In some embodiments, if a whitelist / Intent filtering / input validation is detected in the evidence graph, it is determined that a security protection mechanism has been detected in the evidence graph, and the protection mechanism score is determined to be -0.15 to reduce the risk score; if no security protection mechanism is detected in the evidence graph, the protection mechanism score is 0, and in this case, no protection mechanism score needs to be set.

[0119] Step 505: Check the logical contradictions in the evidence diagram to obtain a consistency score, and determine the logical consistency score based on the consistency score and the third preset weight.

[0120] In some embodiments, all EvidenceNodes in the evidence graph can be traversed to check whether there are logical conflicts between different pieces of evidence, and a consistency score can be obtained based on the obtained logical conflict results.

[0121] In some embodiments, a consistency score can be determined using a consistency score table to identify the consistency scores corresponding to different logical conflict results. Table 2 shows a consistency score table proposed in this embodiment.

[0122] Table 2

[0123] In some embodiments, the aforementioned filtering can refer to the Intent data being filtered using a URI whitelist, and the aforementioned direct transmission can refer to the URI parameters being passed directly to loadUrl without filtering. Furthermore, if the aforementioned conflict occurs in the evidence graph, it will weaken the credibility of the target evidence chain.

[0124] In some embodiments, after obtaining the consistency score through the above steps, the product of the consistency score and the third preset weight can be determined as the logical consistency score.

[0125] In some embodiments, the third preset weight can be set as needed, such as 0.15.

[0126] Step 506: Determine the scoring result based on the preset basic score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score.

[0127] In some embodiments, after obtaining the preset basic score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score through the above steps, the scoring result can be determined based on the preset basic score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score.

[0128] In some embodiments, the method for determining the scoring result based on a preset base score, a first evidence integrity score / second evidence integrity score, a pattern conformity score, a source reliability score, a protection mechanism score, and a logical consistency score may include: summing the preset base score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score to obtain an initial score, and determining the result after truncating the initial score into a preset interval as the final scoring result. In some embodiments, the preset interval may be (0, 1).

[0129] The vulnerability identification method provided in this application obtains a preset basic score and determines whether there is missing evidence based on the evidence graph. If missing evidence is determined, a first evidence integrity score is determined; otherwise, a second evidence integrity score is determined based on the marking results. The method determines the matching result between the evidence graph and a preset vulnerability pattern, and determines the pattern conformity score based on the matching result and a first preset weight. It determines an average reliability score based on the tool source type in the evidence graph and its corresponding preset reliability score, and determines a source reliability score based on the average reliability score and a second preset weight. If a security protection mechanism is detected in the evidence graph, a protection mechanism score is determined. Logical contradictions in the evidence graph are checked to obtain a consistency score, and a logical consistency score is determined based on the consistency score and a third preset weight. The final score is determined based on the preset basic score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score. This application enables structured verification and quantifiable diagnosis through interpretable scoring, achieving precise location and closed-loop resolution of quality problems.

[0130] This embodiment is a detailed explanation of step 104 in the aforementioned embodiments, such as... Figure 6 As shown, it may also include: Step 601: Detect the evidence map and scoring results based on preset multi-dimensional quality indicators to obtain the detection results.

[0131] In some embodiments, evidence maps and scoring results can be detected based on preset multi-dimensional quality indicators to ensure their accuracy.

[0132] In some embodiments, the method for detecting evidence maps and scoring results based on preset multi-dimensional quality indicators to obtain detection results includes the following steps: Step 6011: If the structural ring in the evidence diagram is missing a preset API, the quality problem type included in the detection result is pattern violation.

[0133] In some embodiments, it is determined whether a preset API is missing in each structural ring based on the evidence graph. If the preset API is missing in a structural ring in the evidence graph, the quality problem type included in the detection result is pattern violation; otherwise, the quality problem type of pattern violation is not included in the detection result.

[0134] In some embodiments, the default APIs for Ring 1 in the DeepLink vulnerability type include getIntent / onNewIntent, the default APIs for Ring 2 include getQueryParameter / parseUri, and the default APIs for Ring 3 include loadUrl / startActivity; the default APIs for Ring 1 in the IntentBridge vulnerability type include onReceive, the default APIs for Ring 2 include getExtras / getStringExtra, and the default APIs for Ring 3 include sendBroadcast.

[0135] In some embodiments, if a Ring 1 / 3 lacks a preset API, the severity level of the corresponding problem is severe; if a Ring 2 lacks a preset API, the severity level of the corresponding problem is moderately severe.

[0136] Step 6012: If the source reliability score in the scoring result is less than or equal to the first threshold, then the quality problem type included in the detection result is weak source.

[0137] In some embodiments, if the source reliability score in the scoring result is less than or equal to a first threshold, then the quality problem type that may be included in the corresponding detection result is a weak source.

[0138] In some embodiments, the first threshold can be set as needed, such as 0.1.

[0139] In some embodiments, the severity level of the problem corresponding to the weak source described above can be relatively severe.

[0140] Step 6013: If the logical consistency score in the scoring results is less than the second threshold, then the quality problem type included in the retrieval test results is logical gap.

[0141] In some embodiments, if the logical consistency score in the scoring results is less than the second threshold, then the quality problem type that may be included in the corresponding retrieval test results is a logical gap.

[0142] In some embodiments, the second threshold can be set as needed, such as 0.05.

[0143] In some embodiments, the severity level of the problem corresponding to the above-mentioned logical gap can be relatively severe.

[0144] Step 6014: If the scoring results include a first evidence completeness score, then the quality problem type included in the search results is evidence missing.

[0145] In some embodiments, if the scoring results include a first evidence completeness score, then the quality problem type included in the retrieval test results is evidence missing.

[0146] In some embodiments, the severity level of the problem corresponding to the aforementioned lack of evidence can be relatively severe.

[0147] Step 602: If the detection results include quality problem types, generate at least one executable target recovery strategy, execute the target recovery strategy, update the evidence map and scoring results based on the obtained execution results, and determine the quality diagnosis results.

[0148] In some embodiments, after obtaining the detection results through the above steps, if the detection results include a quality problem type, at least one executable target recovery strategy is generated and executed.

[0149] In some embodiments, if the detection results include a quality problem type, the method for generating at least one executable target recovery strategy may include the following steps: Step 6021: If the quality problem type included in the detection result is pattern violation or missing evidence, then generate a retry strategy for calling alternative analysis tools.

[0150] In some embodiments, the execution of different tool strategies can be carried out by automatically downgrading to a backup tool (such as L2→L3).

[0151] For example, the retry strategy for different tools is "re-extract Ring2 evidence using an alternative static analysis tool".

[0152] Step 6022: If the quality problem type included in the detection result is a weak source or a logical gap, then pause the process and generate a request for manual input strategy.

[0153] In some embodiments, the strategy of requesting manual input can be implemented by generating a manual review request and pausing the process.

[0154] For example, the manual input request policy is "Please have a security expert review the accuracy of the target evidence chain".

[0155] Step 6023: If the quality problem type included in the detection result is evidence missing and partial evidence missing, then a conservative inference strategy based on existing evidence and domain knowledge is generated for supplementary reasoning.

[0156] In some embodiments, if the quality problem type included in the test results is missing evidence, it is determined whether the evidence graph is partially missing, that is, the evidence is insufficient but there are some clues.

[0157] In some embodiments, the conservative inference strategy can be implemented by filling gaps based on domain knowledge and marking the supplemented evidence chain as a reconstructed evidence chain.

[0158] Step 6024: If the quality problem type included in the test results is evidence missing and is non-critical evidence missing, generate a skip step strategy that marks the corresponding step as failed and continues the subsequent process.

[0159] In some embodiments, if the quality problem type included in the detection result is missing evidence, it is determined whether the missing evidence is a non-critical step failure that cannot be recovered. If the missing evidence is a non-critical step failure that cannot be recovered, a skip step strategy is generated to mark the corresponding step as failed and continue the subsequent process.

[0160] For example, the skipping step strategy is "Step 4 (International Case Analysis) failed, has been skipped, does not affect the main conclusions".

[0161] In some embodiments, after executing the corresponding recovery strategy through the above steps, the evidence graph and scoring results can be updated based on the obtained execution results, and a quality diagnosis result can be determined. In some embodiments, the quality diagnosis result may include the above detection results, the recovery strategy executed corresponding to the detection results, and the result after executing the recovery strategy.

[0162] Step 603: If the test results do not include the quality problem type, then determine the quality diagnosis result based on the test results.

[0163] In some embodiments, if the test results do not include a quality problem type, the quality diagnosis result determined based on the test results may be no quality problem.

[0164] The vulnerability identification method provided in this application detects evidence graphs and scoring results based on preset multi-dimensional quality indicators to obtain detection results. If the detection results include quality problem types, at least one executable target recovery strategy is generated and executed. The evidence graph and scoring results are updated based on the execution results, and a quality diagnosis result is determined. Otherwise, the quality diagnosis result is determined based on the detection results. This application enables structured verification and quantifiable diagnosis through quality diagnosis, achieving precise location and closed-loop resolution of quality problems.

[0165] This embodiment is a detailed explanation of the state management method in the foregoing embodiments, such as... Figure 7 As shown, it may also include: Step 701: In response to the triggered state transition, a checkpoint for the current state is created before executing the state transition logic.

[0166] In some embodiments, if the current execution node changes during the execution of the above steps, a state transition will be triggered. For example, during evidence chain reconstruction, after the L2 layer analysis is completed but before the L3 layer analysis is executed, a state transition is triggered, and the checkpoint for the current state is created as the L2 layer.

[0167] Step 702: After executing the state transition logic, the transitioned state is verified according to the preset state invariant rule set.

[0168] In some embodiments, after the state transition logic is executed, that is, after the L3 layer analysis is completed, the transitioned state is verified according to the preset state invariant rule set.

[0169] In some embodiments, the aforementioned preset state invariant rule set may include at least one of the following invariant rules: The iterative monotonicity invariant is used to verify that the number of planning iterations is non-negative and monotonically increasing. The plan integrity invariant is used to verify that when a current vulnerability detection task plan exists, the task plan contains at least one execution step; The APK consistency invariant is used to verify that when entering the APK analysis branch, the vulnerability analysis data associated with the APK analysis branch is not empty; The execution completion invariant is used to verify that when the vulnerability analysis report is generated, all execution steps have produced corresponding execution results. The evidence traceability invariant is used to verify that the evidence graph structure satisfies the directed acyclic graph constraint and that the leaf node evidence in the evidence graph originates from the tool output. The observation consistency invariant is used to verify that the number of observation entries recorded by the vulnerability detection task is not less than the number of iterations planned for the vulnerability detection task.

[0170] In some embodiments, the above iterative monotonicity invariant can be plan_iterations≥0 and monotonically increasing, that is, the number of planning iterations satisfies non-negativity and monotonically increasing. This iterative monotonicity invariant ensures that negative numbers or backtracking will not occur. Furthermore, violating this iterative monotonicity invariant will result in historical data corruption.

[0171] In some embodiments, the number of iterations is bound to the checkpoints one-to-one, which can quickly locate which iteration triggered the rollback / manual modification, while avoiding the problem of repeatedly executing the same version of the plan or the process looping after the rollback.

[0172] In some embodiments, the above planning integrity invariant can be that current_plan is not empty. steps.length > 0. Here, current_plan is the current plan, and steps.length is the task length. In some embodiments, the plan integrity invariant ensures that a valid plan includes steps; violating this invariant may lead to an infinite loop due to an empty plan.

[0173] In some embodiments, if current_plan is not empty but steps.length is empty, the process will continue to try to execute the plan, but there are no specific steps to execute, thus getting stuck in an infinite loop of checking the plan → no steps → re-checking the plan.

[0174] In some embodiments, the above APK consistency invariant can be enabled_apk_investigation=true. `apk_vuln_json` is not empty. Here, `enable_apk_investigation=true` indicates entering the APK analysis branch; `apk_vuln_json` contains the vulnerability analysis data associated with the APK analysis branch. In some embodiments, APK consistency invariants can ensure complete configuration in APK mode; if APK consistency invariants are not used, tool injection will fail.

[0175] In some embodiments, the above execution completion invariant can be a non-empty final_report. ( step: execution_res (not empty), where final_report is the vulnerability analysis report, indicating that all execution steps have produced corresponding execution results. step: execution_res is not empty, indicating that the execution result corresponding to any step is not empty.

[0176] In some embodiments, the above execution completion invariant ensures that all steps have been completed before the report is generated; if the above execution completion invariant is violated, the report content will be incomplete.

[0177] In some embodiments, the above-mentioned traceability invariant can be node: acyclic ∧ (leaf node) (From tools / search tools). Among them, `node` represents any leaf node. Furthermore, in some embodiments, the aforementioned evidence traceability invariant ensures the validity and traceability of the evidence graph; violating this invariant may result in circular references or false evidence.

[0178] In some embodiments, the above observation consistency invariant can be that the number of observations is greater than or equal to the number of plan_iterations. Here, the number of observations is the number of observation entries, and plan_iterations is the number of iterations in the vulnerability detection task planning.

[0179] In some embodiments, the observation consistency invariant described above can guarantee that there is at least one observation record in each iteration; if the observation consistency invariant is violated, the audit log will be incomplete.

[0180] Step 703: If the verification passes, generate the corresponding status management log; otherwise, roll back the status to the checkpoint and generate status error information.

[0181] In some embodiments, if the verification passes, that is, if the invariant rules in the preset state invariant rule set are satisfied, the corresponding state management log can be generated; if the verification fails, the state can be rolled back to the checkpoint, and the Human Feedback node can be standardized to interrupt the [EDIT_PLAN] modification plan or throw an InvariantViolatio exception including details of the violation of specific inequalities, generating state error information.

[0182] In some embodiments, the above method may further include: before executing the state transition logic, verifying the preconditions corresponding to the state transition logic; if the precondition verification fails, pausing the execution of the state transition logic and generating an error message; and / or, after executing the state transition logic and before verifying the state invariant rule set, verifying the postconditions corresponding to the state transition logic; if the postcondition verification fails, rolling back the state to the checkpoint and generating an error message.

[0183] The vulnerability identification method provided in this application embodiment achieves immediate blocking and proactive defense against errors by managing the state throughout the entire process, automatically verifying key constraints after each state transition, and throwing exceptions and automatically rolling back when violations occur, thereby preventing the pollution of subsequent states.

[0184] To provide a clear understanding of this application, the method of this embodiment is described below as an example. The process of this vulnerability identification method may include: The process of reconstructing the aforementioned chain of evidence may include: start ↓ Obtain the vulnerable file and parse it. APK vulnerability type identifier detected Enter APK analysis branch ↓ Initialize APK static analyzer Only inject APK static analysis tool Extracting structured data from {entry, parsing, sink} triples Extracting taint path: Leaked path: intent_data → uri_param → webview_url No sanitization detection Search protection mode (regular expression matching) Result: No whitelist / scheme verification detected. Write back to the target analysis results ↓ Reconstruction of the chain of evidence and interpretability scoring - L1 direct chain: onNewIntent → getQueryParameter → loadUrl - L2 ring reconstruction: Ring1 (entry) → Ring2 (parsing) → Ring3 (sink) - L3 stream parsing: intent_data → uri_param → webview_load - L4 Ring mode verification: Ring 1 requires: getIntent / onNewIntent → Hit Ring2 required: getQueryParameter / parseUri → Hit Ring3 required: loadUrl / startActivity → Hit Compliance: 3 / 3 = 1.0 (Complete chain of evidence) - L5 Intelligent Inference: Accuracy ≥ 0.7 → No Inference Required - Rating Calculation: Base score: 0.20 Completeness of evidence: +0.30 Pattern conformity: +0.25 Source reliability: +0.20 (APK tool) Protection mechanism: +0.00 (No protection) Logical consistency: +0.15 Final score: 0.90 (High risk) ↓ Quality Diagnosis - No pattern violation exists - No weak source exists - No logical gaps exist - No evidence is missing. - Generate quality diagnostic results: No quality issues. - Generate a report (including PoC and remediation suggestions). - Forced referencing strategy: Post-Key Citations - Export audit package ↓ Finish In summary, all evidence in the vulnerability identification process of this embodiment comes from static analysis tools, without LLM inference; mandatory verification of Ring 1 / 2 / 3 key APIs achieves 100% compliance; the report includes a complete exploit chain and Proof of Concept (PoC); the source reliability is 1.0 (highest); evidence Figure 5Each node has a clear source-tracing relationship. Based on this, this embodiment achieves anti-illusion effects through a layered strategy, evidence chain reconstruction, interpretable scoring, state management, and an end-to-end constrained process for vulnerability analysis reports. The layered strategy automatically and orderly switches to alternative tool solutions, reducing the time spent on a single analysis and minimizing overall failures caused by single-point dependency failures. Structured verification and quantifiable diagnosis through evidence chain reconstruction and interpretable scoring enable precise location and closed-loop resolution of quality issues. State management throughout the process automatically verifies key constraints after each state transition, throwing exceptions and automatically rolling back upon violation, thus achieving immediate error blocking and proactive defense to prevent contamination of subsequent states. Therefore, this application achieves anti-illusion effects and improves vulnerability detection efficiency and accuracy.

[0185] To facilitate a clear understanding of this application, the five-layer tool layering strategy corresponding to the layering strategy is described below:

[0186] To facilitate a clear understanding of this application, the following describes the five-layered reconstruction of the evidence chain:

[0187] Corresponding to the vulnerability identification methods provided in the above embodiments, one embodiment of this application also provides a vulnerability identification device. Since the vulnerability identification device provided in this embodiment corresponds to the vulnerability identification methods provided in the above embodiments, the implementation of the vulnerability identification methods is also applicable to the vulnerability identification device provided in this embodiment, and will not be described in detail in this embodiment.

[0188] Figure 8 This is a schematic diagram of a vulnerability identification device according to an embodiment of this application. It should be noted that the vulnerability identification device can be implemented by software and / or hardware. In this embodiment, the vulnerability identification device can be an electronic device, or can be configured within an electronic device. The electronic device in this embodiment may include, but is not limited to, terminal devices and servers, etc., and this embodiment does not specifically limit the type of electronic device.

[0189] like Figure 8 As shown, the vulnerability identification device 800 includes: Analysis module 801 is used to obtain vulnerability files and analyze them using a layered strategy to obtain target analysis results; The evidence chain reconstruction module 802 is used to reconstruct the evidence chain based on the target analysis results, and obtain the target evidence chain and the marking results, wherein the marking results are used to indicate the completeness of the target evidence chain; The scoring module 803 is used to generate an evidence graph based on the target evidence chain, and to perform interpretable scoring based on the evidence graph and the labeling results to obtain the scoring results; The generation module 804 is used to perform quality diagnosis based on the evidence map and scoring results to obtain quality diagnosis results, and to generate a source map and a vulnerability analysis report based on the target analysis results, evidence map, scoring results and quality diagnosis results. The state management module 805 is used to manage the state during the execution of the above modules and to execute exception handling and recovery strategies when an interruption occurs.

[0190] In one embodiment of this application, the analysis module 801 is specifically used for: Obtain the vulnerability type identifier from the vulnerability file; If the vulnerability type identifier belongs to the preset APK vulnerability type set, proceed to the APK analysis branch; otherwise, proceed to the general analysis branch. If it is determined that the APK analysis branch will be entered, and if it is determined that the dedicated tool is available, the vulnerability file will be analyzed based on the dedicated tool to obtain the target analysis results; If it is determined to enter the general analysis branch, then determine whether there are any related local knowledge resources; If local knowledge resources exist, an analysis hint word containing the priority call instruction is generated, and the vulnerability file is analyzed using a local search tool based on the analysis hint word to obtain the target analysis results.

[0191] In one embodiment of this application, the analysis module 801 is further configured to: If no local knowledge resources exist, determine whether to configure a Model Context Protocol (MCP) server; If the MCP server is configured, external tools filtered through the whitelist are loaded from the MCP server, and the vulnerability files are analyzed based on the external tools to obtain the target analysis results. If it is determined that the MCP server is not configured, the tools already injected in the toolchain to be executed are deduplicated to obtain the target tool list, and the decision log of the target tool list construction process is recorded. The vulnerability files are analyzed based on the list of target tools to obtain the target analysis results.

[0192] In one embodiment of this application, the evidence chain reconstruction module 801 is specifically used for: From the target analysis results, extract explicit function call or event sequences according to time series to generate a linear call chain; Based on pre-defined domain knowledge, the linear call chain is divided into multiple semantic rings; Determine the propagation path of data in the semantic ring, remove technical noise in the propagation path, and obtain the target evidence chain; Determine if the target evidence chain matches the target pattern in the predefined pattern registry, and determine the compliance score based on the target pattern; Based on the consistency score, the labeling result of the target evidence chain is determined.

[0193] In one embodiment of this application, the scoring module 803 is specifically used for: Obtain a preset base score and determine whether there is missing evidence based on the evidence diagram. If it is determined that there is missing evidence, determine the first evidence integrity score; otherwise, determine the second evidence integrity score based on the marking results. Determine the matching result between the evidence diagram and the preset vulnerability pattern, and determine the pattern conformity score based on the matching result and the first preset weight; The average reliability score is determined based on the tool source type and corresponding preset reliability score in the evidence diagram, and the source reliability score is determined based on the average reliability score and the second preset weight. If a security protection mechanism is detected in the evidence diagram, a protection mechanism score is determined; The consistency score is obtained by examining the logical contradictions in the evidence diagram, and the logical consistency score is determined based on the consistency score and the third preset weight. The scoring results are determined based on the preset base score, the first evidence integrity score / second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score.

[0194] In one embodiment of this application, the generation module 804 is specifically used for: The evidence map and scoring results are detected based on preset multi-dimensional quality indicators to obtain the detection results. If the detection results include quality problem types, at least one executable target recovery strategy is generated and executed. The evidence map and scoring results are updated based on the execution results, and the quality diagnosis result is determined. Otherwise, the quality diagnosis result is determined based on the detection results.

[0195] In one embodiment of this application, the generation module 804 is further configured to: If the structural ring in the evidence diagram lacks a preset API, the quality problem type included in the detection results is pattern violation; If the source reliability score in the scoring results is less than or equal to the first threshold, then the quality problem type included in the detection results is weak source. If the logical consistency score in the scoring results is less than the second threshold, then the quality problem type included in the retrieval test results is logical gap; If the scoring results include a first evidence completeness score, then the quality problem type included in the search results is evidence missing.

[0196] In one embodiment of this application, the generation module 804 is further configured to: If the quality issues included in the test results are pattern violation or missing evidence, a retry strategy for different tools is generated to call up alternative analysis tools. If the quality issues included in the test results are weak sources or logical gaps, the process is paused and a manual input request strategy is generated. If the quality problem type included in the test results is one of missing evidence and partial missing evidence, a conservative inference strategy based on existing evidence and domain knowledge is generated to supplement the reasoning. If the quality problem type included in the test results is missing evidence and it is a non-critical missing evidence, a skip step strategy is generated to mark the corresponding step as failed and continue to the subsequent process.

[0197] In one embodiment of this application, the state management module 805 is specifically used for: In response to a triggered state transition, a checkpoint for the current state is created before executing the state transition logic; After executing the state transition logic, the transitioned state is verified according to the preset state invariant rule set; If the verification passes, the corresponding status management log is generated; otherwise, the status is rolled back to the checkpoint and a status error message is generated.

[0198] In one embodiment of this application, the preset state invariant rule set includes at least one of the following invariant rules: The iterative monotonicity invariant is used to verify that the number of planning iterations is non-negative and monotonically increasing. The plan integrity invariant is used to verify that when a current vulnerability detection task plan exists, the task plan contains at least one execution step; The APK consistency invariant is used to verify that when entering the APK analysis branch, the vulnerability analysis data associated with the APK analysis branch is not empty; The execution completion invariant is used to verify that when the vulnerability analysis report is generated, all execution steps have produced corresponding execution results. The evidence traceability invariant is used to verify that the evidence graph structure satisfies the directed acyclic graph constraint and that the leaf node evidence in the evidence graph originates from the tool output. The observation consistency invariant is used to verify that the number of observation entries recorded by the vulnerability detection task is not less than the number of iterations planned for the vulnerability detection task.

[0199] In one embodiment of this application, the state management module 805 is further configured to: Before executing the state transition logic, verify the preconditions corresponding to the state transition logic; If the precondition check fails, the execution of the state transition logic is paused and an error message is generated; and / or, After executing the state transition logic and before verifying the set of state invariant rules, verify the postconditions corresponding to the state transition logic; If the postcondition validation fails, the state will be rolled back to the checkpoint and an error message will be generated.

[0200] The vulnerability identification device in this application achieves an anti-illusion effect through a layered strategy, evidence chain reconstruction, interpretable scoring, state management, and an end-to-end constrained process for vulnerability analysis reports. The layered strategy automatically and orderly switches to alternative tool solutions, reducing the time spent on a single analysis and minimizing overall failures due to single-point dependency failures. Structured verification and quantifiable diagnosis through evidence chain reconstruction and interpretable scoring enable precise location and closed-loop resolution of quality issues. State management throughout the process automatically verifies key constraints after each state transition, throwing exceptions and automatically rolling back upon violation, thereby achieving immediate error blocking and proactive defense to prevent contamination of subsequent states. Therefore, the vulnerability identification device proposed in this application achieves an anti-illusion effect, improving vulnerability detection efficiency and the accuracy of vulnerability detection results.

[0201] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.

[0202] Figure 9 This is a block diagram of an electronic device according to an embodiment of this application.

[0203] like Figure 9 As shown, the electronic device includes: The memory 901, the processor 902, and the computer instructions stored in the memory 901 and executable on the processor 902.

[0204] When processor 902 executes instructions, it implements the vulnerability identification method provided in the above embodiments.

[0205] Furthermore, electronic devices also include: Communication interface 903 is used for communication between memory 901 and processor 902.

[0206] Memory 901 is used to store computer instructions that can be executed on processor 902.

[0207] The memory 901 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0208] The processor 902 is used to implement the vulnerability identification method of the above embodiments when executing the program.

[0209] If the memory 901, processor 902, and communication interface 903 are implemented independently, then the communication interface 903, memory 901, and processor 902 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0210] Optionally, in a specific implementation, if the memory 901, processor 902, and communication interface 903 are integrated on a single chip, then the memory 901, processor 902, and communication interface 903 can communicate with each other through an internal interface.

[0211] The processor 902 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0212] This application also proposes a computer program product that implements the vulnerability identification method of the embodiments of this application when the instruction processor in the computer program product is executed.

[0213] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0214] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0215] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0216] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0217] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0218] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0219] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0220] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A vulnerability identification method, characterized in that, The method includes: The vulnerability file is obtained and analyzed using a layered strategy to obtain the target analysis results; Based on the target analysis results, the evidence chain is reconstructed to obtain the target evidence chain and the labeling results, wherein the labeling results are used to indicate the completeness of the target evidence chain; An evidence graph is generated based on the target evidence chain, and an interpretable score is performed based on the evidence graph and the labeling results to obtain a score result. Based on the evidence map and the scoring results, a quality diagnosis is performed to obtain a quality diagnosis result. Based on the target analysis results, the evidence map, the scoring results, and the quality diagnosis results, a source tracing map and a vulnerability analysis report are generated. During the execution of the above steps, status management is performed, and status management logs are generated.

2. The method as described in claim 1, characterized in that, The analysis of the vulnerable file using a layered strategy to obtain target analysis results includes: Obtain the vulnerability type identifier from the vulnerability file; If the vulnerability type identifier belongs to the preset APK vulnerability type set, then proceed to the APK analysis branch; otherwise, proceed to the general analysis branch. If it is determined that the APK analysis branch will be entered, and if it is determined that a dedicated tool is available, the vulnerability file will be analyzed based on the dedicated tool to obtain the target analysis results; If it is determined that the general analysis branch is entered, then it is determined whether there are any related local knowledge resources; If the local knowledge resource exists, an analysis prompt word containing a priority call instruction is generated, and the vulnerability file is analyzed using a local search tool based on the analysis prompt word to obtain the target analysis result.

3. The method as described in claim 2, characterized in that, The method further includes: If the local knowledge resource does not exist, determine whether to configure a Model Context Protocol (MCP) server; If the MCP server is configured, then external tools filtered through the whitelist are loaded from the MCP server, and the vulnerability file is analyzed based on the external tools to obtain the target analysis results; If it is determined that the MCP server is not configured, the tools already injected in the toolchain to be executed are deduplicated to obtain a target tool list, and the decision log of the target tool list construction process is recorded. The vulnerability file is analyzed based on the list of target tools to obtain the target analysis results.

4. The method as described in claim 1, characterized in that, The process of reconstructing the evidence chain based on the target analysis results to obtain the target evidence chain and labeling results includes: From the target analysis results, explicit function call or event sequences are extracted according to time series to generate a linear call chain; Based on pre-defined domain knowledge, the linear call chain is divided into multiple semantic rings; Determine the propagation path of data in the semantic loop, remove technical noise from the propagation path, and obtain the target evidence chain; Determine if the target evidence chain matches the target pattern in the predefined pattern registry, and determine the compliance score based on the target pattern; Based on the conformity score, the labeling result of the target evidence chain is determined.

5. The method as described in claim 1, characterized in that, The process of performing interpretable scoring based on the evidence map and the labeling results to obtain a scoring result includes: Obtain a preset base score and determine whether there is missing evidence based on the evidence diagram. If it is determined that there is missing evidence, determine a first evidence integrity score; otherwise, determine a second evidence integrity score based on the marking results. Determine the matching result between the evidence diagram and the preset vulnerability pattern, and determine the pattern conformity score based on the matching result and the first preset weight; The average reliability score is determined based on the tool source type and corresponding preset reliability score in the evidence diagram, and the source reliability score is determined based on the average reliability score and the second preset weight. If a security protection mechanism is detected in the evidence diagram, a protection mechanism score is determined; The consistency score is obtained by checking the logical contradictions in the evidence diagram, and the logical consistency score is determined based on the consistency score and the third preset weight. The scoring result is determined based on the preset base score, the first evidence integrity score / the second evidence integrity score, the pattern conformity score, the source reliability score, the protection mechanism score, and the logical consistency score.

6. The method as described in claim 1, characterized in that, The quality diagnosis result obtained by performing quality diagnosis based on the evidence graph and the scoring result includes: The evidence image and the scoring results are detected based on preset multi-dimensional quality indicators to obtain detection results; If the detection results include a quality problem type, at least one executable target recovery strategy is generated and executed. The evidence graph and the scoring results are updated based on the execution results, and a quality diagnosis result is determined. Otherwise, a quality diagnosis result is determined based on the detection results.

7. The method as described in claim 6, characterized in that, The step of detecting the evidence image and the scoring result based on preset multi-dimensional quality indicators to obtain the detection result includes: If the structural ring in the evidence diagram is missing a preset API, the quality problem type included in the detection result is pattern violation; If the source reliability score in the scoring results is less than or equal to the first threshold, then the quality problem type included in the detection results is weak source. If the logical consistency score in the scoring results is less than the second threshold, then the quality problem type included in the retrieval test results is logical gap; If the scoring results include a first evidence completeness score, then the quality problem type included in the retrieval test results is evidence missing.

8. The method as described in claim 7, characterized in that, If the detection results include a quality problem type, then at least one executable target recovery strategy is generated, including: If the quality problem type included in the detection results is pattern violation or lack of evidence, a retry strategy for different tools is generated to call the backup analysis tool; If the quality problem type included in the detection results is a weak source or a logical gap, then the process is paused and a manual input request strategy is generated; If the quality problem type included in the detection results is evidence missing and partial evidence missing, then a conservative inference strategy based on existing evidence and domain knowledge to supplement the reasoning is generated. If the quality problem type included in the test results is missing evidence and is a non-critical missing evidence, a skip step strategy is generated to mark the corresponding step as failed and continue to the subsequent process.

9. The method as described in claim 1, characterized in that, The process of performing state management and generating state management logs includes: In response to a triggered state transition, a checkpoint for the current state is created before executing the state transition logic; After executing the state transition logic, the transitioned state is verified according to a preset set of state invariant rules. If the verification passes, a corresponding status management log is generated; otherwise, the status is rolled back to the checkpoint, and a status error message is generated.

10. The method as described in claim 9, characterized in that, The preset state invariant rule set includes at least one of the following invariant rules: The iterative monotonicity invariant is used to verify that the number of planning iterations is non-negative and monotonically increasing. A planning integrity invariant is used to verify that when a current vulnerability detection task plan exists, the task plan contains at least one execution step; The APK consistency invariant is used to verify that when entering the APK analysis branch, the vulnerability analysis data associated with that APK analysis branch is not empty; The execution completion invariant is used to verify that when the vulnerability analysis report is generated, all execution steps have produced corresponding execution results. The evidence traceability invariant is used to verify that the evidence graph structure satisfies the directed acyclic graph constraint and that the leaf node evidence in the evidence graph originates from the tool output. The observation consistency invariant is used to verify that the number of observation entries recorded by the vulnerability detection task is not less than the number of iterations planned by the vulnerability detection task.

11. The method as described in claim 9, characterized in that, The method further includes: Before executing the state transition logic, verify the preconditions corresponding to the state transition logic; If the precondition verification fails, the execution of the state transition logic is paused and an error message is generated; and / or, After executing the state transition logic and before verifying the state invariant rule set, verify the postconditions corresponding to the state transition logic; If the postcondition verification fails, the state is rolled back to the checkpoint, and an error message is generated.

12. A vulnerability identification device, characterized in that, The device includes: The analysis module is used to acquire vulnerability files and analyze the vulnerability files using a layered strategy to obtain target analysis results. The evidence chain reconstruction module is used to reconstruct the evidence chain based on the target analysis results to obtain the target evidence chain and the marking results, wherein the marking results are used to indicate the completeness of the target evidence chain; The scoring module is used to generate an evidence graph based on the target evidence chain, and to perform interpretable scoring based on the evidence graph and the labeling results to obtain a scoring result; The generation module is used to perform quality diagnosis based on the evidence graph and the scoring results to obtain quality diagnosis results, and to generate a source tracing map and a vulnerability analysis report based on the target analysis results, the evidence graph, the scoring results and the quality diagnosis results; The state management module is used to manage the state during the execution of the above modules, and to execute exception handling and recovery strategies when an interruption occurs.

13. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any one of claims 1-11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-11.

Images