A code-level security vulnerability detection method, an electronic device, and a storage medium

Abstract

The application relates to the technical field of vulnerability detection, in particular to a code-level security vulnerability detection method, an electronic device and a storage medium. The method comprises the following steps: acquiring a logic graph corresponding to target code, wherein the logic graph comprises role nodes, business entity nodes, operation edges and access constraint edges; acquiring an application scenario label of the target code according to the logic graph; inputting the target code into an AST parser to acquire a syntax tree corresponding to the target code; acquiring a sensitive function library B and an inhibition function library C matched with the target code according to the application scenario label of the target code; and judging whether the target code has a security vulnerability according to the B, the C and the syntax tree corresponding to the target code. The application can effectively identify an overreach risk vulnerability existing in program code.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vulnerability detection, in particular to a code-level security vulnerability detection method, an electronic device and a storage medium. BACKGROUND

[0002] At present, the privilege violation vulnerability in the financial industry or non-financial industry is a high-incidence vulnerability, and in the OWASP TOP10, the privilege violation vulnerability ranks first, and enterprises pay special attention to this kind of vulnerability, but the current mainstream static code detection tool mainly targets common vulnerabilities such as SQL injection and XSS cross-site attacks. Such vulnerabilities have obvious attack characteristics and can form unified detection rules, while the privilege violation vulnerability has strong correlation with program business processes and program design, and the traditional code detection tool cannot effectively identify it. How to effectively identify the privilege violation risk vulnerability existing in the program code is a problem to be solved. SUMMARY

[0003] The present application aims to provide a code-level security vulnerability detection method, an electronic device and a storage medium to effectively identify the privilege violation risk vulnerability existing in the program code.

[0004] According to a first aspect of the present application, a code-level security vulnerability detection method is provided, which comprises the following steps:

[0005] S100, acquiring a logical graph corresponding to the target code, the logical graph comprising a role node, a business entity node, an operation edge and an access constraint edge; the operation edge is used to connect the role node and the business entity node, and the operation edge is used to represent the operation of the role on the business entity, and the access constraint edge is used to represent the limitation condition of the operation of the role on the entity business.

[0006] S200, acquiring an application scenario label of the target code according to the logical graph.

[0007] S300, inputting the target code into an AST parser to acquire a syntax tree corresponding to the target code.

[0008] S400, acquiring a sensitive function library B and a suppression function library C matched with the target code according to the application scenario label of the target code; B comprises a plurality of sensitive functions, and C comprises a plurality of suppression functions.

[0009] S500, judging whether the target code has a security vulnerability according to B, C and the syntax tree corresponding to the target code.

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

[0011] According to a third aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described code-level security vulnerability detection method.

[0012] Compared with the prior art, the present invention has at least the following beneficial effects:

[0013] This invention obtains a logical graph corresponding to the target code, which includes roles, business entities, operations, and access constraints. Based on this logical graph, the application scenario corresponding to the target code can be determined, resulting in an application scenario tag for the target code. Furthermore, this invention obtains a sensitive function library and a suppression function library corresponding to the application scenario tag of the target code, and uses these libraries to determine whether the target code has security vulnerabilities. This integrates the vulnerability determination logic with the application scenario of the target code, avoiding interference from irrelevant functions (i.e., functions that are sensitive or suppression functions in other application scenarios but not in the target code's application scenario) on the presence of privilege escalation vulnerabilities in the target code. This effectively identifies privilege escalation vulnerabilities in the target code. Attached Figure Description

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

[0015] Figure 1 This is a flowchart of a code-level security vulnerability detection method provided in Embodiment 1 of the present invention. Detailed Implementation

[0016] 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.

[0017] Example 1:

[0018] According to this embodiment, as Figure 1 As shown, a code-level security vulnerability detection method is provided, the method including the following steps:

[0019] 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. Operation edges are used to connect role nodes and business entity nodes, and operation edges are used to represent the operation of a role on a business entity. Access constraint edges are used to represent the restriction conditions of the operation of a role on a business entity.

[0020] In this embodiment, the logical graph is a model that graphically represents the business logic relationships in the target code. It consists of role nodes, business entity nodes, operation edges, and access constraint edges. Among them, role nodes represent user roles or permission subjects; business entity nodes represent data objects or business objects that are operated on; operation edges are directed edges that connect role nodes and business entity nodes, representing the specific operations that roles perform on business entities; access constraint edges depend on the existence of operation edges and represent the restrictions that roles must satisfy when performing operations on business entities.

[0021] The logical graph in this embodiment establishes the association between roles, operations, and business entities, providing a foundation for subsequent identification of the application scenario corresponding to the target code. As a specific implementation, the process of acquiring the logical graph includes:

[0022] S110, Analyze the data model in the target code, extract business entities, and associate each business entity with a corresponding ownership identifier; the data model includes class definitions and database table structures.

[0023] In this embodiment, business entities are the core objects being manipulated. By analyzing the data model, these entities and their relationships can be accurately identified, laying the foundation for subsequent analysis of role operations on these 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`; the attribution identifier can represent relationships such as orders belonging to users and goods belonging to merchants.

[0024] S120: Analyze the role definition constants, permission annotations, and user type judgment logic in the target code to extract the role types.

[0025] In this embodiment, roles are the main entities operating the system, and different roles have different operational permissions. Extracting role types is the foundation for analyzing permission control. By analyzing role definition constants (such as ROLE_ADMIN and ROLE_USER), permission annotations (such as @PreAuthorize(“hasRole('ADMIN')”))), and user type judgment logic in the target code, the role types in the system are extracted. For example, the manager role is extracted from the constant definition public static final String ROLE_MANAGER = “manager”; the role involving the deletion of user permissions is analyzed from the annotation @RequiresPermissions(“user:delete”); and the role corresponding to the user type is identified from the judgment logic if(user.getType()== 1) {...}.

[0026] S130, scan the business content in the target code, identify the operation behavior of the business entity, and associate each operation behavior with the corresponding business entity.

[0027] In this embodiment, operational behaviors are the interaction methods between roles and business entities, and identifying these operations is key to constructing role-entity relationships. By scanning the business processing logic in the target code, various operational behaviors (such as creation, reading, updating, and deletion) on business entities are identified, and each operation is associated with the corresponding business entity. For example, the creation operation is identified from the code orderService.createOrder(...) and associated with the order entity; the deletion operation is identified from the code userDao.deleteById(...) and associated with the user entity; and the inventory update operation is identified from the code productMapper.updateStock(...) and associated with the product entity.

[0028] S140, Analyze the permission verification logic in the target code, determine the operation permissions of each role for different business entities, and form the access constraint relationship between role-business entity-operation.

[0029] In this embodiment, access constraints define the system's permission control rules, serving as the basis for determining whether operations are compliant 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”)) {...}), the operational permissions of different roles for various business entities are determined, forming a ternary access constraint relationship of role-business entity-operation. The analysis shows 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 all users' orders.

[0030] S150 integrates the extracted business entities, roles, operations, and access constraints to generate a logical graph.

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

[0032] S200, obtain the application scenario tags of the target code based on the logical graph.

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

[0034] As one specific implementation, S200 includes:

[0035] S210, reason about the application scenario labels of the logic graph to obtain several application scenario labels and their corresponding probabilities corresponding to the logic graph.

[0036] In this embodiment, different application scenarios have their specific business entities and operation modes. The application scenario to which the target code belongs can be inferred through the logic graph. Based on the roles, business entities, and operation relationships in the logic graph, inference can be performed using a pre-trained scenario recognition model to obtain possible application scenario labels and their corresponding probabilities. For example, if the logic 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 contains elements such as medical records, prescriptions, and patients, labels such as medical system (85% probability) and health management (10% probability) may be inferred.

[0037] In this embodiment, the pre-trained scene recognition model is an AI model used to infer the application scenario to which the target code belongs from the logical graph. Its core function is to analyze the features of roles, business entities, operations, and constraints in the logical graph, match typical features of known scenarios, and output scene labels and corresponding probabilities. Optionally, the pre-trained scene recognition model is a graph neural network (GNN) based model. In the pre-training stage: a large number of logical graphs of known scenarios (such as finance, healthcare, e-commerce, etc.) are collected as training data, and each graph is labeled with a corresponding scene label. The message passing mechanism of GNN (such as GraphSAGE, GAT) is used to learn node features (such as the feature vector of an account in a financial scenario) and graph structure features (such as the connection pattern of user-transfer-account), and the model is trained to recognize the mapping relationship between graph structure and scene label. In the inference stage: the logical graph of the target code is input into the pre-trained GNN, and the model outputs the matching probability of the graph with each known scenario through node feature aggregation and structural analysis. For example, in the logic graph of a financial scenario, nodes such as accounts, transactions, and risk control rules are densely connected, and the operation edges are mostly transfers and settlements; in a medical scenario, the connections between patients, medical records, and doctors are even closer, and the operation 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 know that the structure of GNNs is prior art and will not be described in detail here.

[0038] S220, if the maximum probability is greater than or equal to a preset probability threshold, then 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.

[0039] 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 as the application scenario label of the target code. Optionally, if the maximum probability is less than the preset probability threshold, or the difference between the maximum probability and the second-highest probability is less than the difference threshold, it indicates that the pre-trained scene recognition model cannot determine the application scenario of the target code with a sufficiently high confidence, or the application scenario boundary of the target code is ambiguous. In this case, a preset prompt message is output, and subsequent steps are not performed.

[0040] Optionally, the probability threshold and the difference threshold can be empirical values. For example, if the probability threshold is set to 70% and the difference threshold to 20%, and the probability of e-commerce is 75% and the probability of online retail is 25%, then e-commerce is determined as the scene label; if the probability of social network is 55% and the probability of content community is 40%, then a preset prompt message is output, and no further steps are taken.

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

[0042] In this embodiment, the target code is input into an AST parser. The parser performs lexical and syntactic analysis on the code, generating a corresponding abstract syntax tree. Each node in the syntax tree corresponds to a syntactic structure in the code. Those skilled in the art will understand that AST parsers are existing technology and will not be described in detail here.

[0043] Therefore, 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 flow in the code, providing a foundation for subsequent function identification.

[0044] S400: Based on the application scenario tags of the target code, obtain the sensitive function library B and the suppression function library C that match the target code; B includes several sensitive functions, and C includes several suppression functions.

[0045] In this embodiment, sensitive functions are functions that may lead to security vulnerabilities in specific scenarios, such as data encryption functions and permission verification functions; suppression functions are functions used to enhance security, such as input validation functions and parameter filtering functions. 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 (the application scenario of the target code); suppression function library C includes a set of functions used to mitigate or eliminate the 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., while suppression function library C may include: verifyTransaction(), checkPermission(), logAuditInfo(), etc. For medical system scenarios: sensitive function library B may include: accessMedicalRecord(), modifyPatientData(), etc.; suppression function library C may include: validateMedicalLicense(), encryptPatientInfo(), etc.

[0046] In this embodiment, the sensitive function libraries and suppression function libraries corresponding to different application scenarios are pre-established. The correspondence between sensitive functions in the sensitive function library and suppression functions in the suppression function library for 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() (permission 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 queries and data deletion.

[0047] This embodiment enables targeted security detection by matching specific function libraries to specific scenarios, thereby improving detection efficiency and accuracy.

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

[0049] In this embodiment, by checking whether sensitive functions have appropriate suppression functions for security control, it is determined whether the code has security vulnerabilities. A security vulnerability refers to a security flaw or weakness in the code that can be exploited by attackers. In this embodiment, the security vulnerability is specifically an escalation risk vulnerability. As a specific implementation, S500 includes:

[0050] S510, determine whether each node in the syntax tree corresponding to the target code is a sensitive function in B. If no node in the syntax tree corresponding to the target code is a sensitive function in B, then the target code is determined to have a security vulnerability; otherwise, proceed to S520.

[0051] In this embodiment, all nodes of the target code syntax tree are traversed to check for the existence of sensitive functions from the sensitive function library B. If no sensitive functions from the sensitive function library B are found, it indicates that the target code lacks necessary security design, and the target code is determined to have a security vulnerability; otherwise, proceed to the next step.

[0052] It should be understood that if a sensitive function exists in the target code, then the syntax tree corresponding to the target code will contain a node representing the name of that sensitive function. 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 sensitive function in B exists in the syntax tree corresponding to the target code.

[0053] S520, for the i-th node D in the syntax tree corresponding to the target code that is a sensitive function in B. i Determine D i Did a node exist previously that is in C and D? i If the corresponding suppression function exists, proceed to S521; the value of i ranges from 1 to n, where n is the number of nodes in the syntax tree corresponding to the target code that are sensitive functions in B.

[0054] In this embodiment, sensitive functions need to be controlled by corresponding suppression functions; otherwise, security vulnerabilities may occur. For each node D in the syntax tree belonging to the sensitive function library B... i (i=1 to n, where n is the total number of sensitive function nodes), check if there exists a suppression function library C that is related to D before it. i The corresponding suppression function.

[0055] It should be understood that if a suppression function exists in the target code, then the syntax tree corresponding to the target code will contain a node representing the name of that suppression function. This is achieved by... (The sentence is incomplete and requires further context to be fully translated.) i The previous node and C in D i By comparing the corresponding suppression function names, D can be determined. i Did a node exist previously that is in C and D? i The corresponding suppression function.

[0056] Optional, if D i Previously, there were no nodes in C and D. i The corresponding suppression function determines that the target code has a security vulnerability.

[0057] S521, Determine D i Previously, it was C and D. i The number of nodes corresponding to the suppression function; if the number is 1, then determine D. i Previously, it was C and D. i The system checks whether the corresponding suppression function node is effective. If the suppression is ineffective, the target code is determined to have a security vulnerability.

[0058] In this embodiment, the effectiveness of the suppression function node is determined by whether the actual input parameters of the suppression function in the target code correspond to the suppression function name. If they do not correspond, the suppression is ineffective; if they do correspond, the suppression is effective. As a specific implementation, the parameter node corresponding to the suppression function is first located, and then the assignment chain of the parameters corresponding to the suppression function is traced back through 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, it is determined that the actual input parameters of the suppression function in the target code correspond to the suppression function name; if the original source type does not match the function of the suppression function name, it is determined that the actual input parameters of the suppression function in the target code do not correspond to the suppression function name. A preset rule base can be used to determine whether the original source type matches the function of the suppression function name. The preset rule base stores different matching relationships between suppression function names and different source types, which will not be elaborated here.

[0059] Those skilled in the art will know that the process of determining whether a suppression function is effective is existing technology. The core tools include static analysis tools (TChecker, SyntaxFlow) and dynamic tracing frameworks (libdft). These tools can identify whether a suppression function is effective through AST parsing, data flow tracing, and taint analysis; these will not be elaborated here.

[0060] In this embodiment, S521 further includes: if the quantity is greater than or equal to 2, then determine D. i Previously, it was C and D. i Check if each node of the corresponding suppression function is effectively suppressed. If all nodes are effectively suppressed, then determine D. i Previously, it was C and D. i If the nodes of the corresponding suppression function are redundant, a warning message will be issued.

[0061] In this embodiment, redundancy refers to multiple suppression functions performing the same security control, increasing 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.

[0062] In this embodiment, if D i Previously, it was C and D. i If at least one node of the corresponding suppression function is ineffective, then the target code is determined to have a security vulnerability.

[0063] In this embodiment, if D i Previously, it was C and D. i If the nodes of the corresponding suppression function are not redundant, no warning message will be issued.

[0064] As a specific implementation, S500 further includes: outputting the level of a security vulnerability. Optionally, the level of the security vulnerability is determined based on whether there is a node for a sensitive function of B in the syntax tree corresponding to the target code, and if so, based on the number of risky sensitive functions among the nodes for sensitive functions of B in the syntax tree; for example, when there is no node for a sensitive function of 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 for a sensitive function of B in the syntax tree corresponding to the target code, the level of the security vulnerability is determined by the ratio of the number m of risky sensitive functions among n sensitive functions to n. Here, a risky sensitive function refers to a sensitive function that has no corresponding suppression function or whose corresponding suppression function is ineffective. It should be understood that the higher the level of the security vulnerability, the more serious the security vulnerability.

[0065] This embodiment obtains the logical graph corresponding to the target code. This logical graph includes roles, business entities, operations, and access constraints. Based on this logical graph, the application scenario corresponding to the target code can be determined, and the application scenario label corresponding to the target code can be obtained. On this basis, this embodiment obtains the sensitive function library and suppression function library corresponding to the application scenario label corresponding to the target code, and uses the sensitive function library and suppression function library to determine whether there are security vulnerabilities in the target code. This combines the judgment logic of security vulnerabilities in the target code with the application scenario corresponding to the target code, avoiding interference from irrelevant functions (i.e., functions that are sensitive or suppression functions in other application scenarios, but not in the application scenario corresponding to the target code) on whether there are privilege escalation risk vulnerabilities in the target code, and can effectively identify privilege escalation risk vulnerabilities in the target code.

[0066] Example 2:

[0067] 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, it performs the following steps:

[0068] Obtain the logical graph corresponding to the target code. The logical graph includes role nodes, business entity nodes, operation edges, and access constraint edges. Operation edges are used to connect role nodes and business entity nodes, and operation edges are used to represent the operation of a role on a business entity. Access constraint edges are used to represent the restriction conditions of the operation of a role on a business entity.

[0069] The application scenario tags of the target code are obtained based on the logical graph.

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

[0071] Based on the application scenario tags of the target code, obtain the sensitive function library B and the suppression function library C that match the target code; B includes several sensitive functions, and C includes several suppression functions.

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

[0073] Example 3:

[0074] This embodiment provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps:

[0075] Obtain the logical graph corresponding to the target code. The logical graph includes role nodes, business entity nodes, operation edges, and access constraint edges. Operation edges are used to connect role nodes and business entity nodes, and operation edges are used to represent the operation of a role on a business entity. Access constraint edges are used to represent the restriction conditions of the operation of a role on a business entity.

[0076] The application scenario tags of the target code are obtained based on the logical graph.

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

[0078] Based on the application scenario tags of the target code, obtain the sensitive function library B and the suppression function library C that match the target code; B includes several sensitive functions, and C includes several suppression functions.

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

[0080] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can 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 a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual 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.

[0081] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A code-level security vulnerability detection method, characterized in that, The method includes 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. Operation edges are used to connect role nodes and business entity nodes. Operation edges are used to represent the operation of a role on a business entity. Access constraint edges are used to represent the restriction conditions of the operation of a role on a business entity. S200, Obtain the application scenario tags of the target code based on the logical graph; S300: Input the target code into the AST parser to obtain the syntax tree corresponding to the target code; S400: Based on the application scenario tags of the target code, obtain the sensitive function library B and the suppression function library C that match the target code; B includes several sensitive functions, and C includes several suppression functions. S500 determines 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 graph includes: S110, Analyze the data model in the target code, extract business entities, and associate each business entity with a corresponding ownership identifier; the data model includes class definitions and database table structures. S120, Analyze the role definition constants, permission annotations and user type judgment logic in the target code, and extract the role types; S130, Scan the business content in the target code, identify the operation behavior on the business entity, and associate each operation behavior with the corresponding business entity; S140, Analyze the permission verification logic in the target code, determine the operation permissions of each role to different business entities, and form the access constraint relationship between role-business entity-operation; S150 integrates the extracted business entities, roles, operations, and access constraints to generate a logical graph.

3. The code-level security vulnerability detection method according to claim 1, characterized in that, S200 includes: S210, reason about the application scenario labels of the logic graph to obtain several application scenario labels and their corresponding probabilities corresponding to the logic graph; S220, if the maximum probability is greater than or equal to a preset probability threshold, then 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, The S500 includes: S510, determine whether each node in the syntax tree corresponding to the target code is a sensitive function in B. If no node in the syntax tree corresponding to the target code is a sensitive function in B, then the target code is determined to have a security vulnerability; otherwise, proceed to S520. S520, for the i-th node D in the syntax tree corresponding to the target code that is a sensitive function in B. i Determine D i Did a node exist previously that is in C and D? i If the corresponding suppression function exists, proceed to S521; the value of i ranges from 1 to n, where n is the number of nodes in the syntax tree corresponding to the target code that are sensitive functions in B; S521, Determine D i Previously, it was C and D. i The number of nodes corresponding to the suppression function; if the number is 1, then determine D. i Previously, it was C and D. i The system checks whether the corresponding suppression function node is effective. If the suppression is ineffective, the target code is determined to have a security vulnerability.

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

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

7. The code-level security vulnerability detection method according to claim 6, characterized in that, The process of determining the level of a 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 the n sensitive functions with risks 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, characterized in that, When the processor executes the computer program, it implements the code-level security vulnerability detection method as described in any one of claims 1 to 7.

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

Images