Data processing method, electronic device, storage medium, and computer program product

Abstract

The application discloses a data processing method, an electronic device, a storage medium and a computer program product. The method comprises the following steps: determining one or more upgrade strategies of a first operating system according to security map information of the first operating system and security map information of each of a plurality of second operating systems, wherein the upgrade strategy is used for indicating one or more of the following: upgrading the first operating system to a target operating system in the plurality of second operating systems; upgrading each of one or more components in the first operating system to a corresponding target version component; and recommending the one or more upgrade strategies of the first operating system. Through the application, an evaluation selection mechanism can be provided for operating system upgrade, and the risk that the upgraded operating system cannot meet relevant requirements is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, electronic device, storage medium, and computer program product. Background Technology

[0002] Linux, as an open-source operating system, is widely used in servers, cloud computing, and embedded devices. To fix vulnerabilities in Linux or for security reasons, it is sometimes necessary to upgrade all or part of the components. However, due to the lack of an evaluation and selection mechanism, Linux upgrades are often directly upgraded to the latest version, which may result in the upgraded operating system failing to meet requirements. Summary of the Invention

[0003] To address the related technical problems, embodiments of this application provide a data processing method, an electronic device, a storage medium, and a computer program product.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a data processing method, the method comprising: Based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems, one or more upgrade strategies for the first operating system are determined, wherein the upgrade strategies are used to indicate one or more of the following: upgrading the first operating system to the target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to the corresponding target version of the component; One or more upgrade strategies for the first operating system are recommended.

[0005] In the above scheme, the one or more upgrade strategies recommended for the first operating system include: Recommended upgrade strategies and related information for each of the aforementioned upgrade strategies, wherein the related information includes one or more of the following: The version number of each component; The version number of the target version of each component; The comparison between the security risk indicators of each component and the security risk indicators of the corresponding target version of the component; The comparison between the functionality of each component and the functionality of the corresponding target version of the component; The comparison of known vulnerabilities of each component with known vulnerabilities of the corresponding target version of the component; The status of patching known vulnerabilities for each component; The known vulnerability fix status of the target version of each component; A comparison of the overall security risk indicators of the first operating system and the overall security risk indicators of the target operating system.

[0006] In the above scheme, after recommending one or more upgrade strategies for the first operating system, the method further includes: Receive a first instruction, the first instruction being used to indicate a target upgrade strategy among the one or more upgrade strategies; An upgrade plan is formulated based on the component dependencies in the first security graph information, wherein the first security graph information is the security graph information of the target operating system indicated by the target upgrade strategy; The first operating system is upgraded according to the first component list corresponding to the upgrade plan.

[0007] In the above scheme, when the indicated target operating system is the same major version as the first operating system, the first component list includes one or more of the following: specifying the first target component that needs to be upgraded; the component dependency relationship indicates the components that the first target component depends on; If the indicated target operating system is a different major version from the first operating system, the first component list includes one or more of the following: a second target component that the first operating system needs to upgrade relative to the indicated target operating system; and the component dependency indicates the components that the second target component depends on.

[0008] In the above scheme, before upgrading the first operating system according to the first component list corresponding to the upgrade plan, the method further includes: Determine the security risk indicators of the upgrade plan; Determine if any dependencies of the components in the first component list are missing; Without missing any dependencies of the components in the first component list, the upgrade plan and related information of the upgrade plan are pushed, including the security risk indicators of the upgrade plan. Upgrading the first operating system according to the first component list corresponding to the upgrade plan includes: Upon receiving an instruction confirming the execution of the upgrade plan, the first operating system is upgraded according to the first component list corresponding to the upgrade plan.

[0009] In the above scheme, the security graph information includes security risk indicators for each component in the corresponding operating system. Before determining one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, the method further includes: Determine a first risk indicator for each component in the first operating system, wherein the first risk indicator is used to describe the risk caused by vulnerabilities in the components of the first operating system. Determine a second risk indicator for the first operating system, the second risk indicator being related to one or more of the following: the first activity level of the first operating system in each of one or more communities; the type of object developing each component; The security risk index of each first component in the first operating system is determined based on the first risk index and the second risk index.

[0010] In the above scheme, determining the second risk indicator of the first operating system includes: The first activity level of the first operating system is determined based on one or more of the following: the commit frequency of the first operating system in each community; the average closure time of the response to issues related to the first operating system in each community; the number of maintainers of the first operating system in each community; and the number of times the open-source license of the first operating system has been modified to include restrictive clauses in each community. A second risk indicator for the first operating system is determined based on the first activity level.

[0011] This application also provides a data processing apparatus, including: The first determining unit is configured to determine one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems. The upgrade strategy is configured to indicate one or more of the following: upgrading the first operating system to a target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to a component of the corresponding target version. The first recommendation unit is used to recommend one or more upgrade strategies for the first operating system.

[0012] This application also provides an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor. The processor is used to execute the steps of any of the above-mentioned technical solutions when running the computer program.

[0013] This application also provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above methods.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0015] As can be seen from the above, in this embodiment, based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, one or more upgrade strategies for the first operating system are determined. The upgrade strategy indicates one or more of the following: upgrading the first operating system to a target operating system among the multiple second operating systems; upgrading each of one or more components in the first operating system to a component of the corresponding target version; and recommending one or more upgrade strategies for the first operating system. It is evident that this embodiment does not directly upgrade the operating system to the highest version, but rather formulates an upgrade strategy based on the security graph information of the first operating system and the multiple second operating systems. This upgrade strategy can specify the target operating system and the corresponding target version of the components for the first operating system. In other words, this embodiment uses the security graph information of the first operating system and the multiple second operating systems as the basis for formulating the operating system upgrade strategy, that is, it uses the security graph information as the basis to determine the target operating system and target components, realizing an evaluation and selection mechanism based on the security graph information. This allows for the recommendation of target operating systems or target components based on the security graph information, guiding the user's operating system upgrade process and reducing the risk that the upgraded operating system will not meet relevant requirements. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the data processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating Embodiment 1 provided for application of this application; Figure 3 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0018] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, the term "one or more" in this document is an exemplary expression and can be replaced with any possible expression, such as one or more, at least one, or at least one item, etc.

[0019] It should also be understood that the term "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0020] It should also be understood that the term "correspondence" mentioned in the embodiments of this application may indicate a direct or indirect correspondence between the two, or an association between the two, or a relationship of instruction and being instructed, configuration and being configured, etc.

[0021] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0022] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0023] Before providing a further detailed description of the embodiments of this application, the technologies related to the embodiments of this application will be described: For reasons such as fixing vulnerabilities, maintaining supply security, or improving component performance, it is sometimes necessary to upgrade some or all component packages in a Linux system. For example, in response to the discontinuation of CentOS, many software companies have upgraded and replaced their Linux systems to ensure software supply security.

[0024] Software supply chain security mapping is a crucial technology for ensuring software supply chain security. The security mapping information for a software version is typically released along with the version release and includes three main components: software product information, Software Bill of Materials (SBOM), and security information. The software product information identifies the software name, version, and other details described in the security mapping. The SBOM is a detailed list of all components used by the software, including the name, version number, license information, and dependencies of each component. Security information refers to technical security information present in the component code within the SBOM, such as code vulnerability information.

[0025] Component packages within the same major version of Linux are compatible, allowing you to upgrade existing packages using higher minor version numbers from the same Linux distribution. In this case, you can use Linux package management software for the upgrade; except for kernel component upgrades, system reboots are not required. However, component packages from different major versions or distributions of Linux are incompatible, necessitating a full package replacement. This requires specialized Linux system upgrade and replacement tools to perform a local, cross-version upgrade of all component packages.

[0026] In related technologies, when there are other versions between the current component package version and the highest version, the target version for component upgrades is always the highest version. However, the highest version may introduce security vulnerabilities due to the addition of new features, and it may also have compatibility issues. Furthermore, this approach lacks an evaluation and selection mechanism for the target component version and is not suitable for scenarios involving upgrades across major versions.

[0027] Related technologies propose methods to repair the target operating system to ensure compatibility when migrating and upgrading business systems across different major versions or distributions of operating systems. These technologies also propose methods for upgrading the operating system of local terminals to a domestically developed operating system. In this method, the terminal's underlying closed system automatically downloads an update package for the domestically developed operating system compatible with the local system from the server; then, the terminal machine boots up according to the upgrade package to complete the operating system upgrade. These solutions address scenarios involving cross-version upgrades and replacements of the operating system, typically accomplished using specialized upgrade tools. However, these solutions only emphasize ensuring compatibility between the target operating system and the hardware and original business software, lacking analysis of improvements in system security and functionality before and after the upgrade, lacking an evaluation and selection mechanism for the target operating system version, and are not applicable to scenarios involving upgrades of only components within the original operating system.

[0028] To address at least one of the aforementioned technical problems, this application proposes a data processing method. In this method, based on the security graph information of a first operating system and the security graph information of each of a plurality of second operating systems, one or more upgrade strategies for the first operating system are determined. The upgrade strategy indicates one or more of the following: upgrading the first operating system to a target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to a component of a corresponding target version; and recommending one or more upgrade strategies for the first operating system. It is evident that this application does not directly upgrade the operating system to the highest version, but rather formulates an upgrade strategy based on the security graph information of the first operating system and the plurality of second operating systems. This upgrade strategy can specify the target operating system and the corresponding target version of the components for the first operating system. In other words, this application uses the security graph information of the first operating system and the plurality of second operating systems as the basis for formulating the operating system upgrade strategy, that is, using the security graph information as the basis to determine the target operating system and target components, realizing an evaluation and selection mechanism based on the security graph information. This allows for the recommendation of target operating systems or target components based on the security graph information, guiding the user's operating system upgrade process and reducing the risk that the upgraded operating system will not meet relevant requirements.

[0029] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0030] Please see Figure 1 The data processing method provided in this application includes: Step 101: Based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems, determine one or more upgrade strategies for the first operating system, wherein the upgrade strategy is used to indicate one or more of the following: upgrade the first operating system to the target operating system among the plurality of second operating systems; upgrade each of one or more components in the first operating system to the corresponding target version of the component; For example, the method provided in this application embodiment can be applied to related units, modules, software applications, or devices. The following example uses an application to an upgrade tool, which is deployed on a device connected to the host network of the first operating system to be upgraded (i.e., the original operating system). The upgrade tool remotely manages the upgrade operation of the first operating system via the network. This application embodiment supports batch management of multiple operating systems and / or multiple devices through the upgrade tool.

[0031] For example, in a typical application example of the embodiments of this application, the operating system (such as the first operating system, the second operating system, etc.) can be the Linux operating system. However, the embodiments of this application do not limit the operating system to Linux. The operating system in the embodiments of this application can also be other operating systems.

[0032] For example, the term "upgrade strategy" is an exemplary expression and may be replaced by or cover one or more of the following expressions: upgrade path, upgrade method, upgrade scheme, etc.

[0033] It should be noted that the security graph information in the embodiments of this application can be replaced with or overridden with related information used to characterize components or related information about the operating system, such as a software component list, security graph, etc.

[0034] For example, the security graph information of the first operating system in the embodiments of this application includes one or more of the following: the name of the first operating system; the version of the first operating system; the SBOM of all components of the first operating system; the download address of all components of the first operating system; the identifier of the first operating system; and the security information of the first operating system.

[0035] For example, in addition to the information mentioned above, the security graph information may also include other information, such as information on other software products of the first operating system, such as the minimum storage space or minimum memory required by the operating system, or the hardware models supported by the operating system.

[0036] For example, in the embodiments of this application, the SBOM includes one or more of the following: the name of each component in the first operating system; the version number of the first operating system; the license information of the first operating system; the dependencies between the components in the first operating system; the security risk indicators of each component in the first operating system; the function of each component in the first operating system; the performance of each component in the first operating system; the known vulnerabilities of each component in the first operating system; and a description of the vulnerability remediation status of each component in the first operating system.

[0037] It should be noted that the security graph information of the second operating system can refer to the definition and related description of the security graph information of the first operating system, the bill of materials of the second operating system can refer to the definition and related description of the bill of materials of the first operating system, and the security risk indicators of the second operating system can refer to the definition and related description of the security risk indicators of the first operating system. These will not be elaborated here.

[0038] For example, taking the application of this application embodiment to the upgrade tool as an example, the upgrade tool supports two methods: preset and user-imported security graph information. The upgrade tool maintains security graph information corresponding to multiple operating system versions.

[0039] The security risk indicators in the embodiments of this application are described below: For example, the security risk indicators in this application embodiment include one or more of the following: security risk score; security risk level; security risk type, etc.

[0040] For example, the security risk indicators include a first risk indicator and a second risk indicator; and / or, the security risk indicators are obtained based on the first risk indicator and the second risk indicator. The first risk indicator is also referred to as a vulnerability risk score, and the second risk indicator is also referred to as a supply risk score.

[0041] In practical applications, the security graph information includes security risk indicators for each component in the first operating system. Before determining one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, the method further includes: Determine a first risk indicator for each component in the first operating system, wherein the first risk indicator is used to describe the risk caused by vulnerabilities in the components of the first operating system. Determine a second risk indicator for the first operating system, the second risk indicator being related to one or more of the following: the first activity level of the first operating system in each of one or more communities; the type of object developing each component; The security risk index of each first component in the first operating system is determined based on the first risk index and the second risk index.

[0042] In this embodiment, a preliminary technical risk assessment basis can be established by introducing a first risk indicator. The overall maintainability and sustainability of the first operating system can be analyzed by introducing a second risk indicator. By combining the first and second risk indicators, the security risk indicator of each component can be calculated, thereby more accurately identifying high-risk components. The system can optimize upgrade strategies, improve the overall security and stability of the first operating system, and effectively reduce system failures or performance degradation caused by component vulnerabilities or supply interruptions.

[0043] For example, embodiments of this application support manual triggering or periodic determination of the security risk indicators of each component based on the latest vulnerability database and community dynamic database. Taking the application of this application to the upgrade tool as an example, the upgrade tool supports users to manually trigger or periodically calculate and save the security risk indicators of each component based on the latest vulnerability database and community dynamic database every 2 hours; wherein, the vulnerability database and community dynamic database support updating data in both online and offline ways.

[0044] For example, the second risk metric is used to measure the stability and ongoing maintenance capabilities of the entire first operating system at the supply chain level. The second risk metric considers two aspects: community activity and the type of developers. Higher community activity indicates lower supply risk. This is because higher community activity suggests that the first operating system is more likely to receive timely updates and technical support, thereby reducing the risk of supply disruptions; while the type of developers affects the long-term availability of the first operating system and the reliability of technical support.

[0045] For example, determining the security risk indicator of each first component in the first operating system based on the first risk indicator and the second risk indicator includes: taking the sum of the product of the first risk indicator and the first weight and the product of the second risk indicator and the second weight as the first risk indicator.

[0046] Taking a first weight of 65% and a second weight of 35% as an example, the safety risk index can be determined using the following formula: Safety risk index = First risk index * 65% + Second risk index * 35%.

[0047] The following describes how the embodiments of this application calculate the first risk indicator and the second risk indicator: For example, a first risk indicator is determined for each component in the first operating system: by searching the vulnerability database, if there is a component with an unpatched vulnerability in the SBOM of the first operating system, a first score value is assigned to each vulnerability corresponding to the component with the unpatched vulnerability; for other components that depend on the component with the unpatched vulnerability, a second score value is assigned to each vulnerability corresponding to the component with the unpatched vulnerability; and the sum of all the score values ​​assigned to each component is the first risk indicator of the component.

[0048] For example, taking the vulnerability risk score as the first risk indicator, the total score for the vulnerability risk score is 100. When the vulnerability risk score exceeds 100 points, it is scored as 100 points. Taking the first score as 20 points and the second score as 15 points, by searching the vulnerability database, for components in the SBOM that have unpatched vulnerabilities, each vulnerability receives 20 points. By traversing the dependencies of components in the SBOM, for other components that depend on components with unpatched vulnerabilities, each vulnerability receives 15 points.

[0049] For example, suppose the first operating system only has components A, B and C. Component A has 2 vulnerabilities, while components B and C have no vulnerabilities. For component A, the first risk index is 2 * 10 = 20 points. For components B and C, the first risk index is 2 * 15 = 30 points.

[0050] For example, determining a second risk indicator for the first operating system includes: determining a second risk indicator for the first operating system based on the type of object that develops each of the components.

[0051] For example, taking the supply risk score as the second risk indicator, the total score is 100, and any score exceeding 100 is counted as 100. The supply risk score includes two parts: the basic type score and the community activity risk score.

[0052] For example, the impact of the type of object used to develop each component on the risk to the operating system can be quantified using basic type classification. The types of objects used to develop components can be categorized into community-driven development, commercial company-supported development, and development led by external individual developers. Each of these categories can be further distinguished as domestic or foreign. For instance, a component developed by a domestic community receives a basic type score of 5, a component developed by a foreign community receives a basic type score of 30, a component developed by a domestic company receives a basic type score of 10, and a component developed by a foreign company receives a basic type score of 40. Similarly, a component developed by a domestic individual developer receives a basic type score of 70, and a component developed by a foreign individual developer receives a basic type score of 85.

[0053] In practical applications, determining the second risk indicator of the first operating system includes: The first activity level of the first operating system is determined based on one or more of the following: the commit frequency of the first operating system in each community; the average closure time of the response to issues related to the first operating system in each community; the number of maintainers of the first operating system in each community; and the number of times the open-source license of the first operating system has been modified to include restrictive clauses in each community. A second risk indicator for the first operating system is determined based on the first activity level.

[0054] In this embodiment, a first activity level is calculated by introducing multi-dimensional indicators, and a second risk indicator is determined based on these indicators. This allows for a more accurate assessment of the target operating system's security and supply stability. Using multi-dimensional indicators for comprehensive evaluation avoids misjudgments caused by relying on a single indicator. Based on more accurate security and supply stability assessment results, a scientific basis can be provided for users to choose appropriate upgrade paths, thereby improving the security and reliability of system upgrades.

[0055] For example, the first activity level refers to the activity level of the operating system calculated by comprehensively considering the above-mentioned multiple dimensions (commit frequency, average closure time, number of maintainers, number of license changes, etc.). The higher the first activity level, the better the first operating system represented by the first activity level performs in terms of development, maintenance, and community support, and the lower the supply risk.

[0056] For example, commit frequency refers to the number of times a software community commits code to the first operating system's code repository within a specific time period (such as the past year). A higher commit frequency indicates that the first operating system is being developed actively and updated frequently, which helps to fix vulnerabilities and introduce new features in a timely manner.

[0057] For example, different commit frequencies can correspond to different scores. For instance, if the commit frequency related to the first operating system is 100 times in the past year, the score for the commit frequency of the first operating system is 0 points; if the commit frequency related to the first operating system is 50-100 times in the past year, the score for the commit frequency of the first operating system is 20 points; and if the commit frequency related to the first operating system is less than 100 times in the past year, the score for the commit frequency of the first operating system is 60 points.

[0058] For example, the average closing time of an issue response refers to the average time it takes for an issue related to the first operating system to be resolved from the time it is raised within a specific time period.

[0059] For example, the average closing time of different issue responses can correspond to different scores. For instance, if the average closing time of issue responses in the first operating system is 7 days, then the score corresponding to the average closing time of issue responses in the first operating system is 0 points. If the average closing time of issue responses in the first operating system is 7-30 days, then the score corresponding to the average closing time of issue responses in the first operating system is 30 points. If the average closing time of issue responses in the first operating system is greater than 90 days, then the score corresponding to the average closing time of issue responses in the first operating system is 50 points.

[0060] For example, the number of maintainers refers to the number of developers involved in the development and maintenance of the first operating system.

[0061] For example, different numbers of maintainers can correspond to different scores. For instance, if the number of maintainers of the first operating system is greater than 5, the score corresponding to the number of maintainers of the first operating system is 0 points; if the number of maintainers of the first operating system is 2-5, the score corresponding to the number of maintainers of the first operating system is 30 points; and if the number of maintainers of the first operating system is 1, the score corresponding to the number of maintainers of the first operating system is 50 points.

[0062] For example, the number of times restrictive clauses are added to an open source license, i.e., the change record of restrictive clauses in an open source license, refers to the number of times that additional restrictive clauses are added to the open source license of the first operating system within a specific time period.

[0063] For example, for each additional change to the open source license that adds restrictive clauses, the score corresponding to the number of changes to the open source license that add restrictive clauses increases by 15 points.

[0064] For example, determining the second risk score includes: using the sum of the base type score, the score corresponding to the commit frequency, the score corresponding to the average closure time of issue responses, the score corresponding to the number of maintainers, and the score corresponding to the number of changes to add restrictive clauses to the open source license as the second risk score; or, using the sum of the products of the base type score, the score corresponding to the commit frequency, the score corresponding to the average closure time of issue responses, the score corresponding to the number of maintainers, and the score corresponding to the number of changes to add restrictive clauses to the open source license, and their respective weights as the second risk score.

[0065] For example, the upgrade tool calculates the average of the security risk indicators of each component of each security graph information to obtain the overall security risk indicator of the corresponding security graph information.

[0066] For example, the upgrade tool obtains relevant information about the first operating system to be upgraded. This relevant information includes one or more of the following: the Internet Protocol (IP) address of the host of the first operating system; the host access account of the first operating system, etc. For example, the relevant information of the first operating system can be added to the upgrade tool. For example, embodiments of this application support adding multiple pieces of relevant information about the first operating system in the upgrade tool. Specifically, the relevant developers can manually add or configure the relevant information of the first operating system, or the host of the first operating system can report the relevant information of the first operating system.

[0067] For example, the upgrade tool remotely accesses the first operating system and collects information about the operating system version and all installed component packages. For instance, the upgrade tool can remotely access the first operating system based on the obtained host IP address and host access account.

[0068] For example, the upgrade tool retrieves SBOM information from the security graph information with the same major version number maintained by the upgrade tool based on the version number of the first operating system. For each component in the first operating system, it matches the relevant information (such as functions, known vulnerabilities, etc.) and security risk indicators of that component, and finally summarizes them to obtain the security graph information of the first operating system.

[0069] For example, if one or more components installed on a first operating system cannot be found in the existing security graph information, the upgrade tool queries the latest vulnerability database and community dynamics database to calculate the security risk indicators of the unretrievable components. If no relevant information is found for the unretrievable components, then the component is marked as unupgradeable.

[0070] It is understood that in the embodiments of this application, the security tool can obtain security graph information of multiple operating systems through preset or user import methods, and then maintain the security graph information of multiple operating systems. The security tool can search for the security graph information of an operating system with the same version number as the first operating system and use it as the security graph information of the first operating system. If the security graph information of an operating system with the same version number as the first operating system cannot be found, or if the security graph information cannot find some components in the first operating system, the security risk index of the component can be calculated with the help of data in the database (such as a vulnerability database). If the relevant information of one or more unsearchable components cannot be found, the component is marked as unupgradeable.

[0071] For example, embodiments of this application support users in viewing the security graph information of a first operating system.

[0072] For example, in the embodiments of this application, the multiple second operating systems can be operating systems corresponding to existing security graph information.

[0073] For example, determining one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems includes: the upgrade tool determining the upgrade strategy for the first operating system based on the version of the first operating system and the operating system version corresponding to the existing security graph information. For example, the upgrade strategy can be an upgrade path, and the upgrade tool can list the upgrade paths that the first operating system can implement.

[0074] Step 102: Recommend one or more upgrade strategies for the first operating system.

[0075] For example, recommending one or more upgrade strategies for the first operating system includes one or more of the following: displaying one or more upgrade strategies for the first operating system; listing one or more upgrade strategies for the first operating system; and sending one or more upgrade strategies for the first operating system.

[0076] Understandably, recommending the first operating system upgrade strategy is intended to make it easier for users to refer to the recommended upgrade strategy and thus help them choose the appropriate upgrade strategy.

[0077] In practical applications, the one or more upgrade strategies recommended for the first operating system include: Recommended upgrade strategies and related information for each of the aforementioned upgrade strategies, wherein the related information includes one or more of the following: The version number of each component; The version number of the target version of each component; The comparison between the security risk indicators of each component and the security risk indicators of the corresponding target version of the component; The comparison between the functionality of each component and the functionality of the corresponding target version of the component; The comparison of known vulnerabilities of each component with known vulnerabilities of the corresponding target version of the component; The status of patching known vulnerabilities for each component; The known vulnerability fix status of the target version of each component; A comparison of the overall security risk indicators of the first operating system and the overall security risk indicators of the target operating system.

[0078] In this embodiment of the application, by providing comparative information on component versions, security risks, functions, and vulnerabilities, users can be helped to comprehensively assess the security and functional differences of different upgrade paths. The technical solution of this embodiment of the application can guide users to formulate the optimal upgrade strategy, thereby improving the intelligence level and security assurance capability of the operating system upgrade process.

[0079] For example, the overall security risk index is obtained by averaging the security risk indices of all components in the operating system, and is used to measure the security status of the entire operating system.

[0080] For example, taking the upgrade strategy as the upgrade path, the upgrade path refers to the path from the original operating system (e.g., to the first operating system) to a certain Linux operating system (e.g., the target operating system). This is specifically analyzed using the security graph information corresponding to the target version. Depending on the upgrade scenario, upgrade paths are divided into two categories: those that do not cross major operating system versions and those that cross major operating system versions.

[0081] For example, the target version mentioned above refers to the version of the target operating system.

[0082] It is understood that the target operating system is the target version of the operating system. In determining the upgrade strategy and upgrade plan, the target version can be determined at the version level, that is, determining which version the first operating system will be upgraded to. The selected version is the target version, and the target operating system is the target version of the operating system.

[0083] For example, using the upgrade strategy as the upgrade path, for component upgrade scenarios that do not cross major versions, since the component package corresponding to the target version and the component package already installed on the first operating system have good compatibility, it is possible to support selecting all or some component packages in the first operating system for upgrade. For example, the user can select all or some component packages in the first operating system for upgrade.

[0084] For example, for each upgrade path, the upgrade tool provides the corresponding component package information from the security graph information of the target operating system based on the component packages in the security graph information of the first operating system. It then compares the differences in security risk indicators, functionality, performance, and descriptions of known vulnerabilities and their remediation status between the first operating system and the target component packages (i.e., the corresponding component packages in the security graph information of the target operating system). The upgrade tool sums the changes in security risk indicators for all component packages to be upgraded (including dependent component packages) involved in each upgrade path and recommends the upgrade path with the largest overall reduction in security risk indicators, as shown in the table below.

[0085] Table 1

[0086] It is understandable that the aforementioned original operating system is the first operating system.

[0087] As mentioned earlier, the upgrade strategy information includes a comparison of the security risk indicators of each component with the security risk indicators of the corresponding target version of the component. The security risk indicators of component A and component A'' listed in Table 1 form a comparison; this listed information can be considered a comparison of component A's security risk indicators with the security risk indicators of the target version of component A, and is part of the upgrade strategy information. Similarly, the functions of component A and component A' listed in Table 1 can be considered a comparison of component A's functions with the functions of the target version of component A, and this listed information is also relevant to the upgrade strategy. Likewise, the performance information of component A in Table 1 is also relevant to the upgrade strategy, and will not be elaborated further here.

[0088] For example, for upgrade paths across major versions, since the component packages corresponding to the target version are incompatible with the component packages already installed on the original system, it is only supported to upgrade all component packages in the first operating system to the target version.

[0089] For example, the upgrade tool includes a pre-defined component name mapping table for upgrades across major versions. For each upgrade path, the upgrade tool establishes a new upgrade mapping between the security graph information of the first operating system and the security graph information of the target operating system, based on the component name mapping table. This mapping includes the differences in overall security risk indicators in the security graph information before and after the upgrade, as well as descriptive information such as the magnitude and functionality of security risk indicators before and after the full component upgrade. Similarly, the upgrade tool sums up the changes in security risk indicators of all upgradeable component packages (including dependent component packages) involved in each upgrade path and recommends the upgrade path with the largest reduction in overall security risk indicators, as shown in Table 2 below.

[0090] Table 2

[0091] For example, based on the differences in functionality and performance of components before and after the upgrade, and referring to recommended upgrade strategies, users select a suitable upgrade strategy, i.e., the target upgrade strategy. The upgrade tool can then formulate an upgrade plan under this target upgrade strategy. For instance, users can instruct the upgrade tool to select the target upgrade strategy via commands, as illustrated in the following practical application: In practical applications, after recommending one or more upgrade strategies for the first operating system, the method further includes: Receive a first instruction, the first instruction being used to indicate a target upgrade strategy among the one or more upgrade strategies; An upgrade plan is formulated based on the component dependencies in the first security graph information, wherein the first security graph information is the security graph information of the target operating system indicated by the target upgrade strategy; The first operating system is upgraded according to the first component list corresponding to the upgrade plan.

[0092] In this embodiment, by receiving instructions to confirm the target upgrade strategy and combining the component dependencies in the security graph information to generate an accurate upgrade plan, the integrity and security of the upgrade operation can be ensured, thereby effectively avoiding dependency conflicts and system incompatibility issues, and thus improving the overall efficiency and reliability of Linux system upgrades.

[0093] For example, component dependencies describe the logical dependencies between components during installation and runtime. For instance, if component A requires component B to function properly, then component A is considered to depend on component B.

[0094] For example, an upgrade plan refers to a complete upgrade implementation plan generated based on the target upgrade strategy and component dependencies.

[0095] For example, the first component list is a set of components to be upgraded generated according to the upgrade plan, including the main upgrade component and the components that the main upgrade component depends on.

[0096] In practical applications, when the indicated target operating system is the same major version as the first operating system, the first component list includes one or more of the following: specifying the first target component that needs to be upgraded; the component dependency relationship indicates the components that the first target component depends on; If the indicated target operating system is a different major version from the first operating system, the first component list includes one or more of the following: a second target component that the first operating system needs to upgrade relative to the indicated target operating system; and the component dependency indicates the components that the second target component depends on.

[0097] In this embodiment, by distinguishing between partial upgrades with the same major version and full upgrades with different major versions, a first component list and a second component list are rationally constructed, and component dependencies are considered, thereby improving the accuracy and feasibility of the upgrade path. By differentiating between partial upgrades with the same major version and full upgrades with different major versions, and rationally constructing the first and second component lists, combined with component dependencies, dependency conflicts and installation failures can be effectively avoided. This improves the success rate and stability of system upgrades, and ultimately ensures system security, compatibility, and continuous maintenance capabilities.

[0098] For example, when a user selects a primary target component for upgrade, the system automatically retrieves the dependencies of that primary target component and adds all related components to the primary component list. For instance, in a Linux system, if a user selects to upgrade a graphical interface component, the system automatically identifies the font engine and other dependencies that the graphical interface component depends on and adds them to the primary component list, ensuring that the graphical interface functions correctly after the upgrade.

[0099] For example, the second target component refers to the component in the first operating system that needs to be replaced with the corresponding component in the target operating system in the scenario of cross-version upgrade. For example, the second target component can be a kernel module, system toolchain, basic library, etc.

[0100] For example, in the actual operation of cross-version upgrades, a pre-defined component mapping table can be used to determine which second target components need to be replaced with the corresponding components in the new version.

[0101] For example, the first target component to be upgraded can be a component selected by the user and / or recommended by the system. For instance, the first target component can be a component selected by the user as needing an upgrade.

[0102] For example, developing an upgrade plan based on component dependencies in the first security graph information includes one or more of the following: For upgrade scenarios that do not involve major version changes, after the user selects certain component packages, the upgrade tool automatically merges the selected components and their dependent components into a single upgrade plan by parsing the component dependency relationships in the target version's Security Graph Information (SBOM).

[0103] For upgrade scenarios involving major versions, after the user selects an upgrade path, the upgrade tool automatically merges the components that need to be upgraded and their dependent components into an upgrade plan by parsing the component dependency relationships in the target version's Security Graph Information (SBOM).

[0104] In practical applications, before upgrading the first operating system according to the first component list corresponding to the upgrade plan, the method further includes: Determine the security risk indicators of the upgrade plan; Determine if any dependencies of the components in the first component list are missing; Without missing any dependencies of the components in the first component list, the upgrade plan and related information of the upgrade plan are pushed, including the security risk indicators of the upgrade plan. Upgrading the first operating system according to the first component list corresponding to the upgrade plan includes: Upon receiving an instruction confirming the execution of the upgrade plan, the first operating system is upgraded according to the first component list corresponding to the upgrade plan.

[0105] In this embodiment, by adding steps such as security risk indicator assessment, dependency check, information push, and user confirmation before the upgrade is executed, the feasibility and security of the upgrade operation can be ensured. These measures can mitigate system vulnerabilities caused by missing component dependencies or high-risk components, and further improve the overall efficiency and stability of Linux system upgrades.

[0106] For example, dependencies refer to other components or library files required for a component to function properly.

[0107] For example, the security risk indicator of the upgrade plan can be the average difference between the security risk indicators of all components before and after the upgrade.

[0108] For example, when the upgrade tool parses component dependencies and finds missing dependencies (i.e., when a dependency of a component in the first component list is missing), it will issue an error to remind the user to check the security graph information of the target version and terminate the upgrade process. The upgrade tool supports displaying the differences in version, security risk indicators, and functional descriptions of all components in the upgrade plan. This displayed information can form a component list, and the average difference in security risk indicators of all components before and after the upgrade can be used as the security risk indicator of the upgrade plan, allowing users to formulate their upgrade plans.

[0109] For example, after the user confirms the upgrade plan, i.e., when an instruction to confirm the execution of the upgrade plan is received, the upgrade tool begins to execute the upgrade verification steps according to the first component list corresponding to the upgrade plan.

[0110] For example, upgrading the first operating system according to the first component list corresponding to the upgrade plan includes one or more of the following: For component upgrades that do not cross major versions, the upgrade tool uses overlayFS technology to treat the file system of the first operating system as a read-only layer, and then overlays a read-write layer on top of it. It configures the component download addresses in the security graph information, installs and verifies all component packages in the upgrade plan, and avoids direct modification of the original system file system. For component upgrades across major versions, the upgrade tool creates a simulated root file system in the first operating system, configures the component download addresses in the security graph information in the root file system, installs all component packages in the upgrade plan, and then copies the relevant configuration files from the first operating system for verification.

[0111] For example, after verification, the upgrade tool begins to implement the upgrade, operates the component package management tool in the first operating system, downloads the components in the component list corresponding to the upgrade plan according to the component download address in the configured security graph information, installs the components in the component list corresponding to the upgrade plan, and restarts the operating system as needed.

[0112] For example, after the upgrade is completed, the upgrade tool supports exporting an upgrade report on the implementation of the specific upgrade plan.

[0113] For example, the upgrade report includes one or more of the following: a comparison of the names of all components in the first component list that need to be upgraded before and after the upgrade; a comparison of the versions of all components in the first component list that need to be upgraded before and after the upgrade; a comparison of the security risk indicators of all components in the first component list that need to be upgraded before and after the upgrade; a comparison of the functionality of all components in the first component list that need to be upgraded before and after the upgrade; a comparison of the performance of all components in the first component list that need to be upgraded before and after the upgrade; a comparison of the security vulnerability remediation status of all components in the first component list that need to be upgraded before and after the upgrade; and implementation logs.

[0114] The present application will be further described in detail below with reference to application examples.

[0115] Example 1 Example 1 illustrates the method provided in this application, executed by an upgrade tool. Please refer to [link to example]. Figure 2 , Figure 2 Here is an exemplary flowchart of Example 1. Figure 2 Includes the following steps: S201: Deploy the upgrade tool on a machine that is connected to the host network of the first operating system to be upgraded.

[0116] For example, the upgrade tool remotely manages upgrade operations in the first operating system via a network, supporting batch management.

[0117] For example, the first operating system can be the original Linux system that needs to be upgraded.

[0118] S202: The upgrade tool supports security graph information for multiple Linux operating system versions through both pre-installed and / or user-imported methods.

[0119] For example, the upgrade tool can maintain security graph information for multiple Linux operating system versions.

[0120] For example, these multiple Linux operating system versions are examples of multiple versions of a second operating system.

[0121] S203: Add the IP address and access account information of the host machine where the first operating system to be upgraded is located in the upgrade tool.

[0122] It is understandable that adding the IP address and access account information of the host where the first operating system to be upgraded is located in the upgrade tool can be regarded as managing the first operating system in the upgrade tool.

[0123] For example, embodiments of this application support adding the IP addresses, access accounts, and other information of multiple original system hosts in the upgrade tool.

[0124] S204: The upgrade tool remotely accesses the first operating system and collects information such as the operating system version and fully installed component packages in the first operating system.

[0125] S205: The upgrade tool retrieves SBOM information from the security graph information of the same major version number maintained by itself based on the version number of the first operating system, and obtains the component information and security risk score for each component in the first operating system.

[0126] For example, the upgrade tool can aggregate the component information and security risk scores of each component into the security graph information of the first operating system.

[0127] S206: The upgrade tool recommends an upgrade strategy that can be implemented for the first operating system based on the version of the first operating system and the operating system version corresponding to the existing security graph information.

[0128] S207: Based on the differences in functionality and performance of components before and after the upgrade, and referring to the recommended upgrade strategy, users select the target upgrade strategy and formulate an upgrade plan under the upgrade strategy.

[0129] S208: After the user confirms the upgrade plan, the upgrade tool will begin executing the upgrade verification steps according to the component list corresponding to the upgrade plan.

[0130] It is understandable that the aforementioned upgrade verification refers to the upgrade verification of the first operating system.

[0131] S209: After successful verification, the upgrade tool begins to implement the upgrade of the first operating system.

[0132] For example, when upgrading the operating system, the upgrade tool can operate the component package management tool in the first operating system, download the components in the component list corresponding to the upgrade plan according to the component download address in the configured security graph information, install the components in the component list corresponding to the upgrade plan, and restart the operating system as needed.

[0133] S210: After the upgrade is completed, the upgrade tool supports exporting an upgrade report on the implementation of the upgrade plan.

[0134] For example, the upgrade report includes the name, version, security risk score, functionality, performance, and / or security vulnerability remediation status of all upgraded components in the component list, as well as implementation logs.

[0135] For example, this application embodiment supports querying the upgrade report. Specifically, users can query the upgrade report through the query page.

[0136] As can be seen from the above, the security graph information in this application embodiment can provide accurate and detailed guidance for upgrading components of the Linux operating system. Based on the security graph information of the software supply chain, this application embodiment determines the differences in security graph information between the original version (e.g., the version of the first operating system) and the target version (e.g., the version of the target operating system) in the upgrade tool, providing detailed guidance and explanation for upgrading some or all components in the Linux system. This achieves the goal of conveniently and accurately understanding the improvements in security and functionality of the Linux system before and after the upgrade. When upgrading some or all components in the Linux system, by comparing the security graph information of the original operating system with the security graph information of multiple other operating system versions, the security and functionality improvements of each component upgraded to different versions are listed, guiding and recommending users to choose a specific target version to upgrade to.

[0137] Furthermore, in this embodiment, after the user formulates an upgrade plan based on the upgrade path, the upgrade tool, according to the component dependencies in the SBOM of the security graph information, summarizes the target components to be upgraded and their dependent components to form a component list, calculates the security risk score of the upgrade plan, and verifies the dependency satisfaction in advance. Then, based on the component list, the upgrade tool performs actual installation verification and upgrade implementation on the original system.

[0138] Existing Linux system component upgrade solutions lack mechanisms for evaluating and selecting the security and functionality of the target upgrade version. This application's embodiments compare the security graph information of the original operating system with that of multiple other operating system versions, listing the security and functionality improvements of each component when upgraded to different versions, guiding users to select the appropriate target version based on their actual needs.

[0139] Traditional Linux system upgrade technologies often rely on management software to resolve component dependencies. This approach requires dependency checks during component installation, which introduces a certain lag, and users often struggle to view the list of components involved in the upgrade, resulting in poor operational transparency. This application's embodiment verifies the dependency satisfaction of the component list corresponding to the user-confirmed upgrade plan in advance, preventing dependency missing errors from affecting the original operating system during the upgrade implementation phase. Furthermore, this embodiment allows for self-maintaining of the upgrade component list and supports exporting upgrade reports, significantly improving the transparency of the upgrade process.

[0140] The embodiments of this application propose a solution that determines the differences in security graph information between the original version and the target version in the upgrade tool, providing detailed guidance and instructions for upgrading some or all components in the Linux system, making up for the deficiencies of related upgrade solutions, and can provide an adapted solution for upgrading server operating systems in the cloud computing field.

[0141] Based on the embodiments described above, this application also provides a data processing apparatus, see [link to previous document]. Figure 3 The data processing device includes: The first determining unit 301 is configured to determine one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems. The upgrade strategy is used to indicate one or more of the following: upgrading the first operating system to a target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to a component of the corresponding target version. The first recommendation unit 302 is used to recommend one or more upgrade strategies for the first operating system.

[0142] In one embodiment, the first recommendation unit 302 recommends one or more upgrade strategies for the first operating system, including: Recommended upgrade strategies and related information for each of the aforementioned upgrade strategies, wherein the related information includes one or more of the following: The version number of each component; The version number of the target version of each component; The comparison between the security risk indicators of each component and the security risk indicators of the corresponding target version of the component; The comparison between the functionality of each component and the functionality of the corresponding target version of the component; The comparison of known vulnerabilities of each component with known vulnerabilities of the corresponding target version of the component; The status of patching known vulnerabilities for each component; The known vulnerability fix status of the target version of each component; A comparison of the overall security risk indicators of the first operating system and the overall security risk indicators of the target operating system.

[0143] In one embodiment, the apparatus further includes a first receiving unit, a first designating unit, and a first upgrading unit. After recommending one or more upgrading strategies for the first operating system, the first receiving unit is configured to receive a first instruction, which is configured to indicate a target upgrading strategy among the one or more upgrading strategies. The first formulating unit is used to formulate an upgrade plan based on the component dependencies in the first security graph information, wherein the first security graph information is the security graph information of the target operating system indicated by the target upgrade strategy; The first upgrade unit is used to upgrade the first operating system according to the first component list corresponding to the upgrade plan.

[0144] In one embodiment, when the indicated target operating system is the same major version as the first operating system, the first component list includes one or more of the following: specifying a first target component that needs to be upgraded; the component dependency indicates the components that the first target component depends on; If the indicated target operating system is a different major version from the first operating system, the first component list includes one or more of the following: a second target component that the first operating system needs to upgrade relative to the indicated target operating system; and the component dependency indicates the components that the second target component depends on.

[0145] In one embodiment, the device further includes a second determining unit, a third determining unit, and a first pushing unit. Before upgrading the first operating system according to the first component list corresponding to the upgrade plan, the second determining unit is used to determine the security risk indicators of the upgrade plan. The third determining unit is used to determine whether a dependency of a component in the first component list is missing; Without missing any dependencies of the components in the first component list, the first push unit is used to push the upgrade plan and related information of the upgrade plan, including the security risk indicators of the upgrade plan; The first upgrade unit upgrades the first operating system according to the first component list corresponding to the upgrade plan, including: Upon receiving an instruction confirming the execution of the upgrade plan, the first upgrade unit upgrades the first operating system according to the first component list corresponding to the upgrade plan.

[0146] In one embodiment, the device further includes a fourth determining unit, a fifth determining unit, and a sixth determining unit. The security graph information includes security risk indicators for each component in the corresponding operating system. Before the first determining unit 301 determines one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, the fourth determining unit is used to determine a first risk indicator for each component in the first operating system. The first risk indicator is used to describe the risk caused by vulnerabilities in the components of the first operating system. The fifth determining unit is used to determine a second risk indicator of the first operating system, the second risk indicator being related to one or more of the following: the first activity level of the first operating system in each of one or more communities; the type of object that develops each component; The sixth determining unit determines the security risk index of each first component in the first operating system based on the first risk index and the second risk index.

[0147] In one embodiment, the fifth determining unit determines a second risk indicator of the first operating system, including: The fifth determining unit determines the first activity level of the first operating system based on one or more of the following: the submission frequency of the first operating system in each community; the average closure time of the response to issues related to the first operating system in each community; the number of maintainers of the first operating system in each community; and the number of times restrictive clauses have been added to the open-source license of the first operating system in each community. The fifth determining unit determines the second risk indicator of the first operating system based on the first activity level.

[0148] In practical applications, the first determining unit 301, the first recommending unit 302, the first receiving unit, the first designating unit and the first upgrading unit, the second determining unit, the third determining unit, the first pushing unit, the fourth determining unit, the fifth determining unit and the sixth determining unit can be implemented by the processor in the data processing device, and the first receiving unit can be implemented by the processor in the data processing device in combination with the communication interface.

[0149] It should be noted that the data processing apparatus provided in the above embodiments is only illustrated by the division of the above program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the apparatus can be divided into different program modules to complete all or part of the processing described above. In addition, the data processing apparatus and data processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0150] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, this application also provides an electronic device, see [link to relevant documentation]. Figure 4 The electronic device includes: a first communication interface 1, a first processor 2, and a first memory 3.

[0151] Specifically, the first processor 2 is configured to determine one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems. The upgrade strategy is configured to instruct one or more of the following: upgrade the first operating system to a target operating system among the plurality of second operating systems; upgrade each of one or more components in the first operating system to a component of the corresponding target version. The first processor 2 is also used to recommend one or more upgrade strategies for the first operating system.

[0152] In one embodiment, the first processor 2 recommends one or more upgrade strategies for the first operating system, including: Recommended upgrade strategies and related information for each of the aforementioned upgrade strategies, wherein the related information includes one or more of the following: The version number of each component; The version number of the target version of each component; The comparison between the security risk indicators of each component and the security risk indicators of the corresponding target version of the component; The comparison between the functionality of each component and the functionality of the corresponding target version of the component; The comparison of known vulnerabilities of each component with known vulnerabilities of the corresponding target version of the component; The status of patching known vulnerabilities for each component; The known vulnerability fix status of the target version of each component; A comparison of the overall security risk indicators of the first operating system and the overall security risk indicators of the target operating system.

[0153] In one embodiment, after recommending one or more upgrade strategies for the first operating system, the first communication interface 1 is used to receive a first instruction, which is used to indicate the target upgrade strategy among the one or more upgrade strategies; The first processor 2 is used to formulate an upgrade plan based on the component dependencies in the first security graph information, wherein the first security graph information is the security graph information of the target operating system indicated by the target upgrade strategy. The first processor 2 is also used to upgrade the first operating system according to the first component list corresponding to the upgrade plan.

[0154] In one embodiment, when the indicated target operating system is the same major version as the first operating system, the first component list includes one or more of the following: specifying a first target component that needs to be upgraded; the component dependency indicates the components that the first target component depends on; If the indicated target operating system is a different major version from the first operating system, the first component list includes one or more of the following: a second target component that the first operating system needs to upgrade relative to the indicated target operating system; and the component dependency indicates the components that the second target component depends on.

[0155] In one embodiment, before the first processor 2 upgrades the first operating system according to the first component list corresponding to the upgrade plan, the first processor 2 is further configured to determine the security risk indicators of the upgrade plan; The first processor 2 is further configured to determine whether a dependency of a component in the first component list is missing; Without missing any dependencies of the components in the first component list, the first processor 2 is also used to push the upgrade plan and related information of the upgrade plan, including security risk indicators of the upgrade plan; The first processor 2 upgrades the first operating system according to the first component list corresponding to the upgrade plan, including: Upon receiving an instruction confirming the execution of the upgrade plan, the first processor 2 upgrades the first operating system according to the first component list corresponding to the upgrade plan.

[0156] In one embodiment, the security graph information includes security risk indicators for each component in the corresponding operating system. Before the first processor 2 determines one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, the first processor 2 is further configured to determine a first risk indicator for each component in the first operating system. The first risk indicator is used to describe the risk caused by vulnerabilities in the components of the first operating system. The first processor 2 is further configured to determine a second risk indicator of the first operating system, the second risk indicator being related to one or more of the following: the first activity level of the first operating system in each of one or more communities; the type of object developing each component; The first processor 2 is further configured to determine a security risk indicator for each first component in the first operating system based on the first risk indicator and the second risk indicator.

[0157] In one embodiment, the first processor 2 determines a second risk indicator of the first operating system, including: The first processor 2 determines the first activity level of the first operating system based on one or more of the following: the commit frequency of the first operating system in each community; the average closure time of the response to issues related to the first operating system in each community; the number of maintainers of the first operating system in each community; and the number of times the open-source license of the first operating system has been modified to include restrictive clauses in each community. The first processor 2 determines a second risk indicator of the first operating system based on the first activity level.

[0158] It should be noted that the specific processing procedure of the first communication interface 1 can be understood by referring to the above method.

[0159] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 The general will label all buses as Bus System 4.

[0160] The first memory 3 in this embodiment is used to store various types of data to support operation in the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0161] The methods disclosed in the embodiments of this application can be applied to the first processor 2, or implemented by the first processor 2. The first processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in the first processor 2. The first processor 2 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The first processor 2 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the first memory 3. The first processor 2 reads the information in the first memory 3 and completes the steps of the aforementioned method in combination with its hardware.

[0162] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned methods.

[0163] It is understood that the first memory 3 in this application embodiment can be a volatile memory pool or a non-volatile memory pool, or both. The non-volatile memory pool can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory pool can be a disk storage pool or a magnetic tape storage pool. The volatile memory pool can be a random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The storage pools described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of storage pools.

[0164] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a first memory 3 storing a computer program, which can be executed by a first processor 2 to complete the steps described in the aforementioned method.

[0165] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a first processor 2 to perform the steps described in the foregoing method.

[0166] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The data processing method includes: Based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems, one or more upgrade strategies for the first operating system are determined, wherein the upgrade strategies are used to indicate one or more of the following: upgrading the first operating system to the target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to the corresponding target version of the component; One or more upgrade strategies for the first operating system are recommended.

2. The method according to claim 1, characterized in that, The one or more upgrade strategies recommended for the first operating system include: Recommended upgrade strategies and related information for each of the aforementioned upgrade strategies, wherein the related information includes one or more of the following: The version number of each component; The version number of the target version of each component; The comparison between the security risk indicators of each component and the security risk indicators of the corresponding target version of the component; The comparison between the functionality of each component and the functionality of the corresponding target version of the component; The comparison of known vulnerabilities of each component with known vulnerabilities of the corresponding target version of the component; The status of patching known vulnerabilities for each component; The known vulnerability fix status of the target version of each component; A comparison of the overall security risk indicators of the first operating system and the overall security risk indicators of the target operating system.

3. The method according to claim 1, characterized in that, After recommending one or more upgrade strategies for the first operating system, the method further includes: Receive a first instruction, the first instruction being used to indicate a target upgrade strategy among the one or more upgrade strategies; An upgrade plan is formulated based on the component dependencies in the first security graph information, wherein the first security graph information is the security graph information of the target operating system indicated by the target upgrade strategy; The first operating system is upgraded according to the first component list corresponding to the upgrade plan.

4. The method according to claim 3, characterized in that, If the indicated target operating system is the same major version as the first operating system, the first component list includes one or more of the following: specifying the first target component that needs to be upgraded; the component dependency indicates the components that the first target component depends on. If the indicated target operating system is a different major version from the first operating system, the first component list includes one or more of the following: a second target component that the first operating system needs to upgrade relative to the indicated target operating system; and the component dependency indicates the components that the second target component depends on.

5. The method according to claim 3, characterized in that, Before upgrading the first operating system according to the first component list corresponding to the upgrade plan, the method further includes: Determine the security risk indicators of the upgrade plan; Determine if any dependencies of the components in the first component list are missing; Without missing any dependencies of the components in the first component list, the upgrade plan and related information of the upgrade plan are pushed, including the security risk indicators of the upgrade plan. Upgrading the first operating system according to the first component list corresponding to the upgrade plan includes: Upon receiving an instruction confirming the execution of the upgrade plan, the first operating system is upgraded according to the first component list corresponding to the upgrade plan.

6. The method according to claim 1, characterized in that, The security graph information includes security risk indicators for each component in the corresponding operating system. Before determining one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the multiple second operating systems, the method further includes: Determine a first risk indicator for each component in the first operating system, wherein the first risk indicator is used to describe the risk caused by vulnerabilities in the components of the first operating system. Determine a second risk indicator for the first operating system, the second risk indicator being related to one or more of the following: the first activity level of the first operating system in each of one or more communities; the type of object developing each component; The security risk index of each first component in the first operating system is determined based on the first risk index and the second risk index.

7. The method according to claim 6, characterized in that, The determination of the second risk indicator for the first operating system includes: The first activity level of the first operating system is determined based on one or more of the following: the submission frequency of the first operating system in each community; the average closing time of the response to issues related to the first operating system in each community; The number of maintainers of the first operating system in each community; the number of times the open-source license of the first operating system in each community has been modified to include restrictive clauses; A second risk indicator for the first operating system is determined based on the first activity level.

8. A data processing apparatus, characterized in that, include: The first determining unit is configured to determine one or more upgrade strategies for the first operating system based on the security graph information of the first operating system and the security graph information of each of the plurality of second operating systems. The upgrade strategy is configured to indicate one or more of the following: upgrading the first operating system to a target operating system among the plurality of second operating systems; upgrading each of one or more components in the first operating system to a component of the corresponding target version. The first recommendation unit is used to recommend one or more upgrade strategies for the first operating system.

9. An electronic device, characterized in that, include: The processor and the memory used to store computer programs that can run on the processor. When the processor is used to run the computer program, it performs the steps of the method according to any one of claims 1 to 7.

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

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images