Vulnerability protection method, device and equipment for open source component

Abstract

The invention discloses a vulnerability protection method, device and equipment for an open source component. The method comprises the following steps: receiving a compiling result sent by terminal equipment; the compiling result is obtained by compiling the target project file by the terminal equipment; acquiring information of the target open source component from the compiling result; the target open source component is an open source component called by the target project file; determining at least one potential vulnerability of the target project file based on the information of the target open source component; for each potential vulnerability, verifying whether the potential vulnerability is repaired or not based on a code related to the potential vulnerability in the target project file, and confirming the potential vulnerability which is not repaired as a reachable vulnerability; and repairing the codes related to the reachable vulnerabilities in the target project file. According to the method, the actually reachable open source component vulnerabilities in the project code can be automatically and accurately identified and protected, so that the overall security of the project is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of open source component security technology, and in particular, to a method, device and equipment for protecting open source components from vulnerabilities. Background Art

[0002] In modern software development, developers often reference or integrate third-party open source components in project code to improve project development efficiency. However, some open source components themselves have security vulnerabilities. When the project code calls an open source component with a vulnerability, if there is a path that can directly or indirectly execute the function with the vulnerability (that is, the vulnerability is reachable), an attacker may exploit this vulnerability to affect the security of the entire system.

[0003] Existing open source component security detection tools usually use software composition analysis (SCA) tools after the project is developed. Based on static analysis methods, they directly extract information from the source code or finished products of the project to identify the components used in the project and their versions, and check whether these components have known security vulnerabilities. However, static analysis usually marks all known vulnerabilities of the open source components referenced by the project as potential risks. It cannot distinguish whether a function containing a vulnerability in the open source component is not executed in the actual operation of the project file, or whether the vulnerability has been fixed by the developer in the project file, which leads to unnecessary alerts and makes developers spend a lot of unnecessary time and energy on repair work. Summary of the invention

[0004] The embodiments of the present application provide a method, apparatus and device for protecting open source components from vulnerabilities, which are used to automatically identify and protect open source component vulnerabilities that are actually accessible in project code, thereby improving the overall security of the project.

[0005] In a first aspect, an embodiment of the present application provides a security protection method for an open source component, including:

[0006] Receiving a compilation result sent by a terminal device; the compilation result is obtained by the terminal device compiling a target project file;

[0007] Acquire information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file;

[0008] Determining at least one potential vulnerability of the target project file based on the information of the target open source component;

[0009] For each of the potential vulnerabilities, based on the code related to the potential vulnerability in the target project file, verify whether the potential vulnerability has been repaired, and confirm the unrepaired potential vulnerability as a reachable vulnerability;

[0010] Repair the code involving the reachable vulnerability in the target project file.

[0011] In an embodiment of the present application, by receiving the compilation result and obtaining the information of the target open source component therefrom, the open source component called in the target project file can be determined; then, the potential vulnerabilities of the target project file are determined based on the information of the target open source component, and which potential vulnerabilities have not been repaired are verified to confirm the vulnerabilities that are truly reachable in the target project file, so that the code involved in the reachable vulnerabilities can be repaired in a targeted manner. The present application can more accurately implement the reachability analysis of components and their vulnerabilities, avoid false positives for vulnerabilities that have not been called and vulnerabilities that have been repaired by developers, and improve development efficiency and project security by automatically protecting reachable vulnerabilities.

[0012] In a possible implementation manner, the information of the target open source component includes the name and version number of the target open source component, and context feature information when the target open source component is called;

[0013] The determining, based on the information of the target open source component, at least one potential vulnerability of the target project file comprises:

[0014] Based on the name and version number of the target open source component, vulnerability code feature information of the target open source component is obtained from a component protection information library; the component protection information library stores vulnerability code feature information of multiple open source components;

[0015] The vulnerability code feature information of the target open source component is matched with the context feature information, and at least one potential vulnerability of the target project file is determined based on the matching result.

[0016] In an embodiment of the present application, by matching the context feature information when the target open source component is called in the component protection information library, it is possible to determine which functions involving component vulnerabilities are called by the target project file, thereby determining the potential vulnerabilities of the target project file.

[0017] In a possible implementation, the target project file includes the source code and user configuration code of the target open source component;

[0018] The verifying whether the potential vulnerability has been fixed based on the code related to the potential vulnerability in the target project file includes:

[0019] Acquire a first code in the user configuration code that triggers the potential vulnerability, and a second code in the source code of the target open source component that triggers the potential vulnerability;

[0020] Based on the first code and the second code, verify whether the potential vulnerability has been repaired.

[0021] In an embodiment of the present application, by analyzing the parts of the user configuration code and the source code of the open source component that are related to the potential vulnerability, it is possible to determine whether the developer has fixed the potential vulnerability and whether the developer's repair measures for the potential vulnerability are effective, and then verify whether the potential vulnerability has been fixed in the target project file, thereby avoiding false positives of potential vulnerabilities that have been fixed by the developer.

[0022] In a possible implementation manner, before repairing the code related to the reachable vulnerability in the target project file, the method further includes:

[0023] Determine whether to repair the code involving the accessible vulnerability in the target project file based on default configuration or user instruction.

[0024] In an embodiment of the present application, a confirmation step (default configuration or user instruction) is added before performing a repair for a reachable vulnerability, making the repair process more flexible and controllable, and avoiding unnecessary automatic repair operations when developers need to repair reachable vulnerabilities themselves.

[0025] In a possible implementation, the method further includes:

[0026] Determine whether to push a repair suggestion for the reachable vulnerability based on a default configuration or a user instruction.

[0027] In an embodiment of the present application, determining whether it is necessary to push repair suggestions for reachable vulnerabilities is based on default configuration or user instructions, which can help users better understand and deal with vulnerability issues when developers need to repair reachable vulnerabilities themselves.

[0028] In a possible implementation, the method further includes:

[0029] Monitoring the code in the target project file that calls the target open source component to obtain component usage of the target open source component;

[0030] When it is determined that a new vulnerability appears in the target open source component, a risk level assessment and risk warning are performed on the new vulnerability based on the usage of the component and preset risk assessment rules.

[0031] In an embodiment of the present application, by monitoring the usage of the target open source components during project operation and assessing the risk level when new vulnerabilities are found in the target open source components, and issuing warnings of corresponding levels, it is possible to promptly warn developers when new vulnerabilities pose a high level of security threat to target project files to reduce the losses caused by new vulnerabilities to the project, and to remind them to update the component protection information library and vulnerability repair measures, so that the security measures of the target project files keep up with the latest threats.

[0032] In a second aspect, an embodiment of the present application provides a vulnerability protection method for an open source component, including:

[0033] Compile the target project file based on a preset compilation rule, and send the compilation result to a server, so that the server determines information of a target open source component, and determines at least one potential vulnerability of the target project file based on an information base of the target open source component, wherein the target open source component is an open source component called by the target project file;

[0034] Receiving a code acquisition instruction sent by the server, wherein the code acquisition instruction includes an identity identifier of the potential vulnerability;

[0035] Based on the identity identifier of the potential vulnerability, the code involving the potential vulnerability in the target project file is determined, and the code involving the potential vulnerability is sent to the server, so that the server determines the reachable vulnerability based on the code involving the potential vulnerability and repairs the code involving the reachable vulnerability in the target project file, wherein the reachable vulnerability is an unrepaired potential vulnerability.

[0036] In an embodiment of the present application, by compiling the target project file on the terminal device side and performing extraction of the code involving potential vulnerabilities, not only the accuracy of vulnerability detection and protection on the server side is improved, but also the user's concerns about code leakage are reduced, while the cost of user code management on the server side is reduced.

[0037] In a possible implementation, the target project file includes source code and user configuration code of the target open source component; and determining the code involving the potential vulnerability in the target project file and sending the code involving the potential vulnerability to the server includes:

[0038] Determine a first code in the user configuration code that triggers the potential vulnerability, and determine a second code in the source code of the target open source component that triggers the potential vulnerability, and send the first code and the second code to the server.

[0039] In a third aspect, an embodiment of the present application provides a security protection device for an open source component, including:

[0040] A compilation data receiving module, used for receiving a compilation result sent by a terminal device; the compilation result is obtained by the terminal device compiling a target project file;

[0041] A component information determination module, used to obtain information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file;

[0042] A first vulnerability determination module, configured to determine at least one potential vulnerability of the target project file based on information of the target open source component;

[0043] A second vulnerability determination module is used to verify, for each of the potential vulnerabilities, whether the potential vulnerability has been repaired based on the code related to the potential vulnerability in the target project file, and to identify the unrepaired potential vulnerability as a reachable vulnerability;

[0044] The vulnerability repair module is used to compile the data receiving module, and is used to repair the code related to the reachable vulnerability in the target project file.

[0045] In a possible implementation, the information of the target open source component includes the name and version number of the target open source component, and context feature information when the target open source component is called; and the first vulnerability determination module is used to:

[0046] Based on the name and version number of the target open source component, vulnerability code feature information of the target open source component is obtained from a component protection information library; the component protection information library stores vulnerability code feature information of multiple open source components;

[0047] The vulnerability code feature information of the target open source component is matched with the context feature information, and at least one potential vulnerability of the target project file is determined based on the matching result.

[0048] In a possible implementation, the target project file includes the source code and user configuration code of the target open source component; and the second vulnerability determination module is used to:

[0049] Acquire a first code in the user configuration code that triggers the potential vulnerability, and a second code in the source code of the target open source component that triggers the potential vulnerability;

[0050] Based on the first code and the second code, verify whether the potential vulnerability has been repaired.

[0051] In a possible implementation, the device further includes a repair operation configuration module, wherein the repair operation configuration module is configured to:

[0052] Before repairing the code involved in the reachable vulnerability in the target project file, it is determined whether to repair the code involved in the reachable vulnerability in the target project file based on a default configuration or a user instruction.

[0053] In a possible implementation, the device further includes a push module, and the push module is used to:

[0054] Determine whether to push a repair suggestion for the reachable vulnerability based on a default configuration or a user instruction.

[0055] In a possible implementation, the device further includes a component monitoring module, and the component monitoring module is used to:

[0056] Monitoring the code in the target project file that calls the target open source component to obtain component usage of the target open source component;

[0057] When it is determined that a new vulnerability appears in the target open source component, a risk level assessment and risk warning are performed on the new vulnerability based on the usage of the component and preset risk assessment rules.

[0058] In a fourth aspect, an embodiment of the present application provides a security protection device for an open source component, including:

[0059] A compilation data sending module, used to compile the target project file based on a preset compilation rule, and send the compilation result to a server, so that the server determines the information of the target open source component, and determines at least one potential vulnerability of the target project file based on the information base of the target open source component, wherein the target open source component is an open source component called by the target project file;

[0060] An instruction receiving module, used for receiving a code acquisition instruction sent by the server, wherein the code acquisition instruction includes an identity identifier of the potential vulnerability;

[0061] A vulnerability code sending module is used to determine the code involving the potential vulnerability in the target project file based on the identity identifier of the potential vulnerability, and send the code involving the potential vulnerability to the server, so that the server determines the reachable vulnerability based on the code involving the potential vulnerability and repairs the code involving the reachable vulnerability in the target project file, wherein the reachable vulnerability is a potential vulnerability that has not been repaired.

[0062] In a possible implementation, the target project file includes the source code and user configuration code of the target open source component; the vulnerability code sending module is used to:

[0063] Determine a first code in the user configuration code that triggers the potential vulnerability, and determine a second code in the source code of the target open source component that triggers the potential vulnerability, and send the first code and the second code to the server.

[0064] In a fifth aspect, an embodiment of the present application provides an electronic device, including:

[0065] A memory for storing program instructions;

[0066] A processor is used to call the program instructions stored in the memory, and execute the steps included in the method of the first aspect and any one of its designs according to the obtained program instructions, or execute the steps included in the method of the second aspect and any one of its designs.

[0067] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a computer, the computer executes the method of the first aspect and any one of its designs, or executes the method of the second aspect and any one of its designs.

[0068] The technical effects brought about by the third to sixth aspects and any one of their implementations can refer to the technical effects brought about by the corresponding implementations in the first and second aspects, and will not be repeated here.

[0069] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0071] Figure 1 A schematic diagram of an application scenario provided for an embodiment of the present application;

[0072] Figure 2 A flowchart of a vulnerability protection method for an open source component applied to a server provided in an embodiment of the present application;

[0073] Figure 3 A flowchart of a vulnerability protection method for an open source component of a terminal device provided in an embodiment of the present application;

[0074] Figure 4 An overall flow chart of vulnerability protection for an open source component provided in an embodiment of the present application;

[0075] Figure 5 A schematic diagram of the structure of a vulnerability protection device for an open source component provided in an embodiment of the present application;

[0076] Figure 6 A schematic diagram of the structure of a vulnerability protection device for an open source component provided in an embodiment of the present application;

[0077] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be arbitrarily combined with each other. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0079] The terms "first" and "second" in the specification and claims of the present application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of their variations are intended to cover non-exclusive protection. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. "Multiple" in the present application can mean at least two, for example, two, three or more, and the embodiments of the present application are not limited.

[0080] In the technical solution of this application, the collection, dissemination, and use of data are in compliance with the requirements of relevant national laws and regulations.

[0081] Before introducing a vulnerability protection method for an open source component provided in an embodiment of the present application, in order to facilitate understanding, the technical background of the embodiment of the present application is first introduced in detail below.

[0082] In modern software development, developers often reference or integrate third-party open source components in project code to improve project development efficiency. However, some open source components themselves have security vulnerabilities. When the project code calls an open source component with a vulnerability, if there is a path that can directly or indirectly execute the function with the vulnerability (that is, the vulnerability is reachable), an attacker may exploit this vulnerability to affect the security of the entire system.

[0083] Existing open source component security detection tools usually use software composition analysis (SCA) tools after the project is developed. Based on static analysis methods, they directly extract information from the source code or finished products of the project to identify the components used in the project and their versions, and check whether these components have known security vulnerabilities. However, static analysis usually marks all known vulnerabilities of the open source components referenced by the project as potential risks. It cannot distinguish whether a function containing a vulnerability in the open source component is not executed in the actual operation of the project file, or whether the vulnerability has been fixed by the developer in the project file, resulting in unnecessary alarms, causing developers to spend a lot of unnecessary time and energy on repair work, and the repair may also affect the existing business code or project modules.

[0084] In order to solve the above problems, the present invention proposes a vulnerability protection method, device and equipment for open source components, which are used to automatically and accurately identify and protect the open source component vulnerabilities that are actually reachable in the project code, thereby improving the overall security of the project code. The method can determine the open source components called in the target project file by receiving the compilation result and obtaining the information of the target open source component therefrom; then determine the potential vulnerabilities of the target project file based on the information of the target open source component, and verify which potential vulnerabilities have not been repaired to confirm the vulnerabilities that are truly reachable in the target project file, so that the code involved in the reachable vulnerabilities can be repaired in a targeted manner. The present application can more accurately implement the reachability analysis of components and their vulnerabilities, avoid false positives for vulnerabilities that have not been called and vulnerabilities that have been repaired by developers, and by automatically protecting reachable vulnerabilities, it can avoid the development costs generated by manually repairing vulnerabilities, and improve development efficiency and project security.

[0085] After introducing the design ideas of the embodiments of the present application, the following briefly introduces the application scenarios to which the technical solutions of the embodiments of the present application can be applied. It should be noted that the application scenarios introduced below are only used to illustrate the embodiments of the present application and are not limited. In specific implementation, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0086] refer to Figure 1, which is a schematic diagram of an application scenario of an embodiment of the present disclosure, including a server 11, a terminal device 12, and a collection plug-in 13 installed in the terminal device 12. The collection plug-in 13 is used to compile the target project file based on a preset compilation rule, and send the compilation result to the server 11; the server 11 is used to determine the information of the target open source component based on the compilation result sent by the collection plug-in 13, and determine the potential vulnerability of the target project file based on the information of the target open source component, wherein the target open source component is an open source component called by the target project file; the collection plug-in 13 is also used to determine the code involving the potential vulnerability in the target project file, and send the code involving the potential vulnerability to the server 11; the server 11 is also used to verify the code involving the potential vulnerability, so as to confirm the unrepaired potential vulnerability in the target project file as a reachable vulnerability, and repair the code involving the reachable vulnerability in the target project file.

[0087] In an embodiment of the present application, by receiving the compilation result and obtaining the information of the target open source component therefrom, the open source component called in the target project file can be determined; then, the potential vulnerabilities of the target project file are determined based on the information of the target open source component, and which potential vulnerabilities have not been repaired are verified to confirm the vulnerabilities that are truly reachable in the target project file, so that the code involved in the reachable vulnerabilities can be repaired in a targeted manner. The present application can more accurately implement the reachability analysis of components and their vulnerabilities, avoid false positives for vulnerabilities that have not been called and vulnerabilities that have been repaired by developers, and by automatically protecting against reachable vulnerabilities, it can avoid the development costs generated by manually repairing vulnerabilities, thereby improving development efficiency and project security.

[0088] Of course, the method provided in the embodiment of the present application is not limited to Figure 1 The application scenarios shown can also be used in other possible application scenarios, and the embodiments of the present application are not limited thereto. Figure 1 The functions that can be implemented by each device in the application scenario shown will be described in the subsequent method embodiments, and will not be described in detail here.

[0089] To further illustrate the technical solution provided by the embodiment of the present application, this is described in detail below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiment of the present application provides the method operation steps shown in the following embodiments or drawings, more or fewer operation steps may be included in the method based on routine or no creative labor. In the steps where there is no necessary causal relationship logically, the execution order of these steps is not limited to the execution order provided by the embodiment of the present application.

[0090] Reference below Figure 2 A flowchart of a vulnerability protection method for an open source component applied to a server is shown to illustrate the technical solution provided in an embodiment of the present application.

[0091] Step 201, receiving a compilation result sent by a terminal device; the compilation result is obtained by the terminal device compiling a target project file.

[0092] Step 202, obtaining information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file.

[0093] In the embodiment of the present application, the target project file is configured by the developer in the development environment of the terminal device, and the target project file can call the open source components configured in the development environment of the terminal device. Therefore, in order to avoid marking all known vulnerabilities of the open source components called by the target project file as potential risks, the present application compiles the target project file on the terminal device to obtain the information of the open source components called by the target project file during the actual operation, that is, the information of the target open source components.

[0094] Exemplarily, the information of the target open source component may include: the name and version of the target open source component and the context feature information when the target open source component is called in the compilation result (such as the name of the open source component function called during the compilation process, and the control flow and data flow of the context, etc.), and may also include the function call graph when the target project file calls the target open source component.

[0095] Step 203: determining at least one potential vulnerability of the target project file based on the information of the target open source component.

[0096] Optionally, based on the information of the target open source component, at least one potential vulnerability of the target project file is determined, including the following steps 301-302.

[0097] Step 301, based on the name and version number of the target open source component, obtain vulnerability code feature information of the target open source component from the component protection information library.

[0098] Among them, the component protection information library stores vulnerability code feature information of multiple open source components.

[0099] As a feasible implementation method, this application constructs a component protection information library in the following manner:

[0100] The information of multiple open source components is obtained through web crawlers. The information of each open source component includes at least: the name, version, vulnerability, vulnerability code feature information (such as the name of the open source component function called when the vulnerability is triggered during the compilation process and the control flow and data flow of the context), source code, language, and whether there are dependent components, etc. Then, a component protection information library is created based on the information obtained by the web crawler.

[0101] Step 302: Match the vulnerability code feature information of the target open source component with the context feature information when the target open source component is called, and determine at least one potential vulnerability of the target project file based on the matching result.

[0102] In an embodiment of the present application, by matching the context feature information when the target open source component is called in the component protection information library, it is possible to determine which functions involving component vulnerabilities are called by the target project file, thereby determining the potential vulnerabilities of the target project file.

[0103] In some embodiments, when creating a component protection information library, the present application obtains information about each open source component after obtaining the information of the open source component, and also obtains information such as the function call graph and control flow graph of the internal functions of the open source component based on static analysis technology, and marks the functions / codes involved in the vulnerability risks in the graph, and stores the function call graph in the component protection information library.

[0104] As a feasible implementation method, after determining the vulnerability code feature information of the target open source component based on a pre-created component protection information library, the function call graph when the target project file calls the target open source component and the function call graph of the target open source component in the component protection information library are matched, so as to determine whether the function involved in triggering the vulnerability in the open source component is called when the target project file calls the open source component, and these vulnerabilities are confirmed as potential vulnerabilities of the target project file.

[0105] Step 204 , for each potential vulnerability, based on the code related to the potential vulnerability in the target project file, verify whether the potential vulnerability has been repaired, and confirm the unrepaired potential vulnerability as a reachable vulnerability.

[0106] In the embodiment of the present application, the target project file includes the source code of the target open source component and the user configuration code. The user configuration code refers to the self-developed code configured by the developer on the terminal device. The target open source component will be called in the user-configured self-developed code to achieve development requirements. However, the target open source component used by the developer may have been repaired for potential vulnerabilities, which may include the following two situations.

[0107] Case 1: The target open source component used by the developer is obtained from the company's intranet and the potential vulnerability in the source code of the target open source component in the company's intranet has been fixed. At the same time, the component protection information library created in this application crawls the target open source component of this version with the potential vulnerability fixed in the company's intranet, resulting in the source code of the target open source component used by the developer being different from the source code of the same version of the open source component crawled from the Internet in the component protection information library.

[0108] Case 2: When the developer develops the user configuration code on the terminal device, he or she has configured the code for fixing the vulnerability in the user configuration code, and the vulnerability successfully fixed by the user includes the potential vulnerability detected by this application.

[0109] Therefore, in order to avoid false positives and unnecessary repair operations for potential vulnerabilities that have been repaired, the present application uses the code involving the potential vulnerability in the target project file obtained from the terminal device to verify whether the potential vulnerability has been repaired. Among them, the code involving the potential vulnerability in the target project file can be obtained by sending a code acquisition instruction to the acquisition plug-in on the terminal device, and the code acquisition instruction includes the identity of the potential vulnerability.

[0110] As a feasible implementation method, based on the code involving the potential vulnerability in the target project file, verify whether the potential vulnerability has been fixed, including:

[0111] Obtaining a first code that triggers a potential vulnerability in a user configuration code and a second code that triggers a potential vulnerability in a source code of a target open source component;

[0112] Based on the first code and the second code, verify whether the potential vulnerability has been fixed.

[0113] In an embodiment of the present application, by analyzing the parts of the user configuration code and the source code of the open source component that are related to the potential vulnerability, it is possible to determine whether the developer has fixed the potential vulnerability and whether the developer's repair measures for the potential vulnerability are effective, and then verify whether the potential vulnerability has been fixed in the target project file, thereby avoiding false positives of potential vulnerabilities that have been fixed by the developer.

[0114] Step 205: Repair the code involving the reachability vulnerability in the target project file.

[0115] In some embodiments, when creating a component protection information library, the present application will also add the vulnerability repair code of each vulnerability to the component protection information library for each open source component with a vulnerability, thereby establishing a security protection "armor" library, so that after determining the reachable vulnerability, the vulnerability repair code corresponding to each reachable vulnerability can be added to the corresponding position in the target project file based on the component protection information library to repair the code related to the reachable vulnerability in the target project file.

[0116] Optionally, the present application may add the vulnerability repair code corresponding to each reachable vulnerability to the code that triggers the reachable vulnerability in the target project file through an instrumentation operation.

[0117] In some embodiments, before repairing the code involving the reachability vulnerability in the target project file, the method further includes:

[0118] Determine whether to repair the code involving the reachable vulnerability in the target project file based on default configuration or user instruction.

[0119] In an embodiment of the present application, a confirmation step (default configuration or user instruction) is added before performing a repair for a reachable vulnerability, making the repair process more flexible and controllable, and avoiding unnecessary automatic repair operations when developers need to repair reachable vulnerabilities themselves.

[0120] In some embodiments, the method further comprises:

[0121] Determine whether to push a repair suggestion for the reachable vulnerability based on a default configuration or a user instruction.

[0122] In an embodiment of the present application, determining whether it is necessary to push repair suggestions for reachable vulnerabilities is based on default configuration or user instructions, which can help users better understand and deal with vulnerability issues when developers need to repair reachable vulnerabilities themselves.

[0123] In some embodiments, considering that existing SCA tools usually ignore the monitoring and early warning of the usage of target open source components during the later stage of the project, and lack timely security warnings and preventive measures for newly generated vulnerabilities, when creating a component protection information library, the present application will add the corresponding component monitoring code to the component protection information library for each open source component. The component monitoring code can be used to monitor the usage of the target open source components during the project operation, and the specific monitoring content can be set according to the actual scenario and needs.

[0124] In some embodiments, the method further comprises:

[0125] Monitor the code in the target project file that calls the target open source component to obtain component usage of the target open source component;

[0126] When a new vulnerability is determined to exist in a target open source component, a risk level assessment and risk warning will be conducted on the new vulnerability based on the component usage and preset risk assessment rules.

[0127] The above risk assessment rules can be set according to actual scenarios and needs. For example, if it is determined that a new vulnerability belongs to a target open source component that is frequently called in the target project file, the new vulnerability is identified as a high-risk vulnerability, and a high-level risk warning is issued to remind relevant personnel to update the component protection information library and vulnerability repair measures (vulnerability repair code) in a timely manner, and to issue emergency warnings to the project developers, so as to minimize losses caused by new vulnerabilities.

[0128] In an embodiment of the present application, by monitoring the usage of the target open source components during project operation and assessing the risk level when new vulnerabilities are found in the target open source components, and issuing warnings of corresponding levels, it is possible to promptly warn developers when new vulnerabilities pose a high level of security threat to target project files to reduce the losses caused by new vulnerabilities to the project, and to remind them to update the component protection information library and vulnerability repair measures, so that the security measures of the target project files keep up with the latest threats.

[0129] It should be noted that the compilation and data collection (collecting compilation results and codes involving potential vulnerabilities) of this application can be executed on the terminal device, or the target project file can be uploaded to the server for execution, wherein the former can reduce the risk of user code leakage.

[0130] Reference below Figure 3 A flowchart of a vulnerability protection method for an open source component of a terminal device is shown, and the technical solution provided by the embodiment of the present application is described. Figure 3 As shown, the method includes steps 401-403.

[0131] Step 401, compile the target project file based on preset compilation rules, and send the compilation result to the server.

[0132] Through the above step 401, the server determines the information of the target open source component, and determines at least one potential vulnerability of the target project file based on the information base of the target open source component, wherein the target open source component is an open source component called by the target project file.

[0133] Among them, the above-mentioned preset compilation rules can be set according to actual scenarios and requirements, such as compiling the target project file upon receiving user instructions, or compiling the target project file according to a set cycle, which is not limited in this application.

[0134] Step 402: Receive a code acquisition instruction sent by a server, where the code acquisition instruction includes an identity identifier of a potential vulnerability.

[0135] Step 403, based on the identity of the potential vulnerability, determine the code involving the potential vulnerability in the target project file, and send the code involving the potential vulnerability to the server.

[0136] Through the above step 403, the code involving potential vulnerabilities in the target project file can be determined, and the code involving potential vulnerabilities in the target project file can be sent to the server, so that the server can determine the reachable vulnerability based on the code involving potential vulnerabilities, and repair the code involving reachable vulnerabilities in the target project file, wherein the potential vulnerability is a vulnerability that is triggered by a direct or indirect path when the target project file calls the target open source component, and the reachable vulnerability is a potential vulnerability that has not been repaired.

[0137] In an embodiment of the present application, by compiling the target project file on the terminal device side and performing extraction of the code involving potential vulnerabilities, not only the accuracy of vulnerability detection and protection on the server side is improved, but also the user's concerns about code leakage are reduced, while the cost of user code management on the server side is reduced.

[0138] As a feasible implementation method, the target project file includes the source code and user configuration code of the target open source component; the above step 403 determines the code involving potential vulnerabilities in the target project file and sends the code involving potential vulnerabilities to the server, specifically including:

[0139] A first code in the user configuration code that triggers a potential vulnerability is determined, and a second code in the source code of the target open source component that triggers a potential vulnerability is determined, and the first code and the second code are sent to a server.

[0140] In order to better illustrate the vulnerability protection method of the open source component provided by the present application, in one embodiment of the present application, Figure 4 As shown, the embodiment of the present application provides an overall flow chart of vulnerability protection of open source components, including the following steps:

[0141] Step 501, the developer configures the target project file on the terminal device;

[0142] Step 502: the acquisition plug-in compiles the target project file on the terminal device based on a preset compilation rule, and sends the compilation result to the server;

[0143] Step 503, the server determines the target open source component called by the target project file and the potential vulnerability of the target project file based on the compilation result, and executes steps 504 and 508;

[0144] Step 504: the server sends a code acquisition instruction to the acquisition plug-in on the terminal device to acquire the code involving potential vulnerabilities in the target project file;

[0145] Step 505, the collection plug-in sends the code involving potential vulnerabilities in the target project file to the server;

[0146] Step 506, the server verifies whether the potential vulnerability has been repaired based on the code involving the potential vulnerability in the target project file, and identifies the unrepaired potential vulnerability as a reachable vulnerability of the target project file;

[0147] Step 507, the server uses the vulnerability repair code to repair the code involving the reachable vulnerability in the target project file;

[0148] Step 508, the server uses the component monitoring code to monitor the component usage of the target open source component in the target project file;

[0149] Step 509: When the server determines that a new vulnerability appears in the target open source component, the server performs a risk level assessment and a risk warning on the new vulnerability based on the component usage and preset risk assessment rules.

[0150] It should be noted that the above steps can be executed according to the set trigger conditions during and after the project development process, such as executing the above steps 501-509 according to user instructions, or executing the above steps 501-509 according to a set cycle. This application does not limit this.

[0151] Based on the same technical concept, the present application exemplarily provides a vulnerability protection device for an open source component, such as Figure 5 As shown, the device comprises:

[0152] The compilation data receiving module 501 is used to receive the compilation result sent by the terminal device; the compilation result is obtained by the terminal device compiling the target project file;

[0153] A component information determination module 502 is used to obtain information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file;

[0154] A first vulnerability determination module 503, configured to determine at least one potential vulnerability of the target project file based on information of the target open source component;

[0155] A second vulnerability determination module 504 is used to verify, for each of the potential vulnerabilities, whether the potential vulnerability has been repaired based on the code related to the potential vulnerability in the target project file, and to identify the unrepaired potential vulnerability as a reachable vulnerability;

[0156] The vulnerability repair module 505 is used to compile the data receiving module, and is used to repair the code related to the reachable vulnerability in the target project file.

[0157] In a possible implementation, the information of the target open source component includes the name and version number of the target open source component, and context feature information when the target open source component is called; the first vulnerability determination module 503 is used to:

[0158] Based on the name and version number of the target open source component, vulnerability code feature information of the target open source component is obtained from a component protection information library; the component protection information library stores vulnerability code feature information of multiple open source components;

[0159] The vulnerability code feature information of the target open source component is matched with the context feature information, and at least one potential vulnerability of the target project file is determined based on the matching result.

[0160] In a possible implementation, the target project file includes the source code and user configuration code of the target open source component; the second vulnerability determination module 504 is used to:

[0161] Acquire a first code in the user configuration code that triggers the potential vulnerability, and a second code in the source code of the target open source component that triggers the potential vulnerability;

[0162] Based on the first code and the second code, verify whether the potential vulnerability has been repaired.

[0163] In a possible implementation, the device further includes a repair operation configuration module, wherein the repair operation configuration module is configured to:

[0164] Before repairing the code involved in the reachable vulnerability in the target project file, it is determined whether to repair the code involved in the reachable vulnerability in the target project file based on a default configuration or a user instruction.

[0165] In a possible implementation, the device further includes a push module, and the push module is used to:

[0166] Determine whether to push a repair suggestion for the reachable vulnerability based on a default configuration or a user instruction.

[0167] In a possible implementation, the device further includes a component monitoring module, and the component monitoring module is used to:

[0168] Monitoring the code in the target project file that calls the target open source component to obtain component usage of the target open source component;

[0169] When it is determined that a new vulnerability appears in the target open source component, a risk level assessment and risk warning are performed on the new vulnerability based on the usage of the component and preset risk assessment rules.

[0170] Based on the same technical concept, the present application exemplarily provides a vulnerability protection device for an open source component, such as Figure 6 As shown, the device comprises:

[0171] A compilation data sending module 601 is used to compile the target project file based on a preset compilation rule, and send the compilation result to the server, so that the server determines the information of the target open source component, and determines at least one potential vulnerability of the target project file based on the information base of the target open source component, wherein the target open source component is an open source component called by the target project file;

[0172] An instruction receiving module 602 is used to receive a code acquisition instruction sent by the server, wherein the code acquisition instruction includes an identity identifier of the potential vulnerability;

[0173] The vulnerability code sending module 603 is used to determine the code involving the potential vulnerability in the target project file based on the identity identifier of the potential vulnerability, and send the code involving the potential vulnerability to the server, so that the server determines the reachable vulnerability based on the code involving the potential vulnerability and repairs the code involving the reachable vulnerability in the target project file, wherein the reachable vulnerability is a potential vulnerability that has not been repaired.

[0174] In a possible implementation, the target project file includes the source code and user configuration code of the target open source component; the vulnerability code sending module 603 is used to:

[0175] Determine a first code in the user configuration code that triggers the potential vulnerability, and determine a second code in the source code of the target open source component that triggers the potential vulnerability, and send the first code and the second code to the server.

[0176] Based on the same inventive concept as the above method embodiment, an electronic device is also provided in the embodiment of the present application. The electronic device can be used to perform the actions described in the above method embodiment. In this embodiment, the structure of the electronic device can be as follows: Figure 7 As shown, it includes a memory 101 and one or more processors 102 .

[0177] The memory 101 is used to store computer programs executed by the processor 102. The memory 101 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and programs required for running the instant messaging function, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0178] The memory 101 may be a volatile memory, such as a random-access memory (RAM); the memory 101 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), or the memory 101 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 101 may be a combination of the above memories.

[0179] The processor 102 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 102 is used to implement the vulnerability protection method of the open source component when calling the computer program stored in the memory 101.

[0180] The specific connection medium between the memory 101 and the processor 102 is not limited in the embodiment of the present application. Figure 7 In the embodiment, the memory 101 and the processor 102 are connected via a bus 103. The bus 103 is connected to the processor 102 via a bus 103. Figure 7 The connections between other components are shown in bold lines, and are not intended to be limiting. The bus 103 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0181] Optionally, the processor 102 may be configured to execute the above actions performed by any one or more of the decomposition module, the first prediction module, the second prediction module, and the acquisition module.

[0182] Based on the same inventive concept, the embodiment of the present application provides a computer-readable storage medium, and the computer program product includes: computer program code, when the computer program code is run on a computer, the computer executes any of the open source component vulnerability protection methods discussed above. Since the principle of solving the problem by the above-mentioned computer-readable storage medium is similar to the open source component vulnerability protection method, the implementation of the above-mentioned computer-readable storage medium can refer to the implementation of the method, and the repeated parts will not be repeated.

[0183] Based on the same inventive concept, the embodiment of the present application also provides a computer program product, which includes: computer program code, when the computer program code is run on a computer, the computer executes any of the open source component vulnerability protection methods discussed above. Since the principle of solving the problem by the above computer program product is similar to the open source component vulnerability protection method, the implementation of the above computer program product can refer to the implementation of the method, and the repeated parts will not be repeated.

[0184] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

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

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

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

[0188] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A vulnerability protection method for open source components, applied to a server, characterized in that: include: Receiving a compilation result sent by a terminal device; the compilation result is obtained by the terminal device compiling a target project file; Acquire information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file; Determining at least one potential vulnerability of the target project file based on the information of the target open source component; For each of the potential vulnerabilities, based on the code related to the potential vulnerability in the target project file, verify whether the potential vulnerability has been repaired, and confirm the unrepaired potential vulnerability as a reachable vulnerability; Repair the code involving the reachable vulnerability in the target project file.

2. The method according to claim 1, characterized in that The information of the target open source component includes the name and version number of the target open source component, and context feature information when the target open source component is called; The determining, based on the information of the target open source component, at least one potential vulnerability of the target project file comprises: Based on the name and version number of the target open source component, vulnerability code feature information of the target open source component is obtained from a component protection information library; the component protection information library stores vulnerability code feature information of multiple open source components; The vulnerability code feature information of the target open source component is matched with the context feature information, and at least one potential vulnerability of the target project file is determined based on the matching result.

3. The method according to claim 1, characterized in that The target project file includes the source code and user configuration code of the target open source component; The verifying whether the potential vulnerability has been fixed based on the code related to the potential vulnerability in the target project file includes: Acquire a first code in the user configuration code that triggers the potential vulnerability, and a second code in the source code of the target open source component that triggers the potential vulnerability; Based on the first code and the second code, verify whether the potential vulnerability has been repaired.

4. The method according to claim 1, characterized in that Before repairing the code in the target project file involving the reachable vulnerability, the method further includes: Determine whether to repair the code involving the accessible vulnerability in the target project file based on default configuration or user instruction.

5. The method according to claim 1, characterized in that The method further comprises: Determine whether to push a repair suggestion for the reachable vulnerability based on a default configuration or a user instruction.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Monitoring the code in the target project file that calls the target open source component to obtain component usage of the target open source component; When it is determined that a new vulnerability appears in the target open source component, a risk level assessment and risk warning are performed on the new vulnerability based on the usage of the component and preset risk assessment rules.

7. A vulnerability protection method for open source components, applied to terminal devices, characterized in that: The method comprises: Compile the target project file based on a preset compilation rule, and send the compilation result to a server, so that the server determines information of a target open source component, and determines at least one potential vulnerability of the target project file based on an information base of the target open source component, wherein the target open source component is an open source component called by the target project file; Receiving a code acquisition instruction sent by the server, wherein the code acquisition instruction includes an identity identifier of the potential vulnerability; Based on the identity identifier of the potential vulnerability, the code involving the potential vulnerability in the target project file is determined, and the code involving the potential vulnerability is sent to the server, so that the server determines the reachable vulnerability based on the code involving the potential vulnerability and repairs the code involving the reachable vulnerability in the target project file, wherein the reachable vulnerability is an unrepaired potential vulnerability.

8. The method according to claim 7, characterized in that The target project file includes the source code and user configuration code of the target open source component; determining the code involving the potential vulnerability in the target project file and sending the code involving the potential vulnerability to the server includes: Determine a first code in the user configuration code that triggers the potential vulnerability, and determine a second code in the source code of the target open source component that triggers the potential vulnerability, and send the first code and the second code to the server.

9. A vulnerability protection device for an open source component, characterized in that: include: A compilation data receiving module, used for receiving a compilation result sent by a terminal device; the compilation result is obtained by the terminal device compiling a target project file; A component information determination module, used to obtain information of a target open source component from the compilation result; the target open source component is an open source component called by the target project file; A first vulnerability determination module, configured to determine at least one potential vulnerability of the target project file based on information of the target open source component; A second vulnerability determination module is used to verify, for each of the potential vulnerabilities, whether the potential vulnerability has been repaired based on the code related to the potential vulnerability in the target project file, and to identify the unrepaired potential vulnerability as a reachable vulnerability; The vulnerability repair module is used to compile the data receiving module, and is used to repair the code related to the reachable vulnerability in the target project file.

10. A vulnerability protection device for an open source component, characterized in that: include: A compilation data sending module, used to compile the target project file based on a preset compilation rule, and send the compilation result to a server, so that the server determines the information of the target open source component, and determines at least one potential vulnerability of the target project file based on the information base of the target open source component, wherein the target open source component is an open source component called by the target project file; An instruction receiving module, used for receiving a code acquisition instruction sent by the server, wherein the code acquisition instruction includes an identity identifier of the potential vulnerability; A vulnerability code sending module is used to determine the code involving the potential vulnerability in the target project file based on the identity identifier of the potential vulnerability, and send the code involving the potential vulnerability to the server, so that the server determines the reachable vulnerability based on the code involving the potential vulnerability and repairs the code involving the reachable vulnerability in the target project file, wherein the reachable vulnerability is a potential vulnerability that has not been repaired.

11. An electronic device, characterized in that: It includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes the steps of any method described in claims 1 to 6, or executes the steps of any method described in claims 7 to 8.

12. A computer-readable storage medium, characterized in that: It includes program code. When the program code is run on an electronic device, the program code is used to enable the electronic device to execute the steps of any method described in claims 1 to 6, or execute the steps of any method described in claims 7 to 8.

Images