Code business logic vulnerability static analysis method based on large language model

Abstract

The application relates to the technical field of code analysis, in particular to a code business logic vulnerability static analysis method based on a large language model, which comprises the following steps: performing semantic feature extraction based on a source code file set and a business requirement document to obtain a code business semantic feature graph; constructing a business logic constraint knowledge network based on the code business semantic feature graph; generating a business scene simulation test case set based on the business logic constraint knowledge network; executing the business scene simulation test case set, obtaining corresponding function runtime state data, performing state migration trajectory analysis based on the function runtime state data, and obtaining an actual business state flow sequence.The application can monitor the state change of a program in real time by executing test cases and capturing function runtime state data, can provide an objective basis for subsequent state migration trajectory analysis, and can ensure the reliability of analysis results.

Description

Technical Field

[0001] This invention relates to the field of code analysis technology, specifically a static analysis method for code business logic vulnerabilities based on a large language model. Background Technology

[0002] Currently, many traditional methods rely solely on static analysis or dynamic testing, lacking a comprehensive understanding and systematic analysis of business logic, which can easily lead to the missed detection of potential logical vulnerabilities. Furthermore, traditional detection tools have limited ability to capture state changes during program runtime and cannot provide real-time feedback, making it difficult for developers to quickly locate problems. In addition, many traditional methods lack risk assessment mechanisms for vulnerabilities, making it impossible to effectively prioritize high-risk vulnerabilities, resulting in low remediation efficiency and increasing the risk of potential losses.

[0003] Furthermore, traditional methods typically lack learning capabilities and cannot self-optimize based on historical vulnerability samples, resulting in slow response to new vulnerabilities and decreased detection effectiveness. In addition, the remediation suggestions generated by traditional methods are often not intelligent enough and lack verification mechanisms, which may result in security vulnerabilities still existing in the remediated code, increasing the complexity and cost of subsequent maintenance. Moreover, traditional analysis often lacks comprehensive consideration of global variables and database operations, and cannot provide comprehensive state transition trajectory analysis, which may lead to misjudgment or omission of business state changes. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides the following technical solution: a static analysis method for code business logic vulnerabilities based on a large language model, comprising:

[0005] Obtain the set of source code files and the corresponding business requirement documents of the software system under test, and extract semantic features based on the set of source code files and the business requirement documents to obtain the code business semantic feature map;

[0006] A business logic constraint knowledge network is constructed based on the code business semantic feature graph, and a business scenario simulation test case set is generated based on the business logic constraint knowledge network.

[0007] Execute a set of business scenario simulation test cases, obtain the corresponding function runtime state data, and perform state transition trajectory analysis based on the function runtime state data to obtain the actual business state transition sequence.

[0008] The actual business state transition sequence is compared with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes, and a set of business logic vulnerability candidates is generated based on the set of logical deviation nodes.

[0009] Based on the candidate set of business logic vulnerabilities, vulnerability exploitation chain inference is performed to obtain vulnerability hazard propagation path data. Based on the vulnerability hazard propagation path data, the analysis strategy of the large language model is optimized.

[0010] Preferably, semantic features are extracted based on the source code file set and business requirement documents to obtain a code business semantic feature map, including:

[0011] The source code file set is parsed line by line to extract code function fragments and corresponding variable operation semantics;

[0012] Based on the business terminology in the business requirements document, name entity alignment is performed on code function fragments and their corresponding variable operation semantics to generate business semantic annotated code blocks.

[0013] Based on the function call relationships and data flow in the code blocks annotated with business semantics, corresponding business logic nodes are constructed, and a code business semantic feature map is generated based on all business logic nodes.

[0014] Preferably, a business logic constraint knowledge network is constructed based on the code business semantic feature graph, and a business scenario simulation test case set is generated based on the business logic constraint knowledge network, including:

[0015] Based on each business logic node in the code business semantic feature graph, extract the corresponding precondition constraints and poststate changes;

[0016] Based on precondition constraints and poststate changes, a business logic constraint knowledge network in the form of a directed acyclic graph is constructed.

[0017] Identify key business branch nodes in the business logic constraint knowledge network, and generate multi-dimensional boundary value test parameters based on the key business branch nodes;

[0018] Inject multi-dimensional boundary value test parameters into a preset test template to generate a set of business scenario simulation test cases covering the entire business path.

[0019] Preferably, a set of business scenario simulation test cases is executed to obtain the corresponding function runtime state data. Based on the function runtime state data, state transition trajectory analysis is performed to obtain the actual business state transition sequence, including:

[0020] Deploy the source code file set in the sandbox environment and inject the business scenario simulation test case set in sequence;

[0021] Capture the input parameter values ​​and output return values ​​during function execution to generate function runtime state data;

[0022] Based on the timestamp information in the function runtime state data, the state changes of each function call node are sorted to generate state transition trajectory data;

[0023] The state transition trajectory data is verified based on a preset state machine model, and invalid abnormal jump points are removed to obtain the actual business state transition sequence.

[0024] Preferably, the actual business state transition sequence is compared with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes. Based on the set of logical deviation nodes, a candidate set of business logic vulnerabilities is generated, including:

[0025] Calculate the distance between the actual business state transition sequence and the expected state transition path at each node;

[0026] Nodes whose state vector distance is greater than a preset deviation threshold are selected and a set of logical deviation nodes is generated.

[0027] Obtain the context call stack information corresponding to each node in the logical deviation node set, and determine whether there is bypass logic based on the context call stack information;

[0028] When bypass logic is determined to exist, the corresponding code snippets and triggering conditions are extracted to generate a candidate set of business logic vulnerabilities.

[0029] Preferably, vulnerability exploitation chain deduction is performed based on a candidate set of business logic vulnerabilities to obtain vulnerability propagation path data. The analysis strategy for the large language model is then optimized based on this data, including:

[0030] Based on the vulnerability types in the business logic vulnerability candidate set, construct a vulnerability exploitation dependency graph;

[0031] Find the shortest path from the entry function to the sensitive data operation in the vulnerability exploitation dependency graph, and generate vulnerability hazard propagation path data;

[0032] Transform vulnerability hazard propagation path data into natural language descriptions of counterexamples, and add the counterexamples to the prompt word library of the large language model;

[0033] Fine-tuning of the large language model is performed based on counterexamples, and the semantic understanding weights of the model are updated to achieve feedback optimization of the analysis strategy.

[0034] Preferably, after generating a candidate set of business logic vulnerabilities based on the set of logical deviation nodes, the process further includes:

[0035] Obtain the code complexity metric and business impact weight for each vulnerability in the candidate set of business logic vulnerabilities;

[0036] A vulnerability risk assessment matrix is ​​constructed based on code complexity metrics and business impact weights, and the vulnerability candidate set is classified according to the vulnerability risk assessment matrix.

[0037] Select the highest-risk vulnerability as the target vulnerability and generate corresponding automated remediation code suggestions;

[0038] The automated repair code is suggested to be merged and compiled with the original source code, and the repaired code is verified to pass the business scenario simulation test case set.

[0039] Preferably, the function runtime state data includes global variable snapshots and database operation records;

[0040] State transition trajectory analysis is performed based on function runtime state data to obtain the actual business state transition sequence, including:

[0041] Based on the global variable snapshot, obtain the difference in variable values ​​before and after the execution of each function, and generate a state change vector;

[0042] Based on the database operation records, obtain the corresponding SQL statement type and the number of rows affected, and generate a data persistence operation sequence;

[0043] The state change vector and the data persistence operation sequence are merged along the time axis to generate a complete business state migration trajectory.

[0044] The noise reduction process is applied to the business state transition trajectory to remove non-business state jumps caused by the underlying system scheduling, thus obtaining the actual business state transition sequence.

[0045] Preferably, the method further includes:

[0046] Obtain a historically known database of logical vulnerabilities and construct a vulnerability feature vector space based on the historically known database of logical vulnerabilities.

[0047] The actual business status flow sequence is mapped to the vulnerability feature vector space, and a similarity score is calculated.

[0048] When the similarity score exceeds the preset similarity threshold, it is determined that the code segment being analyzed has a potential logical vulnerability risk, and the deep semantic analysis mode is triggered.

[0049] In deep semantic analysis mode, adversarial test cases are generated for the code segment based on a large language model, and state transition trajectory analysis is re-executed.

[0050] Compared with the prior art, the beneficial effects of the present invention are:

[0051] (1) This invention extracts semantic features from source code and business requirements documents to construct a comprehensive business logic constraint knowledge network, making the analysis process more systematic and helping to identify potential logical vulnerabilities; and by executing test cases and capturing function runtime state data, it can monitor program state changes in real time, providing an objective basis for subsequent state transition trajectory analysis and ensuring the reliability of the analysis results; and by comparing the actual state transition sequence with the expected state transition path, it can quickly identify logical deviation nodes, which provides important clues for locating potential vulnerabilities.

[0052] (2) This invention assesses the risk of the vulnerability candidate set based on code complexity and business impact weight, which helps the development team prioritize high-risk vulnerabilities, improve repair efficiency, and reduce potential losses. Furthermore, by converting vulnerability hazard propagation path data into counterexample samples and adding them to the training of a large language model, the analysis strategy can be continuously optimized, thereby improving the accuracy and efficiency of future vulnerability detection.

[0053] (3) The present invention improves the security of the code and enhances its maintainability by automatically generating repair code suggestions and its verification mechanism, thereby reducing the cost of subsequent maintenance. Furthermore, by combining global variable snapshots and database operation records, it can provide a more comprehensive and detailed state transition trajectory analysis, ensuring that all changes in business states are taken into account and reducing the risk of missed detections. Attached Figure Description

[0054] Figure 1 This is a schematic flowchart of the overall method in one embodiment of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0056] Example 1, please refer to Figure 1 This invention provides a technical solution: a static analysis method for code business logic vulnerabilities based on a large language model, comprising:

[0057] S1. Obtain the set of source code files and the corresponding business requirement documents of the software system under test. Extract semantic features based on the set of source code files and the business requirement documents to obtain the code business semantic feature map.

[0058] S2. Construct a business logic constraint knowledge network based on the code business semantic feature graph, and generate a set of business scenario simulation test cases based on the business logic constraint knowledge network;

[0059] S3. Execute the business scenario simulation test case set, obtain the corresponding function runtime state data, and perform state transition trajectory analysis based on the function runtime state data to obtain the actual business state transition sequence.

[0060] S4. Compare the actual business state transition sequence with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes, and generate a set of business logic vulnerability candidates based on the set of logical deviation nodes.

[0061] S5. Based on the candidate set of business logic vulnerabilities, perform vulnerability exploitation chain deduction to obtain vulnerability hazard propagation path data, and optimize the analysis strategy of the large language model based on the vulnerability hazard propagation path data.

[0062] It should be noted that source code files are the actual code of the program, while business requirements documents describe the functions and performance requirements that the system should implement; combining the two helps to understand the intent of the code and the business logic; for example, the source code of an e-commerce platform may contain functions for processing orders, while the business requirements document will clearly state that when an order is placed, the system should check the inventory and calculate the total price.

[0063] Semantic feature extraction is performed by analyzing source code and business requirements documents. This process involves identifying key business logic in the code, such as function inputs and outputs, conditional statements, and loops. The semantic feature graph presents these extracted features in a structured way, making the business logic more visual. For example, "check inventory" can be regarded as a node and connected to the "update order status" node to form a flowchart.

[0064] Business logic constraint knowledge networks represent the logical relationships and constraints between various operations in a specific business scenario. For example, in an e-commerce system, if a user chooses to purchase a product, the prerequisites of "product in stock" and "payment successful" must be met. This network helps identify dependencies and constraint rules in business processes.

[0065] By leveraging the constructed knowledge network, simulation test case sets for business scenarios can be generated. These test cases simulate different business scenarios to verify whether the system can operate correctly under various conditions. For example, a test case can be designed to test the situation where a user places an order when inventory is insufficient, to ensure that the system handles this abnormal situation correctly.

[0066] Execute these simulation test cases and record the runtime state data of each function; this state data includes input parameters, return values, exceptions, etc.; for example, when executing the "place an order" operation, it may record whether the function successfully called "check inventory" and the returned inventory status.

[0067] Based on the collected runtime state data, state transition trajectory analysis is performed; this means tracking all state changes the system undergoes during execution; for example, state changes from "browsing products" to "adding to cart" and then to "placing an order" need to be recorded and analyzed.

[0068] The actual business state transition sequence is compared with the expected state transition path in the previously constructed business logic constraint knowledge network. Through this comparison, it is possible to discover whether there are logical deviations in the system during execution. For example, if the actual state transition shows "order placed successfully" but does not go through the "payment successful" state, this indicates that there is a logical error.

[0069] The identified logical deviations constitute a set of logical deviation nodes; these nodes point to potential logical vulnerabilities, such as unmet business constraints or inconsistent state transitions; based on the set of logical deviation nodes, vulnerability exploitation chain deduction is performed; this process analyzes how these logical vulnerabilities can cause system problems, forming vulnerability hazard propagation path data; for example, a certain logical vulnerability may allow users to bypass the payment process and directly complete the order, thereby causing financial losses;

[0070] Based on data on the propagation path of vulnerabilities, the analysis strategy of the large language model is optimized through feedback. This may involve adjusting the model's training data or methods to improve its ability to identify and predict business logic vulnerabilities. For example, enhancing the model's ability to identify specific types of logical errors so that it can detect similar problems more effectively in the future.

[0071] In an optional embodiment, semantic feature extraction is performed based on a set of source code files and business requirement documents to obtain a code business semantic feature map, including:

[0072] The source code file set is parsed line by line to extract code function fragments and corresponding variable operation semantics;

[0073] Based on the business terminology in the business requirements document, name entity alignment is performed on code function fragments and their corresponding variable operation semantics to generate business semantic annotated code blocks.

[0074] Based on the function call relationships and data flow in the code blocks annotated with business semantics, corresponding business logic nodes are constructed, and a code business semantic feature map is generated based on all business logic nodes.

[0075] It should be noted that analysts analyze the source code line by line to extract function snippets and variable manipulation semantics. The source code file set refers to all source code files of the software system under test, including different modules and classes. This source code is usually written in a specific programming language, such as Java or Python. Reading the source code line by line helps identify its functionality and structure. For example, in an order processing system, there might be functions like the following:

[0076] def process_order(order_id):

[0077] if check_inventory(order_id):

[0078] update_order_status(order_id,"Processed")

[0079] In the example above, `process_order` is a function fragment responsible for processing orders. A function fragment typically includes a function definition, parameters, return value, and internal logic. Variable manipulation semantics refers to the variables used in the code and the operations performed on them. In the example, `order_id` is a variable representing a unique identifier for an order; `check_inventory` and `update_order_status` are operations on this variable.

[0080] A business requirements document describes the functions and requirements that the system should implement, and contains a series of terms; for example, business requirements might mention terms such as "inventory check" and "order status." The functions and variables in the source code are matched with these business terms; for example, assuming the business requirements document mentions the concept of "processing orders," the `process_order` function can be labeled as "processing orders"; in this case, `check_inventory` can be labeled as "checking inventory." After named entity alignment, the generated code blocks now contain business semantic information; for example, the annotated code snippet might look like this:

[0081] / / Processing orders

[0082] def process_order(order_id): / / Order ID

[0083] if check_inventory(order_id): / / check inventory

[0084] update_order_status(order_id,"Processed") / / Updates the order status to "Processed";

[0085] Function call relationships indicate how one function calls another; in the example, `process_order` calls `check_inventory` and `update_order_status`, which is a function call relationship; data flow involves the movement of data between functions; for example, `order_id` is passed into `process_order` and subsequently used by `check_inventory` and `update_order_status`, which reflects the data flow; nodes built based on the above information represent the key business logic in the system; for example, a node could represent "order processing," which includes the logic of checking inventory and updating status;

[0086] A code business semantic feature graph is a structured representation that shows the relationships and dependencies between various business logic nodes within a system. For example, the feature graph might show that the "process order" node is connected to the "check inventory" node, and also connected to the "update order status" node. Through this graph, developers can more intuitively understand the system's business logic, and it also provides a foundation for subsequent static analysis. It can help identify potential logical vulnerabilities, such as overselling if "check inventory" is not called correctly.

[0087] In an optional embodiment, a business logic constraint knowledge network is constructed based on a code business semantic feature graph, and a business scenario simulation test case set is generated based on the business logic constraint knowledge network, including:

[0088] Based on each business logic node in the code business semantic feature graph, extract the corresponding precondition constraints and poststate changes;

[0089] Based on precondition constraints and poststate changes, a business logic constraint knowledge network in the form of a directed acyclic graph is constructed.

[0090] Identify key business branch nodes in the business logic constraint knowledge network, and generate multi-dimensional boundary value test parameters based on the key business branch nodes;

[0091] Inject multi-dimensional boundary value test parameters into a preset test template to generate a set of business scenario simulation test cases covering the entire business path.

[0092] It should be noted that business logic nodes represent key business operations in the system, such as "processing orders" and "checking inventory"; preconditions are the conditions that must be met before executing a business logic node; for example, before the "processing orders" node, the following preconditions may need to be met: the order ID exists and is valid; the inventory quantity is greater than zero; post-processing state changes refer to the changes in the system state after a node is executed; for example, when the "processing orders" node is successfully executed, the order status may change to "processed," and the inventory quantity may decrease; these state changes define the dynamic behavior of the system in the business process.

[0093] A Directed Acyclic Graph (DAG) is a graph structure in which edges are directed and have no cycles, making it suitable for representing causal relationships. In this graph, each node represents a business logic, and edges represent dependencies from one logic to another. By integrating all identified business logic nodes and their preconditions and postconditions into a DAG, a knowledge network is formed. For example, in the graph, the "Process Order" node points to the "Update Inventory" node, which is a postcondition of the former.

[0094] Key business branch nodes are typically decision points in the system process, affecting subsequent business processes. For example, at the "Check Inventory" node, insufficient inventory may lead to the "Send Inventory Warning" node, while sufficient inventory leads to the "Process Order" node. Based on key business branch nodes, test parameters for boundary conditions can be generated to ensure that the system functions correctly under different conditions. For example, at the "Check Inventory" node, boundary test parameters could be inventory values ​​of 0, 1, or negative numbers to test the system's ability to handle inventory status.

[0095] A preset test template is a standardized test case format that includes test steps, expected results, and other information. The template helps ensure the consistency and completeness of test cases. Combined with previously generated boundary value test parameters, specific test cases can be generated using the template. For example, for the "processing orders" scenario, the following test cases might be generated: Test Case 1: Attempt to process an order when inventory is 0, expecting to return an "Insufficient Inventory" error; Test Case 2: Process an order when inventory is 1, expecting the order status to change to "Processed" and the inventory to decrease to 0; Test Case 3: Process an order when inventory is negative, expecting to return an "Invalid Inventory" error.

[0096] In an optional embodiment, a set of business scenario simulation test cases is executed to obtain corresponding function runtime state data. Based on the function runtime state data, state transition trajectory analysis is performed to obtain the actual business state transition sequence, including:

[0097] Deploy the source code file set in the sandbox environment and inject the business scenario simulation test case set in sequence;

[0098] Capture the input parameter values ​​and output return values ​​during function execution to generate function runtime state data;

[0099] Based on the timestamp information in the function runtime state data, the state changes of each function call node are sorted to generate state transition trajectory data;

[0100] The state transition trajectory data is verified based on a preset state machine model, and invalid abnormal jump points are removed to obtain the actual business state transition sequence.

[0101] It's important to note that a sandbox environment refers to an isolated testing environment used to securely run and test software applications. Executing code in a sandbox does not affect the actual production environment, effectively avoiding potential risks. A collection of source code files refers to all source code files of a project, including business logic, data models, configuration files, etc. Integrating these files into a sandbox environment facilitates subsequent testing and analysis. For example, suppose there is a collection of source code for an e-commerce platform, containing modules for order processing, user management, and inventory management. Deploying this collection to a sandbox environment allows for testing in simulated real-world business scenarios.

[0102] The business scenario simulation test case set is a collection of test cases generated based on the previous steps, covering possible business processes and state changes in the system; injecting test cases means executing these test scenarios one by one to verify the behavior of the code under different input conditions; for example, a test case can be injected to simulate the process of a user placing an order and observe how the system processes the order, updates inventory, and changes the order status;

[0103] Input parameter values ​​refer to the parameters passed to the function during function calls; for example, in a "create order" function, the parameters that might be received include user ID, product ID, quantity, etc.; output return values ​​refer to the results returned after the function has finished executing; for example, after successfully creating an order, the function might return an order ID or a status code; during testing, capturing these values ​​can help analyze the function's behavior and understand how input conditions affect the output results; for example, in a test case for creating an order, if the input product ID is invalid, the output might be an error message or a null value;

[0104] Function runtime state data records information about the function's state during execution, including input parameters, return values, and execution time. This data is crucial for subsequent analysis because it provides detailed context of the function's execution. For example, when the "Create Order" function is called, the state data might record the following information:

[0105] Input parameters: User ID=123, Product ID=456, Quantity=2;

[0106] Output return value: Order ID=789, Status=“Success”;

[0107] Execution timestamp: 2026-02-11 10:00:00;

[0108] Each function execution generates a timestamp, which helps track the order of function calls and state changes. Sorting state changes means ranking the state changes of each function call node according to the timestamps to form a clear execution trajectory. This is crucial for understanding the system's behavior and locating potential problems. For example, if there are multiple function calls, such as "check inventory", "create order", and "update inventory", the timestamps can determine the order in which these functions are called and present it as a linear flow.

[0109] State transition trajectory data refers to the record of transitions between states during function execution; it describes the process of the system changing from one state to another.

[0110] For example, state transitions might include:

[0111] Initial state: Pending processing

[0112] Status Change 1: Inventory Check (Successful)

[0113] Status Change 2: Order Created (Successfully)

[0114] Status Change 3: Inventory Updated (Successfully)

[0115] Final status: Order completed

[0116] These state transitions help in understanding the integrity and consistency of business processes;

[0117] A pre-defined state machine model is a model used to describe the states of a system and their transition rules. The state machine defines the states that the system can be in and under what conditions it can transition to other states. By comparing and verifying the generated state transition trajectory data with the pre-defined state machine model, unexpected state transitions can be identified. For example, if the state machine model stipulates that the "pending" state can only transition to the "processing" state, but the actual trajectory shows that it transitioned to the "completed" state, then it needs to be marked as an anomaly.

[0118] The actual business state transition sequence refers to the state sequence that, after verification, can truly reflect the changes in system state; this sequence corresponds to the legitimate operation path of the system and helps to identify potential business logic vulnerabilities.

[0119] For example, after verification, the possible valid state transition sequence is:

[0120] Pending processing → In progress

[0121] Processing → Updating Inventory

[0122] Update inventory → Order completed

[0123] This final state transition sequence can be used to further analyze the system's stability and correctness, ensuring that there are no potential logical vulnerabilities that could cause errors in business processing.

[0124] In an optional embodiment, the actual business state transition sequence is compared with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes. A candidate set of business logic vulnerabilities is then generated based on this set of logical deviation nodes, including:

[0125] Calculate the distance between the actual business state transition sequence and the expected state transition path at each node;

[0126] Nodes whose state vector distance is greater than a preset deviation threshold are selected and a set of logical deviation nodes is generated.

[0127] Obtain the context call stack information corresponding to each node in the logical deviation node set, and determine whether there is bypass logic based on the context call stack information;

[0128] When bypass logic is determined to exist, the corresponding code snippets and triggering conditions are extracted to generate a candidate set of business logic vulnerabilities.

[0129] It should be noted that the expected state transition path is an ideal sequence of states defined based on business requirements or design documents, defining the state transition rules that the system should follow under normal circumstances; the state vector can be understood as a description of each state, usually including the characteristic information of the state, such as state name, state type, timestamp, etc.; in this context, the state vector may contain relevant attributes of the state for comparison.

[0130] State vector distance is an indicator used to measure the degree of difference between two state vectors. When the actual state transition is inconsistent with the expected state transition, calculating the state vector distance can help locate the problem. For example, if the expected state is "order created" → "payment successful", but the actual state transition is "order created" → "payment failed" → "order canceled", then by calculating the state vector distance between the two, a significant difference can be found, thereby identifying potential problems.

[0131] The preset deviation threshold is a numerical threshold used to determine whether the state vector distance is significant; nodes exceeding this threshold are considered to have logical deviations; the logical deviation node set is those states selected from all state nodes whose state vector distance from the expected state transition path exceeds the preset deviation threshold; these nodes indicate that an anomaly has occurred during execution, which may indicate the existence of business logic vulnerabilities; for example, if the set deviation threshold is 2, and a node's state vector distance calculation score is 3, then this node will be included in the logical deviation node set;

[0132] The context call stack is a data structure that records the order of function calls and related information during program execution. It shows the function call chain at the current execution point, which helps to understand the program's execution context. Obtaining the context call stack information of a logical deviation node means seeing where the program was executed and which functions were called when the node occurred, thereby analyzing the context environment that caused the deviation.

[0133] For example, for a logical deviation node "payment failed", its context call stack might show:

[0134] check Payment() (Check Payment);

[0135] create Order() (create order);

[0136] log Transaction() (records a transaction);

[0137] Bypassing logic refers to skipping necessary logical checks or operations in a business process, causing the system to fail to execute the expected security checks or business rules. By analyzing the context call stack of the logical deviation node, it can be determined whether there is a bypassing logic. For example, if the "payment verification" logic is not called in the "payment failure" call stack, it indicates that there may be a bypassing logic problem.

[0138] Code snippets refer to code blocks associated with logical deviation nodes, which are responsible for implementing the logic of state transitions; triggering conditions refer to the conditions or input parameters that cause a function to be called or a state to be changed; when a certain condition is met, it may cause the system state to be different from expectations; once bypass logic is determined, extracting the relevant code snippets and triggering conditions can help developers understand the root cause of the problem; for example, if in the "payment failure" scenario it is found that the code snippet does not execute the "payment verification" logic, and at the same time detects that the user has entered invalid payment information, then this path may become a candidate set of business logic vulnerabilities.

[0139] In an optional embodiment, vulnerability exploitation chain deduction is performed based on a candidate set of business logic vulnerabilities to obtain vulnerability propagation path data. The analysis strategy for the large language model is then optimized based on this data, including:

[0140] Based on the vulnerability types in the business logic vulnerability candidate set, construct a vulnerability exploitation dependency graph;

[0141] Find the shortest path from the entry function to the sensitive data operation in the vulnerability exploitation dependency graph, and generate vulnerability hazard propagation path data;

[0142] Transform vulnerability hazard propagation path data into natural language descriptions of counterexamples, and add the counterexamples to the prompt word library of the large language model;

[0143] Fine-tuning of the large language model is performed based on counterexamples, and the semantic understanding weights of the model are updated to achieve feedback optimization of the analysis strategy.

[0144] It should be noted that a vulnerability exploitation dependency graph is a graphical data structure used to describe the interrelationships and dependencies between different vulnerabilities. In this graph, nodes typically represent different vulnerability types, while edges represent the dependencies or exploitation relationships between them. For example, if there is an "unauthorized access" vulnerability, an attacker can gain access through this vulnerability and then exploit another "SQL injection" vulnerability to extract sensitive information from the database. These two vulnerabilities can be connected by an edge, forming a dependency relationship.

[0145] The entry point function is the starting point of program execution, usually where user requests or input are processed, such as the main() function or an HTTP request handling function; sensitive data operations refer to operations involving sensitive information, such as database queries to read user passwords or bank card information, file read and write operations, etc.; finding the shortest path from the entry point function to the sensitive data operation means finding a minimal vulnerability chain in the vulnerability exploitation dependency graph. Through this chain, an attacker can start from the program's entry point, gradually exploit the vulnerability, and eventually access or manipulate sensitive data.

[0146] For example, suppose we have the following path:

[0147] Entry function (handle Request());

[0148] Vulnerability A ("Unauthorized Access");

[0149] Vulnerability B (“SQL injection”);

[0150] Sensitive data operations (fetch User Data());

[0151] Graph traversal algorithms, such as breadth-first search (BFS), can be used to find the shortest path from handle Request() to fetchUser Data().

[0152] Vulnerability propagation path data refers to information obtained by analyzing the shortest path, describing how attackers exploit these vulnerabilities to gradually reach sensitive data operations from the entry point function; this data includes specific vulnerability types, exploitation methods, and their order.

[0153] For example, if the result of the above path is:

[0154] Gaining access by exploiting "unauthorized access";

[0155] Subsequently, user information is obtained through "SQL injection". Therefore, this path data can be recorded as "entry point → unauthorized access → SQL injection → obtaining user data".

[0156] Counterexamples are specific cases generated based on vulnerability propagation path data, designed to demonstrate security incidents that may occur under specific conditions. These examples can be used to train models to understand and identify potential security risks. For example, the path data above could be described in natural language as follows: "When a user makes a request, the system fails to effectively verify the user's identity, allowing a malicious user to gain unauthorized access to the system. Subsequently, the malicious user exploits an SQL injection vulnerability to extract sensitive user information from the database."

[0157] The cue word library refers to a set of examples and keywords used in a large language model to provide context and guide the model to generate reasonable output. Adding new counterexamples to the cue word library helps the model better understand and identify similar security issues. By adding the above counterexamples to the cue word library, the model can take these examples into account when processing security-related queries, thereby improving its analytical capabilities.

[0158] Fine-tuning training refers to training an existing model using new data (such as negative examples) to optimize its performance and accuracy. In this process, negative examples serve as training data to update the model's semantic understanding weights, enabling the model to better identify and analyze content related to business logic vulnerabilities. For example, by providing multiple examples of how to exploit "unauthorized access" and "SQL injection," the model will learn the characteristics and attack patterns of these vulnerabilities, thereby more effectively identifying similar risks in future application scenarios.

[0159] In an optional embodiment, after generating a candidate set of business logic vulnerabilities based on the set of logical deviation nodes, the method further includes:

[0160] Obtain the code complexity metric and business impact weight for each vulnerability in the candidate set of business logic vulnerabilities;

[0161] A vulnerability risk assessment matrix is ​​constructed based on code complexity metrics and business impact weights, and the vulnerability candidate set is classified according to the vulnerability risk assessment matrix.

[0162] Select the highest-risk vulnerability as the target vulnerability and generate corresponding automated remediation code suggestions;

[0163] The automated repair code is suggested to be merged and compiled with the original source code, and the repaired code is verified to pass the business scenario simulation test case set.

[0164] It should be noted that the business logic vulnerability candidate set refers to the code segments identified after preliminary analysis that may contain business logic vulnerabilities, such as failure to correctly perform permission checks or incorrect data validation. Code complexity metrics are a way to quantify code complexity, and commonly used metrics include cyclomatic complexity, lines of code, and nesting levels. For example, cyclomatic complexity represents the control flow complexity of a program, and is calculated by determining the number of conditional statements in the program. The higher the cyclomatic complexity, the more complex the logic of the code, and the greater the difficulty in understanding and maintaining it.

[0165] Lines of code refer to the number of lines of code required to implement a function. Too many lines of code may mean that the implementation is too complex or verbose. Business impact weight is an assessment of the business risks that a vulnerability may cause. Factors that are usually considered include: the financial losses that the vulnerability may cause, the risk of user data leakage, and the negative impact on the company's reputation. For example, the code complexity of a "unauthorized access" vulnerability may be 10 (cyclomatic complexity), but its business impact weight is assessed as high, which may lead to user data leakage and company fines.

[0166] A vulnerability risk assessment matrix is ​​a tool used to comprehensively analyze code complexity and business impact weight to determine the overall risk level of a vulnerability. The matrix typically categorizes complexity and impact weight into multiple levels, such as low, medium, and high, and derives the risk level based on a cross-assessment of these two dimensions. For example, a risk assessment matrix might be constructed as follows: high complexity + high impact weight = high risk; low complexity + low impact weight = low risk. After constructing the vulnerability risk assessment matrix, each vulnerability is graded according to its corresponding complexity index and business impact weight. The goal of this step is to quickly identify the vulnerabilities that require the highest priority for handling.

[0167] For example: Vulnerability A (high complexity, high impact) is marked as "high risk"; Vulnerability B (low complexity, low impact) is marked as "low risk"; the target vulnerability is the one identified as the highest risk during the risk assessment process and is usually the priority target; based on the characteristics of the target vulnerability, an automatically generated code remediation plan is proposed; this suggestion usually includes specific code examples and implementation steps for remediating the vulnerability; for example, for a "unauthorized access" target vulnerability, the automated remediation suggestion might include: adding user permission checks; verifying user identity before database queries;

[0168] The generated automated fix code is then applied to the original source code; this process includes:

[0169] Insert the fix code in the appropriate location.

[0170] Ensure compatibility between new and old code.

[0171] For example, if the original code is as follows:

[0172] Python

[0173] def fetch_user_data(user_id):

[0174] #Querying without authorization

[0175] query="SELECT FROM users WHERE id={}".format(user_id)

[0176] execute_query(query)

[0177] The fixed code may become:

[0178] Python

[0179] def fetch_user_data(user_id,current_user):

[0180] if not has_permission(current_user,user_id):

[0181] raise Exception("Unauthorized access")

[0182] query="SELECT FROM users WHERE id={}".format(user_id)

[0183] execute_query(query)

[0184] The business scenario simulation test case set is a test suite used to verify software functionality and business logic. Its purpose is to ensure that the fixed code functions correctly without introducing new problems. At this stage, automated test cases need to be run to verify whether the fixed code meets expectations and ensure that all business logic functions correctly. For example, test cases might include: ensuring that authorized users can successfully query data; ensuring that unauthorized users cannot access sensitive information. If all test cases pass, the fix is ​​considered successful. If any tests fail, further adjustments to the fixed code or a reassessment of other potential problems are needed.

[0185] In an optional embodiment, the function runtime state data includes global variable snapshots and database operation records;

[0186] State transition trajectory analysis is performed based on function runtime state data to obtain the actual business state transition sequence, including:

[0187] Based on the global variable snapshot, obtain the difference in variable values ​​before and after the execution of each function, and generate a state change vector;

[0188] Based on the database operation records, obtain the corresponding SQL statement type and the number of rows affected, and generate a data persistence operation sequence;

[0189] The state change vector and the data persistence operation sequence are merged along the time axis to generate a complete business state migration trajectory.

[0190] The noise reduction process is applied to the business state transition trajectory to remove non-business state jumps caused by the underlying system scheduling, thus obtaining the actual business state transition sequence.

[0191] It should be noted that a global variable snapshot refers to the state (value) of a global variable captured at a specific point in time; for example, recording the current value of all global variables before and after executing a function; by comparing the values ​​of global variables before and after function execution, a vector representing the changes is generated; this vector can clearly indicate which variables have changed their values ​​and the specific details of the changes;

[0192] For example, suppose there are two global variables:

[0193] user_balance=100

[0194] transaction_status="pending"

[0195] After a function is executed, the state of global variables becomes:

[0196] user_balance=80

[0197] transaction_status="completed"

[0198] The state change vector can then be represented as:

[0199] (user_balance:-20,transaction_status:"pending"->"completed")

[0200] Database operation logs refer to the log of all operations performed by the system when interacting with the database, including SQL statements such as insert, update, and delete. Based on the nature of the database operations, SQL statements can be categorized into different types, for example:

[0201] INSERT: Used to add new data.

[0202] UPDATE: Used to modify existing data

[0203] DELETE: Used to delete data.

[0204] The number of rows affected refers to the actual number of rows in the database table affected after executing a certain SQL statement; this can help assess the scope and impact of the operation.

[0205] For example, if the following SQL statement was executed in a certain operation:

[0206] UPDATE accounts SET user_balance=user_balance-20 WHERE user_id=1;

[0207] Assuming the number of rows affected is 1, the data persistence operation sequence might be recorded as follows:

[0208] Type: UPDATE

[0209] SQL statement: UPDATE accounts SET user_balance=user_balance-20 WHERE user_id=1;

[0210] Number of rows affected: 1

[0211] A business state migration trajectory is a detailed record showing how the system's state changes with function calls and database operations during business processing. For example, suppose in a business process, a function is first executed, resulting in a state change vector of (user_balance:-20, transaction_status:"pending"->"completed"), followed by an SQL update operation. The merged business migration trajectory might look like this:

[0212] Status changes: user_balance: 100 -> 80, transaction_status: "pending" -> "completed";

[0213] Data persistence operation: UPDATE accounts SET user_balance=80 WHERE user_id=1;

[0214] Noise reduction aims to filter out state changes not directly caused by business logic. These changes are often due to underlying system scheduling, thread switching, or other non-business operations, and therefore should not be included in the final state transition sequence. After noise reduction, the remaining records are the true business state change records, accurately reflecting the execution path of the business logic. For example, if the business process records certain internal system state changes (such as thread state changes) in addition to changes in user balance and transaction status, these need to be excluded. The final actual business state transition sequence might be:

[0215] user_balance:100->80;

[0216] transaction_status:"pending"->"completed".

[0217] In an optional embodiment, the method further includes:

[0218] Obtain a historically known database of logical vulnerabilities and construct a vulnerability feature vector space based on the historically known database of logical vulnerabilities.

[0219] The actual business status flow sequence is mapped to the vulnerability feature vector space, and a similarity score is calculated.

[0220] When the similarity score exceeds the preset similarity threshold, it is determined that the code segment being analyzed has a potential logical vulnerability risk, and the deep semantic analysis mode is triggered.

[0221] In deep semantic analysis mode, adversarial test cases are generated for the code segment based on a large language model, and state transition trajectory analysis is re-executed.

[0222] It should be noted that the historical known logic vulnerability sample library is a database that collects examples of identified and recorded logic vulnerabilities. These vulnerabilities may come from known security issues in past security reports, security research, or open-source projects. The sample library typically contains descriptions of vulnerabilities, affected code snippets, triggering conditions, and remediation suggestions. For example, a common logic vulnerability might be "unchecked user permissions," which means the system allows users to perform operations beyond their authorized scope. The sample library may contain such descriptions and sample code.

[0223] By analyzing various vulnerabilities in the historical vulnerability sample library, a series of features are extracted and mapped to a high-dimensional space. In this space, each vulnerability sample is represented as a vector, and the dimensions of the vector may include vulnerability type, affected variables, triggering conditions, context information, etc.

[0224] For example, the characteristics of different vulnerabilities can be organized into the following dimensions:

[0225] Vulnerability types (such as permission issues, insufficient input validation, etc.);

[0226] Global variables affected (such as user_balance, transaction_status);

[0227] The structure of conditional statements (such as if, switch, etc.);

[0228] The similarity score is calculated by comparing the features in the actual business state transition sequence with the features in the vulnerability feature vector space. This can be achieved in various ways, such as using cosine similarity or Euclidean distance. For example, if the business state transition sequence shows that the decrease in user balance is highly similar to a certain logical vulnerability feature (such as "unchecked user permissions"), a high similarity score can be obtained.

[0229] The similarity threshold is a preset standard. When the calculated similarity score exceeds this threshold, the system will consider that the current code segment may have a logical vulnerability. For example, the similarity threshold can be set to 0.8. If the actual calculated score is 0.85, subsequent analysis will be triggered. Once the similarity score is found to exceed the threshold, it means that the current code logic is highly similar to known vulnerability features, and therefore there may be undiscovered vulnerability risks.

[0230] Deep semantic analysis is a more in-depth analysis phase that uses more sophisticated algorithms and models (such as large language models) to understand the intent and context of code, thereby identifying potential logical errors. Adversarial test cases refer to code snippets specifically designed to test system boundary conditions in order to expose potential logical vulnerabilities. For example, if it is suspected that a function may be affected by unauthorized access, adversarial test cases generated by large language models may try to operate it with different user permissions to see if it leads to unexpected results.

[0231] After generating adversarial test cases, state transition trajectory analysis will be run again to observe the code's behavior under new inputs. The purpose of this step is to confirm whether vulnerabilities exist and to evaluate whether the generated adversarial test cases can effectively reveal logical flaws in the code. State transition trajectory analysis is a method to track how the state of a system changes during execution and to verify the correctness of the code by analyzing state changes. This can help discover whether the new paths introduced by the adversarial test cases lead to any abnormal behavior or errors.

[0232] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.

Claims

1. A static analysis method for code business logic vulnerabilities based on a large language model, characterized in that, include: Obtain the set of source code files and the corresponding business requirement document of the software system under test. Based on the source code file set and the business requirement document, perform semantic feature extraction to obtain a code business semantic feature map, including: The source code file set is parsed line by line to extract code function fragments and corresponding variable operation semantics; Based on the business terminology in the business requirements document, name entity alignment is performed on code function fragments and their corresponding variable operation semantics to generate business semantic annotated code blocks. Based on the function call relationships and data flow in the code blocks annotated with business semantics, corresponding business logic nodes are constructed, and a code business semantic feature map is generated based on all business logic nodes. A business logic constraint knowledge network is constructed based on the code business semantic feature graph. A business scenario simulation test case set is then generated based on this knowledge network, including: Based on each business logic node in the code business semantic feature graph, extract the corresponding precondition constraints and poststate changes; Based on precondition constraints and poststate changes, a business logic constraint knowledge network in the form of a directed acyclic graph is constructed. Identify key business branch nodes in the business logic constraint knowledge network, and generate multi-dimensional boundary value test parameters based on the key business branch nodes; Inject multi-dimensional boundary value test parameters into a preset test template to generate a set of business scenario simulation test cases covering the entire business path; Execute a set of business scenario simulation test cases, obtain the corresponding function runtime state data, and perform state transition trajectory analysis based on the function runtime state data to obtain the actual business state transition sequence. The actual business state transition sequence is compared with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes, and a set of business logic vulnerability candidates is generated based on the set of logical deviation nodes. Based on the candidate set of business logic vulnerabilities, vulnerability exploitation chain inference is performed to obtain vulnerability hazard propagation path data. Based on the vulnerability hazard propagation path data, the analysis strategy of the large language model is optimized.

2. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 1, characterized in that, Execute a set of business scenario simulation test cases to obtain the corresponding function runtime state data. Based on the function runtime state data, perform state transition trajectory analysis to obtain the actual business state transition sequence, including: Deploy the source code file set in the sandbox environment and inject the business scenario simulation test case set in sequence; Capture the input parameter values ​​and output return values ​​during function execution to generate function runtime state data; Based on the timestamp information in the function runtime state data, the state changes of each function call node are sorted to generate state transition trajectory data; The state transition trajectory data is verified based on a preset state machine model, and invalid abnormal jump points are removed to obtain the actual business state transition sequence.

3. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 2, characterized in that, The actual business state transition sequence is compared with the expected state transition path in the business logic constraint knowledge network to obtain a set of logical deviation nodes. Based on this set of logical deviation nodes, a candidate set of business logic vulnerabilities is generated, including: Calculate the distance between the actual business state transition sequence and the expected state transition path at each node; Nodes whose state vector distance is greater than a preset deviation threshold are selected and a set of logical deviation nodes is generated. Obtain the context call stack information corresponding to each node in the logical deviation node set, and determine whether there is bypass logic based on the context call stack information; When bypass logic is determined to exist, the corresponding code snippets and triggering conditions are extracted to generate a candidate set of business logic vulnerabilities.

4. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 3, characterized in that, Based on the candidate set of business logic vulnerabilities, vulnerability exploitation chains are deduced to obtain vulnerability propagation path data. Based on this data, the analysis strategy for the large language model is optimized, including: Based on the vulnerability types in the business logic vulnerability candidate set, construct a vulnerability exploitation dependency graph; Find the shortest path from the entry function to the sensitive data operation in the vulnerability exploitation dependency graph, and generate vulnerability hazard propagation path data; Transform vulnerability hazard propagation path data into natural language descriptions of counterexamples, and add the counterexamples to the prompt word library of the large language model; Fine-tuning of the large language model is performed based on counterexamples, and the semantic understanding weights of the model are updated to achieve feedback optimization of the analysis strategy.

5. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 1, characterized in that, After generating a candidate set of business logic vulnerabilities based on the set of logical deviation nodes, it also includes: Obtain the code complexity metric and business impact weight for each vulnerability in the candidate set of business logic vulnerabilities; A vulnerability risk assessment matrix is ​​constructed based on code complexity metrics and business impact weights, and the vulnerability candidate set is classified according to the vulnerability risk assessment matrix. Select the highest-risk vulnerability as the target vulnerability and generate corresponding automated remediation code suggestions; The automated repair code is suggested to be merged and compiled with the original source code, and the repaired code is verified to pass the business scenario simulation test case set.

6. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 5, characterized in that, Function runtime state data includes global variable snapshots and database operation records; State transition trajectory analysis is performed based on function runtime state data to obtain the actual business state transition sequence, including: Based on the global variable snapshot, obtain the difference in variable values ​​before and after the execution of each function, and generate a state change vector; Based on the database operation records, obtain the corresponding SQL statement type and the number of rows affected, and generate a data persistence operation sequence; The state change vector and the data persistence operation sequence are merged along the time axis to generate a complete business state migration trajectory. The noise reduction process is applied to the business state transition trajectory to remove non-business state jumps caused by the underlying system scheduling, thus obtaining the actual business state transition sequence.

7. The static analysis method for code business logic vulnerabilities based on a large language model according to claim 6, characterized in that, The method further includes: Obtain a historically known database of logical vulnerabilities and construct a vulnerability feature vector space based on the historically known database of logical vulnerabilities. The actual business status flow sequence is mapped to the vulnerability feature vector space, and a similarity score is calculated. When the similarity score exceeds the preset similarity threshold, it is determined that the code segment being analyzed has a potential logical vulnerability risk, and the deep semantic analysis mode is triggered. In deep semantic analysis mode, adversarial test cases are generated for the code segment based on a large language model, and state transition trajectory analysis is re-executed.

Images