Vulnerability detection method and device

Abstract

One or more embodiments of the invention provide a vulnerability detection method and device. According to the method and device, a to-be-detected target code is subjected to static analysis, and a taint path set in the target code is obtained through recognition; performing priority ranking on each taint path in the taint path set through rules such as DFS, and determining the taint path with higher priority; and selecting taint paths with higher priorities through a preset large language model to perform vulnerability detection. According to the method and the device, semantic filtering is carried out on the taint path set through a preset large language model, and unavailable taint paths in the taint path set are filtered out. According to the method and the device, under the condition that whether the taint path has the vulnerability cannot be judged based on the current information, the context information of the taint path is called based on the MCP, and vulnerability detection is continued based on the context information.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of computer technology, and particularly relate to a vulnerability detection method and device. BACKGROUND

[0002] Code vulnerabilities, i.e., code defects, are usually intentionally or unintentionally generated when editing software program code during the software development process. The existence of code vulnerabilities threatens the safe and stable operation of related software, and even causes serious data security problems. With the development of computer technology and the improvement of people's awareness of computer network security, code vulnerability detection is becoming more and more important.

[0003] In related technologies, vulnerability detection of software source code is realized through manual audit or by using static application security testing (SAST) and the like. However, for large and complex software, the workload of vulnerability detection may grow exponentially, and the above vulnerability detection methods are very low in efficiency. SUMMARY

[0004] One or more embodiments of the present specification provide a vulnerability detection method and device to improve the vulnerability detection efficiency.

[0005] In a first aspect, one or more embodiments of the present specification provide a vulnerability detection method, comprising: performing static analysis on target code to be detected to identify a taint path in the target code, and obtaining a first taint path set; performing priority sorting on each taint path in the first taint path set according to a preset rule, and obtaining a second taint path set; selecting, by using a preset large language model, a taint path with a higher priority in the second taint path set as a current taint path, and performing vulnerability detection on the current taint path.

[0006] In the above technical solution, there may be a large number of taint paths to be detected in the first taint path set obtained based on static analysis. Therefore, compared with randomly selecting a taint path from a large number of taint paths for vulnerability detection, the taint paths are sorted by using a preset rule to form a second taint path set, and a taint path with a higher priority is obtained from the second taint path set by using a preset large language model for vulnerability detection, which can quickly identify a taint path with a higher risk level and improve the vulnerability detection efficiency. In addition, the language understanding and reasoning ability of the large language model is used to realize vulnerability detection of the taint path, which can reduce the labor cost and improve the vulnerability detection efficiency without much human intervention.

[0007] In a possible implementation manner, the vulnerability detection method further includes: The preset large language model is used to perform semantic analysis on each of the second set of tainted paths, and according to a result of the semantic analysis, a non-exploitable tainted path in the second set of tainted paths is identified and filtered out.

[0008] In the technical solution, the semantic filtering of the second set of tainted paths is implemented by using the language analysis capability of the preset large language model. The remaining tainted paths in the filtered second set of paths are all the tainted paths that cannot be determined as exploitable or non-exploitable by the semantic understanding capability of the preset large language model. Therefore, the number of the tainted paths in the second set of tainted paths is reduced, the data processing amount of the vulnerability detection step is reduced, and the vulnerability detection efficiency is improved.

[0009] In a possible implementation manner, the vulnerability detection method further includes: In a case where it is determined by the vulnerability detection that the current tainted path has a vulnerability, vulnerability detail information corresponding to the current tainted path is acquired. The vulnerability detail information includes at least one of the following: tainted path information, vulnerability position information, vulnerability type information, a risk level, a vulnerability exploitation condition, a related code segment, and a repair suggestion.

[0010] In the technical solution, in a case where it is determined that a tainted path has a vulnerability, instead of simply recording that the tainted path has a vulnerability, the vulnerability detail information corresponding to the tainted path is further acquired, so that the reliability and explainability of the vulnerability detection result are improved.

[0011] In a possible implementation manner, the vulnerability detection method further includes: A vulnerability detection report corresponding to the target code is generated, where the vulnerability detection report includes the vulnerability detail information.

[0012] In the technical solution, not only is the vulnerability detection performed on the tainted path by using the preset large language model, but also the natural language understanding and processing capability of the preset large language model is used to generate the vulnerability detection report including the vulnerability detail information based on the vulnerability detection result, so that the detection result is clear and mobile. Not only can the artificial cost be reduced, but also the relevant personnel can clearly understand the vulnerability situation in the target code according to the vulnerability detection report, which facilitates the verification of the relevant vulnerability or the optimization of the target code in the future, and improves the explainability and practicality of the vulnerability detection result.

[0013] In a possible implementation manner, the vulnerability detection method further includes: In a case where the vulnerability detection on the current tainted path cannot be completed based on the current information, path-related information of the current tainted path is acquired. re-perform vulnerability detection on the current taint path according to the obtained path-related information.

[0014] Compared with the traditional vulnerability detection method based on static analysis, in the above embodiment, in the case that the code logic corresponding to the current taint path is complex and the exploitability thereof cannot be directly determined, the context and other path-related information of the current taint path can be obtained, and the vulnerability detection on the current taint path can be re-performed according to the path-related information, thereby realizing multiple rounds of iterative detection on the same taint path, improving the accuracy of vulnerability detection, and reducing the false positive rate and the false negative rate of vulnerability detection.

[0015] Secondly, in the above embodiment, in the case that the vulnerability detection on the current taint path cannot be completed based on the current information, the context and other path-related information of the current taint path are obtained, thereby realizing dynamic on-demand acquisition of the path-related information of the taint path during the vulnerability detection process, enabling the preset large language model to complete the vulnerability detection on the taint path based on as little path-related information as possible, and improving the efficiency of vulnerability detection.

[0016] In addition, in the above embodiment, the path-related information of the current taint path can be automatically and on-demand acquired by the preset large language model without human intervention, and the vulnerability detection method can adapt to the vulnerability detection requirements of complex target code, and therefore has strong flexibility and adaptability.

[0017] In a possible implementation manner, the obtaining of the path-related information of the current taint path comprises at least one of the following: obtaining the path-related information from a preset storage space; calling a preset tool according to a model context protocol (MCP), and obtaining the path-related information through the preset tool.

[0018] In the above embodiment, the preset large language model can call any preset tool based on the MCP, thereby providing the preset large language model with multi-modal tool support, greatly expanding the acquisition range and information types of the path-related information, and enabling the preset tools to be configured or new preset tools to be added at any time without affecting the preset large language model itself and the vulnerability detection execution process, thereby adapting to the diversified vulnerability detection requirements of actual application scenarios.

[0019] In addition, in the above technical solution, the preset tool is called based on the MCP to obtain one or more path-related information of the current taint path, so that the vulnerability detection on the current taint path is not limited to the current taint path itself or the code module where the current taint path is located, but can also realize cross-module code and configuration information query through the related tool, thereby overcoming the problems of vulnerability false positives or false negatives caused by missing or limited context information during the vulnerability detection process, and improving the accuracy and comprehensiveness of vulnerability detection.

[0020] In a possible implementation manner, the vulnerability detection method further includes: The path-related information obtained through the preset tool is stored in the preset storage space.

[0021] Compared with obtaining the path-related information through the preset tool or directly reading from the preset storage space, the information can be obtained more quickly. Based on this, in the above embodiment, the path-related information obtained through the preset tool is stored in the preset storage space, so that the information can be directly read from the preset storage space in the case that the information is needed in the vulnerability detection of other tainted paths, the path-related information is dynamically stored and reused, the obtaining speed of the path-related information is improved, and the vulnerability detection efficiency is improved.

[0022] In a possible implementation manner, the vulnerability detection on the current tainted path includes at least one of the following: detecting whether a preset security processing operation exists in the current tainted path, where the preset security processing operation includes at least one of input verification, output encoding, permission control, and encryption; performing exploitability detection on the current tainted path.

[0023] In the above technical solution, the preset large language model can perform the at least one detection on each node of the current tainted path selected, so as to perform fine judgment and detection on the current tainted path and improve the accuracy of vulnerability detection.

[0024] In a possible implementation manner, the priority of each tainted path in the first tainted path set is sorted according to the preset rule, including: According to a depth-first search (DFS) rule, the path length of each tainted path in the first tainted path set is identified, and the priority of the corresponding tainted path is determined according to the path length.

[0025] In the above technical solution, the DFS rule is used to identify a deeper tainted path in the first tainted path set, that is, a tainted path with a longer path length. Since the longer the tainted path is, the more operation nodes it passes through, and more key functions related to the function or security of the target code may be involved, the tainted path can be used as a tainted path with a higher priority, which can be detected by the preset large language model earlier in the subsequent steps, and the vulnerability detection efficiency is improved.

[0026] In a possible implementation manner, the static analysis on the target code to be detected includes: performing static analysis on the target code by a static application security testing (SAST) engine.

[0027] In the technical solution, potential taint paths in the target code are identified based on multiple static analysis tools, more potential taint paths can be identified, the probability of false negatives is reduced, and the accuracy of vulnerability detection is improved.

[0028] In the above embodiments, the vulnerability detection method for the target code can be implemented by combining static application security testing, depth-first search, large language models, and other technologies, the advantages of different technologies can be combined to improve the vulnerability detection efficiency and accuracy, manual intervention is not required, and the vulnerability detection cost is reduced.

[0029] In a second aspect, one or more embodiments of the present specification provide a vulnerability detection apparatus, comprising: a path identification module configured to identify taint paths in target code to be detected to obtain a first taint path set; a path sorting module configured to sort the taint paths in the first taint path set according to a preset rule to obtain a second taint path set; an intelligent detection module, wherein the intelligent detection module comprises a detection execution submodule configured to select a taint path with a higher priority in the second taint path set as a current taint path by a preset large language model, and perform vulnerability detection on the current taint path.

[0030] In a possible implementation manner, the intelligent detection module further comprises a semantic filtering submodule. The semantic filtering submodule is configured to perform semantic analysis on the taint paths in the second taint path set by the preset large language model, and identify and filter out taint paths that are not exploitable in the second taint path set according to the semantic analysis result.

[0031] In a possible implementation manner, the intelligent detection module further comprises a result recording submodule. The result recording submodule is configured to obtain vulnerability detail information corresponding to the current taint path in a case where the detection execution submodule determines that the current taint path has a vulnerability. The vulnerability detail information comprises at least one of the following: taint path information, vulnerability location information, vulnerability type information, risk level, vulnerability exploitation condition, related code segment, and repair suggestion.

[0032] In a possible implementation manner, the intelligent detection module further comprises a result output submodule. The result output submodule is configured to generate a vulnerability detection report corresponding to the target code, wherein the vulnerability detection report comprises the vulnerability detail information.

[0033] In a possible implementation, the intelligent detection module further comprises a planning and scheduling submodule. The planning and scheduling submodule is configured to, in a case where the detection execution submodule cannot complete vulnerability detection on the current taint path based on current information, acquire path-related information of the current taint path, so that the detection execution submodule re-performs vulnerability detection on the current taint path according to the acquired path-related information.

[0034] In a possible implementation, the planning and scheduling submodule is configured to perform at least one of the following: acquire the path-related information from a preset storage space; invoke a preset tool according to a model context protocol (MCP), and acquire the path-related information through the preset tool.

[0035] In a possible implementation, the intelligent detection module further comprises a data recording submodule. The data recording submodule is configured to store the path-related information acquired through the preset tool to the preset storage space.

[0036] In a possible implementation, the detection execution submodule is configured to perform at least one of the following: detect whether a preset security processing operation exists in the current taint path, wherein the preset security processing operation comprises at least one of input verification, output encoding, permission control, and encryption; perform exploitability detection on the current taint path.

[0037] In a possible implementation, the path sorting module is configured to identify path lengths of each taint path in the first taint path set according to a depth-first search (DFS) rule, and determine priorities of the corresponding taint paths according to the path lengths.

[0038] In a possible implementation, the path identification module is configured to perform static analysis on the target code through a static application security testing (SAST) engine.

[0039] In a third aspect, one or more embodiments of the present specification also provide an electronic device, comprising a memory and a processor; the memory is configured to store a computer program product; the processor is configured to execute the computer program product stored in the memory, and the computer program product is executed to implement the method of the first aspect.

[0040] In a fourth aspect, one or more embodiments of the present specification also provide a computer-readable storage medium, which stores computer program instructions, and the computer program instructions, when executed, implement the method of the first aspect.

[0041] In a fifth aspect, one or more embodiments of the present specification also provide a computer program product, which comprises computer programs or instructions, and when the computer programs or instructions are run on a computer, the computer programs or instructions make the computer implement the method of the first aspect.

[0042] On the basis of the implementation manners provided in the aspects above, the embodiments of the present application can be further combined to provide more implementation manners.

[0043] It can be understood that the schemes provided in the embodiments of the second aspect to the fifth aspect correspond to the scheme provided in the embodiment of the first aspect, and therefore, the beneficial effects of the embodiments of the second aspect to the fifth aspect can refer to the beneficial effects of the embodiment of the first aspect, and the repeated parts will not be described herein. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions of one or more embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of one or more embodiments of the present specification, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0045] Figure 1 A flowchart of a vulnerability detection method provided by one or more embodiments of the present specification; Figure 2 A flowchart of a vulnerability detection method provided by one or more embodiments of the present specification; Figure 3 A flowchart of a vulnerability detection method provided by one or more embodiments of the present specification; Figure 4 A structural diagram of a vulnerability detection device provided by one or more embodiments of the present specification; Figure 5 A structural diagram of a vulnerability detection device provided by one or more embodiments of the present specification; Figure 6 A schematic diagram of an electronic device provided by one or more embodiments of the present specification; Figure 7 A schematic diagram of an application scenario provided by one or more embodiments of the present specification. DETAILED DESCRIPTION

[0046] One or more embodiments of the present specification are further described in detail by the accompanying drawings and examples. The features and advantages of one or more embodiments of the present specification will become more apparent from the detailed description, when read with the accompanying drawings.

[0047] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations. Unless specifically indicated otherwise, the drawings are not necessarily to scale.

[0048] In addition, the technical features involved in different embodiments of one or more embodiments of the present specification described below can be combined with each other as long as there is no conflict.

[0049] For ease of understanding, the terms involved in the embodiments of the present application are explained below.

[0050] Call chain: refers to a sequence of method calls in code from a starting method to a target method (or operation); these methods or operations include function calls, parameter passing, etc.

[0051] Source of pollution: refers to the entry point of code that may introduce unsafe data, such as user input, external API response, etc., which is the starting point of the pollution analysis.

[0052] Sink of pollution: refers to the operation point of code that may cause security risks, such as database query, file writing or log output, which is the target point of the pollution analysis.

[0053] Code vulnerability: refers to a security defect in code that may be maliciously exploited, such as buffer overflow, unauthorized access, etc.; its generating condition is usually the lack of security processing operations for input data in code; due to the lack of security processing operations for output data, the unsafe data received by the source of pollution can be propagated in the code without purification and reach the sink of pollution, causing data security problems.

[0054] Pollution analysis: a static analysis technique that tracks the propagation path of unsafe data input by the source of pollution in the code to determine whether it reaches the sink of pollution (i.e., the sensitive operation point), that is, to identify whether there is a vulnerability in the code; the call chain is the carrier of the propagation of unsafe data in the code.

[0055] Static Application Security Testing (SAST): Also known as white-box testing, it is a software testing method mainly used to detect potential security vulnerabilities in the program to be tested. SAST tools do not need to actually run the program to be tested, but only need to analyze the source code or compiled binary files of the program to be tested to find possible security issues.

[0056] Depth First Search (DFS): A graph traversal algorithm, in the embodiments of the present specification, it specifically refers to exploring layer by layer along the call link until the end point is reached or the termination condition is met.

[0057] Large Language Model (LLM): Refers to a large language model or intelligent model based on deep learning, which has been trained on a large amount of data and has strong context understanding, decision reasoning and adaptive learning capabilities.

[0058] Model Context Protocol (MCP): An open protocol or mechanism that defines a set of standardized communication protocols, data formats and rules, allowing large language models to efficiently obtain the required context information.

[0059] Code vulnerabilities are usually caused by problems such as security design flaws, coding errors and runtime failures. The existence of code vulnerabilities not only affects the normal operation of software, shortens the life cycle of software, but also brings security risks to user personal data, software operator data, etc.

[0060] In some application scenarios, manual auditing is used to detect software code vulnerabilities. However, this method relies on the professional experience of auditors, has high cost and long time consumption, and is difficult to scale and quickly obtain vulnerability detection results when facing large-scale code or frequently updated projects.

[0061] In some application scenarios, static analysis tools are used to detect code vulnerabilities by scanning code structure and call relationships. However, this method often requires pre-configuration of analysis rules, query logic, etc. for these static analysis tools, making it difficult to use. In addition, for large and complex code, the number of call links may grow exponentially, making it time-consuming to detect vulnerabilities using static analysis tools, and it may also cause memory overflow. Due to the lack of context information in static analysis, the false positive rate and false negative rate of vulnerability detection are high.

[0062] In some application scenarios, dynamic analysis is performed by running code to capture vulnerabilities. However, this requires relevant technical personnel to pre-write a large number of test cases, which is not only inefficient, but also can miss a large number of vulnerabilities due to the lack of relevant test cases.

[0063] In some application scenarios, a neural network model is trained to analyze code features and predict potential vulnerabilities. However, this requires a large amount of labeled data to train the relevant neural network model, and has high requirements for the quality and diversity of the training data. In the case of limited training data, the trained neural network model is only suitable for detecting specific types of vulnerabilities.

[0064] In summary, the above-mentioned code vulnerability detection methods have great limitations in detection efficiency, detection accuracy, and universality. Therefore, one or more embodiments of the present specification provide a vulnerability detection method and related device to improve at least one of detection efficiency, detection accuracy, and universality.

[0065] Figure 1 A flowchart of a vulnerability detection method provided by one or more embodiments of the present specification is shown. Referring to Figure 1 , the vulnerability detection method includes the following steps.

[0066] Step 102, performing static analysis on the target code to be detected to identify the taint path in the target code, and obtaining a first taint path set; During execution of the target code, multiple call links can be formed based on conditional judgments, function calls, etc., that is, multiple data propagation paths are formed. The taint path is the propagation path through which the data introduced by the taint source reaches the taint sink.

[0067] Different data introduced by the same taint source can propagate to different taint sinks via different taint paths, or propagate to the same taint sink via different taint paths. The same or different data introduced by different taint sources can propagate to the same or different taint sinks via different taint paths.

[0068] For example, in step 102, static analysis is performed on the target code, that is, the potential data propagation paths in the target code can be identified according to the logical relationship between each method or operation in the code, and the initial taint path set, that is, the first taint path set, is determined based on these data propagation paths.

[0069] For example, all possible data propagation paths identified can be recorded in the first taint path set as taint paths.

[0070] It can be understood that the more complex the logic of the target code is, the more the number of the taint paths in the first set of taint paths can be; and not all taint paths can be maliciously exploited and cause security problems, for example, taint paths existing only in dead code will not be successfully executed in the actual execution process of the target code.

[0071] If the taint path is not exploitable, it can be considered as a safe path, and there is no code vulnerability that can cause data security problems. That is, only the exploitable taint path can be maliciously exploited and cause data security problems. Based on this, the goal of vulnerability detection of the taint path is to determine whether the taint path is exploitable.

[0072] In step 104, each taint path in the first set of taint paths is prioritized according to a preset rule to obtain a second set of taint paths. In step 106, at least one taint path with a higher priority in the second set of taint paths is selected by a preset large language model for vulnerability detection.

[0073] There can be a large number of taint paths to be detected in the first set of taint paths, which are sorted by a preset rule to form a second set of taint paths. Each taint path in the second set of taint paths can be arranged in order from high to low priority. The higher the priority of the taint path, the higher the risk level it may correspond to, i.e., the more serious the data security problem it may cause.

[0074] Based on this, in step 106, each taint path can be obtained from the second set of taint paths in sequence and subjected to vulnerability detection by a preset large language model. Compared with randomly selecting taint paths for vulnerability detection from a large number of taint paths, the above embodiment realizes vulnerability detection in order from high to low priority of the taint paths, so that the taint path with a higher risk level can be identified as soon as possible, and the vulnerability detection efficiency is improved.

[0075] The preset large language model involved in the embodiments of the present specification can use an open source model; or, on the basis of the open source model, a small amount of training data can be used for pre-training to enhance the model's understanding of the code and improve the vulnerability detection efficiency and accuracy.

[0076] In some embodiments, the preset rule used in step 104 can be a sorting rule determined according to the length of the taint path, the key functions involved in the taint path, the sensitivity of the data involved in the taint path, and the like.

[0077] In some embodiments, the prioritization of each taint path in the first set of taint paths according to the preset rule in step 104 can specifically include: According to a depth-first search (DFS) rule, a path length of each of the first set of taint paths is identified, and a priority of the corresponding taint path is determined according to the path length.

[0078] In the above embodiment, based on the DFS rule, a deeper taint path, i.e., a taint path with a longer path length, in the first set of taint paths can be identified. Since the longer the taint path is, the more operation nodes it passes through, and the more key functions related to the function or security of the target code it may involve, the taint path can be regarded as a taint path with a higher priority, which can be detected earlier by the preset large language model in the subsequent step 106, thereby improving the vulnerability detection efficiency.

[0079] In some embodiments, in step 102, the static application security testing (SAST) engine can be used to perform static analysis on the target code to identify potential taint paths in the target code, thereby obtaining the first set of taint paths.

[0080] For example, the SAST engine can be configured with one or more static analysis tools, such as the open source code analysis tool Joern or CodeQL.

[0081] Based on multiple static analysis tools to identify potential taint paths in the target code, more potential taint paths can be identified, the probability of false negatives can be reduced, and the accuracy of vulnerability detection can be improved.

[0082] For example, in step 102, the SAST engine or one or more static analysis tools configured therein can also be used to filter the identified taint paths to remove obviously infeasible taint paths, such as taint paths identified from test code or dead code in the target code, thereby reducing the number of taint paths in the first set of taint paths, reducing the workload of vulnerability detection in the subsequent steps, and improving the efficiency of vulnerability detection.

[0083] Figure 2 Another flowchart of a vulnerability detection method provided for one or more embodiments of the present specification.

[0084] Referring to Figure 2 In some embodiments, the vulnerability detection method described above, before step 106, i.e., before vulnerability detection by the preset large language model, can further include: In step 108, the preset large language model is used to perform semantic analysis on each of the second set of taint paths, and according to the semantic analysis result, identify and filter out infeasible taint paths in the second set of taint paths.

[0085] Since the unexploitable tainted path, that is, the safe path, cannot be maliciously used by an attacker in the actual execution of the target code, it will not cause data security problems and there is no vulnerability. Therefore, the unexploitable tainted path can be determined through semantic understanding, and further vulnerability detection is not needed, so that it can be filtered out from the set.

[0086] In the above step, the language analysis capability of the preset large language model is used to realize semantic filtering of the second tainted path set. The remaining tainted paths in the filtered second path set are all tainted paths that cannot be determined as exploitable or not by the semantic understanding capability of the preset large language model, thereby reducing the number of tainted paths in the second tainted path set, reducing the data processing amount of the vulnerability detection step (i.e., step 106) and the like, and improving the vulnerability detection efficiency.

[0087] In the above step 108, the semantic understanding capability of the preset large language model can be used to perform semantic filtering on the tainted paths in the second tainted path set based on a plurality of semantic filtering rules. Some embodiments will be described below when the preset large language model is used to perform semantic filtering on the tainted paths.

[0088] In some embodiments, the preset large language model can perform semantic filtering on the tainted paths in the second tainted path set based on an input verification rule.

[0089] For example, the input verification rule can include checking whether there is a verification operation on input data in the tainted path. If there is no verification operation, the corresponding tainted path can be exploitable and should not be filtered out from the second tainted path set.

[0090] For example, the verification operation on the input data can include a whitelist or blacklist-based input verification operation, a regular expression-based input verification operation, a type checking-based input verification operation, and the like.

[0091] For example, the input verification rule can also include, if there is a verification operation in the tainted path, determining whether the verification operation can cover the preset or all possible malicious inputs (i.e., unsafe data). If the preset or all possible malicious inputs can be covered, the corresponding tainted path can be filtered out from the second tainted path set as an unexploitable tainted path.

[0092] For example, assuming that through the semantic understanding ability of the preset large language model, it is found by checking that the verification operation in the taint path L1 is implemented based on a whitelist, it is indicated that only input data conforming to the whitelist will continue to propagate in the taint path L1; and the input data conforming to the whitelist are all preset data that will not cause a data security problem. Therefore, if the verification operation in the taint path L1 is implemented based on the whitelist, it is indicated that the taint path L1 is not exploitable and will not cause a data security problem, and it is not necessary to perform vulnerability detection on it, and it can be filtered out from the second taint path set.

[0093] For example, assuming that through the semantic understanding ability of the preset large language model, it is found by checking that the verification operation in the taint path L2 is implemented based on type checking, and the verification is insufficient, such as only checking the data length or data type of the input data, as long as the input data received by the taint path L2 conforms to the corresponding data length or data type, it can pass the above verification operation and continue to propagate in the taint path L2, thereby triggering a code vulnerability and causing a data security problem. Therefore, if the verification operation in the taint path L2 is implemented based on type checking and the verification is insufficient, the taint path L2 may still be an exploitable taint path, and the preset large language model will not filter it out from the second taint path set.

[0094] In some embodiments, the preset large language model can perform semantic filtering on the taint paths in the second taint path set based on a permission checking rule.

[0095] For example, the above permission checking rule can include checking whether there is an operation for checking the user identity and permission corresponding to the input data in the taint path. If not, the corresponding taint path may be exploitable and should not be filtered out from the second taint path set.

[0096] For example, the above permission checking rule can include checking whether there is an operation for checking the user identity and permission corresponding to the input data in the taint path. If not, the corresponding taint path may be exploitable and should not be filtered out from the second taint path set.

[0097] For example, assuming that through the semantic understanding ability of the preset large language model, it is found by checking that there is an “isAdmin()” function for checking the user identity or a “hasPermission()” function for checking whether the user has a related permission token in the taint path L3, it is indicated that there is an operation for checking the user identity and permission corresponding to the input data in the corresponding taint path L3.

[0098] Assuming that the above permission check operation configured in the pollution path L3 is further judged by the semantic understanding ability of the preset large language model, if the input data can pass the above permission check operation by tampering with the Cookie or JWT (JSON Web Token) in the input data (even if the user originally has no related permission is judged as a user with related permission), it means that the corresponding pollution path L3 is a exploitable pollution path, and the preset large language model will not filter it out from the second pollution path set.

[0099] In some embodiments, the preset large language model can perform semantic filtering on the pollution paths in the second pollution path set based on the security library usage rules.

[0100] For example, the above security library usage rules can include checking whether a secure database or a secure database-related framework is used in the pollution path. If not, it means that the input data can be easily passed to the related database based on this pollution path, triggering SQL injection and other vulnerabilities, causing the data in the related database to be illegally obtained or tampered with, etc., so this pollution path is exploitable and should not be filtered out from the second pollution path set.

[0101] For example, the above security library usage rules can also include judging whether the security measures in the database or database-related framework used in the pollution path are appropriate; if not, it means that the related pollution path can still be exploited and should not be filtered out from the second pollution path set.

[0102] For example, assuming that through the semantic understanding ability of the preset large language model, it is found that the ORM (Object-Relational Mapping) framework is used in the pollution path L4 to implement the mapping between the code and the related database, and the security mechanism to prevent SQL injection is configured in the ORM framework, it means that the input data in the pollution path L4 will be verified and checked by the related security mechanism before being passed to the related database, which can ensure the security of the data in the related database, i.e. the pollution path L4 is not exploitable and will not cause data security problems, and it can be filtered out from the second pollution path set.

[0103] For example, assuming that through the semantic understanding ability of the preset large language model, it is found that an encrypted database is used in the pollution path L4, but further checking finds that the encryption algorithm of the encrypted database is a weak encryption algorithm, i.e. it can be easily cracked to trigger SQL injection and other vulnerabilities, so the pollution path L5 is exploitable and the preset large language model will not filter it out from the second pollution path set.

[0104] It should be noted that the input verification rules, permission checking rules, security library usage rules, etc. described above are some examples provided by the specification. In other possible implementations, the semantic understanding capability of the preset large language model can also be used to perform semantic filtering on the tainted paths in the second tainted path set based on other semantic filtering rules to improve the vulnerability detection efficiency, and the specification will not be described one by one.

[0105] In addition, it should be noted that although Figure 2 In the flowchart shown, after obtaining the second tainted path set through step 104, the semantic filtering of the tainted paths in the second tainted path set is performed first through step 108, and then the vulnerability detection of each tainted path in the filtered second tainted path set is performed according to the priority level. However, in other possible embodiments, after obtaining the second tainted path set through step 104 and inputting the second tainted path set into the preset large language model, the preset large language model can also simultaneously perform the above-mentioned semantic filtering step (step 108) and vulnerability detection step (step 106).

[0106] That is, after receiving the above-mentioned second tainted path set, the preset large language model does not need to wait for the completion of semantic filtering, and can directly perform vulnerability detection on the tainted paths in the second tainted path set according to the priority level.

[0107] Since the tainted paths with higher priority have a relatively low probability of being non-exploitable paths, in the above-mentioned embodiments, the preset large language model simultaneously performs the above-mentioned semantic filtering step and vulnerability detection step, which will not cause the vulnerability detection step to detect the vulnerability of the tainted paths that may be filtered out due to the incomplete semantic filtering step, i.e., will not cause the vulnerability detection step to do "useless work" and waste the data processing resources of the preset large language model, but will shorten the time consumption of vulnerability detection of the target code and improve the vulnerability detection efficiency of the target code due to the simultaneous performance of the semantic filtering and vulnerability detection steps.

[0108] In some embodiments, for the tainted path set obtained through step 102, the tainted paths in the tainted path set are sorted based on the DFS rule, and the tainted paths in the tainted path set are also filtered by the preset large language model; for the tainted path set filtered through the above-mentioned sorting and filtering, the preset large language model is used to perform vulnerability detection on each tainted path according to the priority level from high to low.

[0109] In this way, the number of tainted paths that need to be detected by the preset large language model can be reduced, the problem of path explosion in the case of large or complex target code can be effectively addressed, and the high-priority tainted path can be detected preferentially, so that the high-risk tainted path can be detected faster and more in a limited time, efficient use of limited vulnerability detection resources can be achieved, and vulnerability detection efficiency can be improved.

[0110] In some embodiments, in step 106, the at least one tainted path with a higher priority in the second set of tainted paths is selected by the preset large language model for vulnerability detection, which can specifically include performing at least one of the following: detecting whether a preset security processing operation exists in the selected tainted path; detecting whether the selected tainted path is an exploitable tainted path.

[0111] In the above embodiments, the preset large language model can perform the at least one detection along each node of the current tainted path for the selected current tainted path, so as to achieve fine judgment and detection of the current tainted path.

[0112] For example, if it is detected that a node on the tainted path can perform a preset security processing operation on the input data, i.e., harmless processing of the input data, the tainted path can be determined as an unexploitable path, i.e., there is no vulnerability in the tainted path.

[0113] For example, the above-mentioned preset security processing operation includes at least one of input verification, output encoding, permission control, and encryption.

[0114] The above-mentioned input verification is to verify the input data based on a whitelist, a blacklist, a regular expression, type checking, etc., to determine its security.

[0115] The above-mentioned output encoding is to encode the output data according to a preset encoding rule. In this way, even if there is a special character of malicious input in the output data, the special character can be changed by the preset encoding rule, reducing the possibility of SQL injection attack by the special character, and preventing the output data from being tampered in the subsequent propagation process.

[0116] The above-mentioned permission control is to determine whether the identity type or permission level of the corresponding user matches the requested operation type according to the user information contained in the input data. For example, only the administrator is configured with the data deletion permission of the database, and the permission control can be used to check whether the user who sends the data deletion request is an administrator, and if not, the data deletion request is rejected, so as to avoid the data in the database being maliciously deleted.

[0117] Exemplarily, in the above embodiment, the exploitability of the taint path can be evaluated and detected in combination with the context information related to the taint path, the preset vulnerability mode, and the like.

[0118] In the above embodiment, the entire vulnerability detection process can be automatically executed without human intervention, and does not need to be preprogrammed with detection rules, path selection rules, and the like, thereby ensuring the efficiency and accuracy of vulnerability detection.

[0119] Figure 3 Another flowchart of a vulnerability detection method provided for one or more embodiments of the present specification is shown.

[0120] Referring to Figure 3 The vulnerability detection in step 106 can specifically include the following steps. Step 10602, selecting a taint path with a higher priority from the second set of taint paths that has not been detected as a current taint path; Step 10604, detecting whether a preset security processing operation exists in the current taint path; Step 10606, detecting whether the current taint path is an exploitable taint path; Step 10608, in the case where the current taint path has a preset security processing operation or is an unexploitable taint path, setting a first preset identifier for the current taint path; The first preset identifier can be an identifier indicating that the corresponding path is a low-risk path or a safe path. Based on the first preset identifier, subsequent backtracking, re-inspection, and the like of the target code can be facilitated.

[0121] Step 10610, in the case where the current taint path is an exploitable taint path, determining that the current taint path has a vulnerability and obtaining vulnerability detail information corresponding to the current taint path; Exemplarily, the vulnerability detail information includes at least one of the following: taint path information, vulnerability location information, vulnerability type information, risk level, vulnerability exploit condition, related code segment, and repair suggestion.

[0122] Exemplarily, a second preset identifier can also be set for the taint path determined to have a vulnerability; the second preset identifier indicates that the corresponding path is a high-risk path. In addition, different second preset identifiers can be set according to different types of vulnerabilities existing in the taint path, thereby facilitating subsequent backtracking, re-inspection, and the like of the target code.

[0123] Step 10612, determining whether there is still a taint path that has not been detected in the second set of taint paths; if there is, returning to step 10602 to select the next taint path for vulnerability detection, and if there is not, ending the current vulnerability detection.

[0124] In the above embodiments, in the case where it is determined that the taint path has a vulnerability, instead of simply recording that the taint path has a vulnerability, the vulnerability detail information corresponding to the taint path is further obtained, thereby improving the reliability and explainability of the vulnerability detection result.

[0125] In the step 10612, the detection of all the taint paths in the second taint path set is completed as the end condition of the current vulnerability detection. In other possible embodiments, if the target of the current vulnerability detection is only the high-risk path, in the step 10612, the detection of the taint paths in the second taint path set with a priority higher than the preset level is completed as the end condition of the current vulnerability detection.

[0126] In this way, the vulnerability detection can be performed only on the taint paths with a higher priority, so that the current vulnerability detection can be completed as soon as possible under the premise that the high-risk path is detected, thereby meeting the requirement of fast vulnerability detection in some application scenarios.

[0127] In some embodiments, still referring to Figure 3 The above vulnerability detection method can further include: In the step 110, in the case where there is no undetected taint path in the second taint path set, the vulnerability detection of the target code is ended, and a vulnerability detection report corresponding to the target code is generated, wherein the vulnerability detection report includes the vulnerability detail information of the related taint path obtained based on the step 10610.

[0128] For example, in the process of performing the vulnerability detection on the taint paths in the second taint path set by the preset large language model based on the flow shown in FIG. 11, each time a taint path with a vulnerability is determined based on the step 10610 and the corresponding vulnerability detail information is obtained, the vulnerability detail information can be stored in a preset storage space; then in the step 110, the preset large language model can read each vulnerability detail information from the preset storage space, so as to generate the above vulnerability detection report. Figure 3 For example, the above preset storage space can also be used to store other information in the process of executing the above vulnerability detection method, such as the first taint path set, the second taint path set, the taint path information with the first preset label, etc., so that the related steps can read these information at any time, and these information can also be added to the final vulnerability detection report as needed.

[0129]

[0130] ​In the above embodiments, not only can the preset large language model be used to detect vulnerabilities in the taint path, but also the natural language understanding and processing capabilities of the preset large language model can be used to generate a vulnerability detection report containing vulnerability detail information based on the vulnerability detection result, so that the detection result is clear and mobile. Not only can the artificial cost be reduced, but also relevant personnel can clearly understand the vulnerability situation in the target code according to the vulnerability detection report, which facilitates subsequent verification of related vulnerabilities or optimization of the target code, and improves the explainability and practicality of the vulnerability detection result.

[0131] In some embodiments, still referring to Figure 3 The vulnerability detection method can further include: In step 10614, in the case that the current information cannot be used to determine whether the current taint path has a vulnerability, the path-related information of the current taint path is obtained, and at least one of the above steps 10604 and 10606 is returned to re-detect the vulnerability of the current taint path according to the obtained path-related information.

[0132] For example, the path-related information can include detailed code information, context, information of called functions, security configuration information, and the like of the corresponding taint path.

[0133] Compared with the traditional vulnerability detection method based on static analysis, in the above embodiments, in the case that the code logic corresponding to the current taint path is complex and its exploitability cannot be directly determined, the context and other path-related information of the current taint path can be obtained, and the vulnerability of the current taint path can be re-detected according to the path-related information. This realizes multiple rounds of iterative detection of the same taint path, improves the accuracy of vulnerability detection, and reduces the false positive rate and the false negative rate of vulnerability detection.

[0134] Secondly, in the above embodiments, in the case that the current information cannot be used to complete the vulnerability detection of the current taint path, the context and other path-related information of the current taint path are obtained. This realizes dynamic on-demand acquisition of the path-related information of the taint path during the vulnerability detection process, so that the preset large language model can complete the vulnerability detection of the taint path based on as little path-related information as possible, and improve the vulnerability detection efficiency.

[0135] In addition, in the above embodiments, the path-related information of the current taint path can be automatically and on-demand obtained by the preset large language model without human intervention, which can adapt to the vulnerability detection requirements of complex target code. Therefore, the vulnerability detection method has strong flexibility and adaptability.

[0136] In some embodiments, the path-related information of the current taint path obtained in step 10614 can specifically include: calling a preset tool according to a model context protocol (MCP), and obtaining the path-related information of the current taint path through the preset tool.

[0137] The preset tools include, but are not limited to, one or more of a code viewer, a knowledge base / API lookup tool, a specialized analyzer, a configuration checker, and the like.

[0138] Through the code viewer, the source code of a specific function, method, or code fragment in the current taint path can be accurately obtained.

[0139] Through the knowledge base / API lookup tool, information about the internal component library of the target code and the API usage of the third-party library can be queried.

[0140] Through the specialized analyzer, a lightweight checking tool for a specific type of vulnerability can be called. The specific type of vulnerability can include a SQL injection vulnerability, a Cross Site Scripting (XSS) vulnerability, and the like.

[0141] Through the configuration checker, the security configuration information related to the current taint path can be checked.

[0142] In the above embodiments, the MCP can be used to call any preset tool by the preset large language model, thereby providing the preset large language model with multi-modal tool support, which can greatly expand the range of acquisition of path-related information and the types of information, and can configure the callable preset tools or add new preset tools at any time without affecting the preset large language model itself and its vulnerability detection execution process, thereby adapting to the diversified vulnerability detection needs of actual application scenarios.

[0143] For example, the entire source code in the target code can be divided into different code modules based on different functions. Based on the preset tools, relevant information in other code modules other than the code module where the current taint path is located can be obtained, thereby realizing cross-module code and configuration information query.

[0144] In the above embodiments, according to the vulnerability detection needs, the preset tools are called based on the MCP to obtain one or more types of path-related information of the current taint path, so that the vulnerability detection of the current taint path is not limited to the current taint path itself or the code module where the current taint path is located, but also realizes cross-module code and configuration information query, thereby overcoming the false positives or false negatives caused by the lack or limitation of context information in the vulnerability detection process, and improving the accuracy and comprehensiveness of vulnerability detection.

[0145] In some embodiments, still referring to Figure 3 The vulnerability detection method can further include: Step 10616, store the path-related information obtained by the preset tool to the preset storage space.

[0146] Based on step 10616, in step 10614, the path-related information of the current taint path can also be obtained from the preset storage space.

[0147] For example, in the case that the storage resources of the preset storage space are tight, or some path-related information stored in the preset storage space will not be needed again within a certain time, it can also be deleted from the preset storage space.

[0148] It can be understood that, compared with querying or analyzing the path-related information by the preset tool, directly reading from the preset storage space can obtain the information faster. Based on this, in some embodiments, the required path-related information can be read from the preset storage space first; in the case that the required path-related information does not exist in the preset storage space, the preset tool is called based on the MCP to obtain the required path-related information.

[0149] In the above embodiments, the path-related information obtained by the preset tool is stored to the preset storage space, which can be directly read from the preset storage space in the case that these information is also needed in the vulnerability detection of other taint paths, realizing dynamic storage and reuse of the path-related information, improving the acquisition speed of the path-related information, and thus improving the vulnerability detection efficiency.

[0150] In some embodiments, for the preset large language model, an Agent, i.e., an intelligent agent or intelligent proxy, can be configured, and the control of the vulnerability detection process performed by the preset large language model is realized through the Agent.

[0151] In the above embodiments, through the Agent, autonomous path rules, i.e., autonomously selected taint paths to be detected, can be realized, and on-demand calling of the preset tool based on the MCP can also be realized, so that the semantic understanding, reasoning planning and other capabilities of the large language model can be applied to the vulnerability detection process, reducing the labor cost, improving the flexibility and adaptability of the preset large language model in the vulnerability detection process, and can be applied to different scenarios such as financial systems and payment systems; even for complex target codes, the vulnerability detection can be completed by obtaining enough path-related information and ensuring the accuracy of the detection results.

[0152] In addition, compared with the vulnerability detection method based on machine learning in the related art, in the above embodiments, the vulnerability detection is realized through the preset large language model, which does not need to be pre-trained based on a large amount of labeled information, and does not need to manually write path selection rules, tool calling rules or calling time, etc., reducing the dependence on training data, and any type of vulnerability that may exist in the target code can be detected.

[0153] It can be understood that the above embodiments are only examples, and the above embodiments can be modified in actual implementation. Those skilled in the art can understand that the modified methods of the above embodiments without creative labor fall within the protection scope of one or more embodiments of the present specification, and the embodiments will not be described again.

[0154] Based on the same inventive concept, one or more embodiments of the present specification also provide a vulnerability detection device, Figure 4 The structural diagram of the vulnerability detection device is shown in FIG. 3.

[0155] As Figure 4 shown, the vulnerability detection device 300 can include: A path identification module 310 is configured to identify a tainted path in a target code to be detected, and obtain a first set of tainted paths. A path sorting module 320 is configured to sort the priority of each tainted path in the first set of tainted paths according to a preset rule, and obtain a second set of tainted paths. An intelligent detection module 330 includes a detection execution submodule 331 configured to select a tainted path with a higher priority in the second set of tainted paths as a current tainted path by using a preset large language model, and perform vulnerability detection on the current tainted path.

[0156] The intelligent detection module 330 is a vulnerability detection module based on a preset large language model, and at least includes the detection execution submodule 331.

[0157] For example, in order to implement vulnerability detection on the current tainted path, the detection execution submodule 331 performs at least one of the following: Detecting whether a preset security processing operation exists in the current tainted path, wherein the preset security processing operation includes at least one of input verification, output encoding, permission control, and encryption; Performing exploitability detection on the current tainted path.

[0158] In some embodiments, the intelligent detection module 330 can further include a code input module. The code input module can be used as an entrance module of the vulnerability detection device 300 to receive a target code to be detected.

[0159] For example, the code input module can receive a to-be-detected code stored locally in an electronic device where the vulnerability detection device 300 is located, or receive a to-be-detected code transmitted by an external device through a wired or wireless manner.

[0160] In some embodiments, referring to Figure 5 the intelligent detection module 330 further includes a semantic filtering submodule 332.

[0161] The semantic filtering submodule 332 is configured to perform semantic analysis on each of the second set of tainted paths by using a preset large language model, and identify and filter out the non-exploitable tainted paths in the second set of tainted paths according to the semantic analysis result.

[0162] It should be noted that, Figure 5 In the intelligent detection module 330, the data transmission directions between some of the submodules are shown by dashed arrows with arrows, which will be described below in conjunction with the relevant submodules. It can be understood that the interaction between the submodules in the intelligent detection module 330 is not limited to Figure 5 the directions shown by the arrows.

[0163] In some embodiments, referring to Figure 5 The intelligent detection module 330 further includes a result recording submodule 333.

[0164] The result recording submodule 333 is configured to, in a case where it is determined by the detection execution submodule 331 that the current tainted path has a vulnerability, acquire and store the vulnerability detail information corresponding to the current tainted path.

[0165] The vulnerability detail information includes at least one of the following: tainted path information, vulnerability location information, vulnerability type information, risk level, vulnerability exploitation condition, related code segment, and repair suggestion.

[0166] In some embodiments, referring to Figure 5 The intelligent detection module 330 further includes a result output submodule 334.

[0167] The result output submodule 334 is configured to generate a vulnerability detection report corresponding to the target code, wherein the vulnerability detection report includes the vulnerability detail information stored in the result recording submodule 333.

[0168] In some embodiments, referring to Figure 5 The intelligent detection module 330 further includes a planning and scheduling submodule 335.

[0169] The planning and scheduling submodule 335 is configured to, in a case where the detection execution submodule 331 cannot complete the vulnerability detection of the current tainted path based on the current information, acquire path-related information of the current tainted path, and trigger the detection execution submodule 331 to perform vulnerability detection on the current tainted path again according to the acquired path-related information.

[0170] Based on the above planning and scheduling submodule 335, the on-demand acquisition of path-related information such as context information can be realized, and multiple rounds of iterative detection of the current tainted path can be realized, thereby improving the accuracy of vulnerability detection and reducing or avoiding false positives or false negatives caused by insufficient information.

[0171] For example, the planning and scheduling submodule 335 is configured to perform at least one of the following: obtain path-related information of the current tainted path from a preset storage space; invoke a preset tool according to a model context protocol (MCP), and obtain the path-related information of the current tainted path through the preset tool.

[0172] In some embodiments, the planning and scheduling submodule 335 can be an agent of a preset large language model, which can not only invoke a preset tool based on the MCP on demand, but also can control the path selection method and vulnerability detection method of the detection execution submodule 331 by sending relevant control instructions to the detection execution submodule 331, so as to automatically optimize the path selection or vulnerability detection strategy according to the current detection situation, thereby improving the accuracy and adaptability of vulnerability detection.

[0173] In some embodiments, referring to Figure 5 The intelligent detection module 330 further includes a data recording submodule 336.

[0174] The data recording submodule 336 is configured to store the path-related information obtained through the preset tool into a preset storage space.

[0175] Based on the storage operation of the data recording submodule 336 on the path-related information, when the planning and scheduling submodule 335 needs to obtain the path-related information again, it can be directly read from the preset storage space, without the need to invoke the relevant preset tool based on the MCP, thereby improving the information acquisition speed of the planning and scheduling submodule 335 and improving the vulnerability detection efficiency.

[0176] In some embodiments, the path identification module 310 can be specifically configured to perform static analysis on the target code through a SAST engine.

[0177] In some embodiments, the path sorting module 320 can be specifically configured to identify the path length of each tainted path in the first tainted path set according to the DFS rule, and determine the priority of the corresponding tainted path according to the path length.

[0178] Since the principle of solving the problem by the above-mentioned vulnerability detection device 300 is similar to the vulnerability detection method, the implementation of each module in the vulnerability detection device 300 and its principle can be referred to the related embodiments of the vulnerability detection method, and the repeated parts will not be described here.

[0179] Referring to Figure 6 , Figure 6 A structural block diagram of an electronic device is provided for one or more embodiments of the present specification. As shown in Figure 6 , the electronic device 500 can include a processor 501 and a memory 502; the memory 502 can be coupled to the processor 501. It is worth noting that the Figure 6 is exemplary; other types of structures can also be used to supplement or replace the structure to implement telecommunications functions or other functions. The electronic device can be a server, a terminal or other intermediate device.

[0180] In a possible implementation manner, the functions of the vulnerability detection device 300 can be integrated into the processor 501. Among them, the processor 501 can be configured to perform the following operations: performing static analysis on the target code to be detected to identify a taint path in the target code, to obtain a first taint path set; According to a preset rule, each taint path in the first taint path set is prioritized to obtain a second taint path set; Through a preset large language model, at least one taint path with a higher priority in the second taint path set is selected for vulnerability detection.

[0181] In another possible implementation manner, the vulnerability detection device 300 can be configured separately from the processor 501, for example, the vulnerability detection device 300 can be configured as a chip connected with the processor 501, and the vulnerability detection of various software source codes is realized through the control of the processor 501.

[0182] In addition, in some optional implementation manners, the electronic device 500 can also include a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 500 does not necessarily include all the components shown in Figure 6 ; in addition, the electronic device 500 can also include components not shown in Figure 6 , which can refer to the prior art.

[0183] Figure 7 An application scenario diagram of a vulnerability detection method or device is provided for one or more embodiments of the present specification. Referring to Figure 7In some embodiments, the vulnerability detection method or apparatus provided by any of the preceding embodiments can be configured in the terminal 10a, that is, the terminal 10a can perform vulnerability detection on the target code S1 stored locally or sent by the other terminal 10b based on the vulnerability detection method or apparatus provided by any of the preceding embodiments, and display or store the obtained vulnerability detection result, such as the vulnerability detection report T1, locally or return it to the corresponding terminal 10b.

[0184] In some embodiments, the vulnerability detection method or apparatus provided by any of the preceding embodiments can also be configured in the server 20, which can receive the target code S2 sent by the terminal 10b, perform vulnerability detection on the target code S2 based on the vulnerability detection method or apparatus provided by any of the preceding embodiments, and feed back the obtained vulnerability detection result, such as the vulnerability detection report T2, to the terminal 10b.

[0185] One or more embodiments of the present specification also provide a computer readable storage medium capable of implementing all steps of the vulnerability detection method in the above-mentioned embodiments, and the computer readable storage medium has a computer program stored thereon, which, when executed by a processor, implements all steps of the vulnerability detection method in the above-mentioned embodiments. For specific steps, refer to the description of the preceding embodiments, which will not be repeated here.

[0186] In addition, one or more embodiments of the present specification also provide a computer program product capable of implementing all steps of the above-mentioned vulnerability detection method embodiments; the computer program product includes a computer program or instructions, which, when running on a computer, causes the computer to implement all steps of the vulnerability detection method in the above-mentioned embodiments. For specific steps, refer to the description of the preceding embodiments, which will not be repeated here.

[0187] Each of the embodiments in the present specification is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other. Each of the embodiments focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0188] It should be noted that, in the case of no conflict, one or more embodiments of the present specification and the features in the embodiments can be combined with each other. The one or more embodiments of the present specification are not limited to any single aspect or any single embodiment, nor do they need to realize any or all of the aspects and / or embodiments. Moreover, each aspect and / or embodiment of the present specification can be used alone or in combination with one or more other aspects and / or embodiments.

[0189] It should be noted that the above-mentioned embodiments are only used to explain the technical solutions of one or more embodiments of the present specification, but not to limit them. Although the one or more embodiments of the present specification are described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some or all of the technical features can be replaced by equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the one or more embodiments of the present specification, and they should be covered in the scope of the claims and the specification of the one or more embodiments of the present specification.

[0190] The one or more embodiments of the present specification are described above in combination with optional embodiments, but these embodiments are only exemplary and serve only to illustrate. On this basis, various substitutions and improvements can be made to the one or more embodiments of the present specification, which all fall within the protection scope of the one or more embodiments of the present specification.

Claims

1. A vulnerability detection method, characterized in that, include: Static analysis is performed on the target code to be detected to identify tainted paths in the target code, thereby obtaining a first set of tainted paths; According to preset rules, the tainted paths of the first tainted path set are sorted by priority to obtain the second tainted path set. By using a pre-defined large language model, a tainted path with higher priority in the second tainted path set is selected as the current tainted path, and vulnerability detection is performed on the current tainted path.

2. The method according to claim 1, characterized in that, Also includes: Using the preset large language model, semantic analysis is performed on each tainted path in the second tainted path set, and based on the semantic analysis results, unusable tainted paths in the second tainted path set are identified and filtered out.

3. The method according to claim 1, characterized in that, Also includes: If the vulnerability detection determines that the current tainted path has a vulnerability, obtain the vulnerability details information corresponding to the current tainted path; The vulnerability details include at least one of the following: Information on the tainted path, vulnerability location, vulnerability type, risk level, exploitation conditions, related code snippets, and remediation suggestions.

4. The method according to claim 3, characterized in that, Also includes: Generate a vulnerability detection report corresponding to the target code, wherein the vulnerability detection report includes the vulnerability details.

5. The method according to claim 1, characterized in that, Also includes: If the vulnerability detection of the current tainted path cannot be completed based on the current information, obtain the path-related information of the current tainted path; Based on the obtained path-related information, the current tainted path is re-detected for vulnerabilities.

6. The method according to claim 5, characterized in that, The acquisition of path-related information for the current taint path includes at least one of the following: Retrieve the path-related information from the preset storage space; The preset tool is invoked according to the Model Context Protocol (MCP), and the path-related information is obtained through the preset tool.

7. The method according to claim 6, characterized in that, Also includes: The path-related information obtained through the preset tool is stored in the preset storage space.

8. The method according to claim 1, characterized in that, The vulnerability detection of the current tainted path includes at least one of the following: Detect whether there is a preset security processing operation in the current tainted path, wherein the preset security processing operation includes at least one of input verification, output encoding, access control, and encryption; Availability testing is performed on the current taint path.

9. The method according to claim 1, characterized in that, The step of prioritizing each taint path in the first taint path set according to preset rules includes: According to the depth-first search (DFS) rule, the path length of each tainted path in the first tainted path set is identified, and the priority of the corresponding tainted path is determined based on the path length.

10. The method according to claim 1, characterized in that, The static analysis of the target code to be detected includes: The target code was statically analyzed using the SAST engine for static application security testing.

11. A vulnerability detection device, characterized in that, include: The path recognition module is used to identify tainted paths in the target code to be detected, and obtain the first set of tainted paths. The path sorting module is used to sort the tainted paths of the first tainted path set by priority according to preset rules to obtain the second tainted path set. The intelligent detection module includes a detection execution submodule, which selects a higher-priority tainted path from the second tainted path set as the current tainted path using a preset large language model, and performs vulnerability detection on the current tainted path.

12. The apparatus according to claim 11, characterized in that, The intelligent detection module also includes: a semantic filtering submodule; The semantic filtering submodule is used to perform semantic analysis on each tainted path in the second tainted path set through the preset large language model, and to identify and filter out unusable tainted paths in the second tainted path set based on the semantic analysis results.

13. The apparatus according to claim 11, characterized in that, The intelligent detection module also includes: a result recording submodule; The result recording submodule is used to obtain vulnerability details information corresponding to the current tainted path when the detection execution submodule determines that the current tainted path has a vulnerability; The vulnerability details include at least one of the following: Information on the tainted path, vulnerability location, vulnerability type, risk level, exploitation conditions, related code snippets, and remediation suggestions.

14. The apparatus according to claim 13, characterized in that, The intelligent detection module also includes: a result output submodule; The result output submodule is used to generate a vulnerability detection report corresponding to the target code, wherein the vulnerability detection report includes the vulnerability details.

15. The apparatus according to claim 11, characterized in that, The intelligent detection module also includes: a planning and scheduling submodule; The planning and scheduling submodule is used to obtain path-related information of the current tainted path when the detection and execution submodule is unable to complete the vulnerability detection of the current tainted path based on the current information, so that the detection and execution submodule can re-perform vulnerability detection of the current tainted path based on the obtained path-related information.

16. The apparatus according to claim 15, characterized in that, The planning and scheduling submodule is used to perform at least one of the following: Retrieve the path-related information from the preset storage space; The preset tool is invoked according to the Model Context Protocol (MCP), and the path-related information is obtained through the preset tool.

17. The apparatus according to claim 16, characterized in that, The intelligent detection module also includes: a data recording submodule; The data recording submodule is used to store the path-related information obtained through the preset tool into the preset storage space.

18. The apparatus according to claim 11, characterized in that, The detection execution submodule is used to perform at least one of the following: Detect whether there is a preset security processing operation in the current tainted path, wherein the preset security processing operation includes at least one of input verification, output encoding, access control, and encryption; Availability testing is performed on the current taint path.

19. The apparatus according to claim 11, characterized in that, The path sorting module is used to identify the path length of each tainted path in the first tainted path set according to the depth-first search (DFS) rule, and determine the priority of the corresponding tainted path based on the path length.

20. The apparatus according to claim 11, characterized in that, The path identification module is used to perform static analysis on the target code using the Static Application Security Testing (SAST) engine.

21. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method described in any one of claims 1-10.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed, implement the method described in any one of claims 1-10.

23. A computer program product, characterized in that, The computer program product includes: a computer program or instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 10.

Images