Security vulnerability testing method and device for program codes

Abstract

One or more embodiments of the invention provide a method and a device for testing security vulnerabilities of program codes. In one or more embodiments of the specification, the executable application program can be automatically generated according to the calling link information by acquiring the calling link information associated with the specified entry node in the target source code, and then the application program is executed in the pre-established running environment, and the application program can be automatically executed according to the execution result of the application program. And determining security vulnerability information involved in the call link information.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of computer technology, and more particularly, to a method and device for testing security vulnerabilities in program codes. Background Art

[0002] In the software development scenario, the developed software products need to be fully tested and can only be put into use after passing the test. Usually, the testing methods for software products include black box testing and white box testing. Among them, black box testing mainly tests the explicit content such as the function, interface, input, output, compatibility, and security of the software product, while white box testing tests the implicit content such as the logic, syntax, code path, data structure, error handling mechanism, performance, etc. of the program code itself. Therefore, for white box testing, a more comprehensive and in-depth investigation of the program code is required.

[0003] White box testing usually includes two methods: tool testing and manual testing. For tool testing, most of them use code static analysis to check whether there are security vulnerabilities in the program code based on preset security vulnerability rules. However, the testing tool has certain limitations in scanning program code, and often false positives or false negatives occur, and the test results are not ideal. For manual testing, not only does it require testers to be very familiar with the program code, but they also need to have extremely high technical capabilities. However, for program codes with complex functions, even if testers have the above capabilities, it takes a lot of time and effort to complete the testing work.

[0004] Therefore, whether through tool testing or manual testing, the test efficiency and the accuracy of the test results are difficult to guarantee. Summary of the invention

[0005] One or more embodiments of the present specification provide a method and apparatus for testing security vulnerabilities in program codes, so as to improve the accuracy of program code testing and improve testing efficiency.

[0006] In a first aspect, one or more embodiments of the present specification provide a method for testing security vulnerabilities in program code, comprising: obtaining call link information associated with a specified entry node in a target source code; automatically generating an executable application based on the call link information; executing the application in a pre-built operating environment; and determining security vulnerability information related to the call link information based on the execution result of the application.

[0007] In an optional embodiment, obtaining call link information associated with a specified entry node in a target source code includes: obtaining a data flow associated with a specified entry node in the target source code; determining, by the determination module, the call relationship between each node associated with the data flow and the access address of each node as the call link information associated with the specified entry node.

[0008] In an optional embodiment, obtaining call link information associated with a specified entry node in a target source code includes: obtaining an analysis result obtained by performing a static analysis operation on the target source code; and determining, based on the analysis result, the call link information associated with the specified entry node in the target source code.

[0009] In an optional embodiment, obtaining analysis results obtained by performing a static analysis operation on a target source code includes: inputting the target source code into a code static analysis tool; instructing the code static analysis tool to perform a static analysis operation according to a specified entry node in the target source code; and obtaining analysis results output by the code static analysis tool.

[0010] In an optional embodiment, an executable application is automatically generated based on the call link information, including: inputting the call link information into a preset analysis model, the preset analysis model is generated by training source code corresponding to a preset programming language, and the preset programming language includes a programming language corresponding to the target source code; obtaining an executable application generated by the preset analysis model based on the call link information.

[0011] In an optional embodiment, the application is executed in a pre-built operating environment, including: obtaining multiple test cases corresponding to the application; executing the application in a pre-built operating environment according to the multiple test cases to obtain execution results of each test case; and determining security vulnerability information related to the call link information according to the execution results of the application, including: determining security vulnerability information related to the call link information according to the execution results of each test case.

[0012] In an optional embodiment, obtaining multiple test cases corresponding to the application includes: obtaining multiple test cases corresponding to the application generated by the preset analysis model according to the call link information.

[0013] In an optional embodiment, security vulnerability information involved in the call link information is determined based on the execution result of each test case, including: based on the execution result of each test case, determining at least one first target node with a functional defect in the call link information and the defect type caused by each first target node as the security vulnerability information involved in the call link information.

[0014] In an optional embodiment, based on the execution result of each test case, the security vulnerability information involved in the call link information is determined, including: determining at least one vulnerability node existing in the call link information and the vulnerability type caused by each vulnerability node from the analysis result, as the static analysis result of the call link information; based on the execution result of each test case, determining at least one second target node with functional defects in the application and the defect type caused by each second target node, as the dynamic test result of the call link information; based on the static analysis result and the dynamic test result, determining the security vulnerability information involved in the call link information.

[0015] In an optional embodiment, the security vulnerability information involved in the call link information is determined based on the static analysis results and the dynamic test results, including: determining the accuracy of the static analysis results based on the vulnerability type caused by the at least one vulnerability node and each vulnerability node, and the defect type caused by the at least one second target node and each second target node; determining the security vulnerability information involved in the call link information based on the dynamic test results and the static analysis results after the accuracy is determined.

[0016] In a second aspect, one or more embodiments of the present specification provide a security vulnerability testing device for program code, comprising: an acquisition module for acquiring call link information associated with a specified entry node in a target source code; a generation module for automatically generating an executable application based on the call link information; an execution module for executing the application in a pre-built operating environment; and a determination module for determining security vulnerability information related to the call link information based on the execution result of the application.

[0017] In an optional embodiment, the acquisition module acquires the call link information associated with the specified entry node in the target source code, and is used to: acquire the data flow associated with the specified entry node in the target source code; determine the call relationship between each node associated with the data flow and the access address of each node through the determination module as the call link information associated with the specified entry node.

[0018] In an optional embodiment, the acquisition module acquires the call link information associated with the specified entry node in the target source code, and is used to: acquire the analysis result obtained by performing a static analysis operation on the target source code; based on the analysis result, determine the call link information associated with the specified entry node in the target source code.

[0019] In an optional embodiment, the acquisition module acquires analysis results obtained by performing a static analysis operation on a target source code, and is used to: input the target source code into a code static analysis tool; instruct the code static analysis tool to perform a static analysis operation according to a specified entry node in the target source code; and acquire the analysis results output by the code static analysis tool.

[0020] In an optional embodiment, the generation module automatically generates an executable application based on the call link information, and is used to: input the call link information into a preset analysis model, the preset analysis model is generated by training source code corresponding to a preset programming language, and the preset programming language includes the programming language corresponding to the target source code; obtain the executable application generated by the preset analysis model based on the call link information.

[0021] In an optional embodiment, the execution module executes the application in a pre-built operating environment, and is used to: obtain multiple test cases corresponding to the application through the acquisition module; execute the application in the pre-built operating environment according to the multiple test cases to obtain the execution results of each test case; the determination module determines the security vulnerability information involved in the call link information according to the execution results of the application, and is used to: determine the security vulnerability information involved in the call link information according to the execution results of each test case.

[0022] In an optional embodiment, the acquisition module acquires multiple test cases corresponding to the application, and is used to: acquire multiple test cases corresponding to the application generated by the preset analysis model according to the call link information.

[0023] In an optional embodiment, the determination module determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: determine at least one first target node with functional defects in the call link information and the defect type caused by each first target node based on the execution result of each test case, as the security vulnerability information involved in the call link information.

[0024] In an optional embodiment, the determination module determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: determine at least one vulnerability node existing in the call link information and the vulnerability type caused by each vulnerability node from the analysis result, as the static analysis result of the call link information; determine at least one second target node with functional defects in the application and the defect type caused by each second target node based on the execution result of each test case, as the dynamic test result of the call link information; determine the security vulnerability information involved in the call link information based on the static analysis result and the dynamic test result.

[0025] In an optional embodiment, the determination module determines the security vulnerability information involved in the call link information based on the static analysis results and the dynamic test results, and is used to: determine the accuracy of the static analysis results based on the vulnerability type caused by the at least one vulnerability node and each vulnerability node, and the defect type caused by the at least one second target node and each second target node; determine the security vulnerability information involved in the call link information based on the dynamic test results and the static analysis results after the accuracy is determined.

[0026] In a third aspect, one or more embodiments of the present specification further provide an electronic device comprising a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, the security vulnerability testing method of the first aspect mentioned above is implemented.

[0027] In a fourth aspect, one or more embodiments of the present specification further provide a computer-readable storage medium, wherein the computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed, the security vulnerability testing method of the first aspect described above is implemented.

[0028] In summary, by performing static code analysis on the target source code, the call link information and existing vulnerability information in the target source code can be identified from the grammatical and semantic aspects, and the corresponding static analysis results can be obtained. Furthermore, based on the above call link information, the corresponding executable application and the corresponding test case are generated in an automated manner, and in a pre-built operating environment, a variety of methods are used to verify the execution results of the application under each test case as the dynamic test results of the application in the running state. In this way, by simulating the execution performance of the target source code in a real scenario, the target source code is comprehensively tested in a combination of static and dynamic methods, and more accurate test results can be obtained. In addition, the entire test process does not require manual comprehensive investigation of the target source code, nor does it require the performance of complex operations, which helps to improve test efficiency while ensuring the accuracy of the test results. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 1 A flowchart of a method for testing security vulnerabilities in program code provided for one or more embodiments of this specification;

[0031] Figure 2 A structural block diagram of a security vulnerability testing device for program code provided by one or more embodiments of this specification;

[0032] Figure 3 A structural block diagram of an electronic device provided for one or more embodiments of this specification. DETAILED DESCRIPTION

[0033] One or more embodiments of the present invention are further described in detail below through the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present invention will become clearer and more specific.

[0034] The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise noted.

[0035] In addition, the technical features involved in different implementations of one or more embodiments of this specification described below can be combined with each other as long as they do not conflict with each other.

[0036] To facilitate understanding, the application scenarios of the technical solutions provided by one or more embodiments of this specification are first described below.

[0037] In the actual test scenario of software product testing, for software products with complex structures and functions, each test task may only test part of the functions of the software product. That is to say, for the source code of the entire software product, the corresponding source code may be very large. When executing each test task, only the part of the source code corresponding to the software function specified by the test task can be tested, without traversing the entire source code of the entire software product. Of course, in the case where all functions of the entire software product need to be tested, all source codes corresponding to the entire software product can also be tested, which can be determined according to actual needs. In addition, any source code can be tested by the security vulnerability testing method for program code provided in one or more embodiments of this specification. In one or more embodiments of this specification, the source code to be tested is recorded as the target source code. Through the method provided in one or more embodiments of this specification, all functions of the target source code can be tested, and the part of the source code corresponding to the target software function in the target source code can also be tested.

[0038] Based on the above, one or more embodiments of the present specification provide a method and apparatus for testing security vulnerabilities in program codes, so as to improve the accuracy of test results while improving test efficiency.

[0039] The following describes the implementation principles of each step of the method for testing security vulnerabilities in program codes provided by one or more embodiments of this specification in conjunction with the accompanying drawings.

[0040] Figure 1 A flowchart of a method for testing security vulnerabilities in program code provided in this embodiment is shown in FIG. Figure 1 As shown, the method includes:

[0041] S102, obtaining call link information associated with a specified entry node in the target source code;

[0042] S104, automatically generating an executable application program according to the call link information;

[0043] S106, executing the application program in the pre-built operating environment;

[0044] S108. Determine security vulnerability information involved in the call link information according to the execution result of the application program.

[0045] In one or more embodiments of the present specification, in order to test the software function in the software product, it is necessary to determine the designated entry node corresponding to the software function to be tested in the target source code according to the specific test requirements, and then, according to the designated entry node, determine the call link information associated with the designated entry node in the target source code. In actual R&D scenarios, although the source code written by the R&D personnel can reflect the implementation principles of various software functions, since the source code written by the R&D personnel may contain certain errors, this may cause the above-mentioned call link information to involve some security vulnerabilities. Therefore, after determining the call link information associated with the designated entry node, an executable application corresponding to the corresponding call link information can be automatically generated, and then, the application is executed in a pre-built operating environment to determine the security vulnerability information involved in the call link information based on the execution result of the application.

[0046] In one or more embodiments of the present specification, the specific type of the designated entry node is not limited. Optionally, the designated entry node can be a target function executed in the target source code when the user triggers the designated software function, wherein the call link information associated with the designated entry node can be the relevant information generated by the target function calling other functions in sequence during the execution process, including but not limited to the access path corresponding to each function and the parameter list corresponding to each function, as well as the call relationship between the target function and other functions. Of course, in actual applications, it is not limited to this. The designated entry node can also be the class file, executable script, access page, etc. corresponding to the triggered software function in the target source code, which can be determined according to actual needs.

[0047] Accordingly, one or more embodiments of this specification do not limit the specific content of the security vulnerability information involved in the call link information. Optionally, it can be the result information caused by the code error during the execution of the target source code associated with the call link information, and the specific cause corresponding to the corresponding code error. For example, there are vulnerability nodes with code errors in the target source code, as well as the vulnerability type caused by each vulnerability node, the error parameter type involved in the vulnerability node, the error call logic, etc. The specific content can be determined according to the actual situation.

[0048] Based on the above, the implementation principle of each step in the above method is specifically described below.

[0049] For ease of explanation, in one or more embodiments of this specification, the executor of the above method is referred to as a test device, wherein the specific manner in which the test device obtains the call link information associated with the specified entry node in the target source code is not limited, and is exemplified below with specific embodiments.

[0050] In an optional manner, the test device may first obtain the data flow associated with the specified entry node in the target source code, and then determine the call relationship between the nodes associated with the data flow and the access address of each node as the call link information associated with the specified entry node. Wherein, the specific method for obtaining the data flow associated with the specified entry node is not limited. Optionally, the test device may first convert the target source code into a structural object that is easy to analyze, and then obtain the data flow associated with the specified node by analyzing the corresponding structural object. For example, the test device first converts the target source code into an abstract syntax tree (AST) structure, and then finds the specified entry node by traversing the AST corresponding to the target source code, analyzes the interaction information between the specified entry node and other nodes, and obtains the data flow associated with the specified entry node. For example, the test device can track the definition and use of the variables associated with the specified entry node, as well as information such as function calls and return values, and then obtain the values ​​of the corresponding variables, the parameters and return values ​​of the function, and the control flow path as the data flow associated with the specified entry node.

[0051] There is no limitation on the specific method of converting the target source code into the AST structure. Optionally, the test device can use a tool or library that can parse the source code to perform the above conversion operation. The type of tool or library used can be determined according to the programming language type of the target source code. For example, if the target source code uses the Python programming language, the AST module in the Python standard library can be used to parse the target source code and obtain the corresponding AST; for another example, if the target source code uses the Java programming language, Java integrated development tools (Java Development Tools) such as Eclipse can be used, or another tool for language recognition (ANTLR) can be used to parse the target source code and obtain the corresponding AST.

[0052] In another optional manner, the test device may also directly obtain the call link information associated with the specified entry node in the target source code from other devices or objects, and then execute subsequent steps according to the corresponding call link information. Optionally, the code static analysis tool may perform a static analysis operation on the target source code to obtain a corresponding analysis result, wherein when the code static analysis tool performs a static analysis operation on the target source code, the call relationship between each node and the access address of each node can be identified from the target source code. The specific implementation principle is similar to the above example, and the description of the above example can be referred to, which will not be repeated here. Based on this, the test device can obtain the analysis result obtained by the code static analysis tool performing a static analysis operation on the target source code. Among them, this embodiment does not limit the subject running the code static analysis tool. Optionally, it can be run on other devices or on a test device, and can be selected according to actual needs.

[0053] In this embodiment, the specific manner in which the code static analysis tool performs the static analysis operation on the target source code is not limited. In an optional manner, the code static analysis tool can perform the static analysis operation on the entire source code of the software product (i.e., the entire source code of the target source code); or, the code static analysis tool can also perform the static analysis operation on part of the source code of the software product (i.e., part of the source code of the target source code), and the part of the source code includes the source code associated with the specified entry node. In both cases, the analysis result obtained by the code static analysis tool performing the static analysis operation on the corresponding source code includes not only the call link information associated with the specified entry node, but also the call link information associated with other nodes. In another optional manner, the code static analysis tool can perform the static analysis operation only on the source code associated with the specified entry node. In this case, the analysis result obtained by the code static analysis tool performing the static analysis operation on the source code associated with the specified entry node only includes the call link information associated with the specified entry node.

[0054] In one or more embodiments of the present specification, the code static analysis tool only performs static analysis operations on the source code associated with the specified entry node as an example for explanation. Optionally, the entire source code of the software product (i.e., the target source code) can be input into the code static analysis tool, and the scanning parameters corresponding to the software function to be tested can be configured through the configuration interface provided by the code static analysis tool to indicate the designated entry node corresponding to the corresponding software function in the target source code. Among them, the scanning parameter can be an access address, a node identifier, or other indication information that can determine the designated entry node corresponding to the designated entry node, and the specific content is not limited. Based on this, the code static analysis tool can scan the target source code from the designated entry node according to the scanning parameter and perform a static analysis operation to obtain the corresponding analysis result, wherein the analysis result only includes the call link information associated with the designated entry node. Further, the test device can obtain the analysis result output by the code static analysis tool, and determine the call link information associated with the designated entry node in the target source code according to the analysis result.

[0055] Furthermore, in order to automatically generate an executable application corresponding to the above-mentioned call link information, one or more embodiments of the present specification provide a preset analysis model, which is generated by training source code corresponding to a preset programming language, and the preset programming language includes a programming language corresponding to a target source code. Based on this, after the above-mentioned call link information is input into the preset analysis model, the preset analysis model can perform structural, grammatical and semantic recognition on the call link information based on the grammatical rules corresponding to the corresponding programming language, so as to identify the various functions associated with the call link information, the access paths of each function, the call logic and dependencies between each function, and the data flow direction in the corresponding call link information. Furthermore, based on the identified information and the grammatical rules of the programming language corresponding to the target source code, an executable application is automatically generated.

[0056] Optionally, in order to allow the preset analysis model to fully understand the content of the call link information, before the above call link information is input into the preset analysis model, the call link information can also be converted into a format for direct processing by the preset analysis model. Among them, there is no limitation on the type of data format that the preset analysis model can directly process, including but not limited to lightweight data exchange format (javascript object notation, JSON), extensible markup language (extensible markup language, XML), simple table data format (comma-separated values, CSV), lightweight text format (yet another markup language, YAML), of course, it can also be Excel or ordinary text format, the specific type can be determined according to the actual processing requirements of the preset analysis model, and will not be described in detail here.

[0057] In one or more embodiments of the present specification, the type of programming language corresponding to the source code used to train the preset analysis model is not limited. Optionally, the source code used to train the preset analysis model can be source code written in the same programming language, or can be source code written in multiple programming languages. It can be understood that the preset analysis model obtained by training the source code written in the same programming language is only used to identify the target source code written in the corresponding programming language, and the preset analysis model obtained by training the source code corresponding to multiple programming languages ​​can be regarded as a universal analysis model, which can identify the target source code written in the corresponding multiple programming languages.

[0058] For example, if the preset analysis model is generated by training source code written only in the Java programming language, then the preset analysis model can only recognize the target source code written in the Java programming language; for another example, if the preset analysis model is generated by training source code written in multiple programming languages ​​such as PHP, Java, Python, JavaScript, TypeScript, C++, C#, Visual Basic, SQL, etc., then the preset analysis model can recognize the target source code written in any one or more of the above programming languages. Of course, the types of programming languages ​​mentioned above are only exemplary and are not limited to this in actual applications. Accordingly, the embodiments of this specification do not limit the training method of the preset analysis model. For example, the preset analysis model can be trained based on the Transformer architecture, but of course it is not limited to this. As long as the model training method meets the actual needs, it can be applied to this solution and will not be described in detail here.

[0059] Further, in order to automatically generate an executable application corresponding to the above-mentioned call link information through a preset analysis model, a running environment for application execution can be pre-built, wherein the type of framework used to build the running environment is not limited, and the corresponding running environment can be built using an adapted framework according to the execution needs of the application. Optionally, the Spring Boot framework can be used to provide the basic configuration files, startup classes, service classes, necessary application programming interface (API) templates, and pre-packaged library files required for application execution, such as a lightweight database engine. Based on this, through the various files provided by the Spring Boot framework, real running scenarios can be simulated to achieve normal data processing, database access, and receiving of database return data during the execution of the application, and then determine the execution result of the application.

[0060] Based on this, the executable application generated by the preset analysis model can be a Spring Boot application instance. For example, the preset analysis model can identify the core functions involved and the call logic between functions according to the above call link information, and generate specific logic code, including but not limited to building a specific class structure for the Spring Boot framework and filling in various method signatures, comments, annotations and other information, and building necessary dependent objects, such as lib files, to build a complete Spring Boot application instance. Among them, there is no limitation on the way in which the preset analysis model builds the dependent objects required for the Spring Boot application instance. Optionally, in order to improve processing efficiency, the preset analysis model can also directly copy the corresponding dependent objects in the target source code as the dependent objects required for the Spring Boot application instance. Further, after the corresponding Spring Boot application instance is packaged into an executable program file, for example, packaged into a JAR file (JavaArchive) or a WAR file (Web Archive), the test device can deploy it to a pre-built operating environment and execute it to obtain the corresponding execution result.

[0061] Furthermore, the test device can determine the security vulnerability information involved in the call link information based on the execution result of the above application. Optionally, the test device can directly determine the security vulnerability information involved in the call link information based on the execution result of the application. For example, the security vulnerability information involved in the call link information can be determined based on the test data constructed by the R&D personnel and the execution performance at each breakpoint in the execution process of the application by breaking points. Alternatively, the test device can also first obtain multiple test cases corresponding to the application, and then, according to the multiple test cases, execute the application in a pre-built operating environment to obtain the execution result of each test case, so as to determine the security vulnerability information involved in the call link information according to the execution result of each test case.

[0062] In one or more embodiments of the present specification, the generation method of multiple test cases is not limited. In an optional method, multiple test cases can be generated separately by a designated platform for generating test cases. Optionally, the designated platform can automatically generate corresponding test cases in various scenarios based on the received program code. In this case, after the preset analysis model generates the application, the application can be sent to the designated platform, and the designated platform generates corresponding multiple test cases based on the application. Based on this, the test device can directly obtain multiple test cases corresponding to the application from the designated platform. In another optional method, multiple test cases can be directly generated by a preset analysis model. In this case, in the process of identifying the above-mentioned call link information, the preset analysis model can not only identify the dependency relationship between the functions and other information, but also identify the execution performance of each function, and generate the application and its corresponding multiple test cases based on the identification results. Based on this, the test device can obtain multiple test cases generated by the preset analysis model according to the call link information.

[0063] Furthermore, after obtaining multiple test cases corresponding to the application, the test device can execute the corresponding application according to each test case in the pre-built operating environment. According to the execution result of each test case, the security vulnerability information involved in the above-mentioned call link information is determined. Among them, the embodiment of this specification does not limit the method of determining the security vulnerability information. In an optional method, at least one first target node with a functional defect and the defect type caused by each first target node can be directly determined from the above-mentioned call link information according to the execution result of each test case, and the at least one first target node with a functional defect and the defect type caused by each first target node determined are used as the security vulnerability information involved in the above-mentioned call link information. In another optional method, the analysis results output by the code static analysis tool can also be combined with the execution results of each test case to jointly determine the security vulnerability information involved in the above-mentioned call link information. The specific method to be adopted can be determined according to actual needs.

[0064] In one or more embodiments of the present specification, for the analysis results output by the code static analysis tool, the embodiments of the present specification do not limit the corresponding specific content. Optionally, the code static analysis tool can not only identify the call link information associated with the specified entry node in the target source code, but also perform grammatical and semantic analysis on the corresponding call link information according to the preset security vulnerability rules, thereby identifying the vulnerability nodes with functional vulnerabilities and the type of error parameters, error call logic, line number corresponding to the error code, and other information that cause each vulnerability. In other words, the analysis results output by the code static analysis tool can also include information such as at least one vulnerability node existing in the call link information associated with the specified entry node and the type of vulnerability caused by each vulnerability node.

[0065] It should be noted that in the above embodiment, the specific content of the preset security vulnerability rules is not limited. Optionally, the security vulnerability rules include but are not limited to structured query language (SQL) injection vulnerability scanning rules, cross-site scripting (XSS) vulnerability scanning rules, cross-site request forgery (CSRF / XSRF) vulnerability scanning rules, sensitive data leakage vulnerability scanning rules, code injection vulnerability scanning rules, file upload vulnerability scanning rules, input validation and encoding rules, encryption and permission control rules, secure coding practice rules, abstract syntax tree (AST) analysis rules, and the like.

[0066] Accordingly, according to the SQL injection vulnerability scanning rules, it is possible to check whether the user's input information in the target source code contains SQL statement fragments that may be maliciously exploited, so as to prevent illegal operations on the database; according to the XSS vulnerability scanning rules, it is possible to check whether the target source code contains vulnerabilities that may inject malicious scripts, so as to prevent the theft of sensitive information of users; according to the CSRF / XSRF vulnerability scanning rules, it is possible to check whether the target source code lacks necessary protection measures, so as to prevent attackers from using user identities to execute illegal requests; according to the sensitive data leakage vulnerability scanning rules, it is possible to check whether the target source code handles sensitive data safely, so as to avoid improper access or leakage of data during storage or transmission; according to the code injection vulnerability scanning rules, it is possible to check whether the user's input information in the target source code contains malicious code that may be injected, so as to prevent Illegal operation of the system; according to the file upload vulnerability scanning rules, it is possible to check whether the file upload function in the target source code is safe to prevent attackers from uploading malicious files and using them to attack; according to the input validation and encoding rules, it is possible to check whether the user's input information in the target source code is properly validated and encoded to prevent the occurrence of the above-mentioned vulnerabilities; according to the encryption and permission control rules, it is possible to check whether the target source code uses secure encryption methods and appropriate permission control to protect sensitive data and prevent unauthorized access; according to the secure coding practice rules, it is possible to check whether there are deprecated system classes or methods in the target source code; according to the AST analysis rules, it is possible to check whether the specified controllable variables flow into the dangerous function to locate potential vulnerabilities, etc. Of course, the above methods are only exemplary and are not limited to this in actual applications.

[0067] In actual application scenarios, even if the program code itself has no loopholes in syntax and function, due to code logic errors, static analysis scanning may not be able to identify exceptions that can only occur during code execution. The analysis results obtained by code static analysis tools performing analysis operations on the target source code have certain limitations. For example, runtime exceptions such as index out of bounds, forced conversion of object types, concurrent modification restrictions, null pointers, missing objects to wait for or notify, and insufficient memory cannot be detected by code static analysis alone.

[0068] Therefore, in order to obtain more accurate security vulnerability information, the test equipment can also determine at least one vulnerability node in the above-mentioned call link information and the vulnerability type caused by each vulnerability node from the analysis results output by the code static analysis tool, and use the determined at least one vulnerability node and the vulnerability type caused by each vulnerability node as the static analysis result of the corresponding call link information. Furthermore, according to the execution result of each test case, at least one second target node with functional defects in the above-mentioned application and the defect type caused by each second target node are determined, and the determined at least one second target node and the defect type caused by each second target node are used as the dynamic test result of the above-mentioned call link information. Based on this, the security vulnerability information involved in the above-mentioned call link information can be more accurately determined based on the static analysis results and the dynamic test results.

[0069] In this embodiment, the specific manner in which the test device determines the security vulnerability information involved in the above-mentioned call link information based on the static analysis results and the dynamic test results is not limited. Optionally, after determining the static analysis results and the dynamic analysis results of the above-mentioned call link information, the test device can directly use the corresponding static analysis results and the dynamic analysis results as the security vulnerability information involved in the above-mentioned call link information. Alternatively, the test device can also first determine the accuracy of the static analysis results based on at least one vulnerable node and the type of vulnerability caused by each vulnerable node, and at least one second target node and the type of defect caused by each second target node. Then, based on the dynamic test results and the static analysis results after the accuracy is determined, the security vulnerability information involved in the call link information is determined.

[0070] Optionally, when determining the accuracy of the static analysis results, the test device can determine the accuracy of the static analysis results based on the execution results of multiple test cases. For example, taking the generation of multiple test cases through a preset analysis model as an example, the preset analysis model can identify the analysis results output by the code static analysis tool, and generate test cases for testing various vulnerability types in a targeted manner based on the identified static analysis results. Based on this, when executing the corresponding test case, the test device can verify whether the analysis results of at least one vulnerability node and the vulnerability type caused by each vulnerability node in the above static analysis results are accurate based on the execution results of each test case, so as to correct inaccurate analysis results.

[0071] In this embodiment, there is no limitation on the way of generating multiple test cases by the preset analysis model. Optionally, the preset analysis model can determine which functions or components need to be tested according to the call logic between the functions abstracted from the static analysis results, and generate corresponding test cases. For functions or components with simple call logic, test cases with normal input, output and boundary conditions can be directly generated, while for functions or components with complex functions or dependencies with external objects, the preset analysis model can construct Mock test code and test cases corresponding to the corresponding Mock test code for the corresponding functions or components, so as to replace the actual functions or components in the application with the Mock test code in the pre-built operating environment, and test the functions of the Mock test code and the interaction performance with external objects by executing the corresponding test cases. Among them, there is no limitation on the specific way of testing the Mock test code in the operating environment. Optionally, a Docker container can be created in advance, and the application, Mock test code and necessary dependent objects generated by the preset analysis model can be deployed into the Docker container, and the corresponding Mock test code and its corresponding test cases can be executed in the Docker container, and the corresponding execution results can be observed and recorded.

[0072] Of course, the above is only an exemplary description, and different testing methods can also be used according to actual testing needs. For example, a simple Maven project can also be deployed in a pre-built operating environment, and the main test class (Main Class) can be built therein, and the corresponding pom.xml file can be set and the dependencies and necessary configuration information required for the test can be defined therein. Based on this, the above application and the corresponding test case can be built and run in the Maven project by executing various commands to obtain the corresponding execution results. For another example, fuzz testing (fuzzing) can also be used, using a fuzzing tool or a preset analysis model to automatically generate a fuzzing script corresponding to the above application, so as to generate random or pseudo-random input data as the corresponding test case. Furthermore, the corresponding fuzzing test results are obtained by executing the application according to the above test case in the pre-built operating environment.

[0073] Further optionally, for each vulnerability type obtained through the test, a pre-prepared POC verification code (proof of concept, POC) can be used to verify the authenticity of each vulnerability, wherein the POC verification code can be pre-written by R&D personnel, or automatically generated based on the above identification through a preset analysis model, which is not limited here.

[0074] It should be noted that no matter which method is used to test the application, during the execution of multiple test cases, the execution results of each test case can also be fed back to the preset analysis model, so that the preset analysis model can continuously adjust the training data and optimize the training process and code generation capabilities of the preset analysis model. Further optionally, in order to intuitively display the test results, the test equipment can also output the execution results of multiple test cases in the form of reports or visual charts, for example, it can display data flow link diagrams and function call relationship diagrams associated with various vulnerabilities, and an overview description and repair suggestions for each vulnerability, etc., so that R&D personnel can refer to the relevant information to modify the corresponding source code.

[0075] In one or more embodiments of the present specification, by performing code static analysis on the target source code, the call link information and the existing vulnerability information in the target source code can be identified from the grammatical and semantic aspects to obtain the corresponding static analysis results. Further, based on the above call link information, the corresponding executable application and the corresponding test case are generated in an automated manner, and in a pre-built operating environment, a variety of methods such as mock testing, fuzzing testing, and POC verification are used to verify the execution results of the application under each test case as the dynamic test results of the application in the running state. In this way, by simulating the execution performance of the target source code in a real scenario, the target source code is comprehensively tested in a combination of static and dynamic methods, and more accurate test results can be obtained. In addition, the entire test process does not require manual comprehensive investigation of the target source code, nor does it require the performance of complex operations, which helps to improve test efficiency while ensuring the accuracy of the test results.

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

[0077] Based on the same inventive concept, one or more embodiments of the present specification also provide a security vulnerability testing device for program code. Since the principle of solving the problem by the security vulnerability testing device is similar to that of the aforementioned security vulnerability testing method, the implementation of the security vulnerability testing device can refer to the implementation of the aforementioned security vulnerability testing method, and the repeated parts will not be repeated.

[0078] See also Figure 2 , Figure 2 This is a structural block diagram of a security vulnerability testing device provided by one or more embodiments of this specification. Figure 2As shown, the security vulnerability testing device 200 may include: an acquisition module 201, a generation module 202, an execution module 203 and a determination module 204. The acquisition module 201 is used to acquire the call link information associated with the specified entry node in the target source code; the generation module 202 is used to automatically generate an executable application according to the call link information; the execution module 203 is used to execute the application in a pre-built operating environment; the determination module 204 is used to determine the security vulnerability information involved in the call link information according to the execution result of the application.

[0079] In an optional embodiment, the acquisition module 201 acquires the call link information associated with the specified entry node in the target source code, and is used to: acquire the data flow associated with the specified entry node in the target source code; determine the call relationship between each node associated with the data flow and the access address of each node through the determination module 204 as the call link information associated with the specified entry node.

[0080] In an optional embodiment, the acquisition module 201 acquires the call link information associated with the specified entry node in the target source code, and is used to: acquire the analysis result obtained by performing a static analysis operation on the target source code; based on the analysis result, determine the call link information associated with the specified entry node in the target source code.

[0081] In an optional embodiment, the acquisition module 201 acquires the analysis results obtained by performing a static analysis operation on the target source code, and is used to: input the target source code into a code static analysis tool; instruct the code static analysis tool to perform a static analysis operation according to a specified entry node in the target source code; and acquire the analysis results output by the code static analysis tool.

[0082] In an optional embodiment, the generation module 202 automatically generates an executable application based on the call link information, and is used to: input the call link information into a preset analysis model, the preset analysis model is generated by training source code corresponding to a preset programming language, and the preset programming language includes a programming language corresponding to the target source code; obtain the executable application generated by the preset analysis model based on the call link information.

[0083] In an optional embodiment, the execution module 203 executes the application in a pre-built operating environment, and is used to: obtain multiple test cases corresponding to the application through the acquisition module 201; execute the application in the pre-built operating environment according to the multiple test cases to obtain the execution result of each test case; the determination module 204 determines the security vulnerability information involved in the call link information according to the execution result of the application, and is used to: determine the security vulnerability information involved in the call link information according to the execution result of each test case.

[0084] In an optional embodiment, the acquisition module 201 acquires multiple test cases corresponding to the application, and is used to: acquire multiple test cases corresponding to the application generated by a preset analysis model according to the call link information.

[0085] In an optional embodiment, the determination module 204 determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: determine at least one first target node with functional defects in the call link information and the defect type caused by each first target node based on the execution result of each test case, as the security vulnerability information involved in the call link information.

[0086] In an optional embodiment, the determination module 204 determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: determine at least one vulnerability node existing in the call link information and the vulnerability type caused by each vulnerability node from the analysis result, as the static analysis result of the call link information; determine at least one second target node with functional defects in the application and the defect type caused by each second target node based on the execution result of each test case, as the dynamic test result of the call link information; determine the security vulnerability information involved in the call link information based on the static analysis result and the dynamic test result.

[0087] In an optional embodiment, the determination module 204 determines the security vulnerability information involved in the call link information based on the static analysis results and the dynamic test results, and is used to: determine the accuracy of the static analysis results based on at least one vulnerability node and the vulnerability type caused by each vulnerability node, and at least one second target node and the defect type caused by each second target node; determine the security vulnerability information involved in the call link information based on the dynamic test results and the static analysis results after the accuracy is determined.

[0088] It should be noted that the functional principles of each module in the above-mentioned security vulnerability testing device are the same as the implementation principles of the corresponding steps in the above-mentioned question-and-answer service method. For details, please refer to the description of the corresponding parts in the above-mentioned method embodiment, which will not be repeated here.

[0089] See also Figure 3 , Figure 3 This is a structural block diagram of an electronic device provided in one or more embodiments of this specification. Figure 3 As shown, the electronic device 300 may include a processor 301 and a memory 302; the memory 302 may be coupled to the processor 301. It is worth noting that Figure 3 is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunication functions or other functions.

[0090] In a possible implementation, the functions of the security vulnerability testing device 200 may be integrated into the processor 301. The processor 301 may be configured to perform the following operations:

[0091] Obtain call link information associated with a specified entry node in the target source code;

[0092] Automatically generate executable applications based on call link information;

[0093] Execute applications in a pre-built runtime environment;

[0094] According to the execution result of the application, the security vulnerability information involved in the call link information is determined.

[0095] In another possible implementation, the security vulnerability testing device 200 can be configured separately from the processor 301. For example, the security vulnerability testing device 200 can be configured as a chip connected to the processor 301, and the security vulnerability testing with the user can be implemented and question-and-answer services can be provided to the user through the control of the processor 301.

[0096] In addition, in some optional implementations, the electronic device 300 may 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 300 does not necessarily include Figure 3 In addition, the electronic device 300 may also include Figure 3 For components not shown, reference may be made to the prior art.

[0097] In some optional implementations, the processor 301 is sometimes also referred to as a controller or an operation control, and may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device 300.

[0098] The memory 302 may be, for example, a cache, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory or other suitable devices. The memory 302 may store the information related to the security vulnerability testing device 200, and may also store a program for executing the related information. The processor 301 may execute the program stored in the memory 302 to implement information storage or processing.

[0099] The input unit can provide input to the processor 301. The input unit is, for example, a key or a touch input device. The power supply can be used to provide power to the electronic device 300. The display can be used to display display objects such as images and text. The display can be, for example, an LCD display, but is not limited thereto.

[0100] The memory 302 may be a solid-state memory, such as a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It may also be a memory that saves information even when the power is off, can be selectively erased, and is provided with more data, examples of which are sometimes referred to as EPROMs, etc. The memory 302 may also be some other type of device. The memory 302 includes a buffer memory (sometimes referred to as a buffer). The memory 302 may include an application / function storage unit for storing application programs and function programs or processes for executing the operation of the electronic device 300 by the processor 301.

[0101] The memory 302 may also include a data storage unit for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit of the memory 302 may include various drivers for the communication function of the computer device and / or for executing other functions of the computer device (such as a messaging application, a contact book application, etc.).

[0102] The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor 301 to provide input signals and receive output signals, which may be the same as in a conventional mobile communication terminal.

[0103] Based on different communication technologies, multiple communication modules may be provided in the same computer device, such as a cellular network module, a Bluetooth module and / or a wireless local area network module, etc. The communication module (transmitter / receiver) is also coupled to a speaker and a microphone via an audio processor to provide an audio output via the speaker and receive an audio input from the microphone, thereby realizing a common telecommunication function. The audio processor may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor is also coupled to the processor 301, so that recording can be performed on the machine through the microphone, and the sound stored on the machine can be played through the speaker.

[0104] One or more embodiments of the present specification also provide a computer-readable storage medium capable of implementing all the steps of the security vulnerability testing method in the above embodiments. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, all the steps of the security vulnerability testing method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0105] Obtain call link information associated with a specified entry node in the target source code;

[0106] Automatically generate executable applications based on call link information;

[0107] Execute applications in a pre-built runtime environment;

[0108] According to the execution result of the application, the security vulnerability information involved in the call link information is determined.

[0109] Although one or more embodiments of this specification provide method operation steps such as embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative work. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment).

[0110] It should be understood by those skilled in the art that the embodiments of this specification may be provided as methods, devices (systems) or computer program products. Therefore, the embodiments of this specification may take the form of complete hardware embodiments, complete software embodiments or embodiments combining software and hardware. Moreover, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0111] One or more embodiments of the present specification are described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to one or more embodiments of the present specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0112] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0113] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0114] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment 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 partial description of the method embodiments.

[0115] In this article, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. For those of ordinary skill in the art, the specific meaning of the above terms in one or more embodiments of this specification can be understood according to the specific circumstances.

[0116] It should be noted that, in the absence of conflict, one or more embodiments of this specification and the features in the embodiments may be combined with each other. One or more embodiments of this specification are not limited to any single aspect, nor to any single embodiment, nor to any combination and / or replacement of these aspects and / or embodiments. Moreover, each aspect and / or embodiment of one or more embodiments of this specification may be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, rather than to limit them. Although one or more embodiments of this specification have been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some or all of the technical features may be replaced by equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of one or more embodiments of this specification, and they should all be included in the scope of the claims and the specification of one or more embodiments of this specification.

[0118] One or more embodiments of this specification are described above in conjunction with optional implementation methods, but these implementation methods are only exemplary and serve only as an illustration. On this basis, multiple replacements and improvements can be made to one or more embodiments of this specification, all of which fall within the scope of protection of one or more embodiments of this specification.

Claims

1. A method for testing security vulnerabilities in program code, characterized in that: include: Obtain call link information associated with a specified entry node in the target source code; Automatically generate an executable application based on the call link information; Executing the application in a pre-built operating environment; Determine security vulnerability information related to the call link information based on the execution result of the application.

2. The method according to claim 1, characterized in that Get the call chain information associated with the specified entry node in the target source code, including: Get the data flow associated with the specified entry node in the target source code; Determine the calling relationship between each node associated with the data flow and the access address of each node as the calling link information associated with the designated entry node.

3. The method according to claim 1, characterized in that Get the call chain information associated with the specified entry node in the target source code, including: Obtain analysis results obtained by performing static analysis operations on the target source code; Based on the analysis result, call link information associated with the specified entry node in the target source code is determined.

4. The method according to claim 3, characterized in that Obtain the analysis results of static analysis operations on the target source code, including: Input the target source code into the code static analysis tool; instructing the code static analysis tool to perform a static analysis operation according to a specified entry node in the target source code; and Obtain analysis results output by the code static analysis tool.

5. The method according to claim 4, characterized in that Automatically generate an executable application based on the call link information, including: Inputting the call link information into a preset analysis model, wherein the preset analysis model is generated by training source code corresponding to a preset programming language, wherein the preset programming language includes the programming language corresponding to the target source code; Obtain an executable application generated by the preset analysis model according to the call link information.

6. The method according to claim 5, characterized in that Execute the application in a pre-built runtime environment, including: obtaining a plurality of test cases corresponding to the application; Executing the application in a pre-built operating environment according to the multiple test cases to obtain an execution result of each test case; Determining, based on the execution result of the application, security vulnerability information involved in the call link information, including: According to the execution result of each test case, the security vulnerability information involved in the call link information is determined.

7. The method according to claim 6, characterized in that Get a variety of test cases corresponding to the application, including: Acquire multiple test cases corresponding to the application program generated by the preset analysis model according to the call link information.

8. The method according to claim 6, characterized in that Based on the execution results of each test case, determine the security vulnerability information involved in the call link information, including: According to the execution result of each test case, at least one first target node with a functional defect in the call link information and the defect type caused by each first target node are determined as security vulnerability information involved in the call link information.

9. The method according to claim 6, characterized in that Based on the execution results of each test case, determine the security vulnerability information involved in the call link information, including: Determining, from the analysis result, at least one vulnerable node present in the call link information and a vulnerability type caused by each vulnerable node as a static analysis result of the call link information; Determining, based on the execution result of each test case, at least one second target node in the application program having a functional defect and a defect type caused by each second target node as a dynamic test result of the call link information; Determine security vulnerability information related to the call link information based on the static analysis result and the dynamic test result.

10. The method according to claim 9, characterized in that Determining security vulnerability information related to the call link information based on the static analysis results and the dynamic test results includes: Determining the accuracy of the static analysis result based on the at least one vulnerable node and the vulnerability type caused by each vulnerable node, and the at least one second target node and the defect type caused by each second target node; Security vulnerability information involved in the call link information is determined based on the dynamic test results and the static analysis results after accuracy is determined.

11. A device for testing security vulnerabilities in program code, characterized in that: include: An acquisition module, used to obtain call link information associated with a specified entry node in the target source code; A generation module, configured to automatically generate an executable application based on the call link information; An execution module, configured to execute the application in a pre-built operating environment; A determination module is used to determine the security vulnerability information involved in the call link information based on the execution result of the application.

12. The device according to claim 11, characterized in that The acquisition module acquires call link information associated with a specified entry node in the target source code, and is used to: Get the data flow associated with the specified entry node in the target source code; The calling relationship between the nodes associated with the data flow and the access address of the nodes are determined by the determination module as the calling link information associated with the designated entry node.

13. The device according to claim 11, characterized in that The acquisition module acquires call link information associated with a specified entry node in the target source code, and is used to: Obtain analysis results obtained by performing static analysis operations on the target source code; Based on the analysis result, call link information associated with the specified entry node in the target source code is determined.

14. The device according to claim 13, characterized in that The acquisition module acquires the analysis results obtained by performing a static analysis operation on the target source code, and is used to: Input the target source code into the code static analysis tool; Instructing the code static analysis tool to perform a static analysis operation according to a specified entry node in the target source code; as well as Obtain analysis results output by the code static analysis tool.

15. The device according to claim 14, characterized in that The generation module automatically generates an executable application according to the call link information, and is used to: Inputting the call link information into a preset analysis model, wherein the preset analysis model is generated by training source code corresponding to a preset programming language, wherein the preset programming language includes the programming language corresponding to the target source code; Obtain an executable application generated by the preset analysis model according to the call link information.

16. The device according to claim 15, characterized in that The execution module executes the application in a pre-built operating environment, and is used to: Acquire multiple test cases corresponding to the application program through the acquisition module; Executing the application in a pre-built operating environment according to the multiple test cases to obtain an execution result of each test case; The determination module determines, based on the execution result of the application, security vulnerability information involved in the call link information, and is used to: According to the execution result of each test case, the security vulnerability information involved in the call link information is determined.

17. The device according to claim 16, characterized in that The acquisition module acquires multiple test cases corresponding to the application program, and is used to: Acquire multiple test cases corresponding to the application program generated by the preset analysis model according to the call link information.

18. The device according to claim 16, characterized in that The determination module determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: According to the execution result of each test case, at least one first target node with a functional defect in the call link information and the defect type caused by each first target node are determined as security vulnerability information involved in the call link information.

19. The device according to claim 16, characterized in that The determination module determines the security vulnerability information involved in the call link information based on the execution result of each test case, and is used to: Determining, from the analysis result, at least one vulnerable node present in the call link information and a vulnerability type caused by each vulnerable node as a static analysis result of the call link information; Determining, based on the execution result of each test case, at least one second target node in the application program having a functional defect and a defect type caused by each second target node as a dynamic test result of the call link information; Determine security vulnerability information related to the call link information based on the static analysis result and the dynamic test result.

20. The device according to claim 19, characterized in that The determination module determines, based on the static analysis result and the dynamic test result, security vulnerability information involved in the call link information, for: Determining the accuracy of the static analysis result based on the at least one vulnerable node and the vulnerability type caused by each vulnerable node, and the at least one second target node and the defect type caused by each second target node; Security vulnerability information involved in the call link information is determined based on the dynamic test results and the static analysis results after accuracy is determined.

21. An electronic device, characterized in that: The electronic device comprises: a memory for storing a computer program product; A processor is configured to execute a computer program product stored in the memory, and when the computer program product is executed, implements the method described in any one of claims 1 to 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 according to any one of claims 1 to 10.

Images