Cryptographic Misuse Detection Method and Apparatus Based on Large Model and Context Dependency
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-08
- Publication Date
- 2026-08-14
AI Technical Summary
这类方法仅能覆盖已知模式,且误报率和漏报率较高
[0007]由以上技术方案可以看出,本实施例通过在目标代码存在跨文件依赖时,获得目标代码的外部上下文依赖信息,以对目标代码的上下文环境进行精准还原,并利用大语言模型强大的语义理解能力以及从目标代码中识别出的用于密码学误用检测的目标类代码在该还原出的上下文环境中对目标代码进行密码学误用检测,实现了基于大模型与上下文关系进行密码学误用检测,克服了传统静态检测工具的误报率与漏报率较高的问题,解决了传统静态检测工具无法检测跨文件的密码学误用的问题,能够适应复杂的代码项目环境。
Smart Images

Figure CN122569946A_ABST
Abstract
Description
Technical Field
[0001] This application relates to artificial intelligence technology, and in particular to a method and apparatus for detecting cryptographic misuse based on large models and contextual dependencies. Background Technology
[0002] Cryptography, as a core means of ensuring data security, is widely used in scenarios such as identity authentication, data encryption, and digital signatures. However, in actual coding processes, insufficient understanding or negligence of cryptographic principles often leads to various misuses of cryptography.
[0003] Traditional cryptographic misuse detection methods primarily rely on static analysis tools such as FindSecBugs and Checkmarx, which match sensitive function calls using predefined rules or regular expressions. These methods can only cover known patterns and have high false positive and false negative rates. Summary of the Invention
[0004] This application provides a method and apparatus for detecting cryptographic misuse based on large models and context dependencies, so as to detect cryptographic misuse based on large models and context dependencies.
[0005] This application provides a cryptographic misuse detection method based on large models and context dependencies, the method comprising: The target code is parsed according to the parsing method that matches the code type of the target code to be detected, so as to obtain the external context dependency information of the target code when the target code has cross-file dependencies; wherein, the target code having cross-file dependencies means that the target code depends on information in other files other than the code file in which it is located at runtime; Identify the target class code for cryptographic misuse detection from the target code; Based on the first major model and its external context dependencies, as well as the target class code, cryptographic misuse detection is performed on the target code.
[0006] This application also provides an electronic device. The electronic device includes: a processor and a machine-readable storage medium; The machine-readable storage medium stores machine-executable instructions that can be executed by the processor; The processor is used to execute machine-executable instructions to implement the steps of the disclosed method.
[0007] As can be seen from the above technical solutions, this embodiment obtains the external context dependency information of the target code when there are cross-file dependencies, so as to accurately restore the context environment of the target code. It also utilizes the powerful semantic understanding capabilities of the large language model and the target class code identified from the target code for cryptographic misuse detection to perform cryptographic misuse detection on the target code in the restored context environment. This achieves cryptographic misuse detection based on the large model and context relationship, overcomes the problem of high false positive and false negative rates of traditional static detection tools, solves the problem that traditional static detection tools cannot detect cross-file cryptographic misuse, and can adapt to complex code project environments. Attached Figure Description
[0008] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0009] Figure 1 A flowchart illustrating the method provided in this application embodiment; Figure 2 A flowchart illustrating the context dependency resolution process provided in this application embodiment; Figure 3 A flowchart illustrating the implementation of step 102 provided in this application embodiment; Figure 4 A flowchart illustrating the implementation of step 103 provided in this application embodiment; Figure 5 A verification flowchart provided for embodiments of this application; Figure 6 This is a structural diagram of the device provided in the embodiments of this application; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0010] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.
[0011] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application are also intended to include the plural forms unless the context clearly indicates otherwise.
[0012] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, and to make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0013] See Figure 1 , Figure 1 This is a flowchart illustrating a method provided in an embodiment of this application. This method is applied to electronic devices such as computers, but this embodiment is not specifically limited to these applications.
[0014] like Figure 1 As shown, the process may include the following steps: Step 101: Parse the target code according to the parsing method that matches the code type of the target code in the target code file to be detected, so as to obtain the external context dependency information of the target code when there is cross-file dependency.
[0015] As an example, the target code described above may be code in a single file or may consist of code from multiple different files; this example is not specifically limited.
[0016] Furthermore, in this embodiment, the corresponding parsing method can be selected to parse the target code based on its code type (CodeType). In this embodiment, different code types can use different parsing methods.
[0017] Optionally, the target code can be of the following types: Java, C / C++, Python, etc. In specific implementations, Java has its corresponding parsing method, C / C++ has its corresponding parsing method, and Python has its corresponding parsing method. This embodiment does not specifically limit the parsing method, as long as it can parse out the cross-file dependency of the target code and obtain the external context dependency information of the target code when the target code has cross-file dependency.
[0018] Optionally, cross-file dependencies in the target code refer to the target code's runtime dependence on information from files other than its own. If the target code calls code or information, such as configuration information, from files other than its own, it means that the target code has cross-file dependencies.
[0019] The following text will provide examples of how to obtain the external context dependency information of the target code when cross-file dependencies are found, which will not be elaborated here.
[0020] Step 102: Identify the target class code for cryptographic misuse detection from the target code.
[0021] Step 102 involves extracting target class code related to cryptographic misuse detection from the target code and removing code unrelated to cryptographic misuse detection. Examples will be provided below, and will not be elaborated upon here.
[0022] Step 103: Based on the first major model and its external context dependencies and the target class code, perform cryptographic misuse detection on the target code.
[0023] As an example, the first major model here, such as LLM1, can be an existing large model with high code understanding capabilities and long contextualization capabilities, such as Qwen3-32B. This type of model can handle long code segments and has strong code analysis capabilities.
[0024] This concludes the process. Figure 1 The process is shown below.
[0025] pass Figure 1 As shown in the flowchart, this embodiment obtains the external context dependency information of the target code when cross-file dependencies exist, so as to accurately restore the context environment of the target code. It then utilizes the powerful semantic understanding capabilities of the large language model and the target class code identified from the target code for cryptographic misuse detection to perform cryptographic misuse detection on the target code in the restored context environment. This achieves cryptographic misuse detection based on the large model and context relationship, overcomes the problem of high false positive and false negative rates of traditional static detection tools, solves the problem that traditional static detection tools cannot detect cross-file cryptographic misuse, and can adapt to complex code project environments.
[0026] Step 101 is described below: As an example, the external context dependency information of the target code includes at least one of the following: a set of undefined code called in the target code; file information of the configuration files used by the target code; a list of external API calls required by the target code and related dependency files and header file information found based on the project build file of the project to which the target code belongs.
[0027] As an example, if the target code's code type is Java, the corresponding parsing method is as follows: Figure 2 As shown: Step 201: Traverse the abstract syntax tree (AST) of the target code to obtain the call list (CL) and class definition list (DL) corresponding to the target code.
[0028] Here, the Abstract Syntax Tree (AST) of the target code can be obtained by performing semantic parsing on the target code. The AST is used to describe the syntax of the target code. The AST abstractly describes the syntactic structure of the target code using a tree structure, ignoring irrelevant details (such as semicolons and parentheses), and retaining only key syntactic units and their combination relationships. The tree structure mentioned above includes: A node represents a unit of syntax (such as an operator, variable, function, etc.). Edges represent the combination relationship between nodes (such as "belongs to" or "is a substructure"); In a hierarchy, the root node represents the highest level of structure (such as the program entry point), and child nodes represent nested relationships.
[0029] In this embodiment, DL includes the classes defined in the target code, and CL includes the classes, functions, and variables called in the target code.
[0030] Step 202: Obtain a class set based on the above CL and the above DL. The class set includes classes that are called in the target code but are not defined.
[0031] In this embodiment, the intersection of the above CL and the above DL (i.e. This indicates a class that is called in the target code and has been defined in the file where the target code resides. Furthermore, in the above CL, besides... Other classes (i.e.) ) indicates a class that is called in the target code but is not defined (e.g., a class imported via import).
[0032] Step 203: For each class in the above class set, obtain the location where the class is defined from other code files in the project where the target code is applied, and extract the class code from that location; the above code set includes the extracted code of each class.
[0033] For example, in the project where the target code is applied, find the location of each class definition in the class collection and extract the class code according to that location.
[0034] As an example, the code set described above can include the extracted code of various types.
[0035] As another embodiment, after extracting the class code, function code (such as constructor code and other function code (func_code)) can be extracted from that class code. Ultimately, the aforementioned code set will contain all the extracted function code. This embodiment does not specifically limit the form of the code set.
[0036] Step 204: If the target code uses the configuration file (Configlist) of the project, extract the information (configinfo) from the configuration file.
[0037] Here, the information extracted from the configuration file can be all the information contained in the configuration file, or it can be the information in the configuration file used by the target code. This embodiment does not specifically limit it.
[0038] Step 205: Based on the project build file of the project to which the target code belongs, find the list of external API calls required by the target code, as well as related dependency files and header file information.
[0039] For example, if the target code is a C / C++ project, and the project to which the target code belongs has a build file, the list of external API calls required by the target code, as well as related dependency files and header file information, can be found based on the project build file. Here, the project build file is a configuration file used to define and manage the project build process, usually in XML format. It contains key information such as the project's source code, dependencies, build goals, and tasks, and is the basis for build tools (such as Maven, MSBuild, Gradle, etc.) to parse and execute the build process.
[0040] In this embodiment, the order of steps 204, 205 and 201 is not specifically limited.
[0041] This concludes the process. Figure 2 The process is shown below.
[0042] pass Figure 2 The process shown demonstrates how to obtain the external context dependency information of the target code.
[0043] As can be seen, this embodiment analyzes the external dependencies of the target code by collecting the target code's AST, project build files, and configuration files, and obtains as much contextual information as possible from the target code. This effectively solves the problem that current static code analysis tools only analyze single-file or function-level code, making it difficult to effectively detect cross-file cryptographic misuse. This method can significantly improve the accuracy of misuse identification, and is especially suitable for high-risk scenarios such as key management and protocol configuration in complex projects.
[0044] The following describes step 102 above: See Figure 3 , Figure 3 A flowchart illustrating the implementation of step 102 in an embodiment of this application. Figure 3 As shown, the process may include the following steps: Step 301: For each function in the target code, use regular expression matching to check if there is a keyword matching the function in the constructed cryptographic keyword library. If there is, determine that the function is a function used for cryptographic misuse detection. If not, store the function in the skiplist.
[0045] In this embodiment, a cryptographic keyword library has been constructed, such as Cipher, Hash, Http, SSL, Encrypt, Sign, SM4, etc.
[0046] In this embodiment, for each function in the target code, regular expression matching is performed using the aforementioned cryptographic keyword library. If the match is successful, the function is marked as a function for cryptographic misuse detection. If the match fails, the function is skipped and added to the Skiplist.
[0047] Step 302: Traverse the abstract syntax tree of the target code, and when the currently traversed node indicates a function in the target code, check whether there is a keyword matching the function in the constructed cryptographic keyword library. If so, determine that the function is a function used for cryptographic misuse detection. If not, store the function in the Skiplist mentioned above.
[0048] Step 303: Use the large model to check whether the functions in the Skiplist are used for cryptographic misuse detection, so as to find the functions used for cryptographic misuse detection from the Skiplist.
[0049] The purpose of examining functions within the Skiplist using a large model is to avoid missing functions in the target code used for detecting cryptographic misuse.
[0050] As an example, Skipli can be cleared after step 303 is completed.
[0051] As an example, the target class code described above includes functions for cryptographic misuse detection arranged in the order of their calls within the target code.
[0052] pass Figure 3 The process shown ultimately enables the identification of target class code (including at least the functions mentioned above for cryptographic misuse detection) from the target code.
[0053] Step 103 is described below: Before performing step 103, a prompt template can be constructed. This prompt template at least indicates the context and purpose of cryptographic misuse detection of the target code based on the aforementioned target code. The context and purpose are determined based on the aforementioned external context dependencies and the aforementioned target class code.
[0054] In this embodiment, the prompt word template requires combining external context dependencies and the aforementioned target code, and performing cryptographic misuse detection on the target code according to, but not limited to, the Current Common Weakness (CWE) table. As an example, the CWE table here is a CWE table related to cryptographic misuse detection, constructed based on detection requirements, etc. Optionally, the CWE table here mainly covers currently known CWE types of cryptographic misuse, with each entry consisting of a CWE-ID, name, misuse description, family relationship, and misuse example.
[0055] As an example, the prompt word template uses the following structure: ● Role Requirements: The first model mentioned above is required to act as a cryptographic security analysis expert to detect cryptographic misuse of the target code.
[0056] ● Rule: This rule requires at least the first major model to check if a cryptographic misuse type matching the target code exists in the current CWE table. If not, the target code matches a specified type. The specified type is different from any cryptographic misuse type in the CWE table and is denoted as Additional Misues.
[0057] ●Severity-Level Indicator: This indicator is used to classify the severity of impact when the first major model determines that cryptographic misuse exists in the target code. For example, the severity level can be assessed based on factors such as whether the misuse can be executed, the degree of damage to the program, and whether it represents best practice. For instance, the first major model might use four levels: Critical, High, Medium, and Low.
[0058] ● Output format specification: The first large model is required to output the final detection results in JSON format with a fixed framework.
[0059] In this embodiment, the prompt word template will also have terminology accuracy requirements, requiring the first major model to clearly distinguish cryptographic terms, such as distinguishing between a key and a password.
[0060] In this embodiment, the aforementioned external context dependencies and the aforementioned target class code are appended to the prompt word template.
[0061] As an example, the prompt template also includes intent-based requirements. For instance, it requires understanding the purpose of the target code by considering the target code, the aforementioned external context dependencies, and the target class code. It also requires the primary model to consider and determine whether cryptographic misuse exists in the target code within the current environment. For example, if the target code is explicitly used for password storage, the use of salt must be checked. This example guides the primary model to understand the use case and purpose of the target code, reducing false positives caused by mismatched use cases and / or purposes. Furthermore, it builds upon traditional rule-based detection methods by enabling the primary model to explore potential cryptographic misuses outside the CWE table, reducing the possibility of missed detections.
[0062] As can be seen, this embodiment, by utilizing the extensive learning data of the first large model, explores potential cryptographic misuses outside the CWE table, effectively reducing the illusion problem generated by the first large model and more accurately identifying cryptographic misuses. Furthermore, the cue word template guides the first large model from the perspective of a cryptographic analysis expert, enabling it to accurately distinguish cryptographic terms and understand the role of cryptographic codes in their context, effectively suppressing false alarms caused by terminology confusion.
[0063] Based on this, the specific implementation of step 103 above may include: Figure 4 The process shown is as follows: like Figure 4 As shown, the process may include the following steps: Step 401: Input the above prompt word template and the above target code into the first large model to obtain the output result of the first large model. The output result indicates the detection result of the first large model based on the prompt word template for cryptographic misuse detection.
[0064] As an example, the first large model (LLM1) can be an existing large model with high code understanding capabilities and long contextualization capabilities, such as Qwen3-32B. This type of model can handle long code segments and has strong code analysis capabilities.
[0065] Step 402: Based on the output of the first major model, determine the target detection result for cryptographic misuse detection of the target code.
[0066] As described above, the first model will output a result that follows the above output format specifications based on the prompt, such as a JSON format string, which, after parsing, will yield one or more results containing at least one of the following key elements: ●CWE-ID: The type of target code matching, such as a cryptographic misuse type in the CWE table or the Additional Misuse mentioned above; ●Misuse_name: The specific name of a cryptographic misuse type in the CWE table that is matched by the target code; ●Details: Describe the details and / or reasons for the cryptographic misuse when it exists in the target code; ●Severity-Level: The level of impact caused by cryptographic misuse when the target code is misused, such as one of the four levels mentioned above: Critical, High, Medium, and Low. ●Algorithm: The unsafe algorithm used; if it is not related to the algorithm, fill it with 'N / A'. ●Locations: The location in the target code where cryptographic misuse occurs, such as indicated by function information and line numbers.
[0067] As an example, the target detection result for cryptographic misuse detection of the target code, determined based on the output of the first major model, is as follows in specific implementation: Figure 5 As shown, it may include: Step 501: Validate the reference results using the second major model within the context of the target code and the intended use.
[0068] In this embodiment, the second major model (LLM2) is not the same as the first major model LLM1, but LLM2 also needs to have the ability to handle long contexts and long code.
[0069] If there are no other methods besides the above-mentioned method of detecting cryptographic misuse of the target code based on the first major model and the external context dependency relationship and the target class code, then the above reference results include: the current output results of the first major model; otherwise, the reference results include the current output results of the first major model and the detection results of cryptographic misuse of the target code under other methods such as traditional static methods.
[0070] Here, the second major model validates the reference results within the context and intended use of the target code. This includes validating the format and correctness of the reference results, and ultimately outputting feedback results. The format of the feedback results output by the second major model conforms to the output format specifications of the first major model described above.
[0071] Step 502: If the second major model verifies that there is a problem with the reference result, then the first major model performs cryptographic misuse detection on the target code based on the verification result, the external context dependency relationship, and the target class code, and returns to the step in step 501 where the second major model verifies the reference result in the context and purpose of the target code; otherwise, the reference result is used as the above target detection result.
[0072] As an example, after verifying the reference results using the second model within the context of the target code and the intended use, the number of verifications can be updated, such as increasing the existing number of verifications by 1.
[0073] As an example, before the first major model performs cryptographic misuse detection on the target code based on the verification results, the aforementioned external context dependencies, and the target class code, it can first determine whether the current number of verifications has reached the set number. If not, the first major model continues to perform cryptographic misuse detection on the target code based on the verification results, the aforementioned external context dependencies, and the target class code. Otherwise, the reference result is used as the target detection result, or a prompt is output to remind external personnel to adjust the reference result according to their needs to obtain the target detection result.
[0074] This embodiment employs a limited-round verification mechanism. By using the first major model's dependency relationship with the external context and the target class code as a reference, it performs cryptographic misuse detection and other detection methods on the target code. This allows the second major model to judge the correctness of the output results of the first major model within a limited number of rounds, effectively reducing false positives or false negatives caused by illusions and improving the credibility of the results.
[0075] Furthermore, this embodiment uses a second model, different from the first model, to verify the output of the first model. This reduces the likelihood that the illusion generated by the first model will be transmitted to the second model, thereby increasing the robustness of the verification.
[0076] This concludes the process. Figure 5 The process is shown below.
[0077] Finally passed Figure 4 and Figure 5 The process shown demonstrates how to perform cryptographic misuse detection on target code based on the first major model, external context dependencies, and the target class code.
[0078] The methods provided in the embodiments of this application have been described above. The apparatus provided in the embodiments of this application is described below: See Figure 6 , Figure 6 A structural diagram of a device provided in an embodiment of this application. The device includes: A context detection unit is used to parse the target code according to a parsing method that matches the code type of the target code to be detected, so as to obtain the external context dependency information of the target code when the target code has cross-file dependencies; wherein, the cross-file dependencies of the target code mean that the target code depends on information in other files besides the file in which it is located at runtime; and, Identify the target class code for cryptographic misuse detection from the target code; The detection unit is used to perform cryptographic misuse detection on the target code based on the first major model and the external context dependency relationship and the target class code.
[0079] Optionally, the external context dependency information of the target code includes at least one of the following: The set of code that is called but not defined in the target code; The target code uses the configuration file information of the configuration file; The list of external API calls required by the target code, along with related dependency files and header file information, is found based on the project build file of the project to which the target code belongs.
[0080] Optionally, the set of code that is called but not defined in the target code is obtained through the following steps: For each class in the class set, the location where the class is defined is obtained from other code files in the project to which the target code is applied; the class set includes classes that are called in the target code but are not defined. Extract class code from this location; the code set includes the extracted code of various types or function code from various types of code.
[0081] Optionally, the class set is obtained through the following steps: The abstract syntax tree corresponding to the target code is traversed to obtain the call list CL and class definition list DL corresponding to the target code; the abstract syntax tree is used to describe the syntax of the target code; the DL includes the classes defined in the target code, and the CL includes the classes called in the target code; The class set is obtained based on the CL and the DL.
[0082] Optionally, identifying the target class code for cryptographic misuse detection from the target code includes: For each function in the target code, regular expression matching is used to check whether there is a keyword matching the function in the constructed cryptographic keyword library. If there is, the function is determined to be a function used for cryptographic misuse detection. If not, the function is stored in the Skiplist. Traverse the abstract syntax tree of the target code, and when the currently traversed node indicates a function in the target code, check whether there is a keyword matching the function in the constructed cryptographic keyword library. If so, determine that the function is a function used for cryptographic misuse detection. If not, store the function in the Skiplist. A large model is used to check whether the functions in the Skiplist are used for cryptographic misuse detection, so as to find the functions used for cryptographic misuse detection from the Skiplist; The target class code includes functions for cryptographic misuse detection, arranged in the order of their calls within the target code.
[0083] Optionally, the step of performing cryptographic misuse detection on the target code based on the first major model's dependencies on the external context and the target class code includes: The external context dependency, the target class code, and the target code are input into the first large model to obtain the output of the first large model. The output indicates that the first large model performs cryptographic misuse detection on the target code based on the context environment and purpose of use of the target code. The context environment and purpose of use are determined based on the external context dependency and the target class code. Based on the output of the first large model, the target detection result for cryptographic misuse detection of the target code is determined.
[0084] Optionally, inputting the external context dependency, the target class code, and the target code into the first main model includes: inputting the prompt word template and the target code into the first main model; The prompt word template includes the external context dependency, the target class code, and the following: The rule indicates at least that the first large model detects whether the target code matches a cryptographic misuse type in the current general defect CWE table, and if not, determines that the target code matches a specified type, which is different from any cryptographic misuse type in the CWE table; The impact level classification indicator is used to instruct the first large model to classify the impact level when it determines that the target code has cryptographic misuse; Output format specifications.
[0085] Optionally, the output of the first large model includes at least one of the following: The type matched by the target code is either a specified type or a cryptographic misuse type in the CWE table; When cryptographic misuse exists in the target code, the location of the misuse, the level of impact caused by the misuse, the details of the misuse, and / or the cause of the misuse are specified.
[0086] Optionally, determining the target detection result for cryptographic misuse detection of the target code based on the output of the first large model includes: The reference results are verified using the second major model within the context and intended use of the target code. If no other method exists besides the cryptographic misuse detection method based on the first major model, external context dependencies, and the target code, then the reference results include the current output of the first major model; otherwise, the reference results include the current output of the first major model and the detection results of cryptographic misuse detection of the target code under other methods. The context and intended use are determined based on the external context dependencies and the target code. If the second major model verifies that the reference result has a problem, then the first major model performs cryptographic misuse detection on the target code based on the verification result, the external context dependency, and the target class code, and returns to the step of using the second major model to verify the reference result in the context and purpose of the target code; otherwise, the reference result is used as the target detection result.
[0087] This concludes the process. Figure 6 Structural description of the device shown.
[0088] This application also provides embodiments that... Figure 6 The hardware structure of the device shown. See also Figure 7 , Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Figure 7 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.
[0089] Based on the same application concept as the above method, this application embodiment also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the method disclosed in the above examples of this application.
[0090] For example, the aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For instance, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.
[0091] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A cryptographic misuse detection method based on large models and context dependencies, characterized in that, The method includes: The target code is parsed according to the parsing method that matches the code type of the target code to be detected, so as to obtain the external context dependency information of the target code when the target code has cross-file dependencies; wherein, the target code having cross-file dependencies means that the target code depends on information in other files other than the code file in which it is located at runtime; Identify the target class code for cryptographic misuse detection from the target code; Based on the first major model and its external context dependencies, as well as the target class code, cryptographic misuse detection is performed on the target code.
2. The method according to claim 1, characterized in that, The external context dependency information of the target code includes at least one of the following: The set of code that is called but not defined in the target code; The target code uses the configuration file information of the configuration file; The list of external API calls required by the target code, along with related dependency files and header file information, is found based on the project build file of the project to which the target code belongs.
3. The method according to claim 2, characterized in that, The set of code that is called but not defined in the target code is obtained through the following steps: For each class in the class set, the location where the class is defined is obtained from other code files in the project to which the target code is applied; the class set includes classes that are called in the target code but are not defined. Extract class code from this location; the code set includes the extracted code of various types or function code from various types of code.
4. The method according to claim 3, characterized in that, The class set is obtained through the following steps: Traverse the abstract syntax tree corresponding to the target code to obtain the call list (CL) and class definition list (DL) corresponding to the target code; The abstract syntax tree is used to describe the syntax of the target code; the DL includes classes defined in the target code, and the CL includes classes called in the target code; The class set is obtained based on the CL and the DL.
5. The method according to claim 1, characterized in that, The identification of target class code for cryptographic misuse detection from the target code includes: For each function in the target code, regular expression matching is used to check whether there is a keyword matching the function in the constructed cryptographic keyword library. If there is, the function is determined to be a function used for cryptographic misuse detection. If not, the function is stored in the Skiplist. Traverse the abstract syntax tree of the target code, and when the currently traversed node indicates a function in the target code, check whether there is a keyword matching the function in the constructed cryptographic keyword library. If so, determine that the function is a function used for cryptographic misuse detection. If not, store the function in the Skiplist. A large model is used to check whether the functions in the Skiplist are used for cryptographic misuse detection, so as to find the functions used for cryptographic misuse detection from the Skiplist; The target class code includes functions for cryptographic misuse detection, arranged in the order of their calls within the target code.
6. The method according to claim 1, characterized in that, The cryptographic misuse detection of the target code based on the first major model and external context dependencies and the target class code includes: The external context dependency, the target class code, and the target code are input into the first large model to obtain the output result of the first large model. The output result indicates that the first large model performs cryptographic misuse detection on the target code based on the context environment and purpose of use of the target code. The context environment and purpose of use are determined based on the external context dependency and the target class code. Based on the output of the first large model, the target detection result for cryptographic misuse detection of the target code is determined.
7. The method according to claim 6, characterized in that, The step of inputting the external context dependency, the target class code, and the target code into the first large model includes: inputting the prompt word template and the target code into the first large model; The prompt word template includes the external context dependency, the target class code, and the following: The rule indicates at least that the first large model detects whether the target code matches a cryptographic misuse type in the current general defect CWE table, and if not, determines that the target code matches a specified type, which is different from any cryptographic misuse type in the CWE table; The impact level classification indicator is used to instruct the first large model to classify the impact level when it determines that the target code has cryptographic misuse; Output format specifications.
8. The method according to any one of claims 1 to 7, characterized in that, The output of the first large model includes at least one of the following: The type matched by the target code is either a specified type or a cryptographic misuse type in the CWE table; When cryptographic misuse exists in the target code, the location of the misuse, the level of impact caused by the misuse, the details of the misuse, and / or the cause of the misuse are specified.
9. The method according to claim 6, characterized in that, The target detection results for cryptographic misuse detection of the target code, determined based on the output of the first major model, include: The reference results are verified using the second major model within the context and intended use of the target code. If no other method exists besides the cryptographic misuse detection method based on the first major model, external context dependencies, and the target code, then the reference results include the current output of the first major model; otherwise, the reference results include the current output of the first major model and the detection results of cryptographic misuse detection of the target code under other methods. The context and intended use are determined based on the external context dependencies and the target code. If the second major model verifies that the reference result has a problem, then the first major model performs cryptographic misuse detection on the target code based on the verification result, the external context dependency, and the target class code, and returns to the step of using the second major model to verify the reference result in the context and purpose of the target code; otherwise, the reference result is used as the target detection result.
10. An electronic device, characterized in that, The electronic device includes: a processor and a machine-readable storage medium; The machine-readable storage medium stores machine-executable instructions that can be executed by the processor; The processor is used to execute machine-executable instructions to implement the method steps of any one of claims 1-9.