Method, device and storage medium for vulnerability scanning without compilation

Abstract

This invention discloses a compilation-independent vulnerability scanning method, apparatus, and storage medium, comprising: acquiring file information containing source code; determining the language type of the source code; parsing the source code according to the language type to obtain data model information corresponding to the source code; scanning the data model information; and outputting the vulnerability scanning results of the file information. In practical applications, when vulnerability scanning of source code is required, it can perform corresponding parsing according to different language types of different source codes to obtain data model information in a unified format, and then perform vulnerability feature matching scanning on the unified format data model information to accurately obtain vulnerability scanning results. This solves the problem that SAST products can complete analysis and scanning of different languages ​​on the same platform, no longer relying on language-specific compilers, improving versatility without needing to consider the integrity of the project code.

Description

Technical Field

[0001] This invention belongs to the field of static code vulnerability scanning technology, and particularly relates to a vulnerability scanning method, device and storage medium that do not rely on compilation. Background Technology

[0002] Currently, most static application security testing techniques, abbreviated as SAST (Static Application Security Testing), serve to analyze the syntax, structure, processes, and interfaces of application source code or binary files during the coding phase to discover security vulnerabilities in the program code. Generally, it first calls the language's compiler or parser to convert the source code into an intermediate code, clarifying the call relationships, execution environment, and context between the source code lines.

[0003] However, this method is highly dependent on the language's compiler. For example, Swift / Objective-C (programming languages) cannot be compiled without the Mac OS Xcode (development tool) environment, and C# (programming language) also requires a Windows-based compilation environment. Besides the compiler's environment requirements, incomplete code can lead to compilation errors, and incomplete compiled files may result in missed errors.

[0004] Because the binary content compiled from different languages ​​is not uniform, in-depth analysis is required for each language, and developers need a certain understanding of compiler principles. Therefore, code analysis based on compilation suffers from poor universality, and the integrity of the project code must be ensured.

[0005] Therefore, existing technologies need to be improved. Summary of the Invention

[0006] The main objective of this invention is to propose a vulnerability scanning method, apparatus, and storage medium that do not rely on compilation, so as to at least solve the technical problem of low universality of existing vulnerability scanning methods when scanning program code for vulnerabilities.

[0007] A first aspect of the present invention provides a vulnerability scanning method that does not depend on compilation, comprising:

[0008] Obtain file information containing source code;

[0009] Determine the language type of the source code;

[0010] The source code is parsed according to the language type to obtain the data model information corresponding to the source code.

[0011] The system scans the data model information and outputs vulnerability scan results for the file information.

[0012] A second aspect of the present invention provides an electronic device including a memory, a processor, and a bus, the bus being used to enable communication between the memory and the processor, the processor being used to execute a computer program stored in the memory, and the processor executing the computer program implementing the steps of the method of the first aspect.

[0013] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the compilation-independent vulnerability scanning method of the first aspect.

[0014] This invention provides a compilation-independent vulnerability scanning method, apparatus, and storage medium. It acquires file information containing source code, determines the language type of the source code, parses the source code according to the language type to obtain data model information corresponding to the source code, analyzes the data model information, and outputs vulnerability scanning results for the file information. In practical applications, when vulnerability scanning of source code is required, it can perform corresponding analysis based on different language types of different source codes, analyze vulnerability feature matching on the obtained unified format data model information, and finally obtain vulnerability scanning results. This solves the problem of SAST products being able to perform analysis and scanning of different languages ​​on the same platform, no longer relying on language-specific compilers, and without needing to consider the integrity of the project code. Attached Figure Description

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

[0016] Figure 1 A flowchart of a compilation-independent vulnerability scanning method provided in the first embodiment of the present invention;

[0017] Figure 2 This is a schematic diagram of the source code language analyzer in this invention;

[0018] Figure 3 This is a schematic diagram illustrating the process of scanning data model information using different strategies in this invention;

[0019] Figure 4 A flowchart of a compilation-independent vulnerability scanning method provided in the second embodiment of the present invention;

[0020] Figure 5 This is a schematic diagram of the first control interface in this invention;

[0021] Figure 6 This is a schematic diagram illustrating the import of file information via the first control interface in this invention;

[0022] Figure 7 This is a schematic diagram of a portion of the data model information parsed in this invention;

[0023] Figure 8 This is a schematic diagram of a portion of the data model information parsed in this invention;

[0024] Figure 9 This is a schematic diagram of the SQL statement that needs to be dynamically constructed in the SQL injection example of this invention;

[0025] Figure 10 This is a schematic diagram of the dynamically constructed SQL statement in the SQL injection example of this invention;

[0026] Figure 11 This is a schematic diagram of the module connection of the electronic device provided in the third embodiment of the present invention.

[0027] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0028] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0029] It should be noted that related terms such as "first" and "second" can be used to describe various components, but these terms do not limit the component. These terms are only used to distinguish one component from another. For example, without departing from the scope of the invention, the first component can be referred to as the second component, and the second component can similarly be referred to as the first component.

[0030] This invention provides a compiler-independent vulnerability scanning method that can be applied to vulnerability scanning software (e.g., SAST products). After the software is installed on a terminal, the user only needs to upload the file information containing the source code to be scanned. The software then performs a series of steps on the file information to obtain the vulnerability scan results. The entire vulnerability scanning process utilizes only the terminal and server, resulting in low overall deployment costs. It also eliminates the need to consider the operating system environment on which the compiler depends, allowing for deployment anywhere. Furthermore, it eliminates concerns about the integrity of the project code, maximizing the discovery of as many vulnerabilities as possible and minimizing missed detections.

[0031] Figure 1The first embodiment of the present invention illustrates a compilation-independent vulnerability scanning method, including:

[0032] Step S10: Obtain file information containing source code;

[0033] In this embodiment, vulnerability scanning software can obtain file information containing source code in various ways. For example, the vulnerability scanning software can directly obtain file information containing source code imported by the user to a terminal with the vulnerability scanning software installed; the vulnerability scanning software can obtain file information containing source code by communicating with a server. The file information can be a compressed package, which, after decompression, yields the source code; this file information is generally generated by the user using source code-related development software, such as Mac OS XCode.

[0034] Step S20: Determine the language type of the source code;

[0035] In this embodiment, after the vulnerability scanning software obtains file information containing source code, it can decompress the file information to obtain sub-file information storing the source code. Based on the file extension of the sub-file information, it can identify the language type corresponding to the extension, thus determining the language type of the source code. For example, after decompressing the file information 111.ZIP, the sub-file information 1234.Java can be obtained. The language type of the file information can be determined to be Java based on the "Java" extension in the sub-file information.

[0036] Step S30: Parse the source code according to the language type to obtain the data model information corresponding to the source code;

[0037] In this embodiment, after the vulnerability scanning software obtains the language type of the source code, it performs analysis on the source code corresponding to the language type, thereby obtaining data model information corresponding to the source code. The vulnerability scanning software may integrate a source code language analyzer, which has multiple parsers (each parser can parse a corresponding language type), as detailed here. Figure 2 The source code language analyzer integrates Java, PHP, and Python parsers. Therefore, regardless of whether the source code is Java, Python, or any other language type, the source code language analyzer can call the corresponding parser to perform analysis and generate data model information with a unified format.

[0038] It is important to note that the vulnerability scanning method of this invention is based on a data model that can parse source code into a unified format. This method is applicable to incomplete source code, which refers to code that cannot be compiled. For example, if a source code requires three encoded pieces of information to compile, and one of these pieces is missing, preventing compilation, this type of source code is called incomplete source code. Similarly, if a source code requires three syntactically correct encoded pieces of information to compile, and one of these pieces of information contains a syntax error, preventing compilation, this type of source code is also considered incomplete source code.

[0039] Step S40: Scan the data model information and output the vulnerability scan results of the file information.

[0040] In this embodiment, reference can be made to Figure 3 The vulnerability scanning software integrates scanning functionality that supports source code quality scanning rules and source code security vulnerability scanning rules. Due to the complexity of actual source code, matching the same rule requires different strategies. One scanning rule may correspond to multiple scanning strategies. After the scan is completed, the results from multiple strategies are summarized into the result of the corresponding rule, resulting in a comprehensive vulnerability scanning result.

[0041] Once the data model information is obtained, the scanning function is activated to scan the data model information, obtaining vulnerability scan results related to quality and security weaknesses in the source code. In practical applications, when vulnerability scanning of source code is required, it can perform corresponding analysis based on different language types of different source code, scan the obtained unified format data model information, and finally obtain vulnerability scan results. This solves the problem that SAST products can complete analysis and scanning of different languages ​​on the same platform, no longer relying on language-specific compilers, and without needing to consider the integrity of the project code.

[0042] Figure 4 This invention illustrates a compilation-independent vulnerability scanning method according to a second embodiment, specifically defining the steps for obtaining file information containing source code. The method includes: step S201, detecting whether a repository type input by the user is received; and step S202, if the repository type input by the user is received, obtaining file information containing source code from the storage repository with code storage function corresponding to the repository type. Specifically, detecting whether the repository type input by the user is received in the first control interface of the vulnerability scanning software can be found in [reference needed]. Figure 5The area marked with 'A' on the first control interface can display multiple repository types, such as GIT, SVN, and TFS. When the user clicks on a repository type, the vulnerability scanning software can detect the entered repository type from the first control interface and automatically retrieve the file information containing source code from the corresponding code-storing repository (for example, if the GIT repository type is selected, the file information containing source code is automatically retrieved from the GIT code hosting repository). The code-storing repository stores sub-file information; this sub-file information has a file structure that, when opened, reveals the source code (and this sub-file information is compressed to obtain the file information).

[0043] In this embodiment, after the step of detecting whether the user-inputted repository type has been received, the steps include: Step S203, if the user-inputted repository type has not been received, detecting whether the user-inputted import file instruction has been received; Step S204, if the user-inputted import file instruction has been received, obtaining file information with source code according to the import file instruction; Step S205, if the user-inputted import file instruction has not been received, prompting the user to establish an API interface. In specific applications, this can be referred to again. Figure 5 In the area marked with B, if the user has not entered a repository type in the first operation interface, the user can still import the file information to be scanned for vulnerabilities (such as...) by clicking the import icon in the first operation interface. Figure 6 As shown, the imported format is generally ZIP or RAR (i.e., the imported file information is a compressed file). When the user neither selects a repository type nor imports, the vulnerability scanning software displays a second control interface in at least a portion of the first control interface. This second control interface prompts the user to establish an API interface. For example, this second control interface has a target address input field. When the user enters a target address (e.g., IP address 192.1.1.10) in this field, the vulnerability scanning software accesses the storage repository corresponding to the API interface based on the IP address 192.1.1.10, thereby obtaining file information containing source code. This embodiment can obtain file information through multiple acquisition methods using different storage methods, providing better convenience in obtaining file information.

[0044] In this embodiment, the step of determining the language type of the source code is specifically defined, including: decompressing the file information to obtain sub-file information within the file information, and determining the language type of the source code based on the file extension of the sub-file information. For example, when vulnerability scanning software obtains file information containing source code (such as a compressed file XXX.ZIP), it automatically decompresses the file information to obtain sub-file information within the file information (such as a file XXXXX.Java inside the compressed file), and then determines the language type of the source code as Java based on the file extension (Java).

[0045] In this embodiment, the language type corresponding to the repository type can also be obtained based on the repository type. This obtained language type corresponding to the repository type is also the language type of the source code. Furthermore, the language type corresponding to the repository type can be matched with the language type of the source code determined by the suffix name of the sub-file information. If the two are the same, one of them is taken as the determined language type, which can further ensure the accuracy of the language type of the source code in the file information.

[0046] In this embodiment, the step of analyzing the source code according to the language type to obtain the data model information corresponding to the source code is specifically defined, including: determining the parser corresponding to the language type from the source code language analyzer; using the parser to parse the source code to obtain the data model information in AST format corresponding to the source code. For example, the source code language analyzer integrates a Java parser, a Php parser, a Python parser, etc. Therefore, regardless of whether the source code is in Java, Python, or any other language, the source code language analyzer can call the corresponding parser to perform parsing and form data model information with a unified format.

[0047] The process of parsing source code is essentially the formation of an Abstract Syntax Tree (AST), which represents the data model information as an AST. In computer science, an AST is an abstract representation of the syntactic structure of source code. It represents the syntactic structure of a programming language in a tree-like format, with each node representing a structure within the source code. Since each language has its own unique syntactic features, a specific parser is needed for each language to generate a uniform AST. Because the output data model is consistent, the subsequent source code scanner only needs to focus on the business logic of rule matching. This design uses the open-source syntax generator tool ANTLR v4 (an open-source component), customizing parsers for different languages ​​according to requirements to achieve targeted parsing of source code in different language types.

[0048] In this embodiment, the step of scanning data model information and outputting vulnerability scanning results for local files includes: identifying a first data portion in the data model information, scanning the first data portion using a first preset scanning strategy, and obtaining a first scan result related to source code quality. Specifically, when the data model information is an abstract syntax tree, for example, refer to... Figure 7 This forms an abstract syntax tree that includes at least a first data part and a second data part, where the first data part includes the variable data part of the abstract syntax tree, such as... Figure 7 The name in the text. The second data part includes the expression data part of the abstract syntax tree, such as... Figure 8 ExpressionStatement in the context of expression.

[0049] The vulnerability scanning software can identify the first data portion of the data model information and scan it using a first preset scanning strategy to obtain a first scan result related to source code quality. The software also needs to identify the second data portion of the data model information and scan it using a second preset scanning strategy to obtain a second scan result related to source code security vulnerabilities. Specifically, the vulnerability scanning software executes different scanning strategies on different data portions of the data model information, outputting the first scan result related to source code quality and the second scan result related to source code security vulnerabilities as the vulnerability scan results for the local file. In other words, it obtains a comprehensive scan result considering both quality and security vulnerabilities through two different scanning strategies.

[0050] In this embodiment, the first preset scanning strategy includes a regular expression scanning strategy. The step of scanning the first data portion using the first preset scanning strategy to obtain a first scanning result related to the source code quality includes: using the regular expression scanning strategy to validate the node names of the first data portion, obtaining a validation result, and outputting a first scanning result indicating excellent source code quality when the validation result shows that the node names conform to the naming rules. If the validation result shows that the node names do not conform to the rules, it is recorded as not conforming to the encoding rules, and the rule detection ends. For example, taking Java code as an example, Java method names generally follow camelCase naming and have a lowercase first letter, so whether they conform to the encoding rules can be determined based on the node names of the Java code.

[0051] In this embodiment, the second preset scanning strategy includes a JDBC (Java Database Connectivity) scanning strategy, a Hibernate scanning strategy, and a MyBatis scanning strategy. These three strategies are related to SQL injection vulnerabilities. The steps of scanning the second data portion using the second preset scanning strategy include: scanning the second data portion using the JDBC, Hibernate, and MyBatis scanning strategies respectively. Specifically, the JDBC scanning strategy is used to detect direct calls to JDBC APIs (Application Programming Interfaces) in the second data portion; the Hibernate scanning strategy is used to detect the use of the Hibernate framework (an open-source object-relational mapping framework) in the second data portion; and the MyBatis scanning strategy is used to detect the use of iBatis (a persistence layer framework based on SQL mapping supporting Java and .NET) or the MyBatis framework (a Java-based persistence layer framework) in the second data portion. Specifically, scanning the second data portion using JDBC, Hibernate, and MyBatis scanning strategies yields third, fourth, and fifth scan results, respectively. Each scan result indicates the presence of a SQL (Structured Query Language) injection vulnerability in the second scan. In other words, the purpose of employing three different scanning strategies is to ensure the accuracy of the scan.

[0052] For example, if the third scan result shows that the second data part directly calls the JDBC API interface, then the second scan result indicates that there is an SQL (Structured Query Language) injection vulnerability; if the fourth scan result shows that the second data part uses the Hibernate framework, then the second scan result indicates that there is an SQL injection vulnerability; if the fifth scan result shows that the second data part uses the iBatis or Mybatis framework, then the second scan result indicates that there is an SQL injection vulnerability.

[0053] If the source code is not inspected and SQL injection vulnerabilities are allowed to exist, a vulnerability can arise when a specific SQL statement in an application is executed. This vulnerability allows the SQL statement to be dynamically constructed using user input data without rigorous security validation. This can lead to the execution of the concatenated SQL, illegally obtaining or even modifying database information, resulting in a SQL injection attack. For example, a dynamically constructed SQL statement (see reference...) Figure 9If the user inputs "1=1", then the dynamically constructed SQL statement (see reference) will... Figure 10 When the `record_order_info` table contains 1 million or more records, executing this statement may lead to a memory overflow risk. Therefore, this application can detect SQL injection vulnerabilities in source code. Furthermore, the source code language analyzer, designed based on the open-source syntax generator tool ANTLR v4, is cross-platform compatible and highly portable and versatile. It constructs a unified data model based on an Abstract Syntax Tree (AST). Since each language has its own unique syntactic features, a unique parser is needed for each language to generate a unified format of AST information. Developers only need to focus on the business logic implementation of rule matching. Because the output data model is consistent, scanning rules for one language can be quickly applied to other languages. A scanning rule consists of multiple scanning strategies, and each scanning strategy corresponds to a Java implementation class.

[0054] The above embodiments illustrate that the vulnerability scanning method of this application can detect SQL injection vulnerabilities. However, this application can also utilize other scanning rules to derive other vulnerabilities, such as command-line injection vulnerabilities. These will not be elaborated upon here.

[0055] Figure 11 An electronic device according to a third embodiment of the present invention is shown, which can be used to implement the compilation-independent vulnerability scanning method in any of the foregoing embodiments. The electronic device includes:

[0056] The system includes a memory 1101, a processor 1102, a bus 1103, and a computer program stored on the memory 1101 and executable on the processor 1102. The memory 1101 and the processor 1102 are connected via the bus 1103. When the processor 1102 executes the computer program, it implements the compilation-independent vulnerability scanning method described in the foregoing embodiments. The number of processors can be one or more.

[0057] The memory 1101 can be a high-speed random access memory (RAM) or a non-volatile memory, such as a disk storage device. The memory 1101 is used to store executable program code, and the processor 1102 is coupled to the memory 1101.

[0058] Furthermore, embodiments of this application also provide a computer-readable storage medium, which may be disposed in the electronic device in the above embodiments, and the computer-readable storage medium may be a memory.

[0059] The computer-readable storage medium stores a computer program that, when executed by a processor, implements the compilation-independent vulnerability scanning method described in the foregoing embodiments. Furthermore, the computer-readable storage medium can also be a USB flash drive, external hard drive, read-only memory (ROM), RAM, magnetic disk, or optical disk, or any other medium capable of storing program code.

[0060] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0061] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0062] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0063] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0064] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0065] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0066] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A vulnerability scanning method that does not rely on compilation, characterized in that, The method includes: Obtain file information containing source code; wherein, the file information includes a compressed package obtained by compressing the source code; The language type of the source code is determined based on the file extension of the extracted compressed file; The source code is parsed according to the language type to obtain the data model information corresponding to the source code; Identify a first data portion in the data model information, and scan the first data portion using a first preset scanning strategy to obtain a first scan result related to the quality of the source code; wherein, the first preset scanning strategy includes a regular expression scanning strategy; Identify the second data portion in the data model information, and scan the second data portion using a second preset scanning strategy to obtain a second scan result related to the security vulnerabilities of the source code; wherein, the second preset scanning strategy includes a JDBC scanning strategy, a Hibernate scanning strategy, and a MyBatis scanning strategy; The first scan result and the second scan result are output as the vulnerability scan results of the file information.

2. The vulnerability scanning method that does not rely on compilation as described in claim 1, characterized in that, The steps for obtaining file information containing source code include: Check if the user-inputted warehouse type has been received; If the user inputs a repository type, retrieve the file information containing the source code from the storage repository with code storage function corresponding to the repository type.

3. The vulnerability scanning method that does not rely on compilation as described in claim 2, characterized in that, After the step of detecting whether the user-inputted warehouse type has been received, the following is included: If the user-inputted repository type is not received, check whether the user-inputted import file instruction has been received; If a user inputs an import file instruction, the file information containing the source code is obtained according to the import file instruction; If the user's input command to import the file is not received, the user is prompted to create an API interface. The API interface is used to access the storage repository corresponding to the API interface and obtain file information with source code.

4. The vulnerability scanning method that does not rely on compilation as described in claim 1, characterized in that, The step of determining the language type of the source code based on the suffix name extracted from the compressed package includes: The file information is decompressed to obtain the sub-file information within the file information; The language type of the source code is determined based on the file extension of the sub-file information.

5. The vulnerability scanning method that does not rely on compilation as described in claim 1, characterized in that, The data model information includes an abstract syntax tree; The step of parsing the source code according to the language type to obtain the data model information corresponding to the source code includes: Based on the language type, a parser corresponding to the language type is determined from the source code language analyzer; wherein, the source code language analyzer has parsers for multiple language types; The source code is parsed using a parser corresponding to the language type to obtain an abstract syntax tree corresponding to the source code.

6. The vulnerability scanning method that does not rely on compilation as described in claim 1, characterized in that, The step of scanning the first data portion using a first preset scanning strategy to obtain a first scan result related to the source code quality includes: The node names in the first data portion are validated using a regular expression scanning strategy; wherein, the first data portion includes the variable data portion of the data model information; When the node name conforms to the naming rules, the first scan result indicating that the source code is of excellent quality is output.

7. The vulnerability scanning method that does not rely on compilation as described in claim 1, characterized in that, The scanning of the second data portion using the second preset scanning strategy includes: The second data portion is scanned using JDBC scanning strategy, Hibernate scanning strategy, and MyBatis scanning strategy, respectively; the second data portion includes the expression data portion of the data model information. The JDBC scanning strategy is used to detect direct calls to JDBC API interfaces in the first data section; the Hibernate scanning strategy is used to detect the use of the Hibernate framework in the second data section; and the Mybatis scanning strategy is used to detect the use of the iBatis or Mybatis framework in the second data section.

8. An electronic device, characterized in that, The method includes a memory, a processor, and a bus, wherein the bus is used to enable communication between the memory and the processor, and the processor is used to execute a computer program stored in the memory. When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the compilation-independent vulnerability scanning method according to any one of claims 1 to 7.

Images