Code vulnerability propagation path determination method and related equipment

Abstract

The invention provides a code vulnerability propagation path determination method and related equipment, which are used for solving the problem of inaccurate software vulnerability positioning and vulnerability influence analysis results in related technologies, and the method comprises the following steps: obtaining a code file and an installation configuration file of a target project; determining an actually executed target code of the code file after deployment according to the code file and the installation configuration file; extracting program elements related to vulnerability repair semantics based on the vulnerability repair patch of the code file, and generating a vulnerability anchor point set; constructing an operation dependency relationship propagation atlas according to the operation dependency relationship among the program elements in the target code; and mapping the vulnerability anchor point set to the running dependency relationship propagation map to obtain a propagation path of the vulnerability.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method and related equipment for determining the propagation path of code vulnerabilities. Background Technology

[0002] Currently, with the continuous expansion of software system scale and the widespread use of third-party components, software vulnerabilities have become a key factor affecting system security and reliability. Current analysis of software vulnerabilities mainly focuses on vulnerability scanning, vulnerability localization, and vulnerability impact assessment, among which vulnerability impact assessment is a crucial basis for determining vulnerability remediation priorities and risk mitigation strategies.

[0003] In related technologies, vulnerability impact analysis typically generates a component dependency list based on dependency declaration files or build configuration files, and then determines whether the vulnerable component is referenced in the current project. However, this method relies heavily on the developer's explicit declaration of dependencies, making it difficult to accurately reflect the actual runtime relationships of the software in a real deployment environment. On the one hand, dependency declaration files may contain redundant dependencies that are not actually used, leading to false positives in vulnerability analysis results; on the other hand, implicit dependencies introduced through dynamic loading during software operation are often not reflected in the declaration files, easily causing underestimation of the vulnerability's impact scope.

[0004] Vulnerability location analysis typically relies on patch information, comparing line differences between patches to pinpoint the corresponding program location. However, actual vulnerability patches often contain version update notes, code refactoring, test code changes, and other content unrelated to the vulnerability. Furthermore, some vulnerability fixes involve covert modifications. Therefore, relying solely on patch information for location analysis can introduce noise and fail to accurately characterize the key program elements involved in the vulnerability fix.

[0005] Furthermore, the vulnerability location and vulnerability impact assessment are handled separately in related technologies. That is, only the location of the vulnerability is determined, or only the dependency relationship between the vulnerable components is determined, making it difficult to reliably assess the actual impact range and propagation path of the vulnerability. Summary of the Invention

[0006] This disclosure proposes a method and related equipment for determining the propagation path of code vulnerabilities to solve or partially solve the above-mentioned problems.

[0007] The first aspect of this disclosure provides a method for determining the propagation path of a code vulnerability, comprising: obtaining the code file and installation configuration file of a target project; determining the target code that will actually be executed after deployment based on the code file and the installation configuration file; extracting program elements related to vulnerability repair semantics based on the vulnerability repair patch of the code file, and generating a set of vulnerability anchors; constructing a runtime dependency propagation graph based on the runtime dependencies between program elements in the target code; and mapping the set of vulnerability anchors to the runtime dependency propagation graph to obtain the propagation path of the vulnerability.

[0008] A second aspect of this disclosure provides a computer device including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, and the one or more programs include instructions for performing the method of the first aspect.

[0009] A third aspect of this disclosure provides a non-volatile computer-readable storage medium comprising a computer program that, when executed by one or more processors, causes the one or more processors to perform the method described in the first aspect.

[0010] The fourth aspect of this disclosure provides a computer program product comprising one or more computer programs that, when executed by one or more processors, implement the method as described in the first aspect.

[0011] The code vulnerability propagation path determination method of this disclosure determines the target code actually executed after deployment based on the code files and installation configuration files of the target project. This eliminates code irrelevant to actual deployment and execution, clarifying the set of actual executed code upon which subsequent vulnerability analysis is based. Based on vulnerability patch extraction, program elements semantically related to vulnerability repair are generated to form a vulnerability anchor point set. This excludes information irrelevant to the vulnerability in the patch, ensuring that the elements in the anchor point set accurately represent the key locations involved in vulnerability repair. A runtime dependency propagation graph is constructed based on the runtime dependencies between program elements in the target code. This graph, reflecting the actual runtime semantics, provides a structured foundation for determining the vulnerability propagation path. Mapping the vulnerability anchor point set to the runtime dependency propagation graph yields the vulnerability propagation path. This accurately identifies the key program elements involved in vulnerability repair and their impact on other program elements in the dependency relationship, improving the accuracy of vulnerability location results and making the vulnerability analysis results more comprehensive. Attached Figure Description

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

[0013] Figure 1 A schematic diagram of an exemplary system provided by an embodiment of this disclosure is shown.

[0014] Figure 2 A flowchart illustrating an exemplary vulnerability propagation path determination method provided in an embodiment of this disclosure is shown.

[0015] Figure 3 A flowchart illustrating an exemplary vulnerability propagation path determination method provided in an embodiment of this disclosure is shown.

[0016] Figure 4 A flowchart illustrating an exemplary vulnerability propagation path determination method provided in an embodiment of this disclosure is shown.

[0017] Figure 5 A schematic diagram of the hardware structure of an exemplary computer device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0019] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0021] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0022] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0023] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0024] Figure 1 A schematic diagram of an exemplary system 100 provided in an embodiment of this disclosure is shown.

[0025] like Figure 1 As shown, system 100 may include terminal device 102, terminal device 104, server 106, and database server 108. A medium (e.g., a network) may be included between terminal device 102, terminal device 104, server 106, and database server 108 to provide a communication link. This network may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0026] Terminal devices 102 and 104 may have various software or applications (APPs) installed, such as image processing software or applications, video conferencing software or applications, reading software or applications, video software or applications, social networking software or applications, payment software or applications, web browsers, and instant messaging tools. In some embodiments, these software or applications can be used to determine the propagation path of code vulnerabilities.

[0027] The terminal devices 102 and 104 here can be hardware or software. When terminal devices 102 and 104 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 players, laptops, and desktop computers (PCs). When terminal devices 102 and 104 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module. No specific limitations are made here.

[0028] Server 106 can be a server that provides various services, such as a backend server that supports various applications displayed on terminal devices 102 and 104. Database server 108 can also be a database server that provides various services. It is understood that if server 106 can implement the relevant functions of database server 108, database server 108 may not need to be set up in system 100.

[0029] The server 106 and database server 108 here can be either hardware or software. When they are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When they are software, they can be implemented as multiple software programs or software modules (for example, to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0030] It should be noted that the code vulnerability propagation path determination method provided in this disclosure embodiment can be executed by terminal device 102 and / or terminal device 104, or by server 106, or by interactive execution of various devices in system 100. It should be understood that... Figure 1 The number of terminal devices, servers, and database servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, servers, and database servers can be included.

[0031] In view of this, embodiments of this disclosure provide a method for determining vulnerability propagation paths to solve or partially solve the above-mentioned problems. Figure 2 A flowchart illustrating an exemplary vulnerability propagation path determination method 200 provided in an embodiment of this disclosure is shown. Figure 2 As shown, the method includes the following processing: In step 202, the code file and installation configuration file of the target project are obtained.

[0032] In step 204, the target code that will actually be executed after deployment is determined based on the code file and the installation configuration file.

[0033] Optionally, the target code that is loaded and executed in the actual deployment scenario can be identified by parsing the code files and installation configuration files of the target project, thus obtaining the set of code that is actually executed.

[0034] In step 206, program elements related to vulnerability repair semantics are extracted based on the vulnerability repair patch in the code file to generate a set of vulnerability anchor points.

[0035] The extraction of program elements semantically related to vulnerability repair from vulnerability patching in code files refers to extracting program elements directly related to the vulnerability repair behavior from the vulnerability patching in code files. Optionally, extracting program elements semantically related to vulnerability repair from the vulnerability patching in code files may specifically include: standardizing the code before vulnerability repair, the code after vulnerability repair, and their difference information to form a structured patch change representation, and extracting program elements semantically related to vulnerability repair based on the vulnerability patch change behavior to form a vulnerability anchor set. The elements in the vulnerability anchor set are used to characterize the key program locations involved in vulnerability repair. In one or more embodiments of this disclosure, program elements refer to all identifiable, analyzable, and traceable code / architectural units in the software system. These can be categorized by granularity from largest to smallest as follows: components, dynamically loaded plugins, packages, individual code files, modules, functions, methods, classes, interfaces, variables, and constants, etc.

[0036] In step 208, a runtime dependency propagation graph is constructed based on the runtime dependencies between program elements in the target code.

[0037] Optionally, the runtime dependency propagation graph can adopt a directed graph structure, where the set of nodes in the directed graph represents the program elements in the target code, and the set of directed edges represents the runtime dependencies between program elements. Runtime dependencies between program elements can include explicit runtime dependencies and dynamically loaded runtime dependencies. Explicit runtime dependencies are declared by explicit import statements in the code. Dynamically loaded runtime dependencies refer to dependencies triggered on demand by dynamically loading APIs (Application Programming Interfaces) at runtime; whether these dependencies take effect depends on runtime conditions.

[0038] In step 210, the set of vulnerability anchor points is mapped to the runtime dependency propagation graph to obtain the propagation path of the vulnerability.

[0039] In this context, the nodes in the aforementioned runtime dependency propagation graph and the nodes in the vulnerability anchor set are based on unified description rules and identifier formats to ensure that vulnerability anchors can be uniquely identified within the runtime dependency propagation graph. Mapping the vulnerability anchor set to the runtime dependency propagation graph yields the vulnerability propagation path. Specifically, this process may include: traversing the vulnerability anchor set; retrieving corresponding nodes in the runtime dependency propagation graph based on unified program element identifiers; mapping elements in the vulnerability anchor set to nodes in the runtime dependency propagation graph; performing path search in the runtime dependency propagation graph; determining the components affected by the vulnerability and their corresponding propagation paths; and thus obtaining the vulnerability propagation path.

[0040] The code vulnerability propagation path determination method of this disclosure determines the target code actually executed after deployment based on the code files and installation configuration files of the target project. This eliminates some code irrelevant to actual deployment and execution, such as code used only in the development or testing phase, thus clarifying the set of actual executable code upon which subsequent vulnerability analysis is based. Based on vulnerability patch extraction, program elements related to vulnerability repair semantics are generated to form a vulnerability anchor point set. This excludes information irrelevant to the vulnerability in the patch, ensuring that the elements in the vulnerability anchor point set accurately represent the key locations involved in vulnerability repair. A runtime dependency propagation graph is constructed based on the runtime dependencies between program elements in the target code. This graph, reflecting the actual runtime semantics, provides a structured foundation for determining the vulnerability propagation path. Mapping the vulnerability anchor point set to the runtime dependency propagation graph yields the vulnerability propagation path, accurately identifying the key program elements involved in vulnerability repair and their impact on other program elements in the dependency relationship. This improves the accuracy of vulnerability location results and makes the vulnerability analysis results more comprehensive.

[0041] Figure 3 A flowchart illustrating an exemplary vulnerability propagation path determination method 300 provided in an embodiment of this disclosure is shown. This method... Figure 2 Based on the method shown, a specific implementation of step 204 is illustrated. In this method 300, determining the target code to be actually executed after deployment based on the code file and the installation configuration file can specifically include: In step 2042, the top-level entry information in the code file is extracted to obtain the package identifier information; wherein, the package identifier information is used to uniquely identify a package.

[0042] The top-level entry point information is, for example, Python's top-level.txt.

[0043] In step 2044, the installation configuration file is parsed to obtain the deployment package path; wherein, the deployment package path refers to the storage location of the deployment package (such as WAR, JAR, installation package, etc.) in the target system during the software deployment process.

[0044] The installation configuration file describes how the project's code files are organized as packages during deployment. By parsing the installation configuration file, the path of the code that is installed and runs during the actual deployment process can be determined. For example, the installation configuration file can be a setup.cfg file or a pyproject.toml file in Python, or a pom.xml file in Java.

[0045] In step 2046, the code file is parsed based on the project layout information of the code file to obtain a deployment package set; wherein, the deployment package set may include a list of all deployment package paths obtained based on the installation configuration file.

[0046] Project layout information refers to the organization of all files and folders within a project. Optionally, the project layout information of the code files can be used to parse the code files and obtain a set of deployment packages, which may specifically include: In response to the project layout information being source code-based, all packages in the source code directory are identified as deployment packages; In response to a project layout that is not source code layout, the system searches for packages with the same name as the package identifier in the preset directory and obtains the deployment package.

[0047] In step 2048, the target code is obtained based on at least one of the package identifier information, the deployment package path, and the deployment package set.

[0048] Optionally, the code file may have multiple different layouts. Therefore, steps 2042 to 2046 above obtain the deployment package path information based on different methods to ensure that the deployment package path information can be parsed from the code file regardless of its layout. In other words, in actual execution, not all steps 2042 to 2046 need to be completed. Depending on the layout of the code file, it is possible that only one step from steps 2042 to 2046 needs to be executed to obtain the complete deployment package path of the code file.

[0049] In the embodiments disclosed herein, by parsing the top-level entry point information of the target project's code files, the core package structure exposed externally or serving as the runtime entry point in the project can be preliminarily determined. By parsing the installation configuration file, the code paths installed and involved in the actual deployment process are determined. Finally, by combining the project layout information with code file parsing, the deployment package set can be further confirmed. These processes effectively eliminate code content used only in the development or testing phases, thereby enabling the analysis of vulnerability impact based on runtime dependencies established through the actual runtime semantics between program elements.

[0050] Optionally, the deployment package path can be determined based on the installation configuration file, which may specifically include: The installation configuration file is parsed, and the deployment package path is extracted in response to the explicit indication of the deployment package path by the package path parameter in the installation configuration file. In response to the absence of an explicit indication of the deployment package path in the installation configuration file, the directory name of the deployment package to be searched is matched with the directory name in the code file to obtain the deployment package path.

[0051] Optionally, one or more common deployment package storage directories can be predefined in the code (an example of the preset targets mentioned above), such as dist (distribution directory), build (build target), and packages (package / module collection). If the deployment package path is explicitly declared in the package path parameter of the installation configuration file, that deployment package path is extracted. If the deployment package path is not explicitly indicated in the package path parameter of the configuration file—for example, if the configuration file does not exist, cannot be parsed, or the parsed path is invalid—then a search can be performed in a preset directory list based on preset matching logic, and the found deployment package path is returned.

[0052] Optionally, based on the vulnerability patch in the code file, program elements related to vulnerability patching semantics are extracted to generate a set of vulnerability anchors, which may specifically include: Obtain the first code before vulnerability patching is executed, the second code after vulnerability patching is executed, and patch difference information; Here, "First Code" refers to the original code version when the vulnerability existed. "Second Code" refers to the new code version after the vulnerability was patched. "Patch Difference Information" is a text file containing all changes from "First Code" to "Second Code".

[0053] Remove non-target language files, comment lines, and differences in the test directory from the patch difference information to obtain the remaining patch difference information; Here, "target language" refers to the primary programming language targeted by the vulnerability patch. "Comment-based differences" refers to modifications made only to the comments, without altering the code's execution logic. "Difference information in the test directory" refers to test cases added or modified in the `tests / ` or `test / ` directories.

[0054] Adjacent difference lines in the remaining patch difference information are aggregated into change code blocks, and the change code blocks are labeled with change types, including deletion, modification, and addition. Difference lines in a patch are usually consecutive. These consecutive difference lines are combined into one or more change blocks, each of which represents a complete logical modification unit.

[0055] Based on the annotated modified code blocks, program elements related to vulnerability remediation semantics are extracted from the first code and the second code to generate the vulnerability anchor set.

[0056] Optionally, based on the annotated modified code blocks, program elements related to vulnerability remediation semantics are extracted from the first code and the second code to generate the vulnerability anchor set, which may specifically include: Based on the annotated modified code blocks, function, class, and variable identifiers are extracted from the first and second code respectively: For deletion or modification type change code blocks, extract the corresponding functions, classes or variables from the first code as vulnerability anchors based on the annotated change code block; for example, if the annotated change code block is marked as deletion or modification type, extract the corresponding functions, classes or variables from the first code as vulnerability anchors. For newly added modified code blocks, their association with program elements in the first code is used to determine whether they are considered vulnerability anchors. For example, if a newly added code block is associated with a program element in the first code that is semantically related to vulnerability remediation, then the newly added code block is also included in the vulnerability anchor set; otherwise, it is not. When a newly added function, class, or variable does not appear in the first code, a call relationship is constructed based on the second code, and the call relationship is used to trace and determine whether the newly added program element is related to vulnerability remediation.

[0057] The embodiments of this disclosure use vulnerability patching as the analysis entry point, processing the first code before vulnerability patching, the second code after vulnerability patching, and their differences to eliminate interfering information in the vulnerability patching that is not directly related to vulnerability patching. Subsequently, by analyzing the code structure involved in the patch changes, program elements such as functions, classes, or variables are extracted from the first and second code. Based on their change relationships in the patch, their correlation with vulnerability patching is determined, thereby forming a set of vulnerability anchor points used to characterize the key program locations involved in vulnerability patching. By defining vulnerability anchor points as program elements highly related to the semantics of vulnerability patching, the key locations involved in vulnerability patching can be stably characterized, improving the interpretability and consistency of vulnerability location results.

[0058] In one or more embodiments of this disclosure, constructing a runtime dependency propagation graph based on runtime dependencies between program elements in the target code may specifically include: The target code is parsed based on the abstract syntax tree to obtain the import statement; Import statements are used to use functionality defined in another file or module within the current file.

[0059] Explicit dependency analysis is performed on the import statements to extract explicit runtime dependencies between program elements in the target code, and / or dynamic loading dependency analysis is performed on the import statements to extract dynamic loading dependencies between program elements in the target code; wherein, explicit runtime dependencies between program elements can be determined by scanning static import statements in the code. Dynamic loading dependencies refer to dependencies that are not directly visible in the code text but are resolved and loaded only at runtime.

[0060] Using the program elements as nodes in the directed graph and the explicit runtime dependencies and the dynamic loading dependencies as directed edges in the directed graph, a runtime dependency propagation graph is constructed.

[0061] Optionally, the program elements may specifically include: components, modules, and packages; the import statements include main import statements and subordinate import statements; explicit dependency analysis is performed on the import statements to extract explicit runtime dependencies between program elements in the target code, specifically including: Perform explicit dependency analysis on the import statements to obtain the main import statement and the subordinate import statements; Based on the main import statement, extract the external modules or packages that the component directly depends on to obtain the first explicit dependency relationship; Based on the modules that the component directly depends on, extracted from the import statement, a second explicit dependency relationship is obtained.

[0062] The first explicit runtime dependency and the second explicit runtime dependency are used as explicit runtime dependencies between program elements in the target code.

[0063] Optionally, the program elements may specifically include: components, modules, and packages; the import statements may include dynamic loading structures; dynamic loading dependency analysis is performed on the import statements to extract the dynamic loading dependencies between program elements in the target code, specifically including: The dynamic loading structure is analyzed to obtain the dynamic loading parameters; Optionally, dynamic loading structures, such as function calls or statements that execute dynamic loading, can be identified within the code's abstract syntax tree. Then, the parameters used to specify the target module or component—the dynamic loading parameters—are extracted from these dynamic loading structures.

[0064] In response to the dynamic loading parameter being a string, the module or component represented by the string is extracted to obtain the dynamic loading dependency relationship; In response to the dynamic loading parameter being a variable, the module or component corresponding to the variable is parsed based on the assignment process of the variable, thus obtaining the dynamic loading dependency relationship.

[0065] Optionally, the module or component corresponding to the variable can be parsed based on the variable's assignment process to obtain the dynamic loading dependency relationship. Specifically, this involves tracing back the variable's assignment process, including parsing the variable's assignment chain by tracking the complete path from definition to use. If the variable's assignment process contains multiple possible values, candidate modules or components can be filtered based on contextual information to determine dependencies consistent with runtime loading behavior. For example, the most recent assignment can be used as the variable's value.

[0066] Optional import statements include dynamically loaded structures, such as Python importlib (importlib is a standard library in Python 3.4+ used to implement dynamic imports), Java reflection Class.forName (Class.forName() is one of the methods to obtain a Class object), etc. The embodiments of this disclosure, through the above-described dynamic loading dependency analysis, can supplement runtime dependencies that are difficult to cover by explicit dependency analysis, thereby improving the completeness of the runtime dependency propagation graph.

[0067] Figure 4 A flowchart illustrating an exemplary method for determining the propagation path of a code vulnerability, as provided in an embodiment of this disclosure, is shown. Figure 4 As shown, the method may include the following processing: In step 402, input the target project's code file and installation configuration file.

[0068] In step 404, the top-level entry information of the code file is parsed to obtain the package identifier information.

[0069] In step 406, the installation configuration file is parsed to obtain the deployment package path.

[0070] In step 408, the code files are parsed based on the project layout information to obtain a set of deployment packages.

[0071] In step 410, irrelevant code such as non-target language files, comment lines, and difference information in the test directory is removed.

[0072] In step 412, the target code is parsed based on the abstract syntax tree to obtain the import statement.

[0073] In step 414, explicit dependency analysis is performed on the import statements to extract explicit runtime dependencies between program elements in the code file.

[0074] In step 416, dynamic loading dependency analysis is performed on the import statements to extract the dynamic loading dependencies between program elements in the code file.

[0075] In step 418, the explicit runtime dependencies extracted in step 414 and the dynamic loading dependencies extracted in step 416 are merged to construct a runtime dependency propagation graph.

[0076] In step 420, the set of vulnerability anchors is mapped to the runtime dependency propagation graph.

[0077] In step 421, a path search is performed in the runtime dependency propagation graph to determine the components affected by the vulnerability and the propagation path of the vulnerability.

[0078] In step 422, the first code before the vulnerability patch is executed, the second code after the vulnerability patch is executed, and the patch difference information are obtained. In step 424, irrelevant information such as non-target language files, commentary difference lines, and difference information in the test directory are removed from the patch difference information to obtain the remaining patch difference information; In step 426, adjacent difference lines in the remaining patch difference information are aggregated into change code blocks, and the change code blocks are labeled as deletion type, modification type, or addition type change type; In step 428, program elements related to vulnerability fixation semantics are extracted from the first code and the second code based on the annotated modified code block to generate a vulnerability anchor set.

[0079] Steps 422 to 428 can be executed in parallel with steps 402 to 418.

[0080] One or more embodiments of this disclosure also provide a computer device, including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, and the one or more programs include instructions for a code vulnerability propagation path determination method according to one or more embodiments of this disclosure.

[0081] One or more embodiments of this disclosure also provide a non-volatile computer-readable storage medium containing a computer program that, when executed by one or more processors, causes the one or more processors to perform a code vulnerability propagation path determination method according to one or more embodiments of this disclosure.

[0082] This disclosure also provides a computer program product, including one or more computer programs, which, when executed by one or more processors, implement the code vulnerability propagation path determination method of one or more embodiments of this disclosure.

[0083] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0084] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0085] For ease of description, the above computer devices are described in terms of function, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0086] The computer device described in the above embodiments is used to implement the corresponding code vulnerability propagation path determination method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0087] This disclosure also provides a computer device for implementing the above-described method for determining the propagation path of code vulnerabilities. Figure 5 A schematic diagram of the hardware structure of an exemplary computer device 500 provided in an embodiment of this disclosure is shown. The computer device 500 can be used to implement... Figure 1 Server 106 can also be used to implement Figure 1 Terminal devices 102 and 104. In some scenarios, this computer device 500 can also be used to implement... Figure 1 Database server 108.

[0088] like Figure 5 As shown, the computer device 500 may include: a processor 502, a memory 504, a network interface 506, a peripheral interface 508, and a bus 510. The processor 502, memory 504, network interface 506, and peripheral interface 508 are interconnected within the computer device 500 via the bus 510.

[0089] Processor 502 may be a central processing unit (CPU), image processor, neural network processor (NPU), microcontroller (MCU), programmable logic device, digital signal processor (DSP), application-specific integrated circuit (ASIC), or one or more integrated circuits. Processor 502 can be used to perform functions related to the techniques described in this disclosure. In some embodiments, processor 502 may also include multiple processors integrated as a single logic component. For example, such as... Figure 5 As shown, processor 502 may include multiple processors 502a, 502b and 502c.

[0090] Memory 504 can be configured to store data (e.g., instructions, computer code, etc.). Figure 5 As shown, the data stored in memory 504 may include program instructions (e.g., one or more programs for implementing the code vulnerability propagation path determination method of embodiments of this disclosure) and data to be processed (e.g., the memory may store configuration files of other modules, etc.). Processor 502 may also access the program instructions and data stored in memory 504 and execute the program instructions to operate on the data to be processed. Memory 504 may include volatile storage devices or non-volatile storage devices. In some embodiments, memory 504 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0091] Network interface 506 can be configured to provide communication with other external devices to computer device 500 via a network. This network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above.

[0092] The peripheral interface 508 can be configured to connect the computer device 500 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

[0093] Bus 510 can be configured to transfer information between various components of computer device 500 (such as processor 502, memory 504, network interface 506, and peripheral interface 508), such as internal buses (e.g., processor-memory bus), external buses (USB port, PCI-E bus), etc.

[0094] It should be noted that although the architecture of the computer device 500 described above only shows the processor 502, memory 504, network interface 506, peripheral interface 508, and bus 510, in specific implementations, the architecture of the computer device 500 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of the computer device 500 described above may only include the components necessary for implementing the embodiments of this disclosure, and does not necessarily include all the components shown in the figures.

[0095] Based on the same inventive concept, corresponding to any of the above embodiments, this disclosure also provides a non-volatile computer-readable storage medium containing a computer program, which, when executed by one or more processors, causes the one or more processors to execute the code vulnerability propagation path determination method.

[0096] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0097] The computer program stored in the storage medium of the above embodiments is used to cause the one or more processors to execute the code vulnerability propagation path determination method as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0098] Based on the same inventive concept, corresponding to the code vulnerability propagation path determination method in any of the above embodiments, this disclosure also provides a computer program product, which includes one or more computer programs. In some embodiments, the one or more computer programs are executable by one or more processors to cause the one or more processors to execute the code vulnerability propagation path determination method. Corresponding to the execution entity for each step in each embodiment of the code vulnerability propagation path determination method, the processor executing the corresponding step may belong to the corresponding execution entity.

[0099] The computer program product of the above embodiments is used to cause the processor to execute the code vulnerability propagation path determination method as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0100] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0101] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0102] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0103] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for determining the propagation path of a code vulnerability, characterized in that, include: Obtain the code files and installation configuration files of the target project; The target code that will actually be executed after deployment is determined based on the code file and the installation configuration file; Based on the vulnerability patch in the code file, extract program elements related to vulnerability patch semantics to generate a set of vulnerability anchors; Construct a runtime dependency propagation graph based on the runtime dependencies between program elements in the target code; The vulnerability anchor set is mapped to the runtime dependency propagation graph to obtain the vulnerability propagation path.

2. The method according to claim 1, characterized in that, Based on the code file and the installation configuration file, the target code that will actually be executed after deployment is determined, including: Extract the top-level entry point information from the code file to obtain the package identifier information; The installation configuration file is parsed to obtain the deployment package path; Based on the project layout information of the code file, the code file is parsed to obtain a set of deployment packages; The target code is obtained based on at least one of the package identifier information, the deployment package path, and the deployment package set.

3. The method according to claim 2, characterized in that, The deployment package path is determined based on the installation configuration file, including: The installation configuration file is parsed, and the deployment package path is extracted in response to the explicit indication of the deployment package path by the package path parameter in the installation configuration file. In response to the absence of an explicit indication of the deployment package path in the installation configuration file, the directory name of the deployment package to be searched is matched with the directory name in the code file to obtain the deployment package path.

4. The method according to claim 1, characterized in that, Based on the vulnerability patch in the code file, program elements related to vulnerability patching semantics are extracted to generate a set of vulnerability anchors, including: Obtain the first code before vulnerability patching is executed, the second code after vulnerability patching is executed, and patch difference information; Remove non-target language files, comment lines, and differences in the test directory from the patch difference information to obtain the remaining patch difference information; The adjacent difference lines in the remaining patch difference information are aggregated into change code blocks, and the change code blocks are labeled with change types, including deletion, modification and addition. Based on the annotated modified code blocks, program elements related to vulnerability remediation semantics are extracted from the first code and the second code to generate the vulnerability anchor set.

5. The method according to claim 1, characterized in that, Construct a runtime dependency propagation graph based on the runtime dependencies between program elements in the target code, including: The target code is parsed based on the abstract syntax tree to obtain the import statement; Perform explicit dependency analysis on the import statement to extract explicit runtime dependencies between program elements in the target code, and / or perform dynamic loading dependency analysis on the import statement to extract dynamic loading dependencies between program elements in the target code; Using the program elements as nodes in the directed graph and the explicit runtime dependencies and the dynamic loading dependencies as directed edges in the directed graph, a runtime dependency propagation graph is constructed.

6. The method according to claim 5, characterized in that, The program elements include components, modules, and packages. The import statements include main import statements and subordinate import statements. Explicit dependency analysis is performed on the import statements to extract explicit runtime dependencies between program elements in the target code, including: Perform explicit dependency analysis on the import statements to obtain the main import statement and the subordinate import statements; Based on the main import statement, extract the external modules or packages that the component directly depends on to obtain the first explicit runtime dependency relationship; Based on the modules that the components directly depend on, extracted from the import statement, a second explicit runtime dependency relationship is obtained; The first explicit runtime dependency and the second explicit runtime dependency are used as explicit runtime dependencies between program elements in the target code.

7. The method according to claim 5, characterized in that, The program elements include components, modules, and packages. The import statements include dynamic loading structures. Dynamic loading dependency analysis is performed on the import statements to extract the dynamic loading dependencies between program elements in the target code, including: The dynamic loading structure is analyzed to obtain the dynamic loading parameters; In response to the dynamic loading parameter being a string, the module or component represented by the string is extracted to obtain the dynamic loading dependency relationship; In response to the dynamic loading parameter being a variable, the module or component corresponding to the variable is parsed based on the assignment process of the variable, thus obtaining the dynamic loading dependency relationship.

8. A computer device comprising one or more processors, a memory; and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, the one or more programs comprising instructions for performing the method of any one of claims 1 to 7.

9. A non-volatile computer-readable storage medium comprising a computer program, which, when executed by one or more processors, causes the one or more processors to perform the method of any one of claims 1 to 7.

10. A computer program product comprising one or more computer programs that, when executed by one or more processors, implement the method as described in any one of claims 1 to 7.

Images