A Linux distribution operating system security vulnerability automatic repairing method

Abstract

The application discloses a Linux distribution operating system security vulnerability automatic repairing method and relates to the technical field of system security, which comprises a CVE database used for recording all historical CVE information related to a distribution product platform, a distribution product software SBOM database used for recording the basic information of all components of a single distribution system and forming component information, a product-component-CVE repairing state recording database used for recording the affected state and repairing state information of a single component about a specific CVE, a CVE crawler module used for grabbing CVE vulnerability disclosure information from domestic and foreign CVE vulnerability disclosure platforms, an automatic investigation module used for performing automatic investigation work, and an automatic repairing module used for implementing automatic repairing on components with CVE vulnerabilities and performing compiling, installation testing and automatic testing on the repaired code.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system security, and more particularly to a Linux distribution operating system security vulnerability automatic repair method. BACKGROUND

[0002] The Linux operating systems commonly seen on the market are basically built based on open source components. However, open source components often have various security vulnerabilities, which cause the released systems to have security risks, and therefore it is necessary to repair and upgrade the open source components with vulnerabilities in a timely manner. However, when repairing and upgrading the vulnerabilities of open source components, there are problems such as a large number of security vulnerabilities, a huge scale of open source components, a very scattered disclosure of security vulnerabilities of open source components, and a delay in the disclosure process.

[0003] The existing patent with the publication number CN114021145A discloses an operating system vulnerability detection method and device, a computing device and a storage medium, wherein the method comprises: whenever a synchronization instruction is triggered, the latest published vulnerability library is obtained; the vulnerability library includes the correspondence between the operating system name and the vulnerability; the vulnerability library corresponds to a specific language type; based on the operating system name of the specific language type included in the latest published vulnerability library, the latest mapping knowledge base is obtained; the mapping knowledge base includes the mapping relationship between the operating system name of the specific language type and the operating system name of the target language type; the target language type is the language type of the operating system to be detected; according to the latest published vulnerability library and the latest mapping knowledge base, the operating system to be detected is subjected to vulnerability detection.

[0004] The above-mentioned invention can improve the detection efficiency of the security vulnerabilities of the distribution, but does not realize the repair of the vulnerabilities. In view of this, the present application provides a Linux distribution operating system security vulnerability automatic repair method. SUMMARY

[0005] In view of the deficiencies of the prior art, the present application aims to provide a Linux distribution operating system security vulnerability automatic repair method, which has a complexity and a manpower investment for managing security vulnerabilities of open source components, improves the efficiency, comprehensiveness and timeliness of vulnerability repair, and thus improves the security of the distribution system.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical solution:

[0007] A Linux distribution operating system security vulnerability automatic repair method, comprising:

[0008] A CVE database for recording all historical CVE information related to the distribution product platform;

[0009] A distribution product software SBOM database for recording the basic information of all components of a single distribution system and forming component information;

[0010] A product-component-CVE repair status record database for recording the affected status and repair status information of a single component with respect to a specific CVE;

[0011] A CVE crawler module for crawling CVE vulnerability disclosure information from domestic and foreign CVE vulnerability disclosure platforms and recording the information to a local CVE database after screening;

[0012] An automatic investigation module for performing automatic investigation work, which includes the affected status of a component by a known CVE and the affected status of a new CVE on all currently recorded distribution systems, and the automatic investigation module is further configured to initiate an automatic repair process to attempt to automatically repair a security vulnerability of a component when the security vulnerability is identified;

[0013] An automatic repair module for implementing automatic repair on a component with a CVE vulnerability, and compiling, installing, and testing the repaired code.

[0014] As a further improvement of the present application, the CVE record entry information includes but is not limited to: CVE-ID, vulnerability name, open source component associated with the vulnerability, version of the open source component at the time of vulnerability disclosure, vulnerability repair status on the open source component, release version of the open source component after the vulnerability is repaired, and other distribution product disclosure and repair status with respect to the CVE.

[0015] As a further improvement of the present application, the component information includes but is not limited to: component name, component version, component open source distribution information, component upstream engineering information, and external other distribution engineering information related to the component, which includes repository address, branch, and corresponding version.

[0016] As a further improvement of the present application, the CVE crawler module continuously monitors the disclosure of external vulnerability disclosure platforms, and when a new CVE is disclosed, the CVE disclosure is screened and recorded in the local CVE database, and the automatic investigation module is triggered to perform investigation and automatic repair.

[0017] As a further improvement of the present application, the security vulnerability automatic repair method includes known vulnerability screening of a component, and the specific steps of the known vulnerability screening include:

[0018] S1: Construct a software inventory database to record component information integrated into the release version system;

[0019] S2: Collect CVE disclosure information through a CVE crawler module, and filter out general vulnerability disclosure data related to the release system version type after comparison with the release system product, to maintain a local general vulnerability disclosure database;

[0020] S3: Construct a release component vulnerability repair status database to record repair information of a specific component about CVE vulnerabilities under the release version;

[0021] S4: Query all CVEs from the local CVE database through the component name;

[0022] S5: Loop to query and compare each queried CVE and the SBOM information of the component, and determine whether the current component version is within the official component affected version range disclosed by the CVE.

[0023] As a further improvement of the present application, the step of known vulnerability screening further comprises:

[0024] S6: If the current component version is within the official component affected version range disclosed by the CVE, it is determined whether there is an upstream release version for the current release version;

[0025] If the current component version is not within the official component affected version range disclosed by the CVE, it is determined whether the current component version is higher than the official repair version;

[0026] S7: Determine the relationship between the current component version and the official repair version;

[0027] If the current component version is not within the official component affected version range disclosed by the CVE, and the current component version is not higher than the official repair version, record the current component affected state by the queried CVE as: not affected, and continue to loop and compare the next queried CVE;

[0028] If the current component version is not within the official component affected version range disclosed by the CVE, but the component version is higher than the official repair version, record the current component affected state by the queried CVE as: repaired, and continue to loop and compare the next queried CVE.

[0029] As a further improvement of the present application, it further comprises:

[0030] S8: Determine whether there is an upstream release version for the current release version:

[0031] If the current component version is within the official component affected version range disclosed by the CVE, and the current distribution exists an upstream distribution, it is determined whether the current component is within the component affected range disclosed by the CVE upstream distribution.

[0032] If the current component version is within the official component affected version range disclosed by the CVE, and the current distribution exists an upstream distribution, it is determined whether the current component is within the component affected range disclosed by the CVE upstream distribution.

[0033] S9: If the current component is within the component affected range disclosed by the CVE upstream distribution, record the current component affected state by the queried CVE as: needs to be repaired, and enter the automated repair process.

[0034] If the current component is not within the component affected range disclosed by the CVE upstream distribution, it is determined whether the current component version is higher than the upstream distribution component repair version.

[0035] As a further improvement of the application, the CVE automatic repair specific steps include:

[0036] A1: When the component is affected by the queried CVE state is repaired, start repairing;

[0037] A2: Improve the local CVE database, if the affected distribution product exists an upstream distribution product, obtain the disclosure information and repair information of the upstream about the CVE, update to the local CVE database, perform affinity sorting, and obtain the repair scheme; wherein the sorting rule is: if the distribution product exists an upstream product, the repair scheme of the upstream product is preferred; in the official and other distribution product repair, the repair scheme with consistent version is preferred; in the official and other distribution product repair scheme, the versions are inconsistent, and the official repair scheme is preferred;

[0038] A3: Determine whether the obtained repair scheme can be upgraded without conflict;

[0039] When trying to introduce the upstream repair, if the local component inherits from the upstream product, and the local component has no customized modification, the component can be upgraded without conflict by the upstream repair;

[0040] A4: If the repair scheme obtained in step A3 can be upgraded without conflict, upgrade the component according to the CVE record;

[0041] If the repair scheme obtained in step A3 cannot be upgraded without conflict, pull the remote repair component source code about the CVE through the repair information recorded by the CVE to repair;

[0042] A5: After the patch file is applied to the source code of the local component, it is determined whether the patch file is successfully applied to the local;

[0043] A6: When the patch file is successfully applied to the local, or after the component is upgraded according to the CVE record, integration verification is performed, and it is determined whether the integration verification is passed;

[0044] A7: When the component upgrade passes the integration verification, the integration process is entered, and the component affected by the CVE is recorded as repaired;

[0045] A8: When the patch file is not successfully applied to the local, or the component upgrade does not pass the integration verification, it is determined whether there is a next repair scheme;

[0046] A9: If there is a next repair scheme, the next repair scheme is continued to be tried in a loop;

[0047] If there is no next repair scheme, manual patch merging or manual repair is entered.

[0048] As a further improvement of the present application, the step A4 further comprises:

[0049] A401: Clone the remote code repository according to the repair information of the CVE record;

[0050] A402: Locate the submitted code related to the CVE repair according to the repair information of the CVE record;

[0051] A403: Export the submitted code related to the CVE repair as a patch file through a version management tool, including: git and svn;

[0052] A404: Apply the patch file to the source code of the local component.

[0053] As a further improvement of the present application, the step of the component performing new vulnerability screening and automatic repair comprises:

[0054] B1: Record the new CVE information in the local CVE database, and cyclically check each release product through the component name in the CVE record;

[0055] B2: Query the product SBOM library according to the component name, and determine whether there is a related component;

[0056] B3: If the SBOM library does not have a related component, the next release product is cyclically checked;

[0057] If the SBOM library has a related component, it is further determined whether the version of the related component of the SBOM library is within the component affected version range disclosed by the CVE.

[0058] B4: If the version of the component related to the SBOM library is between the component affected version range disclosed by the CVE, record the component affected state of the queried CVE as needing repair, and transfer to the automatic repair process;

[0059] If the version of the component related to the SBOM library is not within the component affected version range disclosed by the CVE, further judge whether the component related to the SBOM library is higher than the official repair version;

[0060] B5: If the component related to the SBOM library is higher than the official repair version, record the component affected state of the queried CVE as repaired, and loop to check the next release product;

[0061] If the component related to the SBOM library is not higher than the official repair version, record the component affected state of the queried CVE as not affected, and loop to check the next release product.

[0062] B6: Perform CVE automatic repair.

[0063] The beneficial effects of the present application are:

[0064] By maintaining the SBOM database of all components of the release version and the local database of the CVE, and through multi-party version comparison, the efficiency and accuracy of vulnerability detection are greatly improved; at the same time, through the comparison of the affinity of multiple repair schemes, the non-conflict upgrade and the same source code patch transplantation are adopted to ensure the accuracy of the automatic repair process; in addition, in the automatic repair link, an integrated verification link is introduced, which further improves the reliability of the automatic repair. It can efficiently identify disclosed security vulnerabilities and automatically repair them during the construction of a release system based on open source components; at the same time, it can instantly perceive new CVE disclosure and repair, and instantly apply it to the component to publish updates. The present application can greatly reduce the complexity and manpower investment of managing open source component security vulnerabilities, improve vulnerability repair efficiency, comprehensiveness and timeliness, and thus improve the security of the release system. BRIEF DESCRIPTION OF DRAWINGS

[0065] Fig. 1 Flowchart for component screening CVE;

[0066] Fig. 2 Flowchart for new CVE impact screening;

[0067] Fig. 3 Flowchart for CVE automatic repair;

[0068] Fig. 4 Schematic diagram of system modules for the embodiment. DETAILED DESCRIPTION

[0069] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be described clearly and completely below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the described embodiments of the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the scope of protection of the present application.

[0070] Unless otherwise defined, technical terms or scientific terms used in the present application shall have the common meaning understood by a person of ordinary skill in the art to which the present application belongs. The terms "first", "second" and similar terms used in the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. The terms "include" or "contain" and similar terms mean that the components or objects before the terms encompass the components or objects listed after the terms and their equivalents, and do not exclude other components or objects. The terms "connect" or "connected" and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms "upper", "lower", "left", "right" and the like only indicate relative positional relationships, and when the absolute positions of the described objects are changed, the relative positional relationships can also be changed accordingly.

[0071] In order to keep the following description of the embodiments of the present application clear and simple, the present application omits the detailed description of known functions and known components.

[0072] Reference Figs. 1 to 4As shown, it is a specific embodiment of a Linux distribution operating system security vulnerability automatic repair method of the application, including CVE database, distribution product software SBOM database, product-component-CVE repair state record database, CVE crawler module, automatic investigation module and automatic repair module, the CVE database is used for recording all historical CVE information related to the distribution product platform, the distribution product software SBOM database is used for recording the basic information of all components of a single distribution system, the product-component-CVE repair state record database is used for recording the affected state and repair state information of a single component about a certain specific CVE, the CVE crawler module is used for crawling CVE vulnerability disclosure information from domestic and foreign CVE vulnerability disclosure platforms, and recording to the local CVE database after screening, the automatic investigation module is used for executing two types of automatic investigation work, which includes the influence of components on known CVE and the influence of new CVE on all currently recorded distribution systems, the automatic investigation module is also used for triggering the automatic repair process when identifying that the component has a security vulnerability, trying to automatically repair the security vulnerability of the component, the automatic repair module is used for implementing automatic repair on the component with CVE vulnerability, and compiling, installing testing, automatic testing on the repaired code, further ensuring the reliability of automatic repair.

[0073] The security vulnerability automatic repair method includes known vulnerability screening of components, and the specific steps of known vulnerability screening include:

[0074] S1: taking the distribution system product as a unit, a software bill of materials database, namely SBOM library, is constructed for each product, wherein each entry records a component information integrated into the distribution, and the component information includes: component name, component version, component open source release information, component upstream engineering information and external other distribution engineering information related to the component, wherein the component open source release information includes: component open source release repository address, component open source release branch, component open source release corresponding version, the component upstream engineering information includes: upstream engineering repository address, upstream engineering branch, upstream engineering corresponding version, and the external other distribution engineering information related to the component includes: external other distribution engineering repository address, external other distribution engineering branch, external other distribution engineering corresponding version.

[0075] S2: Collecting domestic and foreign general vulnerability disclosure information, i.e., CVE disclosure information, through a crawler technology, and screening general vulnerability disclosure data related to the type of the distribution system software by comparing with the distribution system product, to maintain a local general vulnerability disclosure database, i.e., a local CVE database, wherein the CVE entry information in the local CVE database includes: CVE-ID, vulnerability name, open source component associated with the vulnerability, risk level, version of the open source component at the time of vulnerability disclosure, repair of the vulnerability on the open source component, release version of the open source component after repairing the vulnerability, component version disclosed in the upstream distribution at the time of vulnerability disclosure, repair of the corresponding component in the upstream distribution, release version of the component in the upstream distribution after repairing the vulnerability.

[0076] S3: Constructing a distribution component vulnerability repair status database, and recording repair information of a specific component under a distribution about a CVE vulnerability in each entry, wherein the repair information of the CVE vulnerability includes: component name, component version, distribution name, CVE-ID, repair status, and released component version after repair.

[0077] S4: Querying all CVEs from the local CVE database through the component name.

[0078] S5: Comparing and judging whether the current component version is within the range of the official component affected versions disclosed by the CVE by circularly querying each queried CVE and SBOM information of the component.

[0079] S6: If the current component version is within the range of the official component affected versions disclosed by the CVE, judging whether the current distribution has an upstream distribution.

[0080] If the current component version is not within the range of the official component affected versions disclosed by the CVE, judging whether the current component version is higher than the official repair version.

[0081] S7: If the current component version is not within the range of the official component affected versions disclosed by the CVE, and the current component version is not higher than the official repair version, recording the current component affected state by the queried CVE as: not affected, and continuing to compare the next queried CVE.

[0082] S8: If the current component version is not within the range of the official component affected versions disclosed by the CVE, but the component version is higher than the official repair version, recording the current component affected state by the queried CVE as: repaired, and continuing to compare the next queried CVE.

[0083] S9: If the current component version is within the range of the CVE-disclosed official component affected version, but there is no upstream release for the current release, record the current component affected status by the queried CVE as: needs to be repaired, and transfer to the automated repair process.

[0084] S10: If the current component version is within the range of the CVE-disclosed official component affected version, and there is an upstream release for the current release, determine whether the current component is within the range of the CVE-disclosed component affected version of the upstream release.

[0085] S11: If the current component is within the range of the CVE-disclosed component affected version of the upstream release, record the current component affected status by the queried CVE as: needs to be repaired, and transfer to the automated repair process.

[0086] S12: If the current component is not within the range of the CVE-disclosed component affected version of the upstream release, determine whether the current component version is higher than the upstream release component repair version.

[0087] S13: If the current component version is higher than the upstream release component repair version, record the current component affected status by the queried CVE as: repaired, and continue to loop and compare the next queried CVE.

[0088] If the current component version is not higher than the upstream release component repair version, record the current component affected status by the queried CVE as: not affected, and continue to loop and compare the next queried CVE.

[0089] The specific steps of implementing CVE automated repair include:

[0090] A1: When the component affected status by the queried CVE is needs to be repaired, start repairing;

[0091] A2: Collect and organize information about the CVE from multiple domestic and foreign CVE disclosure platforms through a crawler, perfect the local CVE database, if there is an upstream release product for the affected release product, obtain the disclosure information and repair information about the CVE from the upstream, update to the local CVE database, perform affinity sorting, and obtain the repair scheme; wherein the sorting rule is: if there is an upstream product for the release product, preferentially adopt the repair scheme of the upstream product; among the official and other release product repairs, preferentially select the repair scheme with consistent versions; among the official and other release product repair schemes, the versions are inconsistent, preferentially select the official repair scheme;

[0092] A3: Determine whether the obtained repair scheme can be upgraded without conflict; when trying to introduce an upstream repair, if the local component inherits from the upstream product and the local component has no customized modification, the component can be upgraded without conflict through the upstream repair. In this case, the local component can be directly replaced by the repaired component version of the upstream to complete the repair.

[0093] A4: If the repair scheme obtained in step A3 can be upgraded without conflict, upgrade the component according to the CVE record;

[0094] If the repair scheme obtained in step A3 cannot be upgraded without conflict, pull the repair component source code about the CVE from the remote end through the repair information of the CVE record to repair;

[0095] The specific repair steps include:

[0096] A401: Clone the remote code repository according to the repair information of the CVE record;

[0097] A402: Locate the submitted code related to the CVE repair according to the repair information of the CVE record;

[0098] A403: Export the submitted code related to the CVE repair as a patch file through a version management tool, including: git and svn;

[0099] A404: Apply the patch file to the source code of the local component;

[0100] A5: After the patch file is applied to the source code of the local component, determine whether the patch file is successfully applied to the local;

[0101] A6: When the patch file is successfully applied to the local, or after the component is upgraded according to the CVE record, perform integration verification and determine whether the integration verification is passed, including: compilation, automatic testing, and installation testing;

[0102] A7: When the component upgrade passes the integration verification, enter the integration process, and record the state of the component affected by the CVE as repaired;

[0103] A8: When the patch file is not successfully applied to the local, or the component upgrade does not pass the integration verification, determine whether there is a next repair scheme;

[0104] A9: If there is a next repair scheme, continue to try the next repair scheme;

[0105] If there is no next repair scheme, enter manual patch merging or manual repair;

[0106] Embodiment 2

[0107] Based on the same inventive concept as Example 1, this embodiment introduces a Linux distribution operating system security vulnerability automatic repair method, and the specific implementation steps include:

[0108] The steps of the component performing new vulnerability screening and automatic repair include:

[0109] B1: Record the new CVE information in the local CVE database, and loop to check each distribution product through the component name in the CVE record;

[0110] B2: Query the product SBOM library according to the component name, and determine whether there is a related component;

[0111] B3: If the SBOM library does not have a related component, loop to check the next distribution product;

[0112] If the SBOM library has a related component, further determine whether the SBOM library related component version is between the CVE disclosed component affected version range;

[0113] B4: If the SBOM library related component version is between the CVE disclosed component affected version range, record the component affected state by the queried CVE as needing repair, and transfer to the automatic repair process;

[0114] If the SBOM library related component version is not within the CVE disclosed component affected version range, further determine whether the SBOM library related component is higher than the official repair version;

[0115] B5: If the SBOM library related component is higher than the official repair version, record the component affected state by the queried CVE as repaired, and loop to check the next distribution product;

[0116] If the SBOM library related component is not higher than the official repair version, record the component affected state by the queried CVE as not affected, and loop to check the next distribution product.

[0117] B6: Perform CVE automatic repair

[0118] The specific steps of implementing CVE automatic repair are the same as the CVE automatic repair steps described in Example 1 above, and will not be repeated here.

[0119] The application greatly improves the efficiency and accuracy of vulnerability detection by maintaining the SBOM database of all components of the distribution version, the CVE local database, and through multi-party version comparison; at the same time, through the comparison of the affinity of multiple repair schemes, the non-conflict upgrade and the homologous code patch transplantation are adopted to ensure the accuracy of the automatic repair process; in addition, in the automatic repair link, an integrated verification link is introduced to further improve the reliability of automatic repair. It can efficiently identify disclosed security vulnerabilities and automatically repair during the construction of a distribution system based on open source components; at the same time, it can perceive new CVE disclosure and repair in time and apply it to the component immediately. The application can greatly reduce the complexity and manpower investment of managing open source component security vulnerabilities, improve vulnerability repair efficiency, comprehensiveness and timeliness, and thus improve the security of the distribution system.

[0120] In addition, although exemplary embodiments have been described in the present application, the scope thereof includes any and all embodiments having equivalent elements, modifications, omissions, combinations (for example, solutions cross various embodiments), adaptations or alterations based on the present application. The elements in the claims will be interpreted broadly based on the language employed in the claims and not limited to the examples described in the specification or during the implementation of the present application, which examples will be interpreted as non-exclusive. Therefore, the specification and examples are intended to be considered only as examples, and the true scope and spirit are indicated by the entire scope of the following claims and their equivalents.

[0121] The above description is intended to be illustrative and not restrictive. For example, the above-described examples (or one or more aspects thereof) can be used in combination with each other. Other embodiments can be used as would be apparent to one of ordinary skill in the art upon reading the above description. Additionally, in the above detailed description, various features can be grouped together in one or more embodiments for simplicity. This should not be interpreted as a requirement that the features be grouped together in any of the claims. Rather, the subject matter of the application encompasses any combination of features or alternatives. The following claims, as well as the full scope of equivalents, are intended to cover any and all such combinations and alternatives.

[0122] The above embodiments are only exemplary embodiments of the present application, and are not intended to limit the present application, and the protection scope of the present application is defined by the claims. Those skilled in the art can make various modifications or equivalent replacements to the present application within the spirit and protection scope of the present application, and such modifications or equivalent replacements should also be considered to fall within the protection scope of the present application.

Claims

1. A Linux distribution operating system security vulnerability automated fixing method, characterized in that, Comprise: A CVE database for recording all historical CVE information related to the release product platform; A release product software SBOM database for recording the basic information of all components of a single release system and forming component information; A product-component-CVE repair status record database for recording the affected state and repair state information of a single component with respect to a specific CVE; A CVE crawler module for crawling CVE disclosure information from domestic and foreign CVE disclosure platforms and recording it in the local CVE database after screening; An automated investigation module for performing automated investigation work, including the impact of components on known CVEs and the impact of new CVEs on all currently recorded release systems. The automated investigation module is also used to initiate an automated repair process when a security vulnerability is identified in a component to attempt to automatically repair the security vulnerability of the component; An automated repair module for implementing automated repair of components with CVE vulnerabilities, and compiling, installing, and testing or automatically testing the repaired code; The security vulnerability automated repair method comprises known vulnerability screening of components, and the specific steps of known vulnerability screening comprise: S1: Constructing a software inventory database to record component information integrated into the release version system; S2: Collecting CVE disclosure information through the CVE crawler module, and screening out general vulnerability disclosure data related to the release system version type after comparing with the release system product to maintain a local general vulnerability disclosure database; S3: Constructing a release component vulnerability repair status database to record repair information of specific components with respect to CVE vulnerabilities under the release; S4: Querying all CVEs from the local CVE database through the component name; S5: Looping to query and compare each queried CVE and component SBOM information, and determining whether the current component version is within the official component affected version range disclosed by the CVE; The steps of known vulnerability screening further comprise: S6: If the current component version is within the official component affected version range disclosed by the CVE, determine whether there is an upstream release version; If the current component version is not within the official component affected version range disclosed by the CVE, determine whether the current component version is higher than the official repair version; S7: Determine the relationship between the current component version and the official repair version; If the current component version is not within the official component affected version range disclosed by the CVE, and the current component version is not higher than the official repair version, record the current component affected state of the queried CVE as: not affected, and continue to loop and compare the next queried CVE; If the current component version is not within the official component affected version range disclosed by CVE, but the component version is higher than the official repair version, record the current component affected by the queried CVE as: repaired, and continue to loop the next queried CVE; Also includes: S8: Determine whether the current release exists an upstream release: If the current component version is within the official component affected version range disclosed by CVE, but the current release does not exist an upstream release, record the current component affected by the queried CVE as: need to repair, and enter the automatic repair process; If the current component version is within the official component affected version range disclosed by CVE, and the current release exists an upstream release, determine whether the current component is within the component affected range disclosed by the CVE upstream release; S9: If the current component is within the component affected range disclosed by the CVE upstream release, record the current component affected by the queried CVE as: need to repair, and enter the automatic repair process; If the current component is not within the component affected range disclosed by the CVE upstream release, determine whether the current component version is higher than the upstream release component repair version.

2. The method for automatically repairing security holes of a Linux distribution operating system according to claim 1, characterized in that: The CVE record entry information includes but is not limited to: CVE-ID, vulnerability name, open source component associated with vulnerability, open source component version at the time of vulnerability disclosure, vulnerability repair on open source component, release version or other release product about the CVE disclosure and repair.

3. The method for automatically repairing security holes of a Linux distribution operating system according to claim 2, characterized in that: The component information includes but is not limited to: component name, component version, component open source release information, component upstream engineering information and external other release engineering information related to the component, the external other release engineering information includes repository address, branch or corresponding version.

4. The method for automatically repairing security holes of a Linux distribution operating system according to claim 3, characterized in that: The CVE crawler module continuously monitors the disclosure of external vulnerability disclosure platform, when a new CVE is disclosed, filters the CVE disclosure into the local CVE database, and at the same time triggers the automatic investigation module to investigate and automatically repair.

5. The method for automatically repairing security holes of a Linux distribution operating system according to claim 4, characterized in that: The specific steps of the CVE automatic repair include: A1: When the component affected by the queried CVE is in the state of needing repair, start repairing; A2: Perfect the local CVE database, if the affected release product exists an upstream release product, obtain the disclosure information and repair information of the upstream about the CVE, update to the local CVE database, perform affinity sorting, and obtain the repair scheme; wherein the sorting rule is: if the release product exists an upstream product, preferentially adopt the repair scheme of the upstream product; in the official and other release product repair, preferentially select the repair scheme with consistent version; in the official and other release product repair scheme, the versions are inconsistent, preferentially select the official repair scheme; A3: Determine whether the obtained repair scheme can be upgraded without conflict; If the local component inherits from the upstream product, and the local component has no customized modification, the component can be upgraded without conflict through the upstream repair; A4: If the repair scheme obtained in step A3 can be upgraded without conflict, upgrade the component according to the CVE record; If the repair scheme obtained in step A3 cannot be upgraded without conflict, the repair information recorded by the CVE is used to pull the remote repair component source code for the CVE, and the repair is performed; A5: After the patch file is applied to the local component source code, it is determined whether the patch file is successfully applied to the local; A6: When the patch file is successfully applied to the local, or after the component upgrade according to the CVE record, integration verification is performed, and it is determined whether the integration verification is passed; A7: When the component upgrade passes the integration verification, the integration process is entered, and the component affected by the CVE is recorded as repaired; A8: If the patch file is not successfully applied to the local, or the component upgrade does not pass the integration verification, it is determined whether there is a next repair scheme; A9: If there is a next repair scheme, the next repair scheme is tried in a loop; If there is no next repair scheme, manual patch merging or manual repair is entered.

6. The method for automatically repairing security holes of a Linux distribution operating system according to claim 5, wherein: The step A4 further includes: A401: Clone the remote code repository according to the repair information recorded by the CVE; A402: Locate the submitted code related to the CVE repair according to the repair information recorded by the CVE; A403: Export the submitted code related to the CVE repair to a patch file through a version management tool, including git and svn; A404: Apply the patch file to the source code of the local component.

7. The method for automatically repairing security holes of a Linux distribution operating system according to claim 6, wherein: The steps of the component performing new vulnerability screening and automatic repair include: B1: Record the new CVE information in the local CVE database, and loop to check each release product through the component name in the CVE record; B2: Query the product SBOM library according to the component name, and determine whether there is a related component; B3: If the SBOM library does not have a related component, the next release product is checked in a loop; If the SBOM library has a related component, it is further determined whether the SBOM library related component version is within the CVE disclosed component affected version range; B4: If the SBOM library related component version is within the CVE disclosed component affected version range, record that the component is affected by the queried CVE and needs to be repaired, and transfer to the automatic repair process; If the SBOM library related component version is not within the CVE disclosed component affected version range, it is further determined whether the SBOM library related component is higher than the official repair version; B5: If the SBOM library related component is higher than the official repair version, record that the component is affected by the queried CVE and is repaired, and loop to check the next release product; If the SBOM library related component is not higher than the official repair version, record that the component is not affected by the queried CVE, and loop to check the next release product; B6: Perform CVE automatic repair.

Images