A link fusion-based security testing method, device, equipment and medium

Abstract

The application discloses a kind of based on link fusion security test method, device, equipment and medium, it is related to artificial intelligence technical field.The method comprises: generating candidate call chain based on the target interface static analysis target code corresponding to target test demand, in the running environment corresponding to target test demand trigger target interface real-time call chain collection;Link evidence graph is obtained based on the alignment fusion candidate call chain and real-time call chain of target interface and target code;Determine vulnerability hypothesis based on link execution data flow analysis link evidence graph in link evidence graph;Based on vulnerability hypothesis and link evidence graph, generate and execute directional verification task, based on directional verification result optimization adjustment vulnerability hypothesis and link evidence graph, according to optimization adjustment result determines the security test result corresponding to target test demand.By the technical scheme of the application, accurate contraction of test search space and system self-evolution can be realized, and the accuracy and conclusion reproducibility of vulnerability detection are improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a security testing method, apparatus, device, and medium based on link fusion. Background Technology

[0002] With the widespread adoption of World Wide Web applications and microservice architectures, security testing of World Wide Web application programming interfaces has become an important means of ensuring information system security.

[0003] In existing technologies, a combined static and dynamic security testing approach is typically employed, integrating the full-path coverage capability of static analysis with the real-world operational evidence from dynamic analysis to improve the comprehensiveness and accuracy of vulnerability detection. Static analysis, through abstract syntax tree parsing, symbol indexing, and call graph construction of the source code, can uncover potential security risks in the early stages of software development. Dynamic analysis, on the other hand, obtains the actual execution path of the program by collecting runtime information such as tracing, spanning, method probes, and call logs during program execution.

[0004] However, existing dynamic and static combined security testing solutions still have the following technical shortcomings: First, current technologies use static and dynamic analysis as two independent stages in sequence, failing to deeply integrate them at the data structure level, thus reducing the accuracy of vulnerability detection. Second, when generating test cases, existing automated security testing tools typically perform indiscriminate fuzzing or rule matching on all parameters of the interface under test. Due to the huge number of candidate interfaces, parameter and payload combinations and numerous duplicate requests, this can lead to a large number of invalid requests consuming the testing budget. Furthermore, it is easily affected by rate limiting, authentication status, and business preconditions, limiting the efficiency and depth of vulnerability detection. Third, in existing testing solutions, there is a lack of stable evidence correlation between scan results and code call chains, and the verification results are not used to reverse-correct the initial link analysis and risk assessment, resulting in a lack of a closed-loop correction mechanism in the testing process, making continuous optimization difficult.

[0005] Therefore, how to achieve precise shrinkage of the test search space and system self-evolution, and improve the accuracy of vulnerability detection and the reproducibility of conclusions, under the conditions that static analysis and dynamic tracing are not deeply integrated, vulnerability verification lacks precise guidance, and verification results cannot correct the initial analysis model in reverse, is an urgent problem to be solved. Summary of the Invention

[0006] This invention provides a security testing method, apparatus, device, and medium based on link fusion, which can solve the technical problems in the prior art where static analysis and dynamic tracking are separated and cannot form a unified evidence base, vulnerability verification lacks precise guidance leading to an explosion of test search space, and verification results cannot be used to correct the initial analysis model, thus failing to form a self-optimizing closed loop.

[0007] According to one aspect of the present invention, a security testing method based on link fusion is provided, comprising: Obtain the target interface corresponding to the target test requirement and the target code corresponding to the target interface; Static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Based on the interface identifier of the target interface and the version identifier of the target code, the candidate call chain and the real-time call chain are aligned and fused to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; Based on the link execution data flow in the link evidence graph, perform data flow analysis on the link evidence graph to determine the vulnerability hypothesis corresponding to the target test requirement; Based on the vulnerability hypothesis and link evidence graph, a targeted verification task is generated, the targeted verification task is executed, and the vulnerability hypothesis and link evidence graph are optimized and adjusted based on the targeted verification results. Based on the optimization and adjustment results, the security test results corresponding to the target test requirements are determined.

[0008] According to another aspect of the present invention, a security testing apparatus based on link fusion is provided, comprising: The data acquisition module is used to acquire the target interface corresponding to the target test requirement and the target code corresponding to the target interface; The data analysis module is used to perform static analysis on the target code based on the target interface, generate at least one candidate call chain, trigger the target interface in the runtime environment corresponding to the target test requirement, and collect the real-time call chain generated when the target interface is called. The link alignment module is used to align and fuse the candidate call chain and the real-time call chain based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; The hypothesis generation module is used to perform data flow analysis on the link evidence graph based on the link execution data flow in the link evidence graph, and determine the vulnerability hypothesis corresponding to the target test requirement. The result generation module is used to generate a targeted verification task based on the vulnerability hypothesis and the link evidence graph, execute the targeted verification task, optimize and adjust the vulnerability hypothesis and the link evidence graph based on the targeted verification results, and determine the security test result corresponding to the target test requirement based on the optimization and adjustment results.

[0009] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the link fusion-based security testing method described in any embodiment of the present invention.

[0010] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the link fusion-based security testing method described in any embodiment of the present invention.

[0011] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the link fusion-based security testing method described in any embodiment of the present invention.

[0012] The technical solution of this invention involves obtaining the target interface and target code corresponding to the target test requirement. Then, static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Further, the candidate call chain and real-time call chain are aligned and fused based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph. The link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information. Further, data flow analysis is performed on the link evidence graph based on the link execution data flow to determine the vulnerability hypothesis corresponding to the target test requirement. Finally, a targeted verification task is generated based on the vulnerability hypothesis and the link evidence graph, the targeted verification task is executed, and the vulnerability hypothesis and the link evidence graph are optimized and adjusted based on the targeted verification results. The security test result corresponding to the target test requirement is determined based on the optimization and adjustment results. By merging static candidate call chains with runtime real-time call chains into a link evidence graph containing observed and unobserved candidate branches, and using this graph-driven directed verification and feedback correction closed loop, this technology solves the technical problems in existing technologies where static analysis and dynamic tracing are separated and cannot form a unified evidence base, vulnerability verification lacks precise guidance leading to an explosion in the test search space, and verification results cannot back-correct the initial analysis model, thus failing to form a self-optimizing closed loop. This enables precise contraction of the test search space and system self-evolution, improving the accuracy of vulnerability detection and the reproducibility of conclusions.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a flowchart of a security testing method based on link fusion according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of a security testing method based on link fusion according to Embodiment 2 of the present invention; Figure 3This is a schematic diagram of a security testing process based on link fusion according to Embodiment 2 of the present invention; Figure 4 This is a flowchart of an optional security testing method based on link fusion according to Embodiment 2 of the present invention; Figure 5 This is a schematic diagram of a security testing device based on link fusion according to Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device that implements the link fusion-based security testing method of this invention. Detailed Implementation

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

[0017] It should be noted that the terms "first," "second," "target," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] It is worth noting that the information collected in the technical solution of this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse; if the user chooses to refuse, the process will proceed to the expert decision-making process.

[0019] Example 1 Figure 1This is a flowchart of a link-fusion-based security testing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations requiring security testing of World Wide Web application programming interfaces (WWAIs). The method can be executed by a link-fusion-based security testing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes: S110. Obtain the target interface corresponding to the target test requirement and the target code corresponding to the target interface.

[0020] In this context, "test requirements" refers to security testing tasks proposed by users or the testing system. Typically, test requirements include the test object, test scope, authorization boundaries, request budget, and test purpose. "Target test requirements" refer to the security testing task after preliminary parsing and standardization. Typically, target test requirements include all the parameters required for this test. For example, target test requirements may include the Uniform Resource Locator (URL) or request sample of the interface to be tested, test environment identifiers, and authorization boundary information. "Target interface" can refer to the World Wide Web application interface to be tested, i.e., the specific URL endpoint that the user wants to perform security testing on. "Target code" can refer to the source code that is strictly version-consistent with the deployment instance of the target interface.

[0021] S120. Based on the target interface, perform static analysis on the target code to generate at least one candidate call chain, and trigger the target interface in the runtime environment corresponding to the target test requirement to collect the real-time call chain generated when the target interface is called.

[0022] In this context, a call chain refers to the complete call path recorded during program execution, from the entry point method to the end point operation. Typically, a call chain consists of multiple edges, methods, or operations, reflecting the control flow of the program when performing a specific function. A candidate call chain refers to one or more possible call sequences extracted from the target code through static analysis. The runtime environment refers to the actual computing environment in which the target interface runs. For example, the runtime environment may include, but is not limited to, the server or container where the deployment instance resides, the operating system, the middleware version, the dependent library versions, and the network topology. A trigger can refer to the process of sending a real request to a backend interface that provides services over the internet to the target interface, causing the corresponding backend code to actually execute and generate runtime data. A real-time call chain refers to the actual call sequence obtained by collecting runtime information when the target interface is actually triggered in the runtime environment.

[0023] S130. Align and fuse the candidate call chain and the real-time call chain based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information.

[0024] Here, the interface identifier can refer to an immutable identifier used to uniquely distinguish a specific application programming interface. The version identifier can refer to an immutable identifier used to uniquely identify which source code snapshot corresponds to the target interface. Alignment fusion can refer to the process of mapping, matching, and merging candidate call chains and real-time call chains at the node level according to the interface identifier of the target interface and the version identifier of the target code. The link evidence graph can refer to the fused data structure containing complete call relationships and data flow information generated after aligning and fusing candidate call chains and real-time call chains according to interface identifiers and code version identifiers. Typically, the link evidence graph is a directed graph structure, where nodes represent methods or operations in the code, and edges represent call relationships or data propagation relationships. Observed branches can refer to nodes and call edges in the link evidence graph that have actually been executed in the real-time call chain. Unobserved candidate branches can refer to nodes and call edges in the link evidence graph that have been confirmed to exist theoretically through static analysis, but have not been actually executed in all currently collected real-time call chains. It is worth noting that in this embodiment of the invention, unobserved candidate branches represent "potential hidden risks," and even if they have not yet been executed, they are still retained in the graph as candidate targets to be verified. Evidence source information can refer to a label used to identify the type of information source for a node or edge in the link evidence graph. For example, evidence source information may include, but is not limited to: static code parsing, configuration file parsing, large language model inference, and runtime link observation. Confidence information can refer to a quantitative value representing the degree of trustworthiness of a node or edge in the link evidence graph. Typically, confidence information can take values ​​between 0 and 1, with values ​​closer to 1 indicating greater confidence in the existence of the node or edge.

[0025] S140. Based on the link execution data flow in the link evidence graph, perform data flow analysis on the link evidence graph to determine the vulnerability hypothesis corresponding to the target test requirement.

[0026] In this context, the link execution data flow refers to the complete data propagation trajectory in the link evidence graph, where external input parameters flow from the entry node along the call edge and data propagation edge, through a series of intermediate nodes for transmission, transformation, and transmission operations, ultimately reaching the dangerous operation sink node. A vulnerability hypothesis refers to a structured risk description object generated based on the reachable path from the external input source node to the dangerous operation sink node, the distribution of security control points, and evidence gaps in the link evidence graph. For example, a vulnerability hypothesis may include at least: a hypothesis identifier, vulnerability type, external input source node identifier, dangerous operation sink node identifier, a sequence of node identifiers for the reachable path, missing or weak security control points, parameter constraint information, precondition information, load policy information, success criterion information, and confidence level.

[0027] S150. Generate a targeted verification task based on the vulnerability hypothesis and link evidence graph, execute the targeted verification task, optimize and adjust the vulnerability hypothesis and link evidence graph based on the targeted verification results, and determine the security test result corresponding to the target test requirement based on the optimization and adjustment results.

[0028] Specifically, a targeted verification task can refer to an executable test task containing precise verification elements, generated based on vulnerability hypotheses and link constraints in the link evidence graph. A targeted verification result can refer to the actual feedback information obtained after executing the targeted verification task. For example, a targeted verification result may include the request / response status code, response body content, response latency, out-of-band callback signal, and the real-time call chain corresponding to this request. An optimization and adjustment result can refer to the state obtained after updating the link evidence graph and vulnerability hypotheses based on the targeted verification result. A security test result can refer to the security test conclusion corresponding to the final determined target test requirements after one or more iterations of optimization and adjustment. For example, a security test result may include at least: a list of confirmed vulnerabilities and their corresponding risk types, target interface identifiers, code version identifiers, a complete call chain, code location information for each node, the verification request or response content that triggers the vulnerability and its corresponding tracking identifier, confidence level, and remediation suggestions.

[0029] The technical solution of this invention involves obtaining the target interface and target code corresponding to the target test requirement. Then, static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Further, the candidate call chain and real-time call chain are aligned and fused based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph. The link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information. Further, data flow analysis is performed on the link evidence graph based on the link execution data flow to determine the vulnerability hypothesis corresponding to the target test requirement. Finally, a targeted verification task is generated based on the vulnerability hypothesis and the link evidence graph, the targeted verification task is executed, and the vulnerability hypothesis and the link evidence graph are optimized and adjusted based on the targeted verification results. The security test result corresponding to the target test requirement is determined based on the optimization and adjustment results. By merging static candidate call chains with runtime real-time call chains into a link evidence graph containing observed and unobserved candidate branches, and using this graph-driven directed verification and feedback correction closed loop, this technology solves the technical problems in existing technologies where static analysis and dynamic tracing are separated and cannot form a unified evidence base, vulnerability verification lacks precise guidance leading to an explosion in the test search space, and verification results cannot back-correct the initial analysis model, thus failing to form a self-optimizing closed loop. This enables precise contraction of the test search space and system self-evolution, improving the accuracy of vulnerability detection and the reproducibility of conclusions.

[0030] Example 2 Figure 2 This is a flowchart of a security testing method based on link fusion provided in Embodiment 2 of the present invention. This embodiment is a refinement based on the above embodiment. Specifically, this embodiment refines the step of "optimizing and adjusting the vulnerability hypothesis and link evidence graph based on the targeted verification results, and determining the security test result corresponding to the target test requirement based on the optimization and adjustment results." Specifically, it may include: updating the link evidence graph based on the targeted verification results to obtain an updated link evidence graph, and adjusting the confidence level of the vulnerability hypothesis based on the targeted verification results to obtain an adjusted vulnerability hypothesis; obtaining the iteration state information corresponding to the updated link evidence graph and the adjusted vulnerability hypothesis, and judging the iteration state information based on a preset iteration termination condition; wherein, the iteration state information includes the number of processed vulnerability hypotheses, the confidence level of the adjusted vulnerability hypothesis, the coverage status of unobserved candidate branches, and the number of optimization adjustments; if the iteration state information meets the preset iteration termination condition, then a security test result is generated based on the updated link evidence graph and the adjusted vulnerability hypothesis. Figure 2 As shown, the method includes: S210. Obtain the interface description information corresponding to the target test requirement, and determine the target interface corresponding to the target test requirement based on the interface description information.

[0031] The interface description information can refer to the original information provided by the user or the testing system that describes the target interface under test. For example, the interface description information can be a complete Uniform Resource Locator (URL), an interface path template, a Hypertext Transfer Protocol (HTTP) request sample containing a HTTP method and request body structure, or an interface document fragment, etc.

[0032] S220. Match the corresponding deployment instance based on the target interface, and determine the version identifier corresponding to the deployment instance based on the container image digest, build number or version identifier information in the environment variables of the deployment instance, and obtain the target code from the code repository based on the version identifier.

[0033] In this context, a deployment instance can refer to an actual running process entity of the World Wide Web Application Programming Interface (WWAN) service corresponding to the target interface in a specific runtime environment. Typically, a deployment instance can be a specific physical or logical unit containing a complete runtime context. A container image digest can refer to the content addressing hash value of a container image. Typically, a container image digest is a unique fingerprint generated based on the binary file content of the container image using a hash algorithm, and it is tamper-proof. A build number can refer to a unique number assigned to the build task during each build process. Typically, the build number is associated with the trigger information, build environment information, and build artifact information of this build. It is worth noting that in this embodiment of the invention, when the container image digest is unavailable, the build number serves as an alternative source of version identification information, and the corresponding code commit number can be retrieved from the artifact repository. Environment variables can refer to key-value pair variables used at the operating system level or container runtime to pass configuration information to the application. Typically, when the deployment instance cannot directly provide an image digest or build number, the code version identifier can be determined by reading pre-injected environment variables. Version identification information can refer to the collection of all runtime metadata used to determine or derive the version identifier. A code repository can refer to a version control system repository used to store and manage source code. Typically, a code repository contains a project's complete source code history, branch information, tag information, and metadata for each commit.

[0034] Specifically, the process involves obtaining the interface description information corresponding to the target test requirement, parsing this description information, and identifying the target interface for this test. Then, based on the domain name or service name deployed by the target interface, a reverse lookup is performed through a service registry or container orchestration platform to locate one or more deployment instances handling the target interface and obtain the metadata of those instances. For example, in a containerized deployment scenario, the container runtime interface is called to obtain the container image digest used by the container; if the container image digest is unavailable or not configured, the environment variables of the deployment instance are read or the build number corresponding to the instance is queried to obtain the version identifier information of the deployment instance; the obtained container image digest is sent to the container image repository, and the tag information injected during the image build is queried to decipher the image digest into a specific commit number; if a build number scheme is used, the code commit number associated with the build number is queried through the artifact repository to obtain the version identifier. Finally, based on the version identifier and the code repository address, a source code snapshot corresponding to the version identifier is precisely pulled from the code repository as the target code for subsequent static analysis. Therefore, by automatically extracting version identifiers from the runtime metadata of the deployment instance, rather than relying on users to manually specify branches or commit numbers, it ensures that the target code used for static analysis is strictly consistent with the bytecode actually executed in the runtime environment at the version level, eliminating analysis bias and fusion misalignment caused by manually specifying incorrect versions.

[0035] S230. Based on the target interface, perform static analysis on the target code to generate at least one candidate call chain, and trigger the target interface in the runtime environment corresponding to the target test requirement to collect the real-time call chain generated when the target interface is called.

[0036] In an optional implementation, the step of performing static analysis on the target code based on the target interface to generate at least one candidate call chain includes: Step a1: Locate the controller entry of the target interface from the routing definition of the target code based on the entry identifier of the target interface.

[0037] The entry point identifier can be a lookup key generated based on the interface identifier of the target interface, used to locate the corresponding controller method in the route definition. Typically, the entry point identifier can include the Hypertext Transfer Protocol (HTTP) method and normalized path template information. The route definition can be a set of rules defined in the target code that maps HTTP requests to backend processing methods. For example, the route definition can be route annotations in the source code, framework configuration files, or programmatic route registration information. The controller entry point can be the first business layer code node that directly receives and processes HTTP requests.

[0038] Step a2: Use the abstract syntax tree, symbol index, type inference and dependency injection information to traverse downwards from the controller entry point to determine the calling relationship.

[0039] Abstract syntax trees (APIs) refer to the tree-structured representation of source code. Typically, each node in an API represents a syntactic structure in the source code, such as package declarations, class definitions, method declarations, variable declarations, method calls, and conditional branches. Symbol indexes refer to lookup tables that map all identifiers in the code to their definition locations. Type inference refers to the process of deriving the specific type a variable or expression is bound to at runtime based on its declaration type, assignment context, generic parameters, and method return value. Dependency injection information refers to the configuration information of dependency relationships between objects managed by a dependency injection framework. Typically, dependency injection information describes which concrete implementation class a given interface or abstract type should be bound to at runtime. Downward traversal refers to a recursive analysis process that starts from the controller entry method and delves deeper into the call statements within the method body until a predetermined endpoint is reached or traversal can no longer continue. Typically, traversal uses a depth-first strategy, cloning the current path for each branch encountered to ensure no possible execution paths are missed. Call relationships refer to the static call links between caller and callee methods.

[0040] Step a3: Identify the framework metadata and extract the call nodes corresponding to interceptors, filters, aspects, transaction proxies and / or authentication annotations from the framework metadata based on the framework type of the framework metadata.

[0041] Framework metadata refers to the runtime configuration information exposed at the code and configuration levels of the web, microservice, or data access framework used by the application. Typically, framework metadata specifically refers to the configuration information of the framework's own runtime mechanism. For example, framework metadata may include interceptor chain configuration, aspect-oriented programming (AOP) aspect definitions, transaction management configuration, global filter registration, and extension point information loaded internally by the framework through service provider interface mechanisms. Framework type refers to the specific framework category used by the current target code. Different framework types typically correspond to different annotation names, configuration formats, and invocation patterns. Interceptors refer to general processing components automatically invoked by the framework before and after the execution of controller methods. Interceptors typically contain permission verification logic and are an important source of security control points in vulnerability analysis. In this embodiment, the call nodes corresponding to the interceptors are inserted before and after the controller entry point, forming part of the call chain. Filters refer to request or response processing components at an outer layer than interceptors, managed by the server-side applet container. In this embodiment of the invention, the filter is located before the interceptor; that is, the call node corresponding to the filter is inserted at the very beginning of the call chain, forming a pre-node outside the entry point, and may also contain security control point information. An aspect can refer to the implementation of cross-cutting concerns defined in aspect-oriented programming. In this embodiment, an aspect is a framework mechanism for horizontally enhancing business methods, and its corresponding call node is inserted before and after the target business method. A transaction proxy can refer to a proxy object generated by the transaction management framework for the target business method at runtime. An authentication annotation can refer to a control annotation used to declare interface access permissions. A call node can refer to the smallest unit in a method-level call graph and candidate call chain. For example, a call node can represent a method being analyzed or a framework-level logical unit.

[0042] Step a4: Establish a call mapping from the business layer to the database access layer based on the call node, and generate at least one candidate call chain based on the call relationship and the call mapping.

[0043] In this context, call mapping can refer to the complete method call mapping relationship starting from the controller entry method, passing through the business service layer, utility class layer, data mapping interface layer, and finally to the database access layer.

[0044] Specifically, after determining the target interface and target code corresponding to the target test requirements, the target code is first scanned globally. All controller classes and their methods' data mapping interfaces and other routing annotations are parsed. Hypertext Transfer Protocol methods, class-level prefix paths, and method-level paths are concatenated to generate a complete route template, establishing a mapping index from entry point identifiers to controller methods. Then, the entry point identifier is used as the key to search this index, locating the corresponding controller method, which becomes the starting point for downward traversal. Next, an abstract syntax tree of the controller method and its dependent classes is constructed. Symbolic indexing is used to establish cross-file symbol lookup capabilities, type inference is used to handle polymorphic call scenarios, and dependency injection information is used to determine the actual type of dependent objects. Starting from the controller entry method, a depth-first traversal is performed along the call statements within the method body. When a direct method call is encountered, the process jumps to the abstract syntax tree of the called method for further analysis. When an interface call is encountered, the specific implementation class is determined through type inference and dependency injection information before jumping. When conditional branch statements or multi-branch statements are encountered, the current path is cloned for each branch and traced separately. During the traversal, framework metadata is simultaneously identified. Based on the framework type, interceptor chain configurations are extracted from the metadata, and aspect-oriented programming (AOP) aspect configurations, transaction proxy configurations, and authentication annotations are identified. The logical units corresponding to interceptors, filters, aspects, transaction proxies, and authentication annotations are inserted as call nodes into their respective positions in the call chain. Furthermore, during the traversal, each method call is established as a call relationship record, and each framework layer logical unit is established as a call node. Finally, based on these call nodes and call relationships, they are linked end-to-end according to the call order to establish a complete call mapping from the controller entry point to the business layer and then to the data access layer, generating one or more candidate call chains from the controller to the database access layer. This achieves accurate restoration of code call relationships in complex framework environments, effectively avoiding broken chains in static analysis, and providing a clear and complete set of candidate paths for subsequent link fusion.

[0045] S240. Based on the interface identifier of the target interface and the version identifier of the target code, the candidate call chain and the real-time call chain are aligned and fused to obtain a link evidence diagram.

[0046] The link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information.

[0047] Specifically, after obtaining the candidate call chain and the real-time call chain, using the interface identifier of the target interface and the code version identifier of the target code as a joint primary key, firstly, a stable node identifier is generated for each node in the candidate call chain according to its code position. Simultaneously, a stable node identifier is generated for each span in the real-time call chain according to the same rules. Then, bidirectional matching is performed using the stable node identifier as the key. That is, if a node in the candidate call chain has the same stable node identifier in the span list of the real-time call chain, the node is marked as observed, and its observation source is recorded as runtime. If a node in the candidate call chain cannot find a match in the real-time call chain, it is marked as an unobserved candidate, and its evidence source is retained as the abstract syntax tree or large language model. Based on node matching, call edges are further aligned. That is, for each call edge in the candidate call chain, it is checked whether there is a corresponding sequential call order in the span parent-child relationship of the real-time call chain. If it exists, the edge is marked as observed; otherwise, it is retained as an unobserved candidate. After alignment, the confidence score is calculated for each node and edge using the formula: C = w1 × Ssymbol + w2 × Sconfig + w3 × Smodel + w4 × Sruntime. Here, w1, w2, w3, and w4 represent weights, Ssymbol represents the symbolic resolution evidence score, Sconfig represents the framework configuration evidence score, Smodel represents the large model inference evidence score, and Sruntime represents the runtime observation evidence score. Finally, all observed nodes, unobserved candidate nodes, observed edges, unobserved candidate edges, and their respective evidence sources, confidence scores, observation states, and other metadata are aggregated into a directed graph. This graph, known as the link evidence graph, serves as the unified data foundation for subsequent vulnerability hypothesis generation and targeted verification.

[0048] S250. Mark the entry node in the link evidence graph as an external input source node, and mark the database operation node, command execution node, file operation node, template rendering node and / or sensitive data output node in the link evidence graph as a target operation sink node.

[0049] In this context, an entry node can refer to the first node in the link evidence graph that marks the starting point of request processing. An external input source node can refer to an entry node marked as an external input source. A database operation node can refer to a node in the link evidence graph that performs database access operations. A command execution node can refer to a node in the link evidence graph that executes operating system commands. A file operation node can refer to a node in the link evidence graph that performs file system operations. A template rendering node can refer to a node in the link evidence graph that performs template engine rendering operations. A sensitive data output node can refer to a node in the link evidence graph that outputs sensitive data in plaintext to the Hypertext Transfer Protocol response body or log file. An operation sink node can refer to the endpoint of all operations with potential security risks. A target operation sink node can refer to the set of specific dangerous operation node types identified after screening and targeted by the current analysis.

[0050] S260, Mark the authentication node, input verification node, output encoding node and / or parameterization processing node between the external input source node and the target operation sink node as basic control points.

[0051] In this context, authentication nodes refer to code nodes in the link evidence graph that perform identity authentication or permission verification. Input verification nodes refer to code nodes in the link evidence graph that verify the validity of external input parameters. Output encoding nodes refer to code nodes in the link evidence graph that perform secure encoding or escaping of output data. Parameterization processing nodes refer to code nodes in the link evidence graph that use parameterized queries or pre-compiled statements. Control points refer to security protection nodes that can block or weaken attack payloads. Basic control points refer to all control points identified during data flow analysis that are located between external input source nodes and target operation sink nodes.

[0052] S270. Along the data flow edge in the link evidence graph, trace the data propagation path from the external input source node to the target operation sink node. If the data propagation path exists, mark the data propagation path as a reachable path and record all intermediate nodes and corresponding data transformation operations on the reachable path.

[0053] In this context, a data flow edge refers to a directed edge in the link evidence graph that represents data propagating from one node to another. Typically, data flow edges record the paths along which parameters or variables are passed between method calls. A data propagation path refers to the complete trajectory starting from an external input source node, passing through one or more intermediate nodes along the data flow edge, and finally reaching the target operation sink node. A reachable path refers to a path verified by data flow tracing that confirms the existence of a data propagation relationship from an external input source node to the target operation sink node. Intermediate nodes refer to all intermediate processing nodes located between the external input source node and the target operation sink node on the data propagation path. For example, intermediate nodes can include business service layer methods, utility class methods, data transformation functions, and data access layer methods. Data transformation operations refer to the operations that occur at intermediate nodes during data propagation. For example, data transformation operations can include type conversion, encoding or decoding, string concatenation, formatting, encryption or decryption, serialization or deserialization, etc.

[0054] S280. Perform pattern matching on the reachable path based on the preset link pattern table to determine the risk type corresponding to the reachable path.

[0055] The preset link pattern table can refer to a pre-defined knowledge base of security vulnerability patterns. Typically, this table stores mapping rules between link topology and data flow characteristics and risk types. For example, the mapping rules in the preset link pattern table could be: when the link pattern is: the end of the reachable path is a Structured Query Language (SCL) execution node and parameterized processing control points on the path are missing, the risk type can be mapped to SCL injection; when the link pattern is: the end of the reachable path is a file operation node and path normalization verification on the path is missing, the risk type can be mapped to path traversal; when the link pattern is: the reachable path passes through a resource query but lacks subject or resource ownership verification, the risk type can be mapped to unauthorized access. Risk types can refer to security risk classifications determined after pattern matching. For example, risk types include, but are not limited to, SCL injection, command injection, path traversal, arbitrary file read / write, server-side request forgery, cross-site scripting (XSS), template injection, unauthorized access, and sensitive data leakage.

[0056] S290. Perform an evidence gap analysis on each reachable path, determine the evidence gap based on the distribution of the basic control points on the reachable path, and generate the vulnerability hypothesis based on the risk type, the reachable path, and the evidence gap.

[0057] In this context, an evidence gap can refer to a missing or weak security protection mechanism on a specific reachable path that is necessary to prevent the exploitation of a break vulnerability. For example, an evidence gap can be a missing basic control point on the reachable path, or a candidate branch in the reachable path that is not observed in real-time by the call chain.

[0058] Specifically, after obtaining the link evidence graph, using it as input, firstly, all nodes in the graph are traversed, marking the entry controller method as an external input source node. Simultaneously, all dangerous operation nodes in the graph are scanned, marking database operation nodes, command execution nodes, file operation nodes, template rendering nodes, and sensitive data output nodes as target operation sink nodes. Then, the path between the external input source node and the target operation sink node is traversed, identifying and marking authentication nodes, input verification nodes, output encoding nodes, and parameterization processing nodes as basic control points. Next, starting from the external input source node, the data flow edges in the link evidence graph are traversed downstream, tracking whether the external input can reach a target operation sink node. If a path exists that allows the input parameters to pass through the controller entry method, business service layer, utility class layer, data mapping interface layer, and finally to the database access layer, this path is marked as a reachable path, and all intermediate nodes and their data transformation operations are recorded. Furthermore, based on the type of the terminal node and the distribution of intermediate control points on this reachable path, it is matched with a preset link pattern table to determine the risk type corresponding to the reachable path. Furthermore, an evidence gap analysis is performed on the reachable path: the distribution of basic control points along the path is examined to identify evidence gaps. Finally, based on the risk type, reachable path, evidence gaps, and information such as parameter constraints, preconditions, and load strategies obtained from the pattern table, a complete vulnerability hypothesis object is generated. This object contains structured fields such as hypothesis identifier, vulnerability type, external input source node identifier, target operation sink node identifier, reachable path node identifier sequence, missing control point information, parameter constraints, preconditions, load strategies, success criteria, and confidence level, serving as direct input for subsequent targeted verification tasks. Thus, by identifying external input source nodes, target operation sink nodes, and basic control points, vulnerability analysis no longer relies on simple feature matching or rule patterns, but rather on reasoning based on precise link topology and data propagation relationships, improving the targeting and accuracy of vulnerability discovery. Moreover, by tracing the complete propagation path from the external input source to the target operation sink along the data flow edge, subsequent testing can verify only the relevant parameters on the reachable path, fundamentally avoiding the blindness of indiscriminate fuzz testing.

[0059] S2100. Select parameters to be tested from the vulnerability assumptions based on the link constraints in the link evidence graph, and generate a minimum load set based on the context information of the parameters to be tested and the risk type in the vulnerability assumptions.

[0060] Link constraints refer to the conditions and boundaries imposed by the link evidence graph that limit the scope of the targeted verification task. For example, link constraints can include topology constraints, data flow constraints, and control point constraints. The parameter to be tested refers to the set of parameters extracted from the external input source nodes of the vulnerability hypothesis that can actually reach the target operation sink node and need to be verified. Context information refers to the propagation context of the parameter to be tested in the link evidence graph. Minimum payload refers to a very small number of attack strings generated against a specific parameter to be tested and specific context information. The minimum payload set refers to the complete payload group formed by merging the minimum payloads generated for all parameters to be tested in a vulnerability hypothesis.

[0061] S2110. Determine the authentication status based on the precondition information in the vulnerability assumption, determine the precondition request based on the parameter dependency relationship of the target interface, determine the success criterion based on the risk type in the vulnerability assumption, and determine the stop condition based on the authorization boundary information of the target test requirements.

[0062] The preconditions can refer to the business or state prerequisites recorded in the vulnerability hypothesis that are required to trigger the vulnerability. Authentication status can refer to the authentication and session status required to call the target interface. Parameter dependencies can refer to the precondition dependencies between request parameters of the target interface. Precondition requests can refer to one or more auxiliary Hypertext Transfer Protocol requests that must be executed before the main targeted verification task. Success criteria can refer to the set of verification signal rules that determine the existence of the vulnerability. Typically, success criteria can be objective conditions determined based on the risk type in the vulnerability hypothesis that prove the vulnerability has been successfully triggered. Authorization boundary information can refer to the security testing authorization boundaries determined during the task binding phase. For example, authorization boundary information may include, but is not limited to: maximum request budget, allowed vulnerability types, whether destructive payloads are allowed, and the allowed range of target interfaces. Termination conditions can refer to the combination of triggering rules that prematurely terminate further verification of the vulnerability hypothesis.

[0063] S2120. Generate a targeted verification task based on the parameters to be tested, the minimum load set, the authentication status, the prerequisite request, the success criterion, and the stop condition.

[0064] Specifically, after determining the vulnerability hypothesis corresponding to the target testing requirement, using the vulnerability hypothesis and link evidence graph as input, firstly, all parameters that can actually reach the target operation sink node are extracted from the external input source nodes of the vulnerability hypothesis as parameters to be tested. Then, the context information of this parameter on the propagation path is extracted from the link evidence graph. Next, based on this context information and the risk type in the vulnerability hypothesis, a small number of precise payloads are selected and adapted from a pre-set payload template library. Finally, these payloads are aggregated into a minimum payload set. Subsequently, the precondition information in the vulnerability hypothesis is parsed, the token of the administrator role is matched as the authentication status from the pre-set test credential library, and the order unique identifier depends on the pre-created resource by parsing the Unique Resource Locator (URL) template of the target interface. A pre-request is automatically generated, and a variable mapping relationship is established from the order unique identifier field in the response body of the pre-request to the main request path parameters. Simultaneously, success criteria are determined according to the risk type in the vulnerability hypothesis, and stop conditions are determined according to the authorization boundary information of the target testing requirement. Finally, the parameters to be tested, the minimum payload set, authentication status, success criteria, and stop conditions are assembled into a complete targeted verification task object, which is then executed by the tool calling module. Therefore, by precisely selecting the parameters to be tested through link constraints and adapting them to generate a minimum payload set based on context information, the thousands of test cases in traditional indiscriminate fuzzing are compressed into a few targeted payloads. This significantly reduces the number of test requests and effectively avoids interference from rate limiting, authentication status, and business preconditions on large-scale scanning. By utilizing the context information of the parameters to be tested to generate adapted payloads, the inefficiency of blindly sending a large number of irrelevant payloads using a general fuzzing dictionary is avoided, significantly improving the hit rate of vulnerability verification.

[0065] S2130. Execute the targeted verification task, update the link evidence graph based on the targeted verification results to obtain the updated link evidence graph, and adjust the confidence level of the vulnerability hypothesis based on the targeted verification results to obtain the adjusted vulnerability hypothesis.

[0066] The updated link evidence graph can refer to the latest version of the link evidence graph obtained by comparing the actual execution sequence in the directed verification results with the original link evidence graph, and then adding newly discovered actual execution nodes or call edges as new branches to the original link evidence graph. For example, the updated link evidence graph includes at least: the newly added nodes and edges and their observation states, evidence sources, confidence information, and the path topology structure changed due to the added nodes. The adjusted vulnerability hypothesis can refer to the latest version of the vulnerability hypothesis object obtained by quantitatively adjusting the confidence level of the vulnerability hypothesis based on the directed verification results.

[0067] In an optional implementation, updating the link evidence graph based on the targeted verification results to obtain an updated link evidence graph, and adjusting the confidence level of the vulnerability hypothesis based on the targeted verification results to obtain an adjusted vulnerability hypothesis, includes: Step b1: Compare the actual execution sequence in the targeted verification result with the link evidence graph to obtain the comparison result; wherein, the actual execution sequence includes actual execution nodes or call edges.

[0068] In this context, "actual execution node" refers to the method or operation node that is actually called and executed during the execution of the targeted verification task, obtained by collecting the real-time call chain. "Call edge" refers to the sequential call relationship between two actual execution nodes in the actual execution sequence, i.e., the directed connection between the caller node and the callee node. "Actual execution sequence" refers to the complete ordered sequence of nodes formed by sorting all actual execution nodes collected during the targeted verification task execution according to timestamps and call parent-child relationships. "Comparison result" refers to the difference analysis conclusion obtained by comparing the actual execution sequence in the targeted verification result with the candidate path corresponding to the vulnerability hypothesis in the link evidence graph node by node and edge by edge. For example, the comparison result includes at least the following three types of information: nodes or edges present in the actual execution sequence but not in the link evidence graph, i.e., newly discovered actual execution objects; nodes or edges present in the link evidence graph but not in the actual execution sequence, i.e., untriggered candidate branches; and nodes or edges that completely match, i.e., branches that have been observed and confirmed.

[0069] Step b2: If the comparison result indicates that the target execution object in the actual execution sequence does not exist in the link evidence graph, then the target execution object is added to the link evidence graph as a new branch to obtain an updated link evidence graph.

[0070] The target execution object can refer to a node or call edge that exists in the actual execution sequence but does not exist in the link evidence graph, as determined in the comparison results.

[0071] Step b3: If the targeted verification result is that the target operation hub node has not been reached, then reduce the confidence level of the vulnerability hypothesis and record the control point information that blocks the target operation hub node to obtain the adjusted vulnerability hypothesis.

[0072] Step b4: If the targeted verification result satisfies the success criterion of the vulnerability hypothesis and the reachable path is actually executed, then increase the confidence of the vulnerability hypothesis to obtain the adjusted vulnerability hypothesis.

[0073] Specifically, after completing the targeted verification task, the targeted verification result is obtained, which includes the complete actual execution sequence corresponding to this request. Then, the actual execution sequence is cross-compared node-by-node and edge-by-edge with the candidate call path node list corresponding to the vulnerability hypothesis in the link evidence graph, resulting in a comparison result. If the comparison finds that a node in the actual execution sequence does not exist in the link evidence graph, the node and the call edge connecting it are marked as the target execution object, and inserted as a new branch into the corresponding position in the link evidence graph. Simultaneously, its observation status is marked as observed, and the evidence source is marked as running link observation, resulting in an updated link evidence graph. If the comparison finds that the last node in the actual execution sequence is not the target operation sink node in the vulnerability hypothesis, the target operation sink node is determined to have not been reached, reducing the confidence of the vulnerability hypothesis, and recording the specific control point information blocking the target operation sink node, resulting in an adjusted vulnerability hypothesis. If the response of the targeted verification result contains Structured Query Language error information and the actual execution sequence has completely traversed the reachable path, the success criterion of the vulnerability hypothesis is satisfied, and the reachable path has been actually executed, increasing the confidence of the vulnerability hypothesis, resulting in an adjusted vulnerability hypothesis. Therefore, by comparing the actual execution sequence with the link evidence graph at the node or edge level, and adding newly discovered target execution objects as new branches to the graph in real time, the link evidence graph has the ability to self-correct based on runtime evidence, evolving from a static snapshot to continuous updates, effectively solving the problem that static analysis cannot cover complex scenarios.

[0074] S2140. Obtain the updated link evidence graph and the iteration status information corresponding to the adjusted vulnerability hypothesis, and judge the iteration status information based on the preset iteration termination condition; wherein, the iteration status information includes the number of processed vulnerability hypotheses, the confidence level of the adjusted vulnerability hypothesis, the coverage status of unobserved candidate branches, and the number of optimization adjustments.

[0075] The iterative state information refers to a set of multi-dimensional quantitative indicators used to describe the current iterative optimization process status. The number of processed vulnerability hypotheses refers to the cumulative number of vulnerability hypotheses that have completed the complete closed-loop process of generating targeted verification tasks, executing verification, and feedback correction in the current security testing process. The adjusted confidence level of the vulnerability hypothesis refers to the latest value of the confidence field in the current vulnerability hypothesis object after one or more targeted verification and feedback corrections. The unobserved candidate branch coverage status refers to the degree to which all candidate branches marked as "unobserved candidates" in the link evidence graph have been reached and verified by the targeted verification task. The number of optimization adjustments refers to the cumulative number of complete closed-loop iterations from generating targeted verification tasks, executing verification, to feedback correction performed against the current vulnerability hypothesis or link evidence graph. The preset iteration termination condition refers to a pre-set set of trigger rules used to determine whether the current security testing process should be terminated and security test results output. For example, the preset iteration termination condition may consist of at least one of the following sub-conditions: the number of processed vulnerability hypotheses reaches a preset number threshold, such as all hypotheses have been processed; the confidence level of the adjusted vulnerability hypothesis reaches a preset confirmation threshold or is lower than a preset exclusion threshold; the coverage status of unobserved candidate branches reaches a preset coverage threshold; and the number of optimization adjustments reaches a preset maximum number of iterations.

[0076] S2150. If the iteration state information satisfies the preset iteration termination condition, then a security test result is generated based on the updated link evidence graph and the adjusted vulnerability hypothesis.

[0077] Specifically, after completing one targeted verification and updating the link evidence graph and adjusting the vulnerability hypothesis confidence, the current iteration state information is obtained. Then, the iteration state information is compared one by one with the preset iteration termination conditions. If the preset iteration termination conditions are met, further verification is terminated. Security test results are generated based on the updated link evidence graph and adjusted vulnerability hypotheses. The judgment conclusions of each hypothesis, the complete topology of observed branches and unobserved candidate branches in the link evidence graph, and all verification evidence are packaged into the security test results output. Thus, by introducing iteration state information, the decision of "whether to continue testing" is upgraded from manual judgment to autonomous system judgment, realizing the agent's autonomous decision-making capability. Furthermore, through the multiple judgment mechanism of preset iteration termination conditions, the system can achieve a dynamic balance between request budget, detection accuracy, and branch coverage.

[0078] The technical solution of this invention involves obtaining interface description information corresponding to a target test requirement and determining the target interface based on the interface description information. A corresponding deployment instance is matched based on the target interface, and the version identifier of the deployment instance is determined based on the container image digest, build number, or version identifier information in environment variables. The target code is then obtained from the code repository based on the version identifier. Next, static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Further, the candidate call chain and the real-time call chain are aligned and fused based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph. Further, the entry node in the link evidence graph is marked as an external input source node, and the database operation node, command execution node, file operation node, template rendering node, and / or sensitive data output node in the link evidence graph are marked as target operation sink nodes. The authentication node, input verification node, output encoding node, and / or parameterization processing node between the external input source node and the target operation sink node are marked as basic control points. Along the data flow edges in the link evidence graph, the data propagation path from the external input source node to the target operation sink node is traced. If a data propagation path exists, it is marked as a reachable path, and all intermediate nodes and corresponding data transformation operations on the reachable path are recorded. Pattern matching is performed on the reachable paths based on a preset link pattern table to determine the risk type corresponding to each path. Evidence gap analysis is performed on each reachable path. Evidence gaps are determined based on the distribution of basic control points on the reachable path, and vulnerability hypotheses are generated based on the risk type, reachable path, and evidence gap. Finally, based on the link constraints in the link evidence graph, parameters to be tested are selected from the vulnerability hypotheses, and a minimum payload set is generated based on the context information of the parameters to be tested and the risk type in the vulnerability hypotheses. The authentication status is determined based on the precondition information in the vulnerability hypotheses, the precondition requests are determined based on the parameter dependencies of the target interface, the success criteria are determined based on the risk type in the vulnerability hypotheses, and the stop conditions are determined based on the authorization boundary information of the target test requirements. A targeted verification task is generated based on the parameters to be tested, the minimum payload set, the authentication status, the precondition requests, the success criteria, and the stop conditions. Perform targeted verification tasks, update the link evidence graph based on the targeted verification results, obtain the updated link evidence graph, and adjust the confidence level of the vulnerability hypothesis based on the targeted verification results, obtaining the adjusted vulnerability hypothesis. Obtain the iteration state information corresponding to the updated link evidence graph and the adjusted vulnerability hypothesis, and judge the iteration state information based on the preset iteration termination condition. If the iteration state information meets the preset iteration termination condition, generate security test results based on the updated link evidence graph and the adjusted vulnerability hypothesis.By merging static candidate call chains with runtime real-time call chains into a link evidence graph containing observed and unobserved candidate branches, and using this graph-driven directed verification and feedback correction closed loop, this technology solves the technical problems in existing technologies where static analysis and dynamic tracing are separated and cannot form a unified evidence base, vulnerability verification lacks precise guidance leading to an explosion in the test search space, and verification results cannot back-correct the initial analysis model, thus failing to form a self-optimizing closed loop. This enables precise contraction of the test search space and system self-evolution, improving the accuracy of vulnerability detection and the reproducibility of conclusions.

[0079] Figure 3The diagram illustrates a security testing process based on link fusion according to an embodiment of the present invention. Specifically, the security testing process based on link fusion includes a test task input module, a code repository connector, a runtime link acquisition module, a link fusion engine, a vulnerability hypothesis generation module, a targeted verification module, a tool orchestration layer, and an evidence association and write-back module. The test task input module receives the Uniform Resource Locator (URL), interface description information, and code version identifier submitted by the user, triggering the entire security testing process. The code repository connector pulls the target code, consistent with the deployment instance version, from the code repository based on the code version identifier. It constructs a method-level call graph through abstract syntax tree parsing, symbol indexing, type inference, and dependency injection information, and parses the framework configuration information. The runtime link acquisition module triggers the target interface in the runtime environment corresponding to the target test requirement, obtaining the real-time call chain generated when the target interface is called. The link fusion engine aligns the candidate call chain generated by the code repository connector with the real-time call chain acquired by the runtime link acquisition module, aligning nodes and call relationships according to the interface identifier of the target interface and the version identifier of the target code, generating a link evidence graph. The link evidence graph includes observed branches and unobserved candidate branches, with nodes and edges associated with evidence source information and confidence information. The vulnerability hypothesis generation module executes the data flow along the links in the link evidence graph. The system is structured as follows: Annotation identifies external input source nodes, dangerous operation sink nodes, and security control points between them. Based on the reachable paths from external input source nodes to dangerous operation sink nodes and evidence gaps, vulnerability hypotheses are generated. The targeted verification module selects parameters to be tested and generates a minimum payload set and request sequence based on the vulnerability hypotheses and link constraints in the link evidence graph, then performs targeted verification. The evidence association and write-back module compares the actual execution sequence in the targeted verification results with the link evidence graph. If a new branch is found, it is added to the link evidence graph. If the target operation sink node is not reached, the confidence of the vulnerability hypothesis is reduced and the blocking control point information is recorded. If the success criteria are met and the reachable path is actually executed, the confidence of the vulnerability hypothesis is increased, forming a closed-loop self-optimization mechanism from static graph building and dynamic verification to feedback correction. The tool orchestration layer maps targeted verification tasks to specific tool calls and collects execution results through model context protocols, hypertext transfer protocol interfaces, or local process calls to scanners, fuzzing tools, and traffic replay devices.

[0080] Figure 4The diagram shows a flowchart of an optional security testing method based on link fusion provided by an embodiment of the present invention. Specifically, the closed-loop process includes: First, binding code version and target interface: obtaining the target interface corresponding to the target test requirement, determining the code version identifier corresponding to the deployment instance of the target interface, and obtaining the target code based on the code version identifier. Next, generating candidate static call chains: locating the controller entry point from the routing definition of the target code based on the entry point identifier of the target interface, traversing downwards from the controller entry point using abstract syntax tree, symbol index, type inference, and dependency injection information to determine the call relationship, and identifying the call nodes corresponding to framework metadata, interceptors, filters, aspects, transaction proxies, and authentication annotations, establishing a call mapping from the business layer to the database access layer, and generating candidate call chains. Further, collecting real-time runtime links: triggering the target interface in the runtime environment, collecting the traces, spans, method probes, and call logs generated when the target interface is called. Further, fusing into a link evidence graph: aligning and fusing the candidate call chains and the real-time call chains according to the interface identifier of the target interface and the version identifier of the target code to generate a link evidence graph. Furthermore, vulnerability hypotheses are generated: Data flow annotation is performed along the links in the link evidence graph to identify external input source nodes, target operation sink nodes, and basic control points. Reachable paths are marked by tracing data propagation paths. Pattern matching is performed based on a pre-defined link pattern table to determine risk types, and evidence gap analysis is conducted for each reachable path to generate vulnerability hypotheses. Further, targeted payloads and request sequences are generated: Parameters to be tested are selected from the vulnerability hypotheses based on link constraints in the link evidence graph. A minimum payload set is generated based on context information and risk types. Authentication status is determined based on precondition information. Precondition requests are determined based on parameter dependencies. Success criteria are determined based on risk types. Stopping conditions are determined based on authorization boundary information, generating targeted verification tasks. Further, verification is executed and evidence is collected: Targeted verification tasks are executed through the tool orchestration layer, collecting Hypertext Transfer Protocol requests or responses, the real-time call chain corresponding to this request, and out-of-band callback signals to generate verification evidence packets. Finally, the link correction and risk confidence are written back: the actual execution sequence in the directed verification results is compared with the link evidence graph. If the target execution object in the actual execution sequence does not exist in the link evidence graph, the target execution object is added as a new branch to the link evidence graph. If the target operation sink node is not reached, the vulnerability hypothesis confidence is reduced and the blocking control point information is recorded. If the success criterion is met and the reachable path is actually executed, the vulnerability hypothesis confidence is increased. If the verification evidence is inconsistent with the candidate chain, branch completion, link reconstruction or termination is triggered. The updated link evidence graph and the iteration status information corresponding to the adjusted vulnerability hypothesis are obtained. The judgment is made based on the preset iteration termination condition. If the termination condition is met, a security test report is output. If not, the process returns to the step "Generate Vulnerability Hypothesis" or the step "Generate Directed Payload and Request Sequence" to continue iterating, forming a complete closed loop of location, verification and correction.

[0081] Example 3 Figure 5 This is a schematic diagram of a security testing device based on link fusion provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes: a data acquisition module 310, a data analysis module 320, a link alignment module 330, a hypothesis generation module 340, and a result generation module 350; The data acquisition module 310 is used to acquire the target interface corresponding to the target test requirement and the target code corresponding to the target interface. Data analysis module 320 is used to perform static analysis on the target code based on the target interface, generate at least one candidate call chain, trigger the target interface in the runtime environment corresponding to the target test requirement, and collect the real-time call chain generated when the target interface is called; The link alignment module 330 is used to align and fuse the candidate call chain and the real-time call chain based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; Assume that the generation module 340 is used to perform data flow analysis on the link evidence graph based on the link execution data flow in the link evidence graph, and determine the vulnerability hypothesis corresponding to the target test requirement; The result generation module 350 is used to generate a targeted verification task based on the vulnerability hypothesis and the link evidence graph, execute the targeted verification task, optimize and adjust the vulnerability hypothesis and the link evidence graph based on the targeted verification results, and determine the security test result corresponding to the target test requirement based on the optimization and adjustment results.

[0082] The technical solution of this invention involves obtaining the target interface and target code corresponding to the target test requirement. Then, static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Further, the candidate call chain and real-time call chain are aligned and fused based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph. The link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information. Further, data flow analysis is performed on the link evidence graph based on the link execution data flow to determine the vulnerability hypothesis corresponding to the target test requirement. Finally, a targeted verification task is generated based on the vulnerability hypothesis and the link evidence graph, the targeted verification task is executed, and the vulnerability hypothesis and the link evidence graph are optimized and adjusted based on the targeted verification results. The security test result corresponding to the target test requirement is determined based on the optimization and adjustment results. By merging static candidate call chains with runtime real-time call chains into a link evidence graph containing observed and unobserved candidate branches, and using this graph-driven directed verification and feedback correction closed loop, this technology solves the technical problems in existing technologies where static analysis and dynamic tracing are separated and cannot form a unified evidence base, vulnerability verification lacks precise guidance leading to an explosion in the test search space, and verification results cannot back-correct the initial analysis model, thus failing to form a self-optimizing closed loop. This enables precise contraction of the test search space and system self-evolution, improving the accuracy of vulnerability detection and the reproducibility of conclusions.

[0083] Optionally, the result generation module 350 can be specifically used to: update the link evidence graph based on the targeted verification results to obtain the updated link evidence graph, and adjust the confidence level of the vulnerability hypothesis based on the targeted verification results to obtain the adjusted vulnerability hypothesis; obtain the iteration status information corresponding to the updated link evidence graph and the adjusted vulnerability hypothesis, and judge the iteration status information based on a preset iteration termination condition; wherein, the iteration status information includes the number of processed vulnerability hypotheses, the confidence level of the adjusted vulnerability hypothesis, the coverage status of unobserved candidate branches, and the number of optimization adjustments; if the iteration status information meets the preset iteration termination condition, then generate a security test result based on the updated link evidence graph and the adjusted vulnerability hypothesis.

[0084] Optionally, the result generation module 350 can be specifically used to: compare the actual execution sequence in the directed verification result with the link evidence graph to obtain a comparison result; wherein, the actual execution sequence includes actual execution nodes or call edges; if the comparison result indicates that the target execution object in the actual execution sequence does not exist in the link evidence graph, then the target execution object is added to the link evidence graph as a new branch to obtain an updated link evidence graph; if the directed verification result indicates that the target operation sink node has not been reached, then the confidence of the vulnerability hypothesis is reduced, and the control point information blocking the target operation sink node is recorded to obtain an adjusted vulnerability hypothesis; if the directed verification result indicates that the success criterion of the vulnerability hypothesis is met and the reachable path is actually executed, then the confidence of the vulnerability hypothesis is increased to obtain an adjusted vulnerability hypothesis.

[0085] Optionally, assuming the generation module 340, it can be specifically used to: mark the entry node in the link evidence graph as an external input source node, and mark the database operation node, command execution node, file operation node, template rendering node, and / or sensitive data output node in the link evidence graph as a target operation sink node; mark the authentication node, input verification node, output encoding node, and / or parameterization processing node between the external input source node and the target operation sink node as basic control points; trace the data propagation path from the external input source node to the target operation sink node along the data flow edge in the link evidence graph, and if the data propagation path exists, mark the data propagation path as a reachable path and record all intermediate nodes and corresponding data conversion operations on the reachable path; perform pattern matching on the reachable path based on a preset link pattern table to determine the risk type corresponding to the reachable path; perform evidence gap analysis on each reachable path, determine the evidence gap according to the distribution of the basic control points on the reachable path, and generate the vulnerability hypothesis according to the risk type, the reachable path, and the evidence gap.

[0086] Optionally, the result generation module 350 can be specifically used to: select test parameters from the vulnerability hypotheses based on the link constraints in the link evidence graph, and generate a minimum payload set based on the context information of the test parameters and the risk types in the vulnerability hypotheses; determine the authentication status based on the precondition information in the vulnerability hypotheses, determine the precondition requests based on the parameter dependencies of the target interface, determine the success criteria based on the risk types in the vulnerability hypotheses, and determine the stop conditions based on the authorization boundary information of the target test requirements; and generate a targeted verification task based on the test parameters, the minimum payload set, the authentication status, the precondition requests, the success criteria, and the stop conditions.

[0087] Optionally, the data analysis module 320 can be specifically used to: locate the controller entry point of the target interface from the routing definition of the target code based on the entry point identifier of the target interface; traverse downwards from the controller entry point using abstract syntax tree, symbol index, type inference, and dependency injection information to determine the call relationship; identify framework metadata, and extract the call nodes corresponding to interceptors, filters, aspects, transaction proxies, and / or authentication annotations from the framework metadata based on the framework type of the framework metadata; establish a call mapping from the business layer to the database access layer based on the call nodes, and generate the at least one candidate call chain based on the call relationship and the call mapping.

[0088] Optionally, the data acquisition module 310 can be used to: acquire interface description information corresponding to the target test requirement, and determine the target interface corresponding to the target test requirement based on the interface description information; match the corresponding deployment instance based on the target interface, and determine the version identifier corresponding to the deployment instance based on the version identifier information in the container image digest, build number or environment variables of the deployment instance; and acquire the target code from the code repository based on the version identifier.

[0089] The security testing device based on link fusion provided in the embodiments of the present invention can execute the security testing method based on link fusion provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0090] Example 4 Figure 6 A schematic diagram of an electronic device 410 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0091] like Figure 6As shown, the electronic device 410 includes at least one processor 420 and a memory, such as a read-only memory 430 or a random access memory 440, communicatively connected to the at least one processor 420. The memory stores computer programs executable by the at least one processor. The processor 420 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 430 or loaded from storage unit 490 into the random access memory 440. The random access memory 440 may also store various programs and data required for the operation of the electronic device 410. The processor 420, read-only memory 430, and random access memory 440 are interconnected via a bus 450. An input / output interface 460 is also connected to the bus 450.

[0092] Multiple components in electronic device 410 are connected to input / output interface 460, including: input unit 470, such as keyboard, mouse, etc.; output unit 480, such as various types of monitors, speakers, etc.; storage unit 490, such as disk, optical disk, etc.; and communication unit 4100, such as network card, modem, wireless transceiver, etc. Communication unit 4100 allows electronic device 410 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0093] Processor 420 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 420 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 420 performs the various methods and processes described above, such as link fusion-based security testing methods.

[0094] The method includes: Obtain the target interface corresponding to the target test requirement and the target code corresponding to the target interface; Static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Based on the interface identifier of the target interface and the version identifier of the target code, the candidate call chain and the real-time call chain are aligned and fused to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; Based on the link execution data flow in the link evidence graph, perform data flow analysis on the link evidence graph to determine the vulnerability hypothesis corresponding to the target test requirement; Based on the vulnerability hypothesis and link evidence graph, a targeted verification task is generated, the targeted verification task is executed, and the vulnerability hypothesis and link evidence graph are optimized and adjusted based on the targeted verification results. Based on the optimization and adjustment results, the security test results corresponding to the target test requirements are determined.

[0095] In some embodiments, the link-fusion-based security testing method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 490. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 410 via read-only memory 430 and / or communication unit 4100. When the computer program is loaded into random access memory 440 and executed by processor 420, one or more steps of the link-fusion-based security testing method described above can be performed. Alternatively, in other embodiments, processor 420 can be configured to perform the link-fusion-based security testing method by any other suitable means (e.g., by means of firmware).

[0096] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), system-on-a-chip (SoCs), complex programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0097] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0099] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube or liquid crystal display monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0100] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0101] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0102] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the link fusion-based security testing method provided in any embodiment of this application. This program product shares the same inventive concept as the link fusion-based security testing method disclosed in the embodiments of this application, and therefore will not be described further here.

[0103] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A security testing method based on link fusion, characterized in that, include: Obtain the target interface corresponding to the target test requirement and the target code corresponding to the target interface; Static analysis is performed on the target code based on the target interface to generate at least one candidate call chain. The target interface is then triggered in the runtime environment corresponding to the target test requirement, and the real-time call chain generated when the target interface is called is collected. Based on the interface identifier of the target interface and the version identifier of the target code, the candidate call chain and the real-time call chain are aligned and fused to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; Based on the link execution data flow in the link evidence graph, perform data flow analysis on the link evidence graph to determine the vulnerability hypothesis corresponding to the target test requirement; Based on the vulnerability hypothesis and link evidence graph, a targeted verification task is generated, the targeted verification task is executed, and the vulnerability hypothesis and link evidence graph are optimized and adjusted based on the targeted verification results. Based on the optimization and adjustment results, the security test results corresponding to the target test requirements are determined.

2. The method according to claim 1, characterized in that, The optimization and adjustment of the vulnerability hypothesis and link evidence graph based on the targeted verification results, and the determination of the security test results corresponding to the target test requirements based on the optimization and adjustment results, include: The link evidence graph is updated based on the targeted verification results to obtain the updated link evidence graph. The confidence level of the vulnerability hypothesis is adjusted based on the targeted verification results to obtain the adjusted vulnerability hypothesis. The updated link evidence graph and the iteration status information corresponding to the adjusted vulnerability hypothesis are obtained, and the iteration status information is judged based on a preset iteration termination condition; wherein, the iteration status information includes the number of processed vulnerability hypotheses, the confidence level of the adjusted vulnerability hypothesis, the coverage status of unobserved candidate branches, and the number of optimization adjustments; If the iteration status information satisfies the preset iteration termination condition, then a security test result is generated based on the updated link evidence graph and the adjusted vulnerability hypothesis.

3. The method according to claim 2, characterized in that, The process of updating the link evidence graph based on the targeted verification results to obtain the updated link evidence graph, and adjusting the confidence level of the vulnerability hypothesis based on the targeted verification results to obtain the adjusted vulnerability hypothesis, includes: The actual execution sequence in the targeted verification result is compared with the link evidence graph to obtain the comparison result; wherein, the actual execution sequence includes actual execution nodes or call edges; If the comparison result indicates that the target execution object in the actual execution sequence does not exist in the link evidence graph, then the target execution object is added to the link evidence graph as a new branch to obtain an updated link evidence graph. If the targeted verification result indicates that the target operation hub node has not been reached, the confidence level of the vulnerability hypothesis is reduced, and the control point information that blocks the target operation hub node is recorded to obtain the adjusted vulnerability hypothesis. If the targeted verification result satisfies the success criterion of the vulnerability hypothesis and the reachable path is actually executed, then the confidence level of the vulnerability hypothesis is increased, resulting in an adjusted vulnerability hypothesis.

4. The method according to claim 1, characterized in that, The step of performing data flow analysis on the link evidence graph based on the link execution data flow in the link evidence graph to determine the vulnerability hypothesis corresponding to the target testing requirement includes: Mark the entry node in the link evidence graph as an external input source node, and mark the database operation node, command execution node, file operation node, template rendering node and / or sensitive data output node in the link evidence graph as a target operation sink node; Mark the authentication node, input verification node, output encoding node and / or parameterization processing node between the external input source node and the target operation sink node as the basic control point; Along the data flow edge in the link evidence graph, trace the data propagation path from the external input source node to the target operation sink node. If the data propagation path exists, mark the data propagation path as a reachable path and record all intermediate nodes and corresponding data transformation operations on the reachable path. Based on a preset link pattern table, pattern matching is performed on the reachable path to determine the risk type corresponding to the reachable path; For each reachable path, an evidence gap analysis is performed. Evidence gaps are determined based on the distribution of the basic control points on the reachable path. Vulnerability hypotheses are generated based on the risk type, the reachable path, and the evidence gap.

5. The method according to claim 1, characterized in that, The process of generating a targeted verification task based on the vulnerability hypothesis and the link evidence graph includes: Based on the link constraints in the link evidence graph, parameters to be tested are selected from the vulnerability assumptions, and a minimum load set is generated based on the context information of the parameters to be tested and the risk type in the vulnerability assumptions. The authentication status is determined based on the preconditions in the vulnerability hypothesis, the preconditions are determined based on the parameter dependencies of the target interface, the success criteria are determined based on the risk type in the vulnerability hypothesis, and the stop conditions are determined based on the authorization boundary information of the target test requirements. A targeted verification task is generated based on the parameters to be tested, the minimum load set, the authentication status, the prerequisite request, the success criterion, and the stop condition.

6. The method according to claim 1, characterized in that, The step of performing static analysis on the target code based on the target interface to generate at least one candidate call chain includes: The controller entry point of the target interface is located from the routing definition of the target code based on the entry identifier of the target interface; The call relationships are determined by traversing downwards from the controller entry point using abstract syntax tree, symbol index, type inference, and dependency injection information. Identify the framework metadata, and extract the call nodes corresponding to interceptors, filters, aspects, transaction proxies and / or authentication annotations from the framework metadata based on the framework type of the framework metadata; Based on the calling node, a call mapping from the business layer to the database access layer is established, and based on the call relationship and the call mapping, at least one candidate call chain is generated.

7. The method according to claim 1, characterized in that, The process of obtaining the target interface corresponding to the target test requirement and the target code corresponding to the target interface includes: Obtain the interface description information corresponding to the target test requirement, and determine the target interface corresponding to the target test requirement based on the interface description information; Based on the target interface, a corresponding deployment instance is matched, and based on the container image digest, build number, or version identifier information in the environment variables of the deployment instance, the version identifier corresponding to the deployment instance is determined, and the target code is obtained from the code repository based on the version identifier.

8. A security testing device based on link fusion, characterized in that, include: The data acquisition module is used to acquire the target interface corresponding to the target test requirement and the target code corresponding to the target interface; The data analysis module is used to perform static analysis on the target code based on the target interface, generate at least one candidate call chain, trigger the target interface in the runtime environment corresponding to the target test requirement, and collect the real-time call chain generated when the target interface is called. The link alignment module is used to align and fuse the candidate call chain and the real-time call chain based on the interface identifier of the target interface and the version identifier of the target code to obtain a link evidence graph; wherein, the link evidence graph includes observed branches and unobserved candidate branches, and the nodes and / or edges in the link evidence graph are associated with evidence source information and confidence information; The hypothesis generation module is used to perform data flow analysis on the link evidence graph based on the link execution data flow in the link evidence graph, and determine the vulnerability hypothesis corresponding to the target test requirement. The result generation module is used to generate a targeted verification task based on the vulnerability hypothesis and the link evidence graph, execute the targeted verification task, optimize and adjust the vulnerability hypothesis and the link evidence graph based on the targeted verification results, and determine the security test result corresponding to the target test requirement based on the optimization and adjustment results.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the link fusion-based security testing method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the link-fusion-based security testing method according to any one of claims 1-7.

Images