An open source component vulnerability fixing method and device

Abstract

The application provides an open source component vulnerability repair method and device, wherein the method comprises: analyzing a target software by using a software component analysis tool to obtain component information and dependency relationships of all open source components; obtaining global influence of each open source component based on the dependency relationships of all open source components, searching an open source component knowledge base based on the component information of all open source components, and determining at least one open source component with a vulnerability; sorting the at least one open source component with a vulnerability according to the respective global influence, and then performing a vulnerability repair operation in sequence according to the sorting result, including searching the open source component knowledge base based on the component information of the open source component with a vulnerability, obtaining the target open source component and its dependent components, and repairing the vulnerabilities of the open source component and its dependent components. Thus, the automatic recommendation of the open source component vulnerability repair scheme can be realized, the vulnerability repair efficiency is improved, and the system compatibility risk is reduced.

Description

Technical Field

[0001] This application relates to the field of software supply chain security technology, and in particular to a method and apparatus for fixing vulnerabilities in open source components. Background Technology

[0002] In software development, fully utilizing the functionality of open-source components can effectively reduce development workload, allowing developers to focus more on core functionalities. However, the openness and sharing nature of open-source software have led to its expanding scope and depth of influence. In recent years, with the explosive growth in the number of open-source projects, open-source software (OSS) has gained increasing prominence in the global software ecosystem, becoming one of the primary targets of attackers. A typical example is the Apache Log4j2 remote code execution vulnerability (CVE-2021-44228), which, due to being directly or indirectly relied upon by over 350,000 Java components, has threatened millions of systems worldwide, resulting in direct economic losses exceeding tens of billions of dollars. With increasing software supply chain security issues, governments are paying close attention, thus enterprises urgently need to strengthen the management of open-source component vulnerabilities.

[0003] Traditional open-source component vulnerability remediation methods suffer from problems such as insufficient vulnerability discovery capabilities due to indirect reliance, significant delays in vulnerability intelligence response, low remediation efficiency, and unreasonable remediation solutions. These problems lead to misjudgment of the scope of vulnerability impact, long remediation time, and increased compatibility risks. Summary of the Invention

[0004] This application provides a method and apparatus for patching vulnerabilities in open-source components, which can automatically recommend vulnerability patching solutions for open-source components, improve vulnerability patching efficiency, and reduce system compatibility risks.

[0005] In a first aspect, embodiments of this application provide a method for patching vulnerabilities in open-source components, the method comprising:

[0006] The target software was analyzed using software component analysis tools to obtain component information and dependencies of all open-source components; the component information included the name and version number of the open-source component.

[0007] A component dependency network graph is constructed based on the dependencies of all open-source components. Based on the PageRank algorithm and the component dependency network graph, the global influence of each open-source component in the component dependency network graph is obtained. The global influence represents the comprehensive measure of the direct and indirect influence of an open-source component on other components in the component dependency network graph.

[0008] Search the open source component knowledge base based on the component information of all open source components to identify at least one open source component with a vulnerability; the open source component knowledge base includes component information, vulnerability descriptions and dependencies of each open source component in the open source component platform.

[0009] The open-source components with at least one vulnerability are sorted according to their respective global impact, and then the vulnerability patching operations are performed in sequence according to the sorting results.

[0010] The vulnerability remediation operation includes: searching the open-source component knowledge base based on the component information of the vulnerable open-source component to obtain the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the vulnerable open-source component;

[0011] Based on the target open-source component and its dependent components, update the component information and dependencies of the vulnerable open-source component to fix the vulnerabilities in the vulnerable open-source component and its dependent components.

[0012] Therefore, before performing software component vulnerability repair, this application establishes an open-source component knowledge base, including component vulnerability data, component vulnerability repair version information, and component dependency relationships. Based on this, during the component vulnerability repair process, this solution utilizes software component analysis tools to analyze the software and establish a global dependency topology for the open-source components. Furthermore, it automatically performs component vulnerability screening based on the open-source component knowledge base and sorts vulnerable open-source components according to their global impact. Based on the sorting results, it repairs the vulnerable open-source components sequentially, including: determining the component vulnerability repair version based on the open-source component knowledge base, thereby improving vulnerability identification and repair efficiency; and obtaining the dependent component information of the component vulnerability repair version from the open-source component knowledge base, so as to simultaneously repair vulnerabilities in directly and indirectly dependent components related to the software, thereby minimizing the impact on component dependencies and minimizing compatibility risks.

[0013] Secondly, embodiments of this application provide an open-source component vulnerability repair device, the device comprising:

[0014] The software component analysis module is used to analyze the target software using software component analysis tools to obtain component information and dependencies of all open-source components; the component information includes the name and version number of the open-source component;

[0015] The global influence assessment module constructs a component dependency network graph based on the dependencies of all open-source components. Based on the webpage ranking algorithm and the component dependency network graph, it obtains the global influence of each open-source component in the component dependency network graph. Global influence represents a comprehensive measure of the direct and indirect impact of an open-source component on other components in the component dependency network graph.

[0016] The vulnerability identification module is used to search the open source component knowledge base based on the component information of all open source components to identify at least one open source component with a vulnerability. The open source component knowledge base includes component information, vulnerability descriptions, and dependencies of each open source component in the open source component platform.

[0017] The component upgrade module is used to sort at least one vulnerable open-source component according to its corresponding global impact, and then perform vulnerability repair operations in sequence according to the sorting results.

[0018] The vulnerability remediation operation includes: searching the open-source component knowledge base based on the component information of the vulnerable open-source component to obtain the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the vulnerable open-source component;

[0019] Based on the target open-source component and its dependent components, update the component information and dependencies of the vulnerable open-source component to fix the vulnerabilities in the vulnerable open-source component and its dependent components.

[0020] Thirdly, embodiments of this application provide a computer storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0021] Fourthly, embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0022] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0024] Figure 1 A diagram illustrating open-source component dependencies is shown.

[0025] Figure 2 This illustration shows a schematic diagram of an open-source component vulnerability repair method provided in an embodiment of this application;

[0026] Figure 3This paper illustrates a flowchart of an open-source component vulnerability remediation method provided in an embodiment of this application.

[0027] Figure 4 This paper illustrates a vulnerability remediation strategy diagram for an open-source component provided in an embodiment of this application.

[0028] Figure 5 A schematic diagram of an open-source component vulnerability repair device provided in an embodiment of this application is shown. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0030] In the description of the embodiments in this application, any embodiment or design that is “exemplary,” “for example,” or “by way of example” should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as “exemplary,” “for example,” or “by way of example” is intended to present the relevant concepts in a concrete manner.

[0031] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized. "Multiple" can refer to one or more, where multiple means two or more.

[0032] Figure 1 A diagram illustrating the dependencies of open-source components is shown. For example... Figure 1 As shown, component dependencies often present a multi-level nested structure. For example, the main software program depends on component A, component A depends on component B, and component B depends on component C. Therefore, the main software program directly depends on component A and indirectly depends on components B and C, represented as A→B→C. Directly dependent components refer to components that the main program explicitly declares it needs, while indirectly dependent components refer to other components that the main program needs indirectly through its directly dependent components.

[0033] Existing vulnerability remediation tools often lack global dependency topology analysis, leading to misjudgments of the vulnerability's impact scope. Take the Log4j vulnerability as an example: Log4j is a widely used logging library, and many components depend on it. If a main program in a software application indirectly depends on Log4j, and that main program's direct dependency does not explicitly declare Log4j, the tool might overlook the vulnerability in this indirect dependency. This could result in the software still using a vulnerable version of Log4j at runtime, without the developer's knowledge.

[0034] Existing vulnerability remediation tools mainly rely on manual monitoring of vulnerability databases such as CVE / NVD. The average time from vulnerability disclosure to the implementation of remediation solutions exceeds 72 hours (refer to the Equifax incident where 143 million user data were leaked due to delayed response to an Apache Struts vulnerability).

[0035] In order to find component versions with fixable vulnerabilities, existing vulnerability remediation tools require developers to manually check each component and all its dependent components for vulnerabilities, which is both time-consuming and inefficient.

[0036] Existing vulnerability patching tools typically eliminate indirect dependencies and replace them with direct dependencies, altering component dependency relationships and making it easier to cause compatibility issues in subsequent version upgrades.

[0037] In summary, traditional open-source component vulnerability remediation methods suffer from problems such as insufficient vulnerability discovery capabilities due to indirect reliance, significant delays in vulnerability intelligence response, low remediation efficiency, and unreasonable remediation solutions. These problems lead to misjudgment of the vulnerability's impact scope, long remediation times, and increased compatibility risks.

[0038] To address the aforementioned issues, this application establishes an open-source component knowledge base, including component vulnerability data, component vulnerability repair version information, and component dependencies, before performing software component vulnerability repair. Based on this, during the component vulnerability repair process, this solution utilizes software component analysis tools to analyze the software and establish a global dependency topology for the open-source components. Furthermore, it automatically performs component vulnerability screening based on the open-source component knowledge base and sorts vulnerable open-source components according to their global impact. Based on the sorting results, it repairs the vulnerable open-source components sequentially, including: determining the component vulnerability repair version based on the open-source component knowledge base, thereby improving vulnerability identification and repair efficiency; and obtaining the dependent component information of the component vulnerability repair version from the open-source component knowledge base, so as to simultaneously repair vulnerabilities in directly and indirectly dependent components related to the software, thereby minimizing the impact on component dependencies and minimizing compatibility risks.

[0039] Figure 2 A schematic diagram of an open-source component vulnerability remediation method provided in an embodiment of this application is shown. Figure 2 As shown, the open-source component vulnerability remediation method includes the following steps:

[0040] Step S201: Upload the source code or SBOM manifest.

[0041] For example, users need to upload the source code or Software Bill of Materials (SBOM) of the target software to the system. The SBOM contains detailed information about the target software components, such as component names, versions, and licenses.

[0042] Step S202, software component analysis.

[0043] For example, the system analyzes the uploaded source code or SBOM to identify the names, versions, and detailed component dependencies of all components contained in the target software.

[0044] Step S203, global influence ranking.

[0045] For example, a component dependency network graph is constructed based on the dependencies of all open-source components. Then, based on the webpage ranking algorithm and the component dependency network graph, the global influence of each open-source component within the network graph is obtained. All open-source components are then ranked based on their global influence, yielding the ranking results. Global influence represents a comprehensive measure of the direct and indirect impact of an open-source component on other components within the component dependency network graph.

[0046] Step S204: Build an open-source component knowledge base.

[0047] For example, the system collects information related to open-source component vulnerabilities from multiple open-source component platforms, such as vulnerability descriptions, scope of impact, remediation suggestions, and dependencies, in order to build an open-source component knowledge base.

[0048] Specifically, the system can integrate the latest component and vulnerability information through daily scheduled updates, and build a comprehensive knowledge base containing key data such as component dependency topology and vulnerability impact scope, providing comprehensive data support for subsequent analysis.

[0049] Step S205, vulnerability identification.

[0050] For example, based on the results of target software component analysis and an open-source component knowledge base, the system identifies potential security vulnerabilities in the target software. This process includes comparing the extracted open-source component information with a vulnerability database to quickly identify vulnerable open-source components.

[0051] Step S206: Semanticization of component versions.

[0052] For example, the system standardizes the version information of each component in the open-source component knowledge base to facilitate subsequent analysis and comparison.

[0053] Step S207, Intelligent Recommendation.

[0054] For example, based on the ranking of global impact, vulnerable open-source components are patched sequentially from highest to lowest global impact. Vulnerability patching includes: based on the patching strategy, vulnerability identification results, and information from the open-source component knowledge base, the system intelligently recommends the optimal patching solution, such as suggesting that the vulnerable open-source component be upgraded to a secure component version. The patching strategy includes prioritizing compatible versions of the component, followed by the latest version for vulnerability patching. A compatible version refers to a software version that can seamlessly collaborate with existing systems, applications, or other components. The latest version refers to a software version newer than the currently used version, typically including new features, performance improvements, and security fixes. In production environments, compatible versions are usually prioritized to avoid functional incompatibility caused by cross-major version upgrades, thereby improving system stability. Therefore, Figure 2 This paper demonstrates an automated software vulnerability analysis and remediation recommendation process. By integrating multi-source component data, automated analysis, and intelligent recommendations, it significantly reduces the complexity of open-source component vulnerability management while improving the security and maintenance efficiency of software systems.

[0055] Furthermore, after constructing the component dependency network graph, this solution attaches a structured risk label to each dependent component, serving as the core basis for path assessment and risk scoring. This makes the solution applicable to large-scale multilingual dependency projects, security audit platforms, SCA (software composition analysis) tool integration scenarios, and continuous delivery pipelines requiring automated generation of remediation recommendations. Unlike traditional remediation methods based on component vulnerability priority, such as remediation based on common vulnerability scoring system (CVSS), this solution combines graph topology (propagation path), component dependency levels, and compatibility indicators to identify critical components with a greater "amplification effect" at the software level, thus prioritizing the allocation of limited remediation resources to components that contribute more to software risk.

[0056] Based on the above, this application provides a detailed description of an open-source component vulnerability repair method.

[0057] For example, Figure 3 This document illustrates a flowchart of an open-source component vulnerability remediation method provided in an embodiment of this application. This method can be executed by any computing unit, server, device, device cluster, etc., with computing and processing capabilities, such as... Figure 3 As shown, the method mainly includes the following execution steps:

[0058] Step S301: Analyze the target software using a software component analysis tool to obtain component information and dependencies of all open-source components. Component information includes the name and version number of the open-source component.

[0059] For example, a software composition analysis tool is responsible for performing a comprehensive composition analysis of the target software and accurately extracting relevant information about the open-source components. This analysis process includes identifying the open-source components used in the target software and their key information such as names, version numbers, and dependencies through techniques such as static code analysis and dependency resolution.

[0060] Specifically, this tool scans the target software's source code and dependency files (such as package.json, pom.xml, etc.), or scans the target software's SBOM, extracting component names and version numbers. It analyzes component dependencies, generates a component dependency topology graph, and displays the hierarchical dependencies between components. It detects component usage, including direct and indirect dependencies, and marks the specific location of each component in the component dependency topology graph.

[0061] Step S302: Construct a component dependency network graph based on the dependencies of all open-source components. Then, based on the webpage ranking algorithm and the component dependency network graph, obtain the global influence of each open-source component within the network graph. Global influence represents a comprehensive measure of the direct and indirect impact of an open-source component on other components within the component dependency network graph.

[0062] For example, a component dependency network graph is constructed based on the dependencies of all open-source components. For each open-source component, the component dependency network graph is traversed to obtain a first number of other open-source components in the network that depend on the component, and a second number of other open-source components that depend on the component. Based on the first and second numbers, a risk index value for the open-source component is obtained by evaluating it using a webpage ranking algorithm. Based on the first and second numbers, and the risk index value, a global influence of the open-source component in the component dependency network graph is calculated according to a preset comprehensive risk scoring function. Global influence represents a comprehensive measure of the direct and indirect impact of the open-source component on other components in the component dependency network graph.

[0063] The process of calculating global influence is as follows:

[0064] First, traverse the component dependency network graph to obtain the first number of times each open-source component is depended on by other open-source components different from itself in the dependency network graph (i.e., in-degree). In-degree represents the number of times the component is depended on by other components. The higher the in-degree value, the more widely the component is depended on in the target software, and its upgrade may trigger a wider range of cascading effects; therefore, the risk level should be increased accordingly.

[0065] Traverse the component dependency network graph to obtain the second number of other open-source components that each open-source component depends on (i.e., the outdegree). The outdegree represents the number of external components that the component depends on. The higher the outdegree value, the higher the compatibility requirements of the component with the external environment, and the greater the potential compatibility risks during upgrades.

[0066] Secondly, the PageRank algorithm is used to evaluate the global importance of a component in the entire dependency network graph. The higher the PageRank score, the greater the influence of the component in the system, and the wider the scope of its propagation and risk diffusion once a vulnerability is discovered.

[0067] For any component vi, its PageRank value is calculated using the following formula:

[0068] (1)

[0069] Where: -d: damping coefficient, the commonly used default value is 0.85;

[0070] - In( ): All components that directly depend on The set of downstream components, such as components B and C depending on component A, then In(A) = {B, C};

[0071] -PR( Downstream node Its own PageRank value;

[0072] -L( ):node The degree of departure.

[0073] After calculating the above indicators, a comprehensive risk scoring function, RiskScore, is defined to quantify the importance and upgrade priority of each component:

[0074] RiskScore(v) = α * PageRank(v) + β * InDegree(v) + γ * OutDegree(v) + Layer(v), where: - α, β, γ: are weight coefficients, which can be set manually or determined through automatic tuning;

[0075] -InDegree(v): The in-degree value of node v;

[0076] -OutDegree(v): The out-degree value of node v;

[0077] -Layer(v): The shortest path length from node v to the root node of the target software, reflecting its position in the dependency hierarchy; the root node refers to the function in the target software that directly depends on it.

[0078] A higher RiskScore indicates that a component is both critical and sensitive in the dependency network, and should be given priority and handled with care during upgrades.

[0079] The system will traverse the entire component dependency network graph, calculate a comprehensive risk score for all components, and highlight high-risk components in red in the visualization interface. It also supports one-click expansion of its upstream and downstream dependency chains, making it easy to quickly locate the potential risk propagation range.

[0080] Step S303: Search the open-source component knowledge base based on the component information of all open-source components to identify at least one open-source component with a vulnerability. The open-source component knowledge base includes component information, vulnerability descriptions, and dependencies of each open-source component in the open-source component platform.

[0081] For example, before performing component vulnerability patching, real-time integration with multiple authoritative vulnerability databases (such as NVD, CVE, OVAL, etc.) and open-source component repositories (such as GitHub, GitLab, etc.) is established to obtain the latest component and vulnerability data. This enables automated collection and synchronization of open-source component and vulnerability information. The collected data includes multi-dimensional information such as component name, version number, dependencies, vulnerability description, impact scope, and remediation suggestions.

[0082] To ensure data accuracy and timeliness, a scheduled synchronization mechanism can be employed to update the knowledge base daily. Furthermore, manual synchronization can be manually triggered to address the need for rapid response to urgent vulnerabilities. By integrating multi-source data, a comprehensive multimodal knowledge base can be built, providing reliable data support for subsequent vulnerability analysis and remediation.

[0083] Based on this, the component information of the obtained open source components can be compared with the open source component database in real time to intelligently identify whether the components have known vulnerabilities and mark the scope of impact and risk level of the vulnerabilities.

[0084] Specifically, this includes: comparing component names and version numbers with CVE entries in the open-source component database to identify the existence of known vulnerabilities; classifying the vulnerability severity (e.g., critical, high, medium, low) based on its impact and remediation recommendations; analyzing the specific impact of the vulnerability on the target software and generating a detailed vulnerability report, including vulnerability description, affected components, and remediation recommendations.

[0085] Step S304: At least one vulnerable open-source component is sorted according to its corresponding global impact, and then vulnerability remediation operations are performed sequentially according to the sorting results. The vulnerability remediation operations include: searching the open-source component knowledge base based on the component information of the vulnerable open-source component to obtain the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the vulnerable open-source component; and updating the component information and dependencies of the vulnerable open-source component according to the target open-source component and its dependent components to remediate the vulnerabilities in the vulnerable open-source component and its dependent components.

[0086] For example, at least one vulnerable open-source component is sorted according to its corresponding global influence, and then the vulnerable open-source components are patched in order of global influence from high to low.

[0087] For example, before intelligently searching the open-source component knowledge base based on open-source components, the versions of the components collected from the knowledge base are parsed and managed to ensure version compatibility and the correctness of dependencies. For instance, based on semantic versioning rules, the version numbers of components are standardized, and the major version, minor version, and revision information of the version number are parsed to simplify version comparison and compatibility decisions.

[0088] Specifically, a standard semantic version number format is defined: major version number.minor version number.revision number.

[0089] Check that the version numbers of each component conform to semantic versioning rules to ensure the standardization and consistency of version numbers. Standardize the component version numbers and parse out the major version number, minor version number, and revision number.

[0090] Optionally, a pre-release version identifier, such as -alpha or -beta, can be appended to the version number to indicate that the component is still under development and not suitable for production environments. Version compilation information, such as build time and build number, can also be added after the version number to identify a specific build version.

[0091] Establish version compatibility rules and provide version compatibility checks to ensure that the component versions recommended in the remediation plan are compatible with the existing system. This allows for the assessment of compatibility between different versions based on semantic versioning rules, preventing remediation failures or system crashes caused by version incompatibility.

[0092] For example, in version compatibility rules, based on the semantically defined component version number, fix components with the same major version number can be set as compatible versions, and fix components with a higher major version number can be set as the latest versions.

[0093] Suppose a component is currently version 1.2.3. Based on semantic version numbers, the following compatibility rules can be set:

[0094] Fixes with the same major version number (i.e., 1) are considered compatible versions. In compatible versions, minor and revision numbers can increase but not decrease, and backward compatibility must be guaranteed. For example, versions 1.2.4 and 1.3.0 are considered compatible because they maintain the same major version number as 1.2.3 and are backward compatible.

[0095] Fixes with a version number higher than the current major version are considered the latest version. Upgrading to such a version may require corresponding modifications to the target software's main program, as incompatible changes may exist. For example, 2.0.0 would be considered the latest version because an increase in the major version number usually indicates a significant change.

[0096] After semantic versioning, for each vulnerability, based on the information of the open-source components that introduce the vulnerability, and according to the remediation strategy, component dependencies, and version compatibility rules, the optimal vulnerability remediation solution is automatically generated after comprehensive evaluation.

[0097] For example, vulnerability remediation includes: for each vulnerability, the vulnerability remediation plan provides the best patch version to eliminate the vulnerability in the open-source component, i.e., the target open-source component. If the target open-source component includes dependent components, it also obtains information such as the dependent components of the target open-source component and the dependency relationships between the target open-source component and its dependent components based on the open-source component knowledge base.

[0098] If the vulnerable open-source component is determined to be a direct dependency of the main program in the target software, the open-source component knowledge base is searched based on the component's information to obtain all vulnerability patch versions. Following the patching strategy, compatible versions are prioritized from all patch versions, followed by the latest versions, to obtain the target open-source component and its dependent components.

[0099] After searching and obtaining all vulnerability remediation components that meet the vulnerability remediation requirements, the remediation strategy prioritizes compatible versions of open-source components based on their semantic version numbers. If no compatible version exists, the latest version is considered. Within each level, if multiple versions are found, the highest-level version is selected according to the semantic rules.

[0100] If the vulnerable open-source component is determined to be an indirect dependency of the main program in the target software, the open-source component knowledge base is searched based on the information of the vulnerable open-source component to obtain the vulnerability patch version and the vulnerability patch version that directly depends on the vulnerability patch version. According to the patching strategy, it is determined whether the vulnerability patch version that directly depends on the vulnerability patch version exists in the open-source component knowledge base. If it exists, the directly dependent vulnerability patch version is selected; otherwise, the vulnerability patch version is selected as the target open-source component to obtain the target open-source component and its dependent components.

[0101] After obtaining the vulnerability patch version, the search proceeds according to the patching strategy and semantic version number, prioritizing the directly dependent vulnerability patch version, followed by other vulnerability patches, to obtain the target open-source component and its dependencies. Within each level, if multiple versions are found, the highest-level version is selected based on the semantic rules.

[0102] Specifically, when searching open-source component knowledge bases based on information about vulnerable open-source components to obtain the target open-source component and its dependent components, the following remediation strategies should be followed:

[0103] 1. Vulnerabilities must be resolved (unless there is no version), and dependencies should be kept unchanged as much as possible.

[0104] 2. First, address the vulnerabilities in directly dependent components, then address the vulnerabilities in indirectly dependent components (because upgrading directly dependent components may simultaneously fix vulnerabilities in indirectly dependent components).

[0105] 3. For directly dependent components, use compatible versions first.

[0106] 4. For indirect dependent components, firstly, upgrade the bug-free compatible version of the corresponding direct dependent component in its dependency relationship (the version of the indirect dependent component is upgraded along with the direct dependent component). The dependent component of the bug-free compatible version of the direct dependent component is the compatible version of the indirect dependent component.

[0107] Secondly, upgrade the compatible versions of indirectly dependent components.

[0108] Assume a dependency exists: A1.0.0 (no vulnerability) → B1.0.0 (vulnerable), where 1.0.0 represents the version number, and so on. When fixing the vulnerability introduced by B1.0.0, if the open-source component database contains component A1.5.0 (no vulnerability) and the dependency A1.5.0 (no vulnerability) → B1.5.0 (no vulnerability), then component A1.5.0 should be upgraded first. If such component A1.5.0 does not exist, then component B1.5.0 should be considered for upgrading next.

[0109] Secondly, upgrade the latest version of the directly dependent components to be bug-free (the version of the indirectly dependent components is upgraded together with the directly dependent components for cross-compatibility version upgrades), and the dependent components of the latest version of the directly dependent components to be bug-free are the latest versions of the indirectly dependent components.

[0110] Finally, consider upgrading the latest version of the indirectly dependent components.

[0111] Thus, while ensuring that the remediation solution minimizes changes to the dependencies of the target software components, the dual goals of maximizing vulnerability remediation efficiency and minimizing compatibility risks are achieved.

[0112] For each vulnerability, if a search of the open-source component knowledge base based on the information of the open-source component fails to find a target open-source component that meets the above conditions, then the vulnerability of that open-source component has not been fixed, and it is necessary to wait for a new version of the open-source component or replace it with another component.

[0113] The vulnerability remediation also includes updating the component information and dependencies of the target open-source component and its dependent components to fix the vulnerabilities of the open-source component and its dependent components.

[0114] For example, the vulnerable open-source component and its dependent components are replaced with the target open-source component and its dependent components to update the component information of the open-source component. The dependencies of the vulnerable open-source component and its dependent components are replaced with the dependencies of the target open-source component and its dependent components to update the dependencies of the open-source component.

[0115] Therefore, this invention proposes an open-source component vulnerability remediation method that addresses the four major challenges in open-source component vulnerability governance: difficulty in discovery, slow remediation, significant impact, and unreasonable solutions. After identifying high-risk open-source components, this method, based on the strategy in step S206 (intelligent recommendation), combines the component's hierarchical position, RiskScore, and vulnerability information in the open-source component knowledge base to generate an optimal remediation solution for each high-risk component. This solution prioritizes recommending secure versions compatible with the existing system to ensure seamless collaboration between the component, the system, and other dependent components. When compatible versions are unavailable, the latest secure version is recommended to eliminate known vulnerabilities while simultaneously gaining new features and performance optimizations. In this way, the remediation operation not only prioritizes the most critical high-risk components but also indirectly reduces the risk of downstream components, achieving a closed-loop integration of risk quantification and remediation recommendation, thereby maximizing the security and maintenance efficiency of the software system.

[0116] Figure 4 This diagram illustrates an open-source component vulnerability remediation strategy provided in an embodiment of this application. For example... Figure 4 As shown, the remediation strategies are formulated separately for directly dependent components and indirectly dependent components.

[0117] Specifically, for directly dependent components, execute step (1): traverse all directly dependent components with vulnerabilities. For each directly dependent component with a vulnerability, execute step (2): determine if there is a vulnerability-free compatible version. If there is, execute step (3): use the vulnerability-free compatible version. Step (4): update the software component list and the unpatched directly and indirectly dependent components. If there is no vulnerability, execute step (5): determine if there is a vulnerability-free latest version. If there is, execute step (6): use the vulnerability-free latest version and increase the corresponding upgrade risk. Execute step (4): update the software component list and the unpatched directly and indirectly dependent components. If there is no vulnerability-free latest version, execute step (7): the direct dependency vulnerability has not been patched, and it is necessary to wait for a new version or replace other components.

[0118] For indirect dependent components, perform step (8): traverse all indirect dependent components with vulnerabilities. For each indirect dependent component with a vulnerability, perform step (9): determine if there is a vulnerability-free compatible version. If not, perform step (10): determine if there is a vulnerability-free latest version. If not, perform step (11): the indirect vulnerability has not been fixed and you need to wait for a new version or replace other software.

[0119] If the result of step (9) is that it exists, execute step (12): determine whether there is a vulnerability-free compatible version of the direct dependent component corresponding to the dependency relationship of the indirect dependent component (the dependent component of the vulnerability-free compatible version is the vulnerability-free compatible version of the indirect dependent component). If it exists, execute step (13): use the vulnerability-free compatible version of the direct dependent component and execute step (14): update the software component list and the unfixed direct and indirect dependent components. If it does not exist, execute step (15): use the vulnerability-free compatible version of the indirect dependent component and execute step (14), which includes removing the indirect dependent component and replacing it with the direct dependent component.

[0120] If the result of step (10) is that it exists, execute step (16): determine whether there is a vulnerability-free latest version of the direct dependent component corresponding to the dependency relationship of the indirect dependent component (the dependent component of the vulnerability-free latest version is the vulnerability-free latest version of the indirect dependent component). If it exists, execute step (17): use the vulnerability-free latest version of the direct dependent component and execute step (14); if it does not exist, execute step (18): use the vulnerability-free latest version of the indirect dependent component and execute step (14), which includes removing the indirect dependent component and replacing it with the direct dependent component.

[0121] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Furthermore, in some possible implementations, each step in the above embodiments may be selectively executed according to actual circumstances; it may be partially or fully executed, without limitation here. Additionally, all or part of any feature in the above embodiments can be freely and arbitrarily combined without contradiction. The combined technical solutions are also within the scope of this application.

[0122] Figure 5 A schematic diagram of an open-source component vulnerability repair device provided in an embodiment of this application is shown. Figure 5 As shown, the device 500 includes:

[0123] The software component analysis module 510 is used to analyze the target software using software component analysis tools to obtain component information and dependencies of all open-source components; the component information includes the name and version number of the open-source component.

[0124] The Global Influence Assessment Module 520 constructs a component dependency network graph based on the dependencies of all open-source components. Then, based on the webpage ranking algorithm and the component dependency network graph, it obtains the global influence of each open-source component within the component dependency network graph. Global influence represents a comprehensive measure of the direct and indirect impact of an open-source component on other components within the component dependency network graph.

[0125] The vulnerability identification module 530 is used to search the open source component knowledge base based on the component information of all open source components to identify at least one open source component with a vulnerability. The open source component knowledge base includes component information, vulnerability descriptions, and dependencies of each open source component in the open source component platform.

[0126] The component upgrade module 540 is used to sort at least one vulnerable open-source component according to its corresponding global impact, and then perform vulnerability repair operations in sequence according to the sorting results.

[0127] The vulnerability remediation operation includes: searching the open-source component knowledge base based on the component information of the vulnerable open-source component to obtain the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the vulnerable open-source component;

[0128] Based on the target open-source component and its dependent components, update the component information and dependencies of the vulnerable open-source component to fix the vulnerabilities in the vulnerable open-source component and its dependent components.

[0129] For example, the software component analysis module 510 is used to implement Figure 2 Steps S201 and S202 in the process, the global influence assessment module 520 is used to implement Figure 2 In step S203, the vulnerability identification module 530 is used to implement... Figure 2 In step S205, the component upgrade module 540 is used to implement... Figure 2 Step S207. The process by which the device 500 performs open-source component vulnerability remediation is as described above. Figure 3 The steps S301 to S304 described herein will not be repeated here.

[0130] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0131] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. It should be understood that in the embodiments of this application, the order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0132] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method for patching vulnerabilities in open-source components, characterized in that, The method includes: The target software is analyzed using software component analysis tools to obtain component information and dependencies of all open-source components; the component information includes the name and version number of the open-source component. A component dependency network graph is constructed based on the dependencies of all the open-source components. Based on the webpage ranking algorithm and the component dependency network graph, the global influence of each open-source component in the component dependency network graph is obtained. The global influence represents a comprehensive measure of the direct and indirect influence of the open-source component on other components in the component dependency network graph. Based on the component information of all open source components, search the open source component knowledge base to identify at least one open source component with a vulnerability; the open source component knowledge base includes component information, vulnerability descriptions, and dependencies of each open source component in the open source component platform. The at least one open-source component with a vulnerability is sorted according to its corresponding global impact, and then the vulnerability is fixed in sequence according to the sorting results. The vulnerability remediation operation includes: searching the open-source component knowledge base based on the component information of the open-source component with the vulnerability, and obtaining the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the open-source component with the vulnerability. Based on the target open-source component and its dependent components, update the component information and dependencies of the vulnerable open-source component to fix the vulnerabilities of the vulnerable open-source component and its dependent components. The method based on the webpage ranking algorithm and the component dependency network graph obtains the global influence of each open-source component in the component dependency network graph, including: For each open-source component, traverse the component dependency network graph to obtain a first number of open-source components that the open-source component depends on in the component dependency network graph that are different from the open-source component, and a second number of open-source components that the open-source component depends on in the other open-source components. Based on the first quantity and the second quantity, the risk index value of the open source component is obtained by evaluating it according to the webpage ranking algorithm. Based on the first quantity, the second quantity, and the risk index value, the global influence of the open-source component in the component dependency network graph is calculated according to the preset comprehensive risk scoring function RiskScore. The comprehensive risk scoring function RiskScore is expressed by the formula: RiskScore(v) = α * PageRank(v) + β * InDegree(v) + γ * OutDegree(v) + Layer(v), where α, β, and γ are weight coefficients, v is the node representing the open-source component in the component dependency network graph; PageRank(v) is the risk index value of node v; InDegree(v) is the first number of nodes v; OutDegree(v) is the second number of nodes v; and Layer(v) is the shortest path length from node v to the root node of the target software, where the root node of the target software refers to the function that the target software directly depends on.

2. The method according to claim 1, characterized in that, The step of updating the component information and dependency relationships of the vulnerable open-source component based on the target open-source component and its dependent components includes: The vulnerable open-source component and its dependent components are replaced with the target open-source component and its dependent components to update the component information of the vulnerable open-source component. The dependencies of the vulnerable open-source component and its dependent components are replaced with the dependencies of the target open-source component and its dependent components to update the dependencies of the vulnerable open-source component.

3. The method according to claim 1, characterized in that, The process of searching the open-source component knowledge base based on the component information of the vulnerable open-source component to obtain the target open-source component and its dependent components includes: If the vulnerable open-source component is determined to be a direct dependency of the main program in the target software, then... Based on the component information of the open-source component with the vulnerability, search the open-source component knowledge base to obtain all vulnerability fix versions; According to the remediation strategy, from all the vulnerability remediation versions, the compatible version is selected first, followed by the latest version, in order to obtain the target open source component and its dependent components.

4. The method according to claim 1, characterized in that, The method involves searching the open-source component knowledge base based on the component information of the open-source component with the vulnerability to obtain the target open-source component and its dependent components, including: If the vulnerable open-source component is determined to be an indirect dependency of the main program in the target software, Search the open-source component knowledge base based on the component information of the open-source component with the aforementioned vulnerability to obtain the vulnerability patch version; According to the remediation strategy, determine whether the open-source component knowledge base contains a vulnerability remediation version that the vulnerability remediation version directly depends on; If it exists, select the directly dependent vulnerability patch version; otherwise, select the vulnerability patch version as the target open-source component to obtain the target open-source component and its dependent components.

5. The method according to claim 1, characterized in that, Before searching the open-source component knowledge base based on component information from all open-source components, the following steps are also included: The version numbers of each open-source component in the open-source component knowledge base are semantically processed.

6. The method according to claim 1, characterized in that, The analysis of the target software using software component analysis tools includes: The source code or bill of materials of the target software is analyzed using software component analysis tools.

7. The method according to claim 1, characterized in that, The open-source component knowledge base is constructed by collecting the names, version numbers, vulnerability descriptions, and dependencies of each component in the open-source component platform in real time.

8. An open-source component vulnerability repair device, the device comprising: The software component analysis module is used to analyze the target software using software component analysis tools to obtain component information and dependencies of all open-source components; The component information includes the name and version number of the open-source component; The global influence assessment module constructs a component dependency network graph based on the dependencies of all the open-source components, and obtains the global influence of each open-source component in the component dependency network graph based on the webpage ranking algorithm and the component dependency network graph. The global influence represents a comprehensive measure of the direct and indirect impact of the open-source component on other components in the component dependency network graph. The vulnerability identification module is used to search the open source component knowledge base based on the component information of all open source components to identify at least one open source component with a vulnerability; the open source component knowledge base includes the component information, vulnerability descriptions and dependencies of each open source component in the open source component platform. The component upgrade module is used to sort the at least one open-source component with a vulnerability according to its corresponding global influence, and then perform vulnerability repair operations in sequence according to the sorting results. The vulnerability remediation operation includes: searching the open-source component knowledge base based on the component information of the open-source component with the vulnerability, and obtaining the target open-source component and its dependent components; the target open-source component is the vulnerability-remediated version of the open-source component with the vulnerability. Based on the target open-source component and its dependent components, update the component information and dependencies of the vulnerable open-source component to fix the vulnerabilities of the vulnerable open-source component and its dependent components. The method based on the webpage ranking algorithm and the component dependency network graph obtains the global influence of each open-source component in the component dependency network graph, including: For each open-source component, traverse the component dependency network graph to obtain a first number of open-source components that the open-source component depends on in the component dependency network graph that are different from the open-source component, and a second number of open-source components that the open-source component depends on in the other open-source components. Based on the first quantity and the second quantity, the risk index value of the open source component is obtained by evaluating it according to the webpage ranking algorithm. Based on the first quantity, the second quantity, and the risk index value, the global influence of the open-source component in the component dependency network graph is calculated according to the preset comprehensive risk scoring function RiskScore. The comprehensive risk scoring function RiskScore is expressed by the formula: RiskScore(v) = α * PageRank(v) + β * InDegree(v) + γ * OutDegree(v) + Layer(v), where α, β, and γ are weight coefficients, v is the node representing the open-source component in the component dependency network graph; PageRank(v) is the risk index value of node v; InDegree(v) is the first number of nodes v; OutDegree(v) is the second number of nodes v; and Layer(v) is the shortest path length from node v to the root node of the target software, where the root node of the target software refers to the function that the target software directly depends on.

9. A computer storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-7.

Images