Risk detection method and system

Abstract

The embodiment of the invention provides a risk detection method and system. According to the method, an HOP execution framework obtains a programmed analysis process composed of a plurality of execution steps, and the programmed analysis process is started and executed. When a target analysis step is encountered in the execution process, the HOP execution framework calls the large language model for analysis, and an analysis result is obtained. Then, the HOP execution framework verifies the analysis result through a preset programmed verification process, so as to determine whether the programmed analysis process continues to be executed or the programmed analysis process is executed after the analysis result is adjusted according to the verification result until all the programmed analysis processes are executed and an execution result is obtained; and finally, the HOP execution framework generates a risk detection report corresponding to the risk detection task based on an execution result.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and in particular to a risk detection method and system. Background Technology

[0002] As software systems, network infrastructure, and workflows become increasingly digitized and complex, the demand for risk detection regarding system security, configuration compliance, and logical reliability is growing. Traditional detection methods typically rely on predefined rule sets or pattern matching, which face challenges in adaptability and analytical depth when dealing with novel risk patterns, unstructured data, or complex logical relationships.

[0003] In recent years, large language models have demonstrated their application potential in various fields such as code review, log analysis, and security intelligence extraction due to their powerful semantic understanding and content generation capabilities. However, applying large language models to risk detection processes also faces some problems and challenges. For example, large language models may encounter illusion problems during analysis, generating conclusions that deviate from actual logic or facts. Alternatively, when handling complex analysis tasks with long chains and multiple steps, large language models may forget key steps or introduce logical errors, leading to deviations in the entire analysis path or incorrect conclusions, thus affecting the reliability and accuracy of risk detection. Therefore, how to effectively integrate the intelligent analysis advantages of large language models to provide a more efficient and reliable risk detection solution has become an urgent problem to be solved.

[0004] The information in the background section is merely information known only to the inventor and does not imply that such information had entered the public domain before the date of this application, nor does it imply that it can be considered prior art in this disclosure. Summary of the Invention

[0005] This specification provides a risk detection method and system that can be applied to automated risk detection scenarios where the reliability, security, and accuracy of execution need to be guaranteed.

[0006] Firstly, this specification provides a risk detection method applied to the HOP execution framework. The method includes: obtaining a procedural analysis process corresponding to a risk detection task, wherein the procedural analysis process includes multiple execution steps, wherein the multiple execution steps include one or more target analysis steps; initiating the execution of the multiple execution steps, and when the target analysis step is executed, calling a large language model to analyze the target analysis step to obtain an analysis result; verifying the analysis result based on a preset procedural verification process to obtain a verification result; continuing or adjusting the execution of the procedural analysis process according to the verification result until the entire procedural analysis process is executed to obtain an execution result; and generating a risk detection report corresponding to the risk detection task based on the execution result.

[0007] In some embodiments, verifying the analysis results based on a preset procedural verification process to obtain a verification result includes: determining one or more target verification components in a preset verification component library according to the context information of the target analysis step, wherein the context information includes: relevant information of the analysis results; and calling the target verification component to verify the analysis results to obtain a verification result.

[0008] In some embodiments, the relevant information of the analysis results includes one or more of the following: risk type, analysis results, confidence level of the analysis results, analysis path, and information on the tools called during the analysis process.

[0009] In some embodiments, determining one or more target verification components in a preset verification component library based on the context information of the target analysis step includes: matching in a preset verification rule table based on the context information of the target analysis step to determine whether there is a verification condition corresponding to the context information; the verification rule table includes the correspondence between verification conditions and verification components; if a corresponding verification condition exists, then at least one verification component corresponding to the verification condition is determined as the target verification component; and if no corresponding verification condition is found, then at least one target verification component is determined in the verification component library based on the context information using the large language model.

[0010] In some embodiments, the components in the verification component library include one or more of the following types: deterministic verification, reverse verification, and forward cross-verification.

[0011] In some embodiments, the deterministic verification type includes one or more of the following components: format and structure verification component, link integrity verification component, and data flow verification component; the reverse verification type includes one or more of the following components: large model counter-proof component and dynamic analysis component; the forward cross-verification verification type includes one or more of the following components: SOP compliance verification component and multi-model voting component.

[0012] In some embodiments, the step of continuing or adjusting the execution of the procedural analysis process based on the verification result until the entire procedural analysis process is executed and an execution result is obtained includes: if the verification result indicates that the process passes, then continuing to execute the subsequent execution steps of the procedural analysis process based on the analysis result until the entire procedural analysis process is executed and an execution result is obtained; if the verification result indicates that the process fails, then adjusting the analysis result based on the verification result until the adjusted analysis result passes the verification; and continuing to execute the subsequent execution steps of the procedural analysis process based on the analysis result until the entire procedural analysis process is executed and an execution result is obtained.

[0013] In some embodiments, adjusting the analysis result based on the verification result includes: generating a correction instruction containing correction information, and re-invoking the large language model to analyze the target analysis step based on the correction instruction to obtain the analysis result; or, the HOP execution framework adjusts the analysis result; or, the context information of the target analysis step is sent to the operation and maintenance terminal so that the operation and maintenance terminal adjusts the analysis result based on the context information, wherein the context information includes: relevant information of the analysis result.

[0014] In some embodiments, obtaining the procedural analysis process corresponding to the risk detection task includes: obtaining a standard operating procedure template corresponding to the task type in a preset knowledge graph based on the task type of the risk detection task; and determining an executable procedural analysis process corresponding to the risk detection task based on the standard operating procedure template and the risk detection task.

[0015] In some embodiments, the analysis objects of the target analysis step include one or more of the following: source code fragments to be detected, configuration information, application programming interface definitions, and function call chains.

[0016] Secondly, this specification also provides a risk detection system, including at least one storage medium and at least one processor, wherein the at least one storage medium stores at least one instruction set for risk detection; the at least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method described in any of the first aspects above according to the instructions of the at least one instruction set.

[0017] As can be seen from the above technical solutions, the risk detection method and system provided in this specification utilize the HOP execution framework to acquire and execute a procedural analysis process consisting of multiple execution steps. When a target analysis step is encountered during execution, the HOP execution framework calls a large language model for analysis and obtains the analysis results. Subsequently, the HOP execution framework verifies the analysis results through a pre-set procedural verification process to determine whether to continue executing the procedural analysis process or adjust the analysis results before executing the procedural analysis process again, until the entire procedural analysis process is completed and the execution results are obtained. Finally, the HOP execution framework generates a risk detection report corresponding to the risk detection task based on the execution results. This detection method ensures the standardization and completeness of the analysis process by acquiring an executable procedural analysis process. During the execution of the procedural analysis process, the large language model is only called when executing the target analysis task, limiting the capabilities of the large language model to specific semantic understanding and reasoning tasks. Furthermore, after obtaining the analysis results output by the large language model, the HOP execution framework verifies the results and dynamically adjusts the procedural analysis process based on the verification results, thus constructing an execution-verification-execution / correction process. By verifying the analysis results through a procedural verification process, the HOP execution framework avoids potential illusions and logical errors that may arise from the large language model, thereby improving the reliability of risk detection.

[0018] Other functions of the risk detection methods and systems provided in this specification will be partially listed in the following description. The inventive aspects of the risk detection methods and systems provided in this specification can be fully understood through practice or use of the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this specification, 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 this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram illustrating an application scenario of a risk detection system provided according to an embodiment of this specification is shown. Figure 2 A schematic diagram of the hardware structure of a computing device provided according to some embodiments of this specification is shown; Figure 3 A schematic flowchart of a risk detection method according to an embodiment of this specification is shown; Figure 4A schematic diagram of the overall process of a risk detection method according to another embodiment of this application is shown; and Figure 5 A flowchart illustrating an analysis result verification method according to another embodiment of this specification is shown. Detailed Implementation

[0021] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0022] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.

[0023] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0024] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0025] In this specification, "X includes at least one of A, B, or C" means that X includes at least A, or X includes at least B, or X includes at least C. That is, X may include only one of A, B, and C, or any combination of A, B, and C, as well as other possible content / elements. The arbitrary combination of A, B, and C can be A, B, C, AB, AC, BC, or ABC.

[0026] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0027] It should be noted that the user data obtained in this manual is authorized by the user and does not involve user privacy.

[0028] For ease of description, the terms that will appear later in this manual will be explained first.

[0029] High-Order Program (HOP) Execution Framework: A framework for orchestrating and executing standardized, programmable workflows. In this specification, the HOP framework is responsible for driving the entire procedural analysis process of risk detection, managing dependencies and transitions between steps, and coordinating the execution of large language model calls and verification components.

[0030] Large Language Model (LLM): Commonly used in the field of artificial intelligence in Natural Language Processing (NLP), it specifically refers to large machine learning models with a large number of parameters and computational resources. Large language models are named for their huge number of parameters and complex network structures. They have powerful feature representation and feature understanding capabilities, and can better capture patterns and regularities in data when dealing with complex tasks. They are designed and trained to better understand and generate natural language.

[0031] Standard Operating Procedure (SOP): In a specific field (such as security auditing or financial risk control), a proven set of standardized steps and checklists for completing a complex and critical task.

[0032] Programmed analysis process: This refers to transforming a risk detection SOP into structured code logic or workflow that can be executed automatically by a computer. This process consists of a series of deterministic execution steps, clearly defining the goal, inputs, outputs, and interrelationships between each step.

[0033] Verification Component Library: A collection of various types of pluggable verification tools or rules. Each verification component encapsulates a reusable program module with specific verification logic, designed to perform specific types of verification tasks, such as format checking, logical disproving, and multi-model cross-validation.

[0034] The risk detection methods and systems provided in this manual are applicable to scenarios requiring automated risk detection, such as: financial transaction anti-fraud, intelligent code security auditing, system configuration compliance, process vulnerabilities, and network interface (API) risks, requiring automated and intelligent detection. Examples include: code auditing of financial systems, configuration risk scanning of cloud infrastructure, supply chain software component analysis, and protocol security testing of industrial control systems.

[0035] However, risk detection solutions in related technologies generally rely entirely on preset detection rules, resulting in insufficient flexibility and an inability to handle novel or complex vulnerabilities. Alternatively, these solutions may directly depend on large language models or invoke them through preset prompts. However, when performing complex analysis tasks with long chains and multiple steps, large language models may forget a crucial step or experience illusions at a particular step, leading to deviations in the entire analysis path or incorrect conclusions. This results in unreliable detection results and issues of false positives and false negatives.

[0036] To address this, this specification provides a risk detection method that integrates a large language model into the HOP procedural execution framework. The entire risk detection process is controlled by this defined, procedural HOP execution framework. When the HOP execution framework reaches a target analysis step requiring natural language understanding, fuzzy concept matching, or complex logical reasoning, it invokes the large language model to analyze the target analysis step and obtain the analysis results. The HOP execution framework does not directly use the analysis results returned by the large language model; instead, it verifies the analysis results based on a pre-defined procedural verification process. This approach maintains the intelligence of the analysis while improving the controllability, interpretability, and reliability of the entire detection process.

[0037] It should be noted that the above description of application scenarios is only one of the many use cases provided in this specification. Those skilled in the art should understand that when the risk detection methods and systems provided in this specification are applied to other use cases, their implementation methods and technical effects are similar.

[0038] Figure 1 A schematic diagram of an application scenario 100 of a risk detection system 130 provided according to an embodiment of this specification is shown.

[0039] like Figure 1As shown, this application scenario may include a risk detection system 130. The risk detection system can be a system that provides automated risk detection services. The risk detection system 130 can obtain the programmed analysis flow corresponding to the risk detection task, perform risk detection on the risk detection task based on the programmed analysis flow, and generate a corresponding risk detection report. The risk detection system 130 executes each step sequentially according to the order of the programmed analysis flow.

[0040] When the target analysis step is executed, the risk detection system 130 calls the large language model to analyze the target analysis step, obtains the analysis results, and verifies the analysis results based on the procedural verification process to obtain the verification results. Based on the verification results, the system continues or adjusts the execution of subsequent procedural analysis processes.

[0041] The risk detection system 130 is a computing system with a certain computing capability. The risk detection system 130 can correspond to a single computing device or a computing cluster composed of multiple computing devices. The risk detection system 130 can be deployed locally or remotely. In this case, the physical device corresponding to the risk detection system 130 can store data or instructions for executing the anomaly analysis methods described in this specification, and can execute or be used to execute the data or instructions.

[0042] In some embodiments, the physical device corresponding to the risk detection system 130 may include a hardware device with data information processing capabilities and the necessary programs required to drive the hardware device to work.

[0043] Figure 2 A schematic diagram of the hardware structure of a computing device 200 according to some embodiments of this specification is shown. This computing device 200 can be used as... Figure 1 The risk detection system 130 is described in some embodiments. When the risk detection system 130 employs a device cluster, the computing device 200 can be any one of the devices in the risk detection system 130.

[0044] like Figure 2 As shown, the computing device 200 includes at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 200 may further include an internal communication bus 210. In some embodiments, the computing device 200 may further include a communication port 250. In some embodiments, the computing device 200 may further include I / O components 260.

[0045] The internal communication bus 210 can connect different system components, including storage medium 230 and processor 220. I / O component 260 supports input / output between computing device 200 and other components.

[0046] Communication port 250 is used for data communication between computing device 200 and the outside world. For example, computing device 200 can connect to a network through communication port 250.

[0047] Storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set is computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the risk detection methods provided in this specification.

[0048] At least one processor 220 is communicatively connected to at least one storage medium 230 via an internal communication bus 210. The at least one processor 220 is used to execute at least one instruction set. When the system 130 is running, the at least one processor 220 reads at least one instruction set and executes the risk detection method provided in this specification according to the instructions of the at least one instruction set.

[0049] Processor 220 can execute all the steps included in the risk detection method. Processor 220 can be in the form of one or more processors. Processor 220 can issue execution instructions. Processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0050] For illustrative purposes only, only one processor 220 is shown in the accompanying drawings of the computing device 200. However, it should be noted that the computing device 200 may also include multiple processors. Therefore, the operation and / or method steps disclosed herein may be executed by a single processor or by multiple processors in combination, as described herein. For example, if processor 220 of the computing device 200 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 220 (e.g., a first processor executes step A, a second processor executes step B, or the first and second processors jointly execute steps A and B).

[0051] Figure 3 A flowchart illustrating a risk detection method according to an embodiment of this specification is shown; this risk detection method P300 can be executed by system 130. Figure 3 As shown, the method P300 provided in this specification may include S310-S390, wherein: S310: Obtain the procedural analysis process corresponding to the risk detection task. The procedural analysis process includes multiple execution steps, among which one or more target analysis steps are included.

[0052] The risk detection task can be triggered in the following ways: by user initiative, by event hook at code submission node, by timed triggering, or by risk alarm event after a risk event occurs. It should be understood that the above triggering methods are merely illustrative examples, and the specific triggering method for risk detection tasks can be flexibly adjusted according to the scenario and user needs, and is not limited to the methods given in the above embodiments.

[0053] In some embodiments, the procedural analysis process is not a simple set of linear instructions, but a structured procedural analysis process that can be parsed and driven by the HOP execution framework. This procedural analysis process, based on predefined or dynamically generated workflow specifications, explicitly defines the complete path required to complete the risk detection task. The procedural analysis process consists of multiple sequential or parallel execution steps, which together encode the necessary sequence of operations for the risk detection task. Among these, the target analysis step is the analysis step that relies on a large language model for semantic understanding, logical reasoning, or concept matching.

[0054] For example, the objects analyzed in the target analysis step may include one or more of the following: source code fragments to be detected, configuration information, application programming interface definitions, and function call chains.

[0055] The source code snippets to be inspected are extracted from software projects and are portions of program code that need to be reviewed. Inspecting these source code snippets can uncover code-layer security vulnerabilities (such as injection and memory corruption) and logical flaws. Configuration information encompasses various configuration files for applications, middleware, or infrastructure settings. Analyzing this information aims to identify security risks caused by improper configuration (such as excessive privileges, plaintext storage of sensitive information, or service exposure). Application programming interfaces (APIs) generally describe the service endpoints, parameters, and interaction methods provided by the system. Analyzing APIs aims to uncover security flaws at the interface design level (such as unprotected sensitive interfaces or missing parameter validation). Function call chains refer to a series of function call paths obtained through static analysis, from user input points to critical security operations (such as database access and file operations). Analyzing function call chains aims to trace whether security controls are effectively implemented or potentially bypassed during data flow.

[0056] In some embodiments, the risk detection system can obtain a standard operating procedure (SOP) template corresponding to a task type from a preset knowledge graph based on the task type of the risk detection task. Subsequently, the risk detection system determines the executable procedural analysis flow corresponding to the risk detection task based on the SOP template and the risk detection task.

[0057] The task type can be specified by the user or automatically categorized by the HOP execution framework through natural language understanding of the task description information. A pre-defined knowledge graph is stored in a domain knowledge base, which structurally links different risk types, their corresponding standard operating procedure (SOP) templates, related code patterns, vulnerability characteristics, verification rules, etc. Each SOP template describes the general steps for analyzing a type of risk, the logical relationships between the steps, and the input / output specifications for each step.

[0058] After obtaining the SOP template, the HOP execution framework needs to instantiate the SOP template into an executable form specific to the current risk detection task, based on relevant information. For example, the general steps included in an SOP template for "horizontal privilege vulnerability detection" might include: identifying all operation interfaces involving resource identifiers; tracing the data source of resource identifiers in each interface; analyzing whether there is verification logic for resource access permissions in the interface; and evaluating the effectiveness of the verification logic. The HOP execution framework will then bind the abstract steps in the SOP template to specific code files, functions, and variables based on the specific detection object of the current risk detection task (e.g., analyzing a specific Java code repository), generating an executable programmatic analysis flow that includes specific file paths, function names, and tool call parameters.

[0059] For example, taking the scenario of automating the audit of horizontal privilege vulnerabilities in an application as an example, when an operations and maintenance personnel initiates a task to audit the privileges of an order module on a platform, the risk detection system will receive this task. The risk detection system first identifies the task type as "horizontal privilege vulnerability detection." Then, the risk detection system calls the HOP execution framework to retrieve the corresponding standard operating procedure (SOP) template from a pre-defined knowledge graph based on the risk type. This SOP template is a programmatic and executable SOP. For example, an SOP for horizontal privilege detection might include four analysis processes: "identity controllability analysis," "data operation point location," "resource sensitivity determination," and "security verification function evaluation."

[0060] In the above embodiments, the programmatic analysis process is the result of instantiating the aforementioned SOP template. During execution, each analysis process may contain multiple execution steps, most of which are deterministic operations that can be completed by the HOP framework itself or by calling the toolchain, such as: "reading the order query API interface definition," "extracting resource ID patterns from the URL path," "locating the core service function for processing order queries," and "retrieving permission verification calls within the function," etc. Among these, one or more steps, referred to as target analysis steps, cannot be completed simply through regular expression matching or static pattern scanning. They require a deep understanding of code semantics and logic, or complex reasoning. Executing these steps relies on the cognitive capabilities of a large language model. For example, the steps of "locating the core service function for processing order queries" and "evaluating whether the found permission verification function is valid" require understanding code semantics and judging the function's functionality and security attributes.

[0061] In some embodiments, the analysis objects of the target analysis step may include one or more of the following: source code fragments to be detected, configuration file content, application programming interface (API) definitions, function call chain data, etc. The HOP execution framework will explicitly identify which steps are target analysis steps in the programmatic analysis flow.

[0062] The aforementioned method of obtaining the procedural analysis workflow ensures that risk detection is based on validated analysis paths, rather than potentially incomplete or flawed paths temporarily planned by a large language model, thus guaranteeing the standardization and comprehensiveness of the analysis process from the outset. Furthermore, the procedural analysis workflow makes the entire risk detection process deterministic, repeatable, and auditable. Moreover, the method of deriving the procedural verification workflow from standard operating procedure (SOP) templates allows a unified SOP template to be quickly adapted to different specific application scenarios, improving the reusability of the SOP template.

[0063] S330: Initiates the execution of multiple execution steps. When the target analysis step is executed, the large language model is called to analyze the target analysis step and obtain the analysis results.

[0064] In some embodiments, the HOP execution framework executes each step of the programmatic analysis flow sequentially. During execution, the HOP execution framework itself is responsible for advancing the analysis flow, transferring data between analysis steps, and scheduling the toolchain. For non-target analysis steps, the risk detection framework may directly invoke the toolchain (e.g., code scanning tools, configuration readers) to complete the task.

[0065] When the target analysis step is reached, the HOP execution framework collects the input data required for this step, such as the code snippet to be analyzed, the current analysis status, intermediate execution results from previous steps, and relevant configuration information. The HOP framework integrates this input data with the specific analysis requirements to construct a prompt word. Subsequently, the HOP framework calls a large language model through a pre-defined interface, inputting the prompt word to enable the model to understand, reason, and analyze, and then obtains the analysis results returned by the large language model. Upon receiving these analysis results, the HOP framework uses them as an intermediate result in the procedural verification process, providing input for subsequent execution steps.

[0066] The above analysis method clarifies which analysis steps need to be executed by the large language model and which execution steps need to be executed by deterministic tools through a procedural analysis process, thus achieving an effective combination of intelligent and deterministic tools.

[0067] S350: Verify the analysis results based on a pre-defined procedural verification process to obtain the verification results.

[0068] To avoid the problem of unreliable analysis results from large language models leading to errors in subsequent analysis steps, the method provided in this manual verifies the analysis results of the large language model after obtaining them.

[0069] In some embodiments, the risk detection system can determine one or more target verification components from a preset verification component library based on the context information of the target analysis step. The context information includes relevant information about the analysis results. Then, the risk detection system calls the target verification component to verify the analysis results and obtain the verification results.

[0070] The risk detection system, when analyzing the results, first extracts contextual information from the target analysis steps and relevant information from the analysis results. Based on this information, it determines which target verification components need to be invoked to verify the analysis results. During verification, the HOP execution framework invokes the target verification components sequentially or in parallel. Each verification component is an independent execution unit that receives the analysis results from the large language model and related context as input, executes its internally encapsulated specific verification logic, and outputs a verification result. The verification result is typically a structured judgment, containing a verification conclusion and a reason, such as "Pass," "Fail, reason: no taint propagation was found in the data flow analysis," or "Fail, reason: the agent found a feasible bypass path." Alternatively, the verification result may also include correction suggestions or other more detailed data.

[0071] For example, the relevant information in the analysis results includes one or more of the following: risk type, analysis results, confidence level of the analysis results, analysis path, and information on the tools used in the analysis process.

[0072] In some embodiments, the risk detection system compares the context information corresponding to the target analysis step and the relevant information of the analysis results with each verification component in the verification component library based on the decision logic of the elements and the result (e.g., a preset rule matching engine or a lightweight selector model). This comparison includes, for example, comparing the verification function or triggering conditions of each verification component. Each verification component in the verification component library encapsulates a preset, automated verification capability. The risk detection system selects one or more components from the verification component library to verify potential problems in the current target analysis step (e.g., factual errors, logical contradictions, or formatting issues), and identifies these as the target verification components for this verification.

[0073] Subsequently, the risk detection system calls the aforementioned target verification components through a preset interface. Each target verification component independently performs a verification process on the analysis results and returns a verification sub-result. The risk detection system then aggregates these sub-results to obtain a verification result specific to the target analysis results.

[0074] In the above detection method, the risk detection system dynamically determines the target verification component corresponding to the target analysis step in the verification component library based on the context information corresponding to the target analysis step and the relevant information of the analysis results. This avoids the limitations of using a single or fixed verification component and improves the pertinence of the verification and the reliability of the verification results.

[0075] S370: Continue or adjust the execution of the procedural analysis process based on the verification results until the entire procedural analysis process is executed and the execution results are obtained.

[0076] After obtaining the verification results, the risk detection system will make subsequent process control decisions based on the verification results.

[0077] In some embodiments, if the verification result indicates that the verification has passed, the risk detection system will determine that the analysis result of the target analysis step is reliable and has a high degree of confidence. The HOP execution framework uses the analysis result as the output of the target analysis step, and continues to execute the subsequent execution steps of the procedural analysis process based on the analysis result until the entire procedural analysis process is executed and the execution result of the procedural analysis process is obtained.

[0078] If the verification result indicates failure, the risk detection system adjusts the analysis result based on the verification result until the adjusted analysis result passes verification. Then, the risk detection system continues to execute the subsequent steps of the procedural analysis process based on the analysis result until the entire procedural analysis process is executed, yielding the execution result of the procedural analysis process.

[0079] The above approach enables adaptive and error-correcting capabilities in the risk detection process, ensuring that temporary errors or uncertainties in the target analysis steps do not lead to interruptions in the entire procedural analysis process or invalid results. This enhances the robustness of the risk detection system while guaranteeing the overall quality of the final execution results.

[0080] In some embodiments, the adjustment methods may include: retrying and modifying the large language model, adjusting the HOP execution framework itself, or adjusting through the intervention of the operation and maintenance terminal.

[0081] During the retry and modification process of the large language model, the HOP execution framework generates a correction instruction containing corrective information based on the specific reasons for the failure indicated by the verification results. The correction instruction typically includes the specific reasons for the failure given by the target verification component, such as "You missed analyzing the else branch" or "The data field you judged as sensitive is not actually sensitive personal information according to Article X of the GDPR." Subsequently, the HOP execution framework re-invokes the large language model to analyze the target analysis step based on the correction instruction, obtaining the analysis results. This analysis process can be iterated until the analysis results output by the large language model pass verification or the maximum number of retries is reached.

[0082] For simple, well-defined errors, the HOP execution framework can directly adjust the execution results. For example, if the validation result only indicates that the output format of the analysis results does not conform to the JSON data structure specification, the HOP execution framework can attempt to automatically correct field names or types according to the data structure specification. Alternatively, if the validation result indicates a failure, and the target validation component includes a data flow validation component that provides an accurate corrected data flow diagram, the HOP execution framework can directly use the corrected data flow diagram to adjust the context related to the data flow diagram in the analysis results of the large language model.

[0083] In some embodiments, if the analysis results still fail verification after multiple adjustments, or if the verification component determines that the analysis results are complex or have a high risk level, the HOP execution framework can send the context information of the target analysis step (including the original risk detection task, the procedural analysis process, the analysis results of the large language model, detailed information on verification failures, etc.) to the operations and maintenance terminal, so that the operations and maintenance terminal can adjust the analysis results based on the context information. The context information includes relevant information about the analysis results.

[0084] For example, when the verification result indicates that the analysis result has failed the verification, the risk detection system can automatically generate a modification instruction. S390: Based on the execution results, generate a risk detection report corresponding to the risk detection task.

[0085] After the entire procedural analysis process is completed, the HOP framework summarizes, organizes, and formats the results of each execution step to generate a risk detection report corresponding to the risk detection task.

[0086] In some embodiments, the HOP execution framework organizes key information from the execution results according to a preset report template. For example, the preset report template instructs the risk detection report to list all confirmed risk points and related information for each risk point. The related information for each risk point may include: risk type, risk location, risk description, analysis process of the large language model, type of verification passed and verification conclusion, and risk remediation suggestions. To improve the transparency of the risk detection report, the report needs to summarize "suspected risks" discovered during the analysis process but excluded after verification, and explain the reasons for exclusion. It should be understood that the above embodiments are merely illustrative, and the content included in a specific risk detection report can be flexibly adjusted according to user needs and is not limited to the embodiments described above.

[0087] The risk detection report generated in the above manner transforms the complex, multi-step deterministic execution process within the HOP execution framework into an output that is understandable and actionable for the user. Furthermore, the content of the risk detection report is derived from verified, high-confidence data, thus enhancing its comprehensiveness and reliability.

[0088] Figure 4 A schematic diagram of the overall process of a risk detection method according to another embodiment of this application is shown, such as... Figure 4 As shown, the risk detection method can be viewed as four deterministic phases under the control of the HOP execution framework: planning phase, execution phase, verification phase, and summary phase.

[0089] In the planning phase, the HOP execution framework receives risk detection tasks and retrieves standard operating procedure (SOP) templates for those tasks from a pre-defined knowledge graph based on their task types. Then, it determines the executable, procedural analysis workflow corresponding to the risk detection task based on the SOP templates. This planning phase ensures that the analysis path of the procedural analysis workflow is determined based on the pre-defined knowledge graph, resulting in a targeted and procedural analysis path.

[0090] During the execution phase, the HOP execution framework executes each analysis step sequentially according to the programmatic analysis workflow. For routine analysis steps, the HOP execution framework directly calls the toolchain corresponding to the current analysis step to complete the step's execution, obtains the corresponding execution result, and continues to execute subsequent analysis steps based on the execution result. For target analysis steps, the HOP execution framework calls the large language model for analysis to obtain the corresponding analysis result. At this time, the analysis result generated by the large language model may be inaccurate due to illusion problems or other issues.

[0091] The Reflect phase is crucial for eliminating illusions and ensuring the reliability of the large language model analysis results. The HOP execution framework verifies the analysis results using pre-defined, procedural verification results to obtain a final verification result. During verification, the HOP framework utilizes a verification component library to perform multi-dimensional verification of the analysis results output by the large language model, determining the final verification result based on the verification results for each dimension. Subsequently, the HOP framework continues or adjusts the execution review of the procedural analysis process based on the verification results. For example, it may adopt the analysis results when verification passes, or revise or report the analysis results when verification fails, thereby obtaining a reliable execution result.

[0092] In the conclusion phase, the HOP execution framework integrates and organizes the results of the routine analysis steps and the analysis results of the verified target analysis steps to obtain the risk detection report corresponding to the risk detection task.

[0093] The above four stages make the analysis process of the risk detection method procedural. When it is necessary to call the large language model to analyze the target, the analysis results need to be further verified. This solves the illusion problem and inconsistency problem that may exist in the large language model, and ensures the accuracy and consistency of risk detection.

[0094] In summary, in the risk detection method P300 and system 130 provided in this specification, the HOP execution framework acquires and executes a procedural analysis process consisting of multiple execution steps. When a target analysis step is encountered during execution, the HOP execution framework calls the large language model for analysis and obtains the analysis results. Subsequently, the HOP execution framework verifies the analysis results through a pre-set procedural verification process to determine whether to continue executing the procedural analysis process or adjust the analysis results before executing the procedural analysis process again, until all procedural analysis steps are completed and the execution results are obtained. Finally, the HOP execution framework generates a risk detection report corresponding to the risk detection task based on the execution results. This detection method ensures the standardization and completeness of the analysis process by acquiring an executable procedural analysis process. During the execution of the procedural analysis process, the large language model is only called when executing the target analysis task, limiting the capabilities of the large language model to specific semantic understanding and reasoning tasks. Furthermore, after obtaining the analysis results output by the large language model, the HOP execution framework verifies the results and dynamically adjusts the procedural analysis process based on the verification results, thus constructing an execution-verification-execution / correction process. By verifying the analysis results through a procedural verification process, the HOP execution framework avoids potential illusions and logical errors that may arise from the large language model, thereby improving the reliability of risk detection.

[0095] In some embodiments, the components in the verification component library include one or more of the following types: deterministic verification, reverse verification, and forward cross-verification.

[0096] For example, deterministic verification types include one or more of the following components: format and structure verification components, link integrity verification components, and data flow verification components. Among them, the components under the deterministic verification type perform verification through rule-based and code logic-based programs, without relying on large language models, and are used to verify "factual" issues.

[0097] For example, the format and structure verification component is used to ensure that the structure of the analysis content output by the large language model conforms to predefined specifications (such as JSON Schema or Pydantic model) to avoid problems in subsequent processing due to format errors. If the format and structure verification component fails to verify the analysis results, it inputs instructions containing specific correction requirements into the large language model (such as: "The value of the risk_level field must be one of High, Medium or Low, please correct") to form a closed-loop correction.

[0098] The link integrity verification component reconstructs the analysis trajectory by parsing the tool call records generated by the large language model during analysis. It checks whether the necessary analysis dimensions are covered (e.g., whether the complete call stack is traced or all conditional branches are covered) to ensure the integrity of the large language model's analysis process and avoid misjudgments due to missing critical code paths. If the link integrity verification component finds that some analysis dimensions are missing during the large language model's analysis, it returns supplementary instructions to the large language model so that it can further analyze and supplement the missing dimensions.

[0099] The data flow verification component constructs a local abstract syntax tree (AST) on the code fragment sequence collected by the large language model, and performs deterministic data flow analysis in a programmatic manner based on the AST to verify whether the conclusions of the large language model about taint propagation or data dependencies are true, thereby ensuring the accuracy of data analysis and avoiding misjudgment of security vulnerabilities due to variable confusion.

[0100] Reverse verification types include one or more of the following components: large model disproving components and dynamic analysis components. Components under the reverse verification type propose hypotheses contrary to the analysis results of the large language model and attempt to verify whether there are logical errors in the large language model through disproving methods.

[0101] For example, the large model disproving component is triggered when the large language model's analysis conclusion indicates a negative conclusion such as "no risk." The HOP execution framework instantiates an independent disproving agent, instructing it to assume the large language model's analysis result is incorrect. This allows the disproving agent to proactively search for potential attack paths or logical flaws, performing adversarial verification to uncover potential missed detections in the analysis result. By assuming the opposite conclusion and seeking disproving evidence, the logical evolution of the large language model's analysis result can be ensured, avoiding missed detections due to logical errors.

[0102] The dynamic analysis component is used to process conclusions that require empirical verification. It transforms the vulnerability assumptions of the large language model into test actions that can be executed in real or simulated environments (such as generating and sending specific interface requests). By comparing the actual responses or runtime monitoring (such as IAST) results, it generates high-confidence empirical conclusions. This method of verifying the analysis results of the large language model through dynamic testing ensures that the analysis results hold true in the actual operating environment, avoiding misjudgments of risks due to logical errors.

[0103] Positive cross-validation types include one or more of the following components: SOP compliance verification components and multi-model voting components. Components under the positive cross-validation type evaluate the target analysis steps of large language model analysis by introducing one or more independent third-party perspectives to verify "consistency" errors.

[0104] For example, the SOP compliance verification component introduces an independent review agent. This agent verifies, through semantic comparison, whether the large language model's analysis trajectory strictly follows the target analysis steps defined in the procedural analysis workflow. If any omissions are found, supplementary instructions are returned to allow the large language model to complete all missing steps. This approach ensures that the large language model executes the analysis trajectory specified in the SOP completely, avoiding risky misjudgments due to missing steps.

[0105] The multi-model voting component, when faced with ambiguous issues or problems requiring multi-dimensional analysis, distributes the same verification task in parallel to multiple large models with different characteristics (e.g., models skilled in logical reasoning, models skilled in compliance review, etc.). The confidence level of the final conclusion is determined by comprehensively considering the consistency of the results returned by each large model or through weighted voting. This multi-model cross-validation method ensures the consistency and reliability of the analytical conclusions, avoiding risk misjudgments due to biases in a single model.

[0106] In some embodiments, the HOP execution framework systematically verifies the analysis results output by large language models by orchestrating deterministic verification, reverse verification, and cross-verification components. These verification components validate the analysis results of large language models from different perspectives, ensuring that the analysis results meet professional standards in terms of fact, logic, and consistency. This solves the illusion problem of large language models and improves the reliability and accuracy of intelligent risk detection.

[0107] In some embodiments, the risk detection system can match the context information of the target analysis step with a preset verification rule table to determine whether a verification condition corresponding to the context information exists. The verification rule table includes the correspondence between verification conditions and verification components. If a corresponding verification condition exists, the risk detection system determines at least one verification component corresponding to the verification condition as the target verification component. If no corresponding verification condition is found, the risk detection system uses a large language model to determine at least one target verification component from the verification component library based on the context information.

[0108] The verification rule table can be a configurable file or a database table. For example, a rule in the verification rule table might be: "When the risk type is horizontal unauthorized access, and the analysis conclusion of the large language model is that there is a risk, and the confidence level is below 80%, trigger the large model disproving component and the dynamic analysis component." The HOP execution framework extracts key information (such as risk type, analysis result, confidence level, etc.) from the context information of the target analysis step and matches it in the verification rule table. If a matching target rule is found, one or more verification components specified by the target rule are directly obtained as the target verification components.

[0109] For example, the verification rule table may record the relationship between each rule and the verification component in the form of "IF-THEN". For example, "IF step attribute = "formatted output" THEN must be added to the format and structure verification component", "IF step attribute = "data flow analysis" THEN priority to add to the data flow verification component", "IF target risk type = high risk AND conclusion direction = "no risk" THEN mandatory addition to the dynamic testing component and multi-model voting component", "IF confidence level < 0.6 THEN add to the large model counter-evidence component", "IF tool call record shows critical path not covered by SOP requirements THEN add to the SOP compliance verification component".

[0110] In some embodiments, due to the diversity of scenarios, the verification rule table may not cover all cases. Therefore, when the HOP execution framework does not find a match in the verification rule table, the HOP execution framework can call the large language model to provide the context information corresponding to the target analysis step and the list of each verification component contained in the verification component library to the large language model, so that the large language model can determine one or more target verification components in the verification component library according to the specific circumstances of the target analysis step.

[0111] Figure 5 A flowchart illustrating an analytical result verification method according to another embodiment of this specification is shown, such as... Figure 5As shown, after the large language model completes the analysis process for the target analysis step and outputs the analysis results, the HOP execution framework detects the end of the analysis and triggers the verification module within the HOP execution framework to verify the analysis results. The verification module determines at least one target verification component from the verification component library based on the context data of the analysis results, and then verifies the analysis results based on the target verification component. Specifically, the verification module may perform deterministic verification of the analysis results (e.g., verification of data flow or link integrity); or reverse verification (e.g., verification through AI-based counter-verification or dynamic testing); or cross-verification (e.g., SOP compliance verification or multi-model voting verification), etc.

[0112] Continue as Figure 5 As shown, after verification fails (e.g., a hallucination or false positive issue is found in the large language model), the verification module sends the verification failure conclusion and reason to the HOP execution framework. This allows the HOP execution framework to issue a pre-fill instruction to the large language model, enabling the large language model to adjust the analysis results based on the adjustment instruction. For example, the verification module sends a pre-fill instruction to the HOP execution framework: Verification failed (risk detected), reason: 'checkAccess' is invalid, and the fourth step of the procedural execution process is not satisfied. After receiving the information from the verification module, the HOP execution framework organizes the information and issues an adjustment instruction to the large language model: Verification failed, this is a high-risk vulnerability; reason: 'checkAccess' did not perform ownership verification, please re-analyze and confirm the risk.

[0113] Continue as Figure 5 As shown, after successful verification, the verification component sends the successful verification conclusion and the confidence level of the current verification result to the HOP execution framework. This allows the HOP execution framework to send a pre-fill instruction to the large language model, enabling the large language model to continue execution based on the pre-fill instruction. For example, after successful verification, the HOP execution framework could send a pre-fill instruction to the large language model: "Verification passed, please generate a report."

[0114] This specification, in another aspect, provides a computer-readable non-transitory storage medium storing at least one set of instructions for performing risk detection executable instructions. When the at least one set of instructions is executed by a processor, it instructs the processor to implement the steps of the risk detection method P300 of this specification. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on the risk detection system 130, the program code causes the risk detection system 130 to perform the steps of the method P300 described in this specification. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the risk detection system 130. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination of the foregoing. Program code for performing the operations described herein may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar programming languages.

[0115] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0116] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0117] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0118] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment.

[0119] Every patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, and literature (excluding any related historical examination documents), cited in this disclosure is incorporated herein for all purposes, including, for example, in the specification and claims of this disclosure. However, in the event of any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing and those used in this disclosure, the descriptions, definitions, and / or terms used in this disclosure shall prevail.

[0120] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A risk detection method, characterized in that, Applied to the HOP execution framework, the method includes: Obtain the procedural analysis process corresponding to the risk detection task, wherein the procedural analysis process includes: multiple execution steps, wherein the multiple execution steps include one or more target analysis steps; The execution of the multiple execution steps is initiated. When the target analysis step is executed, the large language model is invoked to analyze the target analysis step and obtain the analysis results. The analysis results are verified based on a preset procedural verification process to obtain the verification results; The execution of the procedural analysis process continues or is adjusted based on the verification results until the entire procedural analysis process is executed and the execution results are obtained. Based on the execution results, a risk detection report corresponding to the risk detection task is generated.

2. The method according to claim 1, wherein, The verification of the analysis results based on a preset procedural verification process yields the following verification results: Based on the context information of the target analysis step, one or more target verification components are determined from a preset verification component library. The context information includes: relevant information about the analysis results; and The target verification component is invoked to verify the analysis results, and the verification results are obtained.

3. The method according to claim 2, wherein, The relevant information in the analysis results includes one or more of the following: risk type, analysis results, confidence level of the analysis results, analysis path, and information on the tools used in the analysis process.

4. The method according to claim 2, wherein, The step of determining one or more target verification components from a preset verification component library based on the context information of the target analysis step includes: Based on the context information of the target analysis step, a match is performed in a preset verification rule table to determine whether there is a verification condition corresponding to the context information; the verification rule table includes the correspondence between verification conditions and verification components; If a corresponding verification condition exists, then at least one verification component corresponding to the verification condition is determined as the target verification component; and If no corresponding verification condition is found, the large language model is used to determine at least one target verification component in the verification component library based on the context information.

5. The method according to claim 2, wherein, The components in the verification component library include one or more of the following types: deterministic verification, reverse verification, and forward cross-verification.

6. The method according to claim 5, wherein, The deterministic verification type includes one or more of the following components: format and structure verification component, link integrity verification component, and data flow verification component; The reverse verification type includes one or more of the following components: large model counter-verification component, dynamic analysis component; The positive cross-validation verification type includes one or more of the following components: SOP compliance verification component, multi-model voting component.

7. The method according to claim 1, wherein, The step of continuing or adjusting the execution of the procedural analysis process based on the verification result until the entire procedural analysis process is executed and the execution result is obtained includes: If the verification result indicates that the verification is successful, the subsequent execution steps of the procedural analysis process will continue to be executed based on the analysis result until the entire procedural analysis process is executed and the execution result is obtained. If the verification result indicates failure, the analysis result is adjusted based on the verification result until the adjusted analysis result passes the verification; based on the analysis result, the subsequent execution steps of the procedural analysis process continue to be executed until the entire procedural analysis process is executed and the execution result is obtained.

8. The method according to claim 7, wherein, The adjustment of the analysis results based on the verification results includes: A correction instruction containing correction information is generated, and the target analysis step is re-invoked based on the correction instruction to obtain the analysis result; Alternatively, the HOP execution framework may adjust the analysis results; Alternatively, the context information of the target analysis step can be sent to the operation and maintenance terminal so that the operation and maintenance terminal can adjust the analysis results based on the context information, wherein the context information includes: relevant information of the analysis results.

9. The method according to claim 1, wherein, The programmed analysis process for obtaining the risk detection task includes: Based on the task type of the risk detection task, obtain the standard operating procedure template corresponding to the task type from the preset knowledge graph; Based on the standard operating procedure template and the risk detection task, determine the executable procedural analysis process corresponding to the risk detection task.

10. The method according to claim 1, wherein, The analysis objects of the target analysis step include one or more of the following: source code fragments to be detected, configuration information, application programming interface definitions, and function call chains.

11. A risk detection system, comprising: At least one storage medium storing at least one instruction set for risk detection; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method according to any one of claims 1-10 based on the instructions of the at least one instruction set.

Images