Code-level security vulnerability detection method, electronic equipment and storage medium

Abstract

The invention relates to the technical field of vulnerability detection, in particular to a code-level security vulnerability detection method, electronic equipment and a storage medium. The method comprises the steps of obtaining a logic graph corresponding to a target code, wherein the logic graph comprises a role node, a service entity node, an operation edge and an access constraint edge; obtaining an application scene label of the target code according to the logic graph; inputting the target code into an AST resolver to obtain a syntax tree corresponding to the target code; obtaining a sensitive function library B and a suppression function library C matched with the target code according to the application scene label of the target code; and judging whether the target code has security vulnerabilities or not according to the syntax trees corresponding to the B, the C and the target code. According to the method, the unauthorized risk vulnerabilities in the program codes can be effectively identified.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability detection, and in particular to a code-level security vulnerability detection method, electronic equipment, and storage medium. Background Art

[0002] Currently, privilege escalation vulnerabilities are a common vulnerability in both the financial and non-financial sectors. They rank first in the OWASP TOP10, and companies are paying particular attention to them. However, current mainstream static code detection tools primarily target common vulnerabilities such as SQL injection and XSS cross-site attacks. These vulnerabilities have distinct attack signatures and can be standardized with unified detection rules. However, privilege escalation vulnerabilities are strongly associated with program business processes and design, making them ineffective for traditional code detection tools. Therefore, effectively identifying privilege escalation vulnerabilities in program code is a pressing issue. Summary of the Invention

[0003] The present invention aims to provide a code-level security vulnerability detection method, electronic device and storage medium to effectively identify unauthorized risk vulnerabilities in program codes.

[0004] According to a first aspect of the present invention, a method for detecting code-level security vulnerabilities is provided, the method comprising the following steps: S100, obtain the logical graph corresponding to the target code, the logical graph includes role nodes, business entity nodes, operation edges and access constraint edges; the operation edges are used to connect the role nodes and the business entity nodes, the operation edges are used to represent the role's operation on the business entity, and the access constraint edges are used to represent the restriction conditions of the role's operation on the entity business.

[0005] S200: Obtain an application scenario label of the target code according to the logic graph.

[0006] S300: Input the target code into the AST parser to obtain the syntax tree corresponding to the target code.

[0007] S400 , obtaining a sensitive function library B and a suppressed function library C matching the target code according to the application scenario label of the target code; B includes several sensitive functions, and C includes several suppressed functions.

[0008] S500: Determine whether the target code has a security vulnerability based on B, C, and the syntax tree corresponding to the target code.

[0009] According to a second aspect of the present invention, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned code-level security vulnerability detection method when executing the computer program.

[0010] According to a third aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the computer program implements the above-mentioned code-level security vulnerability detection method.

[0011] Compared with the prior art, the present invention has at least the following beneficial effects: The present invention obtains a logical graph corresponding to the target code, which includes roles, business entities, operations and access constraints. Based on the logical graph, the application scenario corresponding to the target code can be judged, and the application scenario label corresponding to the target code can be obtained; on this basis, the present invention obtains a sensitive function library and a suppression function library corresponding to the application scenario label corresponding to the target code, and uses the sensitive function library and the suppression function library to judge whether there is a security vulnerability in the target code, so that the judgment logic of the security vulnerability of the target code is combined with the application scenario corresponding to the target code, avoiding the interference of irrelevant functions (that is, sensitive functions or suppression functions in other application scenarios, but not sensitive functions or suppression functions in the application scenario corresponding to the target code) on whether there is an unauthorized risk vulnerability in the target code, and can effectively identify the unauthorized risk vulnerability existing in the target code. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0013] Figure 1 This is a flowchart of the code-level security vulnerability detection method provided in Example 1 of the present invention. DETAILED DESCRIPTION

[0014] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of the present invention.

[0015] Example 1: According to this embodiment, Figure 1 As shown, a code-level security vulnerability detection method is provided, the method comprising the following steps: S100, obtain the logical graph corresponding to the target code, the logical graph includes role nodes, business entity nodes, operation edges and access constraint edges; the operation edges are used to connect the role nodes and the business entity nodes, the operation edges are used to represent the role's operation on the business entity, and the access constraint edges are used to represent the restriction conditions of the role's operation on the entity business.

[0016] In this embodiment, the logic graph is a model that graphically represents the business logic relationship in the target code, and is composed of role nodes, business entity nodes, operation edges and access constraint edges; among them, the role node represents the user role or authority subject; the business entity node represents the data object or business object being operated; the operation edge is a directed edge connecting the role node and the business entity node, representing the specific operation of the role on the business entity; the access constraint edge depends on the existence of the operation edge, and the access constraint edge represents the restriction conditions that the role must meet when operating the business entity.

[0017] The logic map of this embodiment establishes the relationship between roles, operations and business entities, providing a basis for the subsequent identification of application scenarios corresponding to the target code. As a specific implementation method, the acquisition process of the logic map includes: S110, analyzing the data model in the target code, extracting business entities, and associating each business entity with a corresponding attribution identifier; the data model includes class definitions and database table structures.

[0018] In this embodiment, business entities are the core objects being manipulated. By analyzing the data model, these entities and their ownership relationships can be accurately identified, laying the foundation for subsequent analysis of roles' operations on the entities. For example, if the target code is e-commerce system code, the order business entity can be extracted from the class definition class Order {...} and the database table orders; the user business entity can be extracted from the class definition class User {...} and the database table users. Ownership identifiers can indicate relationships such as orders belonging to users and products belonging to merchants.

[0019] S120, analyzing the role definition constants, permission annotations, and user type judgment logic in the target code to extract the role type.

[0020] In this embodiment, roles are the main body of system operations, and different roles have different operational permissions. Extracting role types is the basis for analyzing permission control. Role types in the system are extracted by analyzing the target code's role definition constants (such as ROLE_ADMIN and ROLE_USER), permission annotations (such as @PreAuthorize("hasRole('ADMIN')")), and user type determination logic. For example, the constant definition public static final String ROLE_MANAGER = "manager" extracts the manager role; the annotation @RequiresPermissions("user:delete") identifies the role associated with user deletion permissions; and the determination logic if(user.getType() == 1) {...} identifies the role corresponding to the user type.

[0021] S130 , scanning the business content in the target code, identifying the operation behavior on the business entity, and associating each operation behavior with the corresponding business entity.

[0022] In this embodiment, operations represent the interaction between roles and business entities. Identifying these operations is key to building role-entity relationships. By scanning the business processing logic within the target code, various operations on business entities (such as create, read, update, and delete) are identified and each operation is associated with the corresponding business entity. For example, the create operation is identified from the code orderService.createOrder(...) and associated with the order entity; the delete operation is identified from the code userDao.deleteById(...) and associated with the user entity; and the update stock operation is identified from the code productMapper.updateStock(...) and associated with the product entity.

[0023] S140 , analyzing the permission verification logic in the target code, determining the operation permissions of each role on different business entities, and forming an access constraint relationship between role-business entity-operation.

[0024] In this embodiment, access constraints define the system's permission control rules, serving as the basis for determining operational compliance and identifying logical vulnerabilities such as unauthorized operations. By analyzing the permission verification logic in the target code (e.g., if(hasPermission(user, "order:edit")) {...}), we determine the operational permissions of different roles for various business entities, forming a ternary access constraint relationship of role, business entity, and operation. This analysis reveals that administrators can delete any user, while ordinary users can only delete their own accounts; managers can approve orders under 100,000 yuan, while directors can approve all orders; and users can only view their own orders, while customer service representatives can view the orders of all users.

[0025] S150: Integrate the extracted business entities, roles, operations, and access constraint relationships to generate a logical graph.

[0026] In this embodiment, the logical graph integrates scattered business elements and relationships into an organic whole, providing structured data for subsequent scenario identification and security analysis. By integrating the previously extracted business entities, role types, operation behaviors, and access constraint relationships, a complete logical graph is constructed in the form of nodes and edges. For example, a simplified e-commerce system logical graph may include: role nodes: users, administrators, merchants; business entity nodes: orders, products, user information; operation edges: users - create - orders, administrators - delete - user information, merchants - update - products; access constraint edges: users can only create their own orders, and administrators can delete illegal user information.

[0027] S200: Obtain an application scenario label of the target code according to the logic graph.

[0028] In this embodiment, application scenario tags are used to identify the business domain or application scenario to which the target code belongs, such as financial payment, e-commerce, or medical systems. The security risks of the same code may vary in different application scenarios. Scenario tags enable targeted security testing, improving detection accuracy and reducing false positive rates.

[0029] As a specific implementation, S200 includes: S210 , inferring the application scenario labels of the logic graph to obtain a number of application scenario labels and corresponding probabilities corresponding to the logic graph.

[0030] In this embodiment, different application scenarios have their own specific business entities and operation modes. The application scenario to which the target code belongs can be inferred through the logical graph. Based on the roles, business entities, and operation relationships in the logical graph, reasoning can be performed using a pre-trained scenario recognition model to obtain possible application scenario labels and their corresponding probabilities. For example, if the logical graph contains entities and operations such as accounts, transactions, and transfers, labels such as financial payment (70% probability) and e-wallet (20% probability) may be inferred; if it includes elements such as medical records, prescriptions, and patients, labels such as medical system (85% probability) and health management (10% probability) may be inferred.

[0031] In this embodiment, the pre-trained scenario recognition model is an AI model used to infer the application scenario to which the target code belongs from a logical graph. Its core function is to analyze the features of roles, business entities, operations, and constraints in the logical graph, match them with typical features of known scenarios, and output scenario labels and corresponding probabilities. Optionally, the pre-trained scenario recognition model is based on a graph neural network (GNN). During the pre-training phase, a large number of logical graphs from known scenarios (such as finance, healthcare, and e-commerce) are collected as training data, and each graph is annotated with a corresponding scenario label. Using the GNN's message-passing mechanism (such as GraphSAGE and GAT), node features (such as the feature vectors of accounts in financial scenarios) and graph structure features (such as the user-transfer-account connection pattern) are learned. The model is trained to identify the mapping between graph structure and scenario labels. During the inference phase, the target code's logical graph is input into the pre-trained GNN. The model aggregates node features and analyzes the structure to output the probability of matching the graph with each known scenario. For example, in the logical graph of financial scenarios, nodes such as accounts, transactions, and risk control rules are densely connected, and the operational edges are mostly transfers and settlements. In medical scenarios, the connections between patients, medical records, and doctors are even closer, and the operational edges are mostly queries and modifications (with strict permission constraints). GNNs can capture these structural differences and distinguish between scenario types. Those skilled in the art will appreciate that the structure of GNNs is existing technology and will not be further explained here.

[0032] S220: If the maximum probability is greater than or equal to a preset probability threshold, determine whether the difference between the maximum probability and the second highest probability is greater than or equal to a preset difference threshold; if so, determine the application scenario label corresponding to the maximum probability as the application scenario label of the target code.

[0033] In this embodiment, when the maximum probability is greater than or equal to the probability threshold, and the difference between the maximum probability and the second-highest probability is greater than or equal to the difference threshold, the label of the application scenario corresponding to the maximum probability is determined to be the application scenario label of the target code. Optionally, if the maximum probability is less than a preset probability threshold, or the difference between the maximum probability and the second-highest probability is less than the difference threshold, this indicates that the pre-trained scene recognition model cannot determine the application scenario of the target code with a sufficiently high confidence level, or that the boundary of the application scenario of the target code is fuzzy. In this case, a preset prompt message is output, and subsequent steps are not performed.

[0034] Optionally, the probability threshold and difference threshold are empirical values. For example, if the probability threshold is set to 70% and the difference threshold is set to 20%, and if the inference result is that the probability of e-commerce is 75% and the probability of online retail is 25%, then e-commerce is determined as the scenario label; if the inference result is that the probability of social network is 55% and the probability of content community is 40%, then a preset prompt message is output and subsequent steps are not performed.

[0035] S300: Input the target code into the AST parser to obtain the syntax tree corresponding to the target code.

[0036] In this embodiment, the target code is input into an AST parser, which performs lexical analysis and syntactic analysis on the code to generate a corresponding abstract syntax tree. Each node in the syntax tree corresponds to a grammatical structure in the code. Those skilled in the art will appreciate that AST parsers are state of the art and will not be described in detail here.

[0037] Thus, this embodiment obtains the syntax tree corresponding to the target code. The syntax tree is structured data that facilitates program analysis and can accurately capture the function call relationship and execution process in the code, providing a basis for subsequent function identification.

[0038] S400 , obtaining a sensitive function library B and a suppressed function library C matching the target code according to the application scenario label of the target code; B includes several sensitive functions, and C includes several suppressed functions.

[0039] In this embodiment, sensitive functions are functions that may cause security vulnerabilities in specific scenarios, such as data encryption functions, permission verification functions, etc.; suppressed functions are functions used to enhance security, such as input verification functions, parameter filtering functions, etc. The security sensitivity of functions varies in different application scenarios. Sensitive function library B includes a set of functions that may introduce security risks in specific application scenarios (application scenarios of target codes); suppressed function library C includes a set of functions used to mitigate or eliminate security risks of sensitive functions in sensitive function library B. For example, for financial payment scenarios: sensitive function library B may include: transferMoney(), updateBalance(), processPayment(), etc., and suppressed function library C may include: verifyTransaction(), checkPermission(), logAuditInfo(), etc. For medical system scenarios: sensitive function library B may include: accessMedicalRecord(), modifyPatientData(), etc.; suppressed function library C may include: validateMedicalLicense(), encryptPatientInfo(), etc.

[0040] In this embodiment, the sensitive function library and the suppression function library corresponding to different application scenarios are pre-established. The correspondence between the sensitive functions in the sensitive function library and the suppression functions in the suppression function library corresponding to any application scenario is also known. One sensitive function may correspond to multiple suppression functions (for different risk points), and one suppression function may also correspond to multiple sensitive functions (for common risks). For example, the risk points of the sensitive function (user information modification) include unauthorized modification and input injection, corresponding to the suppression functions checkUserRole() (authority verification) and filterInput() (input filtering). For example, the suppression function filterSQL() (SQL injection filtering) can correspond to multiple sensitive functions involving SQL operations such as database query and data deletion.

[0041] This embodiment can achieve targeted security detection by matching specific function libraries with scenarios, thereby improving detection efficiency and accuracy.

[0042] S500: Determine whether the target code has a security vulnerability based on B, C, and the syntax tree corresponding to the target code.

[0043] In this embodiment, by checking whether sensitive functions have appropriate suppression functions for security control, it is determined whether the code has security vulnerabilities. Wherein, security vulnerabilities refer to security defects or weaknesses in the code that may be exploited by attackers. The security vulnerabilities in this embodiment are specifically unauthorized risk vulnerabilities. As a specific implementation method, S500 includes: S510, determine whether each node in the syntax tree corresponding to the target code is a sensitive function in B. If any node in the syntax tree corresponding to the target code is not a sensitive function in B, it is determined that the target code has a security vulnerability; otherwise, enter S520.

[0044] In this embodiment, all nodes of the target code syntax tree are traversed to check whether there are any sensitive functions in the sensitive function library B. If no sensitive functions in the sensitive function library B are found, it indicates that the target code lacks the necessary security design, and it is determined that there is a security vulnerability in the target code; otherwise, the process proceeds to the next step.

[0045] It should be understood that if a sensitive function exists in the target code, then a node representing the sensitive function name will exist in the syntax tree corresponding to the target code. By comparing all nodes in the syntax tree corresponding to the target code with all sensitive function names in B, it can be determined whether the syntax tree corresponding to the target code contains the sensitive function in B.

[0046] S520, for the i-th node D in the syntax tree corresponding to the target code, which is the sensitive function in B i , judge D i Is there a node in C and D before? i If the corresponding suppression function exists, then go to S521; the value range of i is 1 to n, and n is the number of nodes of the sensitive function in B in the syntax tree corresponding to the target code.

[0047] In this embodiment, sensitive functions need to have corresponding suppression functions for security control, otherwise it may lead to security vulnerabilities. i (i=1 to n, n is the total number of sensitive function nodes), check whether there is a previous suppression function library C with D i The corresponding suppression function.

[0048] It should be understood that if there is a suppression function in the target code, then there will be a node representing the name of the suppression function in the syntax tree corresponding to the target code. i The previous node and C and D i The corresponding suppression function name comparison method can determine D i Is there a node in C and D before? i The corresponding suppression function.

[0049] Optional, if D i There was no node between C and D before i The corresponding suppression function determines that the target code has a security vulnerability.

[0050] S521, judgment D i Previously, it was C and D i The number of nodes of the corresponding inhibition function, if the number is 1, then judge D i Previously, it was C and D i Whether the node of the corresponding inhibition function is inhibited effectively, if the inhibition is not effective, it is determined that the target code has a security vulnerability.

[0051] In this embodiment, whether the suppression of the node of the suppression function is effective is determined by judging whether the actual incoming parameters of the suppression function in the target code correspond to the name of the suppression function. If not, the suppression is invalid; if corresponding, the suppression is effective. As a specific implementation method, first locate the parameter node corresponding to the suppression function, and then trace back the assignment chain of the parameters corresponding to the suppression function through the data flow to identify the original source type of the suppression function; if the original source type matches the function of the suppression function name, then judge that the actual incoming parameters of the suppression function in the target code correspond to the name of the suppression function; if the original source type does not match the function of the suppression function name, then judge that the actual incoming parameters of the suppression function in the target code do not correspond to the name of the suppression function. Among them, the preset rule library can be used to judge whether the original source type matches the function of the suppression function name. The preset rule library stores the matching relationship between different suppression function names and different source types, which will not be repeated here.

[0052] Those skilled in the art are aware that the process of determining whether a suppression function is effective is an existing technology. Core tools include static analysis tools (TChecker, SyntaxFlow) and a dynamic tracing framework (libdft). These tools can identify whether a suppression function is effective through AST parsing, data flow tracing, and taint analysis. This will not be described in detail here.

[0053] In this embodiment, S521 further includes: if the number is greater than or equal to 2, then determine D i Previously, it was C and D i Whether each node of the corresponding inhibition function is inhibited effectively, if all the inhibitions are effective, then judge D i Previously, it was C and D i Whether the node of the corresponding suppression function is redundant. If it is redundant, a prompt message will be issued.

[0054] In this embodiment, redundancy refers to the situation where multiple suppression functions execute the same security control, adding unnecessary overhead. As a specific implementation, if two suppression functions have the same name and the same actual input parameters, they are considered redundant. For example, for the sensitive function processPayment(), there are two suppression functions, validateAmount1() and validateAmount2(), which have identical functionality and are therefore considered redundant.

[0055] In this embodiment, if D i Previously, it was C and D i If at least one node of the corresponding inhibition function is invalid, it is determined that the target code has a security vulnerability.

[0056] In this embodiment, if D i Previously, it was C and D i If the corresponding suppression function node is not redundant, no prompt message will be issued.

[0057] As a specific embodiment, S500 also includes: outputting the level of the security vulnerability. Optionally, the level of the security vulnerability is determined based on whether there is a node of the sensitive function in B in the syntax tree corresponding to the target code, and if so, based on the number of risky sensitive functions in the nodes of the sensitive function in B in the syntax tree; for example, when there is no node of the sensitive function in B in the syntax tree corresponding to the target code, the level of the security vulnerability is determined to be 1; when there is a node of the sensitive function in B in the syntax tree corresponding to the target code, the ratio of the number m of risky sensitive functions in n sensitive functions to n is determined as the level of the security vulnerability. Among them, a risky sensitive function refers to a sensitive function that has no corresponding inhibition function or whose corresponding inhibition function has no effect. It should be understood that the greater the level of the security vulnerability, the more serious the security vulnerability.

[0058] This embodiment obtains a logical graph corresponding to the target code, which includes roles, business entities, operations and access constraints. Based on the logical graph, the application scenario corresponding to the target code can be judged, and the application scenario label corresponding to the target code can be obtained; on this basis, this embodiment obtains a sensitive function library and a suppression function library corresponding to the application scenario label corresponding to the target code, and uses the sensitive function library and the suppression function library to judge whether there are security vulnerabilities in the target code, so that the judgment logic of the security vulnerabilities of the target code is combined with the application scenario corresponding to the target code, avoiding the interference of irrelevant functions (that is, sensitive functions or suppression functions in other application scenarios, but not sensitive functions or suppression functions in the application scenario corresponding to the target code) on whether there are unauthorized risk vulnerabilities in the target code, and can effectively identify unauthorized risk vulnerabilities in the target code.

[0059] Example 2: This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed: Obtain a logical graph corresponding to the target code, wherein the logical graph includes role nodes, business entity nodes, operation edges and access constraint edges; the operation edges are used to connect role nodes and business entity nodes, the operation edges are used to represent the role's operations on the business entity, and the access constraint edges are used to represent the restrictions on the role's operations on the entity business.

[0060] An application scenario label of the target code is obtained according to the logic graph.

[0061] Input the target code into the AST parser to obtain the syntax tree corresponding to the target code.

[0062] A sensitive function library B and a suppression function library C matching the target code are obtained according to the application scenario label of the target code; B includes several sensitive functions, and C includes several suppression functions.

[0063] Determine whether the target code has a security vulnerability based on B, C, and the syntax tree corresponding to the target code.

[0064] Example 3: This embodiment provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the following steps are implemented: Obtain a logical graph corresponding to the target code, wherein the logical graph includes role nodes, business entity nodes, operation edges and access constraint edges; the operation edges are used to connect role nodes and business entity nodes, the operation edges are used to represent the role's operations on the business entity, and the access constraint edges are used to represent the restrictions on the role's operations on the entity business.

[0065] An application scenario label of the target code is obtained according to the logic graph.

[0066] Input the target code into the AST parser to obtain the syntax tree corresponding to the target code.

[0067] A sensitive function library B and a suppression function library C matching the target code are obtained according to the application scenario label of the target code; B includes several sensitive functions, and C includes several suppression functions.

[0068] Determine whether the target code has a security vulnerability based on B, C, and the syntax tree corresponding to the target code.

[0069] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0070] Although some specific embodiments of the present invention have been described in detail by way of example, it should be understood by those skilled in the art that the above examples are for illustration only and are not intended to limit the scope of the present invention. It should also be understood by those skilled in the art that various modifications may be made to the embodiments without departing from the scope and spirit of the present invention. The scope of the present invention is defined by the appended claims.

Claims

1. A code-level security vulnerability detection method, characterized in that: The method comprises the following steps: S100: Obtain a logical graph corresponding to the target code, wherein the logical graph includes role nodes, business entity nodes, operation edges, and access constraint edges; the operation edges are used to connect role nodes and business entity nodes, the operation edges are used to represent the operations of the role on the business entity, and the access constraint edges are used to represent the restrictions on the operations of the role on the entity business; S200, obtaining an application scenario label of the target code according to the logic graph; S300, input the target code into the AST parser to obtain the syntax tree corresponding to the target code; S400, obtaining a sensitive function library B and a suppression function library C matching the target code according to the application scenario label of the target code; B includes several sensitive functions, and C includes several suppression functions; S500: Determine whether the target code has a security vulnerability based on B, C, and the syntax tree corresponding to the target code.

2. The code-level security vulnerability detection method according to claim 1, characterized in that: The process of obtaining the logic map includes: S110, analyzing the data model in the target code, extracting business entities, and associating each business entity with a corresponding attribution identifier; the data model includes class definitions and database table structures; S120, analyzing the role definition constants, permission annotations, and user type judgment logic in the target code to extract the role type; S130, scanning the business content in the target code, identifying the operation behavior on the business entity, and associating each operation behavior with the corresponding business entity; S140 , analyzing the permission verification logic in the target code, determining the operation permissions of each role on different business entities, and forming an access constraint relationship between role, business entity, and operation; S150: Integrate the extracted business entities, roles, operations, and access constraint relationships to generate a logical graph.

3. The code-level security vulnerability detection method according to claim 1, characterized in that: S200 includes: S210, inferring the application scenario labels of the logic graph to obtain a number of application scenario labels corresponding to the logic graph and corresponding probabilities; S220: If the maximum probability is greater than or equal to a preset probability threshold, determine whether the difference between the maximum probability and the second highest probability is greater than or equal to a preset difference threshold; if so, determine the application scenario label corresponding to the maximum probability as the application scenario label of the target code.

4. The code-level security vulnerability detection method according to claim 1, characterized in that: S500 includes: S510, determining whether each node in the syntax tree corresponding to the target code is a sensitive function in B. If any node in the syntax tree corresponding to the target code is not a sensitive function in B, it is determined that the target code has a security vulnerability; otherwise, proceeding to S520; S520, for the i-th node D in the syntax tree corresponding to the target code, which is the sensitive function in B i , judge D i Is there a node in C and D before? i If the corresponding suppression function exists, then go to S521; the value range of i is 1 to n, and n is the number of nodes in the syntax tree corresponding to the target code that are sensitive functions in B; S521, judgment D i Previously, it was C and D i The number of nodes of the corresponding inhibition function, if the number is 1, then judge D i Previously, it was C and D i Whether the node of the corresponding inhibition function is inhibited effectively, if the inhibition is not effective, it is determined that the target code has a security vulnerability.

5. The code-level security vulnerability detection method according to claim 4, characterized in that: S521 also includes: if the number is greater than or equal to 2, then determine D i Previously, it was C and D i Whether each node of the corresponding inhibition function is inhibited effectively, if all inhibitions are effective, then judge D i Previously, it was C and D i Whether the node of the corresponding suppression function is redundant. If it is redundant, a prompt message will be issued.

6. The code-level security vulnerability detection method according to claim 1, characterized in that: S500 further includes: outputting the level of the security vulnerability.

7. The code-level security vulnerability detection method according to claim 6, characterized in that: The process of determining the level of the security vulnerability includes: when there is no node of the sensitive function in B in the syntax tree corresponding to the target code, the level of the security vulnerability is determined to be 1; when there is a node of the sensitive function in B in the syntax tree corresponding to the target code, the ratio of the number m of sensitive functions with risks among n sensitive functions to n is determined as the level of the security vulnerability; n is the number of nodes of the sensitive function in B in the syntax tree corresponding to the target code.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the code-level security vulnerability detection method according to any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the code-level security vulnerability detection method according to any one of claims 1 to 7 is implemented.

Images