Open source component vulnerability upgrade compatibility analysis method and electronic equipment

Abstract

The invention provides an open source component vulnerability upgrade compatibility analysis method and electronic equipment, and belongs to the technical field of upgrade compatibility analysis. According to the method, automatic pre-upgrade verification is carried out on the vulnerability component with the vulnerability in the open source component called by the project file, and the upgrade compatibility information of the vulnerability component can be obtained. And integrating the upgrading compatibility information of each vulnerability component corresponding to different project files to construct a knowledge base of the large model, and the knowledge base comprises a component name corresponding to each vulnerability component, a version number before upgrading, a version number after upgrading, an upgrading compatibility result, a calling mode, a calling code snippet and a repair code sample. Therefore, the large model can perform upgrade compatibility analysis on the vulnerability components with vulnerabilities in the open source components called by the to-be-tested project file depending on the knowledge base so as to obtain upgrade compatibility results corresponding to the vulnerability components. Through a large model, the accuracy and comprehensiveness of compatibility analysis can be ensured, and meanwhile, the upgrading efficiency can be effectively improved.

Description

Technical Field

[0001] The present application relates to the technical field of upgrade compatibility analysis, and in particular to an open source component vulnerability upgrade compatibility analysis method and electronic device. Background Art

[0002] As open source components become a global trend, upgrades to open source components are inevitable. Since upgrading frameworks and components often leads to compatibility and security issues, whether there are compatibility issues between versions of open source components has become an issue that needs to be addressed urgently.

[0003] Currently, SCA (Software Composition Analysis) tools can identify open source component vulnerabilities in projects. Most of their repair suggestions are to recommend upgraded versions. However, they lack the ability to judge the compatibility between the upgraded version and the current version. Or they can only judge compatibility based on the difference in version numbers (such as whether it spans major version 1.0.1, if it is 2.0.1, it spans major versions). However, there is no inevitability for component upgrades across major versions to be incompatible.

[0004] In the absence of definite compatibility analysis results, in order to ensure normal and stable functions after the upgrade, development and testing personnel still need to invest extra time and energy in preliminary research and analysis and post-upgrade testing and verification. The repair efficiency is low and the upgrade resistance is large. Summary of the invention

[0005] The main purpose of the embodiment of the present application is to propose an open source component vulnerability upgrade compatibility analysis method and electronic device. It aims to obtain the upgrade compatibility information of each vulnerable component by automatically pre-upgrade verification of vulnerable components with vulnerabilities in open source components, and then integrate and construct a knowledge base of a large model, so that the large model can perform upgrade compatibility analysis on vulnerable components based on the knowledge base, which can ensure the accuracy and comprehensiveness of the upgrade compatibility analysis results and effectively improve the upgrade efficiency.

[0006] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application proposes a method for compatibility analysis of open source component vulnerability upgrades, the method comprising:

[0007] Obtain the vulnerable components in the open source components called by the project files;

[0008] Performing automated pre-upgrade verification on the vulnerable component to obtain upgrade compatibility information of the vulnerable component;

[0009] Integrate the upgrade compatibility information of each vulnerability component corresponding to different project files, and construct a knowledge base of a large model, which includes the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method, calling code snippet and repair code sample corresponding to each vulnerability component;

[0010] The large model is used to perform upgrade compatibility analysis on the vulnerable components with vulnerabilities in the open source components called by the project file to be tested, and obtain upgrade compatibility results corresponding to each vulnerable component.

[0011] In one embodiment of the present application, the open source components called by the project file for obtaining the vulnerability components include:

[0012] Performing open source component analysis on the project file using a software component analysis tool to obtain a number of open source components called by the project file;

[0013] Each of the open source components is scanned by the software component analysis tool to obtain vulnerable components with vulnerabilities.

[0014] In one embodiment of the present application, the performing automated pre-upgrade verification on the vulnerable component to obtain upgrade compatibility information of the vulnerable component includes:

[0015] Scanning source code of the project files to extract component dependency chains;

[0016] According to the component dependency chain, determine the introduction method of each vulnerable component;

[0017] According to the introduction method of the vulnerability component, the corresponding vulnerability component is upgraded;

[0018] After upgrading each of the vulnerable components, redeploying the project based on the project file;

[0019] If there are any abnormalities in the deployment, the upgrade compatibility of each vulnerable component is determined by rolling back the upgraded and fixed vulnerable components one by one, redeploying the project, and checking whether the deployment is abnormal.

[0020] If there is no abnormality in the deployment, the deployed project is tested through the automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerable component.

[0021] In one embodiment of the present application, determining the upgrade method adopted by each of the vulnerability components according to the introduction method of the vulnerability components includes:

[0022] If the vulnerability component is introduced in a direct manner, the version number of the vulnerability component contained in the configuration file corresponding to the project file is modified to a repair version number, so as to upgrade and repair the vulnerability component;

[0023] If the vulnerable component is introduced by indirect dependency, the parent component of the vulnerable component is obtained according to the component dependency chain;

[0024] Get the current version number of the parent component, and find the latest version number of the parent component under the current major version number;

[0025] Determine whether the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the fixed version number of the vulnerable component;

[0026] If the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the repair version number, then the current version number of the parent component is upgraded to the latest version number to upgrade and repair the vulnerable component;

[0027] If the version number of the vulnerable component referenced by the parent component under the latest version number is smaller than the repair version number, a new declaration introducing the component name of the vulnerable component and the corresponding repair version number is added to the configuration file corresponding to the project file to upgrade and repair the vulnerable component.

[0028] In one embodiment of the present application, the upgrade compatibility results of each vulnerability component are determined by rolling back the upgraded and fixed vulnerability components one by one, then redeploying the project and detecting whether the deployment is abnormal. The results include:

[0029] Obtain all the vulnerability components that have been upgraded and fixed, and build a vulnerability component set;

[0030] Randomly select a target vulnerable component from the vulnerable component set, and return the target vulnerable component to its original state before the upgrade;

[0031] After returning the target vulnerability component to its original state before the upgrade, redeploy the project based on the project file, and detect whether the deployment is abnormal;

[0032] If there is no abnormality in the deployment, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and the other vulnerability components in the vulnerability component set except the target vulnerability component are compatible with the upgrade;

[0033] If there is an exception in the deployment, determine whether the error message of the current exception is consistent with the error message of the first exception, wherein the first exception is an exception that occurs when the project is redeployed based on the project file after each of the vulnerability components is upgraded;

[0034] If the error message of the current exception is consistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is compatible with the upgrade, but there are other vulnerability components in the vulnerability component set that are not compatible with the upgrade;

[0035] After the target vulnerability component is upgraded and repaired again, the target vulnerability component is excluded from the vulnerability component set to update the vulnerability component set;

[0036] Returning to the step of arbitrarily selecting a target vulnerability component from the set of vulnerability components and returning the target vulnerability component to its original state before the upgrade;

[0037] If the error message of the current exception is inconsistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and there are other vulnerability components in the vulnerability component set that are incompatible with the upgrade;

[0038] Excluding the target vulnerability component from the vulnerability component set to update the vulnerability component set;

[0039] Return to the step of arbitrarily selecting a target vulnerability component from the component set and returning the target vulnerability component to its original state before the upgrade.

[0040] In one embodiment of the present application, if there is an abnormality in the deployment, the method further includes:

[0041] Count the incompatibility possibilities of each upgraded and fixed vulnerability component;

[0042] The upgraded and repaired vulnerability components are rolled back one by one in the order of the incompatibility possibility from greatest to least, and then the project is redeployed to detect whether the deployment is abnormal to determine the upgrade compatibility result of each vulnerability component.

[0043] In one embodiment of the present application, the deployed project is tested by the automated regression test cases corresponding to the project file to determine the upgrade compatibility results of each vulnerable component, including:

[0044] Testing the redeployed project using automated regression test cases corresponding to the project files;

[0045] If the automated regression test case passes, it is determined that each of the vulnerability components is upgrade compatible;

[0046] If the automated regression test case fails, the upgrade compatibility results of each vulnerability component are determined by rolling back the upgraded and fixed vulnerability components one by one and then retesting them using the automated regression test case.

[0047] In one embodiment of the present application, if the automated regression test case fails the test, the method further includes:

[0048] Count the incompatibility possibilities of each upgraded and fixed vulnerability component;

[0049] The upgraded and repaired vulnerability components are rolled back one by one in the order of the incompatibility possibility from greatest to least, and then retested using the automated regression test case to determine the upgrade compatibility result of each vulnerability component.

[0050] In one embodiment of the present application, when the automated pre-upgrade verification of the vulnerability component determines that the upgrade compatibility result of the vulnerability component is upgrade incompatible, a repair code sample is also generated;

[0051] Correspondingly, when the upgrade compatibility result of the vulnerable component output by the large model is upgrade incompatibility, the large model also outputs a corresponding repair code sample.

[0052] To achieve the above-mentioned purpose, the second aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the method described in any embodiment of the present application when executing the computer program.

[0053] In the technical solution provided in one embodiment of the present application, an automated pre-upgrade verification is performed on the vulnerability components with vulnerabilities in the open source components called by the project files, and the upgrade compatibility information of the vulnerability components can be obtained. Then, by integrating the upgrade compatibility information of each vulnerability component corresponding to different project files, a knowledge base of a large model can be constructed, and the knowledge base includes the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method, calling code snippet and repair code sample corresponding to each vulnerability component. Thereby, the large model can rely on the knowledge base to perform upgrade compatibility analysis on the vulnerability components with vulnerabilities in the open source components called by the project file to be tested, so as to obtain the upgrade compatibility results corresponding to each vulnerability component. That is, the large model performs compatibility analysis based on the knowledge base, which can ensure the accuracy and comprehensiveness of the component upgrade compatibility analysis results, and can effectively improve the upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 It is a flow chart of an open source component vulnerability upgrade compatibility analysis method provided by an embodiment of the present application;

[0055] Figure 2 It is a flowchart of the steps of obtaining a vulnerability component having a vulnerability in an open source component called by a project file provided by an embodiment of the present application;

[0056] Figure 3 It is a flowchart of the steps of performing automated pre-upgrade verification on a vulnerable component to obtain upgrade compatibility information of the vulnerable component, provided by an embodiment of the present application;

[0057] Figure 4It is a flowchart of the steps of upgrading the corresponding vulnerability component according to the introduction method of the vulnerability component provided by an embodiment of the present application;

[0058] Figure 5 It is a flowchart provided by an embodiment of the present application for determining the upgrade compatibility result of each vulnerability component by rolling back the upgraded and repaired vulnerability components one by one, then redeploying the project and detecting whether the deployment is abnormal;

[0059] Figure 6 It is a flowchart of steps performed when a project is redeployed after each vulnerable component is upgraded and an exception occurs in the deployment, provided by an embodiment of the present application;

[0060] Figure 7 A flowchart of the steps of testing a deployed project through an automated regression test case corresponding to a project file to determine the upgrade compatibility results of each vulnerability component provided by an embodiment of the present application;

[0061] Figure 8 It is a flowchart provided by an embodiment of the present application for determining the upgrade compatibility results of each vulnerability component by rolling back the upgraded and repaired vulnerability components one by one and then retesting them using automated regression test cases;

[0062] Fig. 9 It is a flowchart of steps performed after each vulnerability component is upgraded and the project is successfully redeployed, but the use case test fails, provided by an embodiment of the present application;

[0063] Fig.10 It is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0064] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0065] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0066] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0067] Open source components are widely used in the software development process, which improves development efficiency while increasing the security risks of software. As open source software vulnerabilities emerge in an endless stream, the industry has begun to pay attention to and start security governance of open source components.

[0068] However, in the actual open source component security management work, everyone generally faces problems such as high repair costs and low repair efficiency. The main reason is that the open source component's own vulnerability repair is generally achieved by upgrading the version. The component upgrade operation is not complicated. You only need to modify the version number in the corresponding configuration file. However, component upgrades will bring potential incompatibility issues. Once the new version of the component is incompatible with the system, it will cause functional abnormalities and affect system availability.

[0069] In order to ensure that component upgrades are compatible and reliable, developers will spend a lot of time conducting research and analysis before performing the upgrade. After the upgrade, testers need to perform regression testing on related functions, so the vulnerability repair process of open source components is greatly lengthened.

[0070] In the related art, the upgrade compatibility is simply identified by whether the component is upgraded across major versions, or by comparing the interface changes before and after the upgrade of the open source component itself to determine the upgrade compatibility of the component. However, there is no inevitability of component incompatibility across major versions. By comparing the changes before and after the version of the component's own interface, we can only draw the compatibility changes based on the component itself, which does not represent the actual compatibility of the specific project. As a result, in the absence of definite compatibility analysis results, in order to ensure the normal and stable functions after the upgrade, development and testing personnel still need to invest extra time and energy in preliminary research and analysis and post-upgrade testing and verification, resulting in low repair efficiency and high upgrade resistance.

[0071] Based on this, an embodiment of the present application proposes a method for compatibility analysis of vulnerability upgrades of open source components. By performing automated pre-upgrade verification on vulnerable components with vulnerabilities in open source components, the upgrade compatibility information of each vulnerable component is obtained, and then the knowledge base of the large model is integrated and constructed. The large model can perform upgrade compatibility analysis on the vulnerable components based on the knowledge base, thereby ensuring the accuracy and comprehensiveness of the upgrade compatibility analysis results and effectively improving the upgrade efficiency.

[0072] Reference Figure 1 , Figure 1It is a flowchart of an open source component vulnerability upgrade compatibility analysis method provided in an embodiment of the present application, including but not limited to steps S110 to S140.

[0073] Step S110, obtaining a vulnerable component having a vulnerability in an open source component called by the project file.

[0074] In the embodiment of the present application, considering that there may be vulnerable components in the open source components called by the project, it is necessary to first find out or obtain the vulnerable components in the open source components called by the project files, so that the vulnerable components can be upgraded and repaired and the upgrade compatibility of the vulnerable components can be analyzed later.

[0075] Reference Figure 2 , Figure 2 It is a flowchart of the steps of obtaining a vulnerability component having a vulnerability in an open source component called by a project file provided by an embodiment of the present application, including but not limited to steps S210 to S220.

[0076] Step S210, performing open source component analysis on the project file using a software component analysis tool to obtain a number of open source components called by the project file;

[0077] Step S220, scanning each open source component by using a software component analysis tool to obtain vulnerable components with vulnerabilities.

[0078] In an embodiment of the present application, the open source component analysis of the project file is performed through the software component analysis tool (SCA), and several open source components called by each project file can be obtained. Then, each open source component is scanned through the software component analysis tool (SCA) to obtain the vulnerable components with vulnerabilities. Specifically, the open source component analysis can be performed by integrating SCA in the CI / CD pipeline, and each open source component called by the project file can be obtained. Then, the vulnerable components with vulnerabilities in each open source component can be obtained by scanning. For example, through SCA scanning, it can be found that there are 10 vulnerable components in project A, then the current version numbers of these 10 vulnerable components and the vulnerability-free version number to be upgraded (that is, the repair version number) are recorded.

[0079] Step S120, performing automated pre-upgrade verification on the vulnerable component to obtain upgrade compatibility information of the vulnerable component.

[0080] In the embodiment of the present application, after determining the list of vulnerable components corresponding to the project file, each vulnerable component can be automatically pre-upgraded to obtain the upgrade compatibility results of each vulnerable component, and when the upgrade compatibility result of the vulnerable component is determined to be incompatible with the upgrade, a corresponding repair code sample can be generated. This can reduce the workload of manual analysis and reduce the cost of vulnerability repair.

[0081] Reference Figure 3 , Figure 3 It is a flowchart of the steps of performing automated pre-upgrade verification on vulnerable components to obtain upgrade compatibility information of vulnerable components, provided by an embodiment of the present application, including but not limited to steps S310 to S360.

[0082] Step S310, scanning the source code of the project file to extract the component dependency chain;

[0083] Step S320, determining the introduction method of each vulnerable component according to the component dependency chain;

[0084] Step S330, upgrading the corresponding vulnerable component according to the introduction method of the vulnerable component;

[0085] Step S340, after upgrading each vulnerable component, redeploy the project based on the project file;

[0086] Step S350, if there is an abnormality in the deployment, the upgrade compatibility results of each vulnerable component are determined by rolling back the upgraded and fixed vulnerable components one by one, then redeploying the project and detecting whether the deployment is abnormal;

[0087] Step S360: If there is no abnormality in the deployment, the deployed project is tested through the automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerable component.

[0088] In an embodiment of the present application, the source code of the project file can be first scanned by a software component analysis tool (SCA) to extract the component dependency chain. For example, by analyzing the configuration files such as pom.xml, build.gradle in the source code of the project file, the component dependency chain can be extracted. Based on the component dependency chain, the introduction method of each vulnerability component can be determined, so that the upgrade method adopted by each vulnerability component can be determined based on the different introduction methods of the vulnerability components. Thus, the corresponding vulnerability component can be upgraded based on the determined upgrade method. If the introduction method of the vulnerability component is direct introduction, the vulnerability component is directly upgraded and repaired. If the introduction method of the vulnerability component is indirect dependency introduction, the vulnerability component can be repaired by upgrading the parent component of the vulnerability component or by upgrading the vulnerability component itself.

[0089] Reference Figure 4 , Figure 4 It is a flowchart of the steps for upgrading the corresponding vulnerable components according to the introduction method of the vulnerable components provided by an embodiment of the present application, including but not limited to steps S410 to S460.

[0090] Step S410: If the vulnerability component is introduced in a direct manner, the version number of the vulnerability component contained in the configuration file corresponding to the project file is modified to a repair version number to upgrade and repair the vulnerability component;

[0091] Step S420: If the vulnerable component is introduced by indirect dependency, the parent component of the vulnerable component is obtained according to the component dependency chain;

[0092] Step S430, obtaining the current version number of the parent component, and searching for the latest version number of the parent component under the current major version number;

[0093] Step S440, determining whether the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the fixed version number of the vulnerable component;

[0094] Step S450: if the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the repair version number, the current version number of the parent component is upgraded to the latest version number to upgrade and repair the vulnerable component;

[0095] Step S460, if the version number of the vulnerable component referenced by the parent component under the latest version number is smaller than the repair version number, then a new declaration of the component name of the introduced vulnerable component and the corresponding repair version number is added to the configuration file corresponding to the project file to upgrade and repair the vulnerable component.

[0096] In the embodiment of the present application, if the introduction method of the vulnerability component to be repaired is direct introduction, the declaration of the configuration file of the project file will contain the component name and current version number corresponding to the vulnerability component. At this time, after retrieval and positioning by regular matching or tag number parsing, the current version number of the vulnerability component contained in the configuration file of the project file can be directly modified to the repair version number, so that when the project is actually built, the original version (low version) of the vulnerability component will be replaced with the repair version (high version), so that the vulnerability component can be upgraded and repaired. If the introduction method of the vulnerability component to be repaired is indirect dependency introduction, it is necessary to further obtain the parent component of the vulnerability component based on the component dependency chain. Among them, the parent component is the component directly introduced by the project, and the component depends on and introduces the vulnerability component to be repaired. If the vulnerability component to be repaired is component A, the parent component of component A obtained through the component dependency chain is component C, and component C is the component directly introduced by the project, and component C depends on and introduces component A. Then obtain the current version number of the parent component, and search and find the latest version number of the parent component under the current major version number. If the current version number of the parent component is 1.1, then search for the latest version of the parent component under the current major version number (that is, under the 1.0 major version), such as 1.8 is the latest version of the parent component under the 1.0 major version. Then determine whether the version number of the vulnerability component referenced by the parent component under the latest version number is greater than or equal to the repair version number of the vulnerability component. If the version number of the vulnerability component referenced by the parent component under the latest version number is greater than or equal to the repair version number, then the vulnerability component can be repaired by upgrading the parent component, and the current version number of the parent component can be upgraded to the latest version number to upgrade and repair the vulnerability component. For example, the repair version number corresponding to the vulnerability component A to be repaired is 1.7, and the version number of the vulnerability component A referenced by the parent component C under the latest version number (such as 1.8 version number) is 1.8. Since 1.8 is greater than 1.7, the current version number (1.1) of the parent component C can be upgraded to the latest version number (1.8), and the version number of the vulnerability component A can be upgraded to 1.8 (greater than the repair version number 1.7) accordingly, so that the vulnerability component A can be repaired. If the version number of the vulnerable component referenced by the parent component under the latest version number is smaller than the fixed version number, then the vulnerable component cannot be fixed by upgrading the parent component, so the vulnerable component needs to be fixed directly. Since the vulnerable component is introduced indirectly as a dependency, the declaration of the configuration file of the project file does not contain relevant information about the vulnerable component. At this time, the vulnerable component can be upgraded and fixed by adding a new declaration to the configuration file of the project file to introduce the component name of the vulnerable component and the corresponding fixed version number.For example, if the repair version number of the vulnerable component A to be repaired is 1.7, and the version number of the vulnerable component A referenced by the parent component C under the latest version number (such as version number 1.8) is 1.6, since 1.6 is smaller than 1.7, upgrading the current version number (1.1) of the parent component C to the latest version number (1.8) will not repair the vulnerable component. Therefore, it is necessary to add a new declaration in the configuration file of the project file to introduce the component name and repair version number of the vulnerable component A to repair the vulnerable component A.

[0097] After upgrading and repairing each vulnerability component, redeploy the project based on the project file and detect whether there are any abnormalities in the deployment. If there are any abnormalities in the deployment, it means that there are vulnerability components with upgrade compatibility issues in each vulnerability component. The upgrade compatibility results corresponding to the changed vulnerability components can be detected by detecting whether there are any abnormalities in the deployment. If there are no abnormalities in the deployment, there may not be any vulnerability components with upgrade compatibility issues in each vulnerability component. At this time, the deployed project can be further tested through the automated regression test case corresponding to the project file to determine the upgrade compatibility results of each vulnerability component. Specifically, if there are any abnormalities in the deployment, the upgrade compatibility results of each vulnerability component can be determined by returning the upgraded and repaired vulnerability components one by one, then redeploying the project and detecting whether the deployment is abnormal. If there are no abnormalities in the deployment, the upgrade compatibility results of each vulnerability component can be determined by returning the upgraded and repaired vulnerability components one by one, and then retesting them using the automated regression test case.

[0098] Reference Figure 5 , Figure 5 It is a flowchart provided by an embodiment of the present application for determining the upgrade compatibility results of each vulnerability component by rolling back the upgraded and repaired vulnerability components one by one, then redeploying the project and detecting whether the deployment is abnormal, including but not limited to steps S510 to S5100.

[0099] Step S510, obtaining all the vulnerability components that have been upgraded and repaired, and constructing a vulnerability component set;

[0100] Step S520, randomly selecting a target vulnerable component from the vulnerable component set, and returning the target vulnerable component to its original state before the upgrade;

[0101] Step S530, redeploying the project based on the project file;

[0102] Step S540, detecting whether the deployment is abnormal;

[0103] Step S550, if there is no abnormality in the deployment, it is determined that the target vulnerability component in the vulnerability component set is not compatible with the upgrade, and the other vulnerability components in the vulnerability component set except the target vulnerability component are compatible with the upgrade;

[0104] Step S560: If there is an exception in the deployment, determine whether the error message of the current exception is consistent with the error message of the first exception;

[0105] Step S570: If the error message of the current exception is consistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is compatible with the upgrade, but there are other vulnerability components in the vulnerability component set that are incompatible with the upgrade;

[0106] Step S580, after the target vulnerability component is upgraded and repaired again, the target vulnerability component is excluded from the vulnerability component set, and the vulnerability component set is updated and then the process returns to step S520;

[0107] Step S590: If the error message of the current exception is inconsistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and there are other vulnerability components in the vulnerability component set that are incompatible with the upgrade;

[0108] Step S5100, exclude the target vulnerability component from the vulnerability component set to update the vulnerability component set and then return to step S520.

[0109] In the embodiment of the present application, after all the vulnerability components in the current project are upgraded and repaired, the project can be rebuilt and deployed based on the upgraded components, and in the case of abnormal deployment, the upgrade compatibility results of each vulnerability component can be determined by returning the upgraded and repaired vulnerability components one by one, and then redeploying the project and detecting whether the deployment is abnormal. For example, there are three vulnerability components in the open source components called by the current project, namely component A, component B and component C. After upgrading and repairing these three vulnerability components, the project is rebuilt and deployed again. It is found that the deployment is abnormal, indicating that these three vulnerability components contain vulnerability components with upgrade compatibility issues. At this time, one of the vulnerability components can be selected from the three vulnerability components at will. For example, if component A is selected, component A is returned from the upgraded state to the original state before the upgrade. If the version number of component A before the upgrade is 1.1, and the upgraded version is 1.5, at this time, the version number of component A is returned from 1.5 to 1.1. At this time, only components B and C of the current project have been upgraded, and component A has not been upgraded. Then rebuild and deploy the project. If there is no abnormality in the deployment, it means that component A can be deployed normally after rollback and upgrade, and component B and component C are compatible with each other. The reason for the first abnormality is the incompatibility of component A upgrade. It can be concluded that component A upgrade is incompatible, and component B and component C are compatible. If component A is rolled back and upgraded and redeployed, and there is still an abnormality, it is necessary to further check whether the error message of the current abnormality is consistent with the error message of the first abnormality. If they are consistent, that is, the reason for the abnormality has not disappeared after component A is rolled back and upgraded, it can be said that the reason for the abnormality is not the incompatibility of component A upgrade, which means that component A is compatible with each other, but the reason for the abnormality should be the incompatibility of other components. At this time, it is necessary to further select one of the vulnerable components from the remaining vulnerable components (including component B and component C), such as selecting component B, and roll component B back from the upgraded state to the original state before the upgrade. For example, the version number of component B before the upgrade is 1.1, and the version after the upgrade is 1.5. At this time, roll the version number of component B back from 1.5 to 1.1. In addition, since it has been determined that component A is compatible with the upgrade, component A can be upgraded again in the same way as before. For example, to fix the vulnerability of component A, component A is upgraded from version 1.1 to version 1.5. After rolling back the upgrade (i.e. rolling back component A from version 1.5 to 1.1) to determine that component A is compatible with the upgrade, component A needs to be upgraded from version 1.1 to version 1.5 again. At this point, component A and component C are in the upgraded state, and component B is rolled back to the state before the upgrade. Then rebuild the deployment project. If there are no abnormalities in the deployment, it means that component B can be deployed normally after rolling back the upgrade. The reason for the first abnormality is that the upgrade of component B is incompatible. It can be concluded that the upgrade of component B is incompatible, and the upgrade of component A and component C is compatible.If the exception still exists after component B is redeployed after being rolled back for upgrade, it is necessary to further check whether the error message of the current exception is consistent with the error message of the first exception. If they are consistent, that is, the error message that caused the exception has not changed after component B is rolled back for upgrade, it can be said that the cause of the exception is not the incompatibility of component B upgrade, which means that component B upgrade is compatible, and the cause of the exception should be the incompatibility of other component upgrades, which can also be inferred that the cause of the exception should be the incompatibility of component C upgrade. In order to further verify whether component C is incompatible with the upgrade, component C can be rolled back from the upgraded state to the original state before the upgrade. For example, the version number of component C before the upgrade is 1.1, and the upgraded version is 1.5. At this time, the version number of component C is rolled back from 1.5 to 1.1. In addition, since it has been determined that component A and component B are compatible for upgrade, component A and component B can be upgraded again according to the previous upgrade method. At this point, component A and component B are in the upgraded state, and component C is back to the state before the upgrade. Then rebuild the deployment project. If there is no abnormality in the deployment, it means that component C can be deployed normally after the upgrade, and the first abnormality is caused by the incompatibility of component C upgrade. Therefore, it can be determined that the upgrade compatibility results corresponding to the three vulnerable components in the current project are: component A and component B are compatible with upgrades, and component C is incompatible with upgrades. At this point, since component C is incompatible with upgrades, a repair code sample for repairing the vulnerability of component C can be further generated.

[0110] If component A is redeployed after being rolled back for upgrade and there are still exceptions, and the error message of the current exception is inconsistent with the error message of the first exception, that is, the deployment of component A after being rolled back for upgrade is still abnormal but the error message is changed, it can be explained that the cause of the exception is not only caused by the incompatibility of component A upgrade, but also caused by the incompatibility of other component upgrades. At this time, it can be determined that component A is incompatible with upgrades, and there are other component upgrade incompatibilities. In order to determine which component upgrade is incompatible among the remaining vulnerable components, it is necessary to further select one of the vulnerable components from the remaining vulnerable components (including component B and component C) at random. For example, if component B is selected, component B is rolled back from the upgraded state to the original state before the upgrade. For example, the version number of component B before the upgrade is 1.1, and the upgraded version is 1.5. At this time, the version number of component B is rolled back from 1.5 to 1.1. In addition, since it has been determined that component A is incompatible with upgrades, component A needs to be kept in its original state before the upgrade. At this point, component A and component B are in the state before the upgrade, and component C is in the state after the upgrade. Then rebuild the deployment project. If there is no abnormality in the deployment, it can be said that component A and component B can be deployed normally after the return and upgrade, and the reason for the first abnormality is the incompatibility of component A and component B upgrades. It can be concluded that component A and component B are incompatible with each other, and component C is compatible with each other. If there are still abnormalities after component A and component B are returned and upgraded and redeployed, it is necessary to further detect whether the error information of the current abnormality is consistent with the error information of the first abnormality. If they are consistent, that is, the error information causing the abnormality after component A and component B are returned and upgraded has not changed, it can be said that component B is compatible with the upgrade, and the cause of the abnormality should be caused by the incompatibility of other component upgrades. It can also be inferred that the cause of the abnormality should be caused by the incompatibility of component A and component C upgrades. It can be concluded that component A and component C are incompatible with each other, and component B is compatible with each other. If, however, component A and component B are rolled back and redeployed after upgrade, and the error message of the current exception is inconsistent with the error message of the first exception, that is, the error message that caused the exception after component A and component B are rolled back and upgraded has changed, it can be said that the upgrade of component B is incompatible, and there are other component upgrades (i.e. component C) that are incompatible, and it can be inferred that the upgrades of component A, component B, and component C are incompatible. In order to further verify whether component A, component B, and component C are all incompatible, component C can also be rolled back from the upgraded state to the original state before the upgrade. At this point, component A, component B, and component C are all in the state before the upgrade, and then the deployment project is rebuilt. If there is no abnormality in the deployment, it can be said that component A, component B, and component C can be deployed normally after rolling back and upgrading, and the cause of the first abnormality is caused by the incompatibility of the upgrades of the three components A, component B, and component C. Therefore, it can be determined that the upgrade compatibility results corresponding to the three vulnerable components in the current project are: component A, component B, and component C are all incompatible.At this point, a repair code sample for repairing the vulnerability of component A, a repair code sample for repairing the vulnerability of component B, and a repair code sample for repairing the vulnerability of component C may be further generated.

[0111] It should be noted that the first exception is the exception that occurs when the project is redeployed based on the project file after each vulnerable component is upgraded. Taking the case where the vulnerable components of the above current project include components A, B, and C as an example, the first exception refers to the exception that occurs when the current project is rebuilt and deployed after components A, B, and C are upgraded and repaired, that is, the exception that occurs when the project is deployed when components A, B, and C are all in the upgraded state.

[0112] In some embodiments, in order to improve the efficiency of determining the upgrade compatibility results of each vulnerability component, the incompatibility possibility of each vulnerability component corresponding to the current project can also be analyzed to determine the incompatibility possibility of each vulnerability component, so that the upgraded and repaired vulnerability components can be rolled back one by one in the order of incompatibility possibility from large to small, and then the project is redeployed and the deployment is detected to determine the upgrade compatibility results of each vulnerability component. This can improve the efficiency of vulnerability component upgrade compatibility analysis.

[0113] Reference Figure 6 , Figure 6 It is a flowchart of steps provided by an embodiment of the present application for redeploying a project after upgrading each vulnerable component, but when an abnormality occurs in the deployment, including but not limited to steps S610 to S620.

[0114] Step S610, counting the incompatibility possibilities corresponding to each upgraded and repaired vulnerability component;

[0115] Step S620, the upgraded and repaired vulnerability components are rolled back one by one in order of incompatibility possibility from greatest to least, and then the project is redeployed to detect whether the deployment is abnormal to determine the upgrade compatibility result of each vulnerability component.

[0116] In the embodiment of the present application, after upgrading each vulnerability component and redeploying the project, if there is an abnormality in the deployment, the incompatibility probability corresponding to each upgraded and repaired vulnerability component can be counted first. Among them, the incompatibility probability of the vulnerability component can be represented by an incompatibility score. Specifically, the incompatibility score of the component can include three aspects:

[0117] (1) Analyze the error information of the parsable records to extract the potential component information. Use the component name that the project depends on to search. If there is a related record, it indicates that the component may be incompatible. If the component is in the list of this upgrade, add 4 points to the component; if the component is not in the list of this upgrade, further search in the project component dependency and check its parent component layer by layer. If the corresponding parent component exists in the upgrade list, add 4 points to the parent component.

[0118] (2) Search from the maintained compatibility database (if there is no data at the beginning of the project or the first execution, this step can be skipped). Search the database for the list of components to be upgraded. If there is a corresponding record for a component, further analysis is performed:

[0119] i. When the compatibility is incompatible, the corresponding incompatible calling method is recorded in the knowledge base, so you can check whether the project uses this method to call the corresponding method. Download the project source code and parse it. If there is a corresponding call in the project source code and the version number matches, the component will be scored 5 points;

[0120] ii. If the compatibility is incompatible, there is a corresponding code call, but no corresponding version number record, then the component will be scored 3 points;

[0121] iii. If there is a compatible record of the component calling method used in the project, -2 points will be deducted.

[0122] (3) Check whether the component is upgraded across major versions. If so, score 1 point.

[0123] After the calculation is completed, the incompatibility score of each component can be counted and sorted from high to low, so that the upgraded and repaired vulnerability components can be rolled back one by one in order of incompatibility possibility (that is, incompatibility score) from large to small, and then the project can be redeployed and the deployment can be detected to determine whether it is abnormal. The upgrade compatibility result of each vulnerability component can be determined, which can improve the efficiency of the upgrade compatibility analysis of each vulnerability component.

[0124] Taking the above-mentioned current project's vulnerability components including component A, component B, and component C as an example, if the incompatibility probability of component A, component B, and component C is ranked as component A's incompatibility probability is greater than component B's incompatibility probability, which is greater than component C's incompatibility probability, then the upgrade of the upgraded and repaired vulnerability components is smooth. First, component A is upgraded and verified, then component B is upgraded and verified, and then component C is upgraded and verified. Since component A has the greatest incompatibility probability, a large reason for the deployment anomaly may be the incompatibility of component A upgrade, that is, the upgrade compatibility results of each vulnerability component can be determined through a single rollback verification, thereby improving the efficiency of the upgrade compatibility analysis of each vulnerability component.

[0125] In an embodiment of the present application, after upgrading each vulnerability component and rebuilding the deployment project, if there is no abnormality in the deployment, the deployed project can be further tested through the automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerability component.

[0126] Reference Figure 7 , Figure 7 A flowchart of steps for testing a deployed project through automated regression test cases corresponding to project files to determine the upgrade compatibility results of each vulnerability component, including but not limited to steps S710 to S730, is provided in an embodiment of the present application.

[0127] Step S710, testing the redeployed project through the automated regression test cases corresponding to the project files;

[0128] Step S720: If the automated regression test case passes, it is determined that each vulnerable component is compatible with the upgrade;

[0129] Step S730, if the automated regression test case fails, the upgrade compatibility results of each vulnerability component are determined by rolling back the upgraded and fixed vulnerability components one by one and then retesting them using the automated regression test case.

[0130] In the embodiment of the present application, after upgrading each vulnerability component and rebuilding the deployment project, if there is no abnormality in the deployment, the deployed project can be allowed to execute the automated regression test case. If the automated regression test case passes, it can be determined that each vulnerability component is upgraded and compatible. If the automated regression test case fails, the upgrade compatibility results of each vulnerability component can be determined by further rolling back the upgraded and fixed vulnerability components one by one and then retesting them using the automated regression test case.

[0131] Reference Figure 8 , Figure 8 A flowchart is provided in an embodiment of the present application for determining the upgrade compatibility results of each vulnerability component by rolling back the upgraded and fixed vulnerability components one by one and then retesting them using automated regression test cases, including but not limited to steps S810 to S8100.

[0132] Step S810, obtaining all the vulnerability components that have been upgraded and repaired, and constructing a vulnerability component set;

[0133] Step S820, randomly selecting a target vulnerable component from the vulnerable component set, and returning the target vulnerable component to its original state before the upgrade;

[0134] Step S830, retesting the project based on the automated regression test case;

[0135] Step S840, checking whether the use case test passes;

[0136] Step S850, if passed, it is determined that the target vulnerability component in the vulnerability component set is not compatible with the upgrade, and the other vulnerability components in the vulnerability component set except the target vulnerability component are compatible with the upgrade;

[0137] Step S860: If not passed, determine whether the current error message is consistent with the first error message;

[0138] Step S870: If the current error message is consistent with the first error message, it is determined that the target vulnerability component in the vulnerability component set is compatible with the upgrade, but other vulnerability components in the vulnerability component set are not compatible with the upgrade;

[0139] Step S880, after the target vulnerability component is upgraded and repaired again, the target vulnerability component is excluded from the vulnerability component set, so as to update the vulnerability component set and then return to step S820;

[0140] Step S890: If the current error message is inconsistent with the first error message, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and there are other vulnerability components in the vulnerability component set that are incompatible with the upgrade;

[0141] Step S8100, exclude the target vulnerability component from the vulnerability component set to update the vulnerability component set and then return to step S820.

[0142] In the embodiment of the present application, after all the vulnerability components in the current project are upgraded and repaired, the project can be rebuilt and deployed based on the upgraded components, and when it is detected that the deployment is normal, but the automated regression test case fails, the upgrade compatibility results of each vulnerability component can be determined by returning the upgraded and repaired vulnerability components one by one and then retesting them using the automated regression test case. For example, there are three vulnerability components in the open source components called by the current project, namely component A, component B and component C. After upgrading and repairing these three vulnerability components, the project is rebuilt and deployed again. It is found that the deployment is normal, but the automated regression test case fails. It means that these three vulnerability components contain vulnerability components with upgrade compatibility issues. At this time, one of the vulnerability components can be selected from the three vulnerability components at will. For example, if component A is selected, component A is returned from the upgraded state to the original state before the upgrade. For example, the version number of component A before the upgrade is 1.1, and the upgraded version is 1.5. At this time, the version number of component A is returned from 1.5 to 1.1. At this time, only components B and C of the current project have been upgraded, and component A has not been upgraded. Then retest the project based on the automated regression test case. If the test passes, that is, component A passes the test after being rolled back and upgraded, indicating that component B and component C are compatible with each other, and the reason for the failure of the first test is due to the incompatibility of component A upgrade. It can be concluded that component A is incompatible with each other, and component B and component C are compatible with each other. If component A still fails after being rolled back and upgraded, it is necessary to further check whether the current error information recorded in the log is consistent with the first error information. If they are consistent, that is, the reason for the failure of the test after component A is rolled back and upgraded has not disappeared, it can be said that the reason for the failure of the test is not the incompatibility of component A upgrade, which means that component A is compatible with each other, and the reason for the failure of the test should be the incompatibility of other components. At this time, it is necessary to further select one of the vulnerable components from the remaining vulnerable components (including component B and component C), such as selecting component B, and rolling component B back from the upgraded state to the original state before the upgrade. For example, the version number of component B before the upgrade is 1.1, and the upgraded version is 1.5. At this time, roll the version number of component B back from 1.5 to 1.1. In addition, since it has been confirmed that component A is compatible with the upgrade, component A can be upgraded again in the same way as before. For example, to fix a vulnerability in component A, component A is upgraded from version 1.1 to version 1.5. After rolling back the upgrade (i.e. rolling back component A from version 1.5 to 1.1) and confirming that component A is compatible with the upgrade, component A needs to be upgraded again from version 1.1 to version 1.5.At this time, component A and component C are in the upgraded state, and component B is returned to the state before the upgrade. Then, the use case test is re-performed. If the test passes, that is, component B passes the test after the upgrade, indicating that the reason for the failure of the first test is due to the incompatibility of component B upgrade, and the result that component B upgrade is incompatible and component A and component C are compatible can be obtained. If the use case test of component B still fails after the upgrade, it is necessary to further check whether the current error information recorded in the log is consistent with the first error information. If they are consistent, that is, the error information that caused the test failure after component B returned to the upgrade has not changed, it can be explained that the reason for the failure of the test is not the incompatibility of component B upgrade, which means that component B is compatible, and the reason for the failure of the test should be caused by the incompatibility of other component upgrades. It can also be inferred that the cause of the exception should be caused by the incompatibility of component C upgrade. In order to further verify whether component C is incompatible with the upgrade, component C can be returned from the upgraded state to the original state before the upgrade. For example, the version number of component C before the upgrade is 1.1, and the version after the upgrade is 1.5. At this time, the version number of component C is returned from 1.5 to 1.1. In addition, since it has been determined that component A and component B are compatible with each other, component A and component B can be upgraded again according to the previous upgrade method. At this time, component A and component B are in the upgraded state, and component C is returned to the state before the upgrade. Then the use case test is re-performed. If the test passes, that is, the use case test of component C passes after the upgrade, it means that the reason for the failure of the first test is the incompatibility of component C upgrade. Therefore, it can be determined that the upgrade compatibility results corresponding to the three vulnerable components in the current project are: component A and component B are compatible with each other, and component C is incompatible with each other. At this time, since component C is incompatible with the upgrade, a repair code sample for repairing the vulnerability of component C can be further generated.

[0143] If component A still fails the test after the upgrade, and the current error message recorded in the log is inconsistent with the first error message, that is, the test still fails after component A is upgraded, but the error message is changed, which means that the reason for the failure of the test is not only due to the incompatibility of component A upgrade, but also due to the incompatibility of other components. At this time, it can be determined that component A is incompatible with the upgrade, and there are other components that are incompatible with the upgrade. In order to determine which component among the remaining vulnerable components is incompatible with the upgrade, it is necessary to further select one of the vulnerable components from the remaining vulnerable components (including component B and component C). For example, if component B is selected, component B is returned from the upgraded state to the original state before the upgrade. For example, the version number of component B before the upgrade is 1.1, and the upgraded version is 1.5. At this time, the version number of component B is returned from 1.5 to 1.1. In addition, since it has been determined that component A is incompatible with the upgrade, component A needs to be kept in its original state before the upgrade. At this time, component A and component B are in the state before the upgrade, and component C is in the state after the upgrade. Then, the use case test is re-performed. If the test passes, it can be explained that the use case test of component A and component B passed after the return and upgrade, and the reason for the failure of the first test was due to the incompatibility of component A and component B upgrades. It can be concluded that component A and component B are incompatible, and component C is compatible. If component A and component B still fail to pass the retest after the return and upgrade, it is necessary to further check whether the current error information recorded in the log is consistent with the first error information. If they are consistent, that is, the error information that caused the test failure after component A and component B returned and upgraded has not changed, it can be explained that component B is compatible with the upgrade, and the cause of the exception should be the incompatibility of other component upgrades. It can also be inferred that the cause of the exception should be the incompatibility of component A and component C upgrades. It can be concluded that component A and component C are incompatible, and component B is compatible. If component A and component B still fail the re-test after the upgrade, and the current error information recorded in the log is inconsistent with the first error information, that is, the error information that caused the test failure to pass has changed after component A and component B are upgraded, it can be said that the upgrade of component B is incompatible, and there are other component upgrades (i.e. component C) that are incompatible, and it can be inferred that the upgrades of component A, component B and component C are incompatible. In order to further verify whether component A, component B and component C are all incompatible, component C can also be returned from the upgraded state to the original state before the upgrade. At this time, component A, component B and component C are all in the state before the upgrade, and then the use case test is re-executed. If the test passes, it can be said that component A, component B and component C have passed the test after the upgrade, and the reason for the failure of the first test is caused by the incompatibility of the upgrades of component A, component B and component C. Therefore, it can be determined that the upgrade compatibility results corresponding to the three vulnerable components in the current project are: component A, component B and component C are all incompatible.At this point, a repair code sample for repairing the vulnerability of component A, a repair code sample for repairing the vulnerability of component B, and a repair code sample for repairing the vulnerability of component C may be further generated.

[0144] It should be noted that the first error message refers to the corresponding error message when the use case test fails after each vulnerable component is upgraded and the project is successfully redeployed. Taking the case where the vulnerable components of the above current project include component A, component B, and component C as an example, the first error message refers to the corresponding error message when the use case test fails after components A, component B, and component C are upgraded and repaired and the current project is successfully redeployed, that is, the corresponding error message when the use case test fails when components A, component B, and component C are all in the upgraded state.

[0145] In some embodiments, in order to improve the efficiency of determining the upgrade compatibility results of each vulnerability component, the incompatibility possibility of each vulnerability component corresponding to the current project can also be analyzed to determine the incompatibility possibility of each vulnerability component, so that the upgraded and repaired vulnerability components can be rolled back one by one in the order of incompatibility possibility from large to small, and then retested using automated regression test cases to determine the upgrade compatibility results of each vulnerability component. This can improve the efficiency of vulnerability component upgrade compatibility analysis.

[0146] Reference Fig. 9 , Fig. 9 It is a flowchart of steps provided by an embodiment of the present application, which is performed after each vulnerable component is upgraded and the project is successfully redeployed, but the use case test fails, including but not limited to steps S910 to S920.

[0147] Step S910, counting the incompatibility possibilities corresponding to each upgraded and repaired vulnerability component;

[0148] Step S920, the upgraded and repaired vulnerability components are rolled back one by one in order of incompatibility possibility from greatest to least, and then retested using automated regression test cases to determine the upgrade compatibility results of each vulnerability component.

[0149] In the embodiment of the present application, after each vulnerability component is upgraded and the project is successfully redeployed, but the use case test fails, the incompatibility probability corresponding to each upgraded and repaired vulnerability component can be counted first. Among them, the incompatibility probability of the vulnerability component can be represented by an incompatibility score. Specifically, the incompatibility score of the component can include three aspects:

[0150] (1) Extract the interface information corresponding to the automated test case, then pull the source code, analyze the interface code, and check whether there is an open source component call in the upgrade list. If so, the corresponding component incompatibility score is increased by 4 points.

[0151] (2) Search from the maintained compatibility database (if there is no data at the beginning of the project or the first execution, this step can be skipped). Search the database for the list of components to be upgraded. If there is a corresponding record for a component, further analysis is performed:

[0152] i. When the compatibility is incompatible, the corresponding incompatible calling method is recorded in the knowledge base, so you can check whether the project uses this method to call the corresponding method. Download the project source code and parse it. If there is a corresponding call in the project source code and the version number matches, the component will be scored 5 points;

[0153] ii. If the compatibility is incompatible, there is a corresponding code call, but no corresponding version number record, then the component will be scored 3 points;

[0154] iii. If there is a compatible record of the component calling method used in the project, -2 points will be deducted.

[0155] (3) Check whether the component is upgraded across major versions. If so, score 1 point.

[0156] After the calculation is completed, the incompatibility score of each component can be counted and sorted from high to low, so that the upgraded and fixed vulnerability components can be rolled back one by one in the order of incompatibility possibility from large to small, and then re-tested using automated regression test cases to determine the upgrade compatibility results of each vulnerability component, which can improve the efficiency of upgrade compatibility analysis of each vulnerability component.

[0157] In the embodiment of the present application, after the automatic pre-upgrade verification is performed on each vulnerability component corresponding to different projects, the upgrade compatibility results corresponding to each vulnerability component can be obtained. When the upgrade compatibility result of the vulnerability component is upgrade compatible, the corresponding vulnerability component is marked as having good upgrade compatibility, and the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method and repair code sample of the vulnerability component are recorded. For example, when component A is upgrade compatible, the following information can be recorded: component A-1.1.0 (pre-upgrade version number)-1.2.1 (post-upgrade version number)-compatible (upgrade compatibility result)-JSON Array.parseArray (str) (calling method)-none (repair code sample). When the upgrade compatibility result of the vulnerability component is upgrade incompatibility, the R&D personnel need to modify the code, that is, to make a repair code sample. The unique identifier (commit_id) of the corresponding code submission is recorded through the system process association. Pull the corresponding code for analysis and extract the methods or classes of the open source components involved. For example, because component e is upgraded from version 1.2.5 to 1.3.1, there is an incompatibility. After confirmation, the R&D personnel supplement the modified code sample, automatically associate the unique identifier (commit_id) corresponding to the repair code sample through the process, and then pull the code to analyze the modified code. If it involves methods or classes provided by open source components, the corresponding code snippet will be recorded. For example, when component e is upgraded and incompatible, the following information can be recorded: component e-1.2.5 (version number before upgrade)-1.3.1 (version number after upgrade)-incompatible (upgrade compatibility result)-JSON Array.parseArray(str) (calling method)-repair code sample.

[0158] Step S130, integrate the upgrade compatibility information of each vulnerability component corresponding to different project files, and construct a knowledge base of the large model, which includes the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method, calling code snippet and repair code sample corresponding to each vulnerability component.

[0159] In the embodiment of the present application, after the vulnerability components with vulnerabilities in the open source components called by different project files are automatically pre-upgraded and verified, the upgrade compatibility information of each vulnerability component corresponding to the different project files can be obtained. Then, the upgrade compatibility information of each vulnerability component corresponding to the different project files is integrated to construct a knowledge base of the large model. The knowledge base may include the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method and repair code sample corresponding to each vulnerability component. By constructing this knowledge base, the speed and accuracy of obtaining component upgrade compatibility results can be improved in the automated pre-upgrade verification stage. In addition, the knowledge base can also be used for large model analysis. And by constructing this knowledge base, the large model can quickly and accurately output the upgrade compatibility results of the vulnerability components with vulnerabilities in the open source components called by the project file to be tested.

[0160] It should be noted that the corresponding repair code samples for incompatible upgrades of vulnerability components in different projects in the knowledge base mainly record the repair codes of each project when dealing with incompatible scenarios, which can be used as a reference for developers. At the same time, a corresponding like / dislike mechanism can also be provided to provide feedback on the accuracy of the code by R&D personnel, and regularly clean up the repair code samples with poor results.

[0161] Step S140, using the large model, performs upgrade compatibility analysis on the vulnerable components with vulnerabilities in the open source components called by the project file to be tested, and obtains upgrade compatibility results corresponding to the vulnerable components.

[0162] In the embodiment of the present application, after the knowledge base of the large model is constructed, the vulnerability components with vulnerabilities in the open source components called by the project file to be tested can be upgraded compatibility analysis through the large model to obtain the upgrade compatibility results corresponding to each vulnerability component. Specifically, the project file to be tested can be scanned based on the software component analysis tool (SCA) to obtain the vulnerability components with vulnerabilities in the open source components called by the project file to be tested, and obtain the current version number and repair version number corresponding to each vulnerability component. Scan the source code of the project file to be tested and analyze it, extract the relevant parts of the source code that call each vulnerability component, that is, extract the call code fragments that call the vulnerability component in the source code, so that the call code fragments that call the vulnerability component in the extracted source code can be assembled and generate problems. Specifically, pull the source code of the project file to be tested, analyze the code files one by one, and use the methods called in the code as nodes, generate a method call tree based on code abstraction, and then traverse the generated method call tree. When the method corresponding to the node is provided by the vulnerability component, record the code fragment of the corresponding node. After the traversal is completed, the components are classified into components name-version number units, and the calling methods in the code are extracted. That is, for the same method of the same component, if the number of parameters, parameter types, and parameter order are consistent, the method can be regarded as the same type of call, and only one of them can be retained. In this way, the calling code snippet that calls the vulnerable component in the source code can be extracted. Exemplarily, the vulnerable component to be repaired in a project file to be tested includes component f. The source code of the project file to be tested is pulled and analyzed, and the calling code snippet that calls component f in the source code is extracted. The calling code snippets are assembled to generate questions, such as the generated question "Please analyze whether there are any incompatibilities in the upgrade of component f. If there are any incompatibilities, please provide code repair samples."

[0163] Next, generate the prompt word. The generation process of the prompt word is as follows:

[0164] i. Clarify roles and goals. For example, if you are an open source component vulnerability upgrade compatibility analysis assistant, you will analyze the compatibility of the specific version components and calling methods specified by the questioner or provide repair suggestions;

[0165] ii. Explain the knowledge base format, such as: including component name - version number before upgrade - version number after upgrade - upgrade compatibility result - calling method - calling code snippet - repair code sample;

[0166] iii. Clarify the context based on the question content: Since our questions are extracted and generated based on actual calling codes, they are more targeted than ordinary questions, and the knowledge base design also has corresponding fields, so the following settings can be made: 1. First, learn the method calling compatibility and repair code samples of various versions of open source components based on the knowledge base. 2. The question specifies the specific open source components and version numbers, including the specific calling methods. Learn and understand the versions and calling methods used in the question. 3. Analyze whether the current calling method is compatible based on the compatibility records of the corresponding version components in the knowledge base. If it is not compatible, modify and give the corresponding repair code based on the questioner's code;

[0167] i v. Clarify output requirements, such as: the output content includes: whether the component upgrade given in the question is compatible, if not compatible, provide specific reasons, and provide repair code samples.

[0168] In the embodiment of the present application, based on the constructed knowledge base and the manually tuned prompt words, the above generated questions are sent to the big model for analysis, and the upgrade compatibility results of the vulnerability components analyzed by the big model can be obtained. If the upgrade compatibility result of the vulnerability component output by the big model is upgrade compatible, the vulnerability component is marked as upgrade compatible. If the upgrade compatibility result of the vulnerability component output by the big model is upgrade incompatible, the big model also outputs the corresponding repair code sample.

[0169] In the embodiment of the present application, the corresponding large model questions are generated based on the actual calling situation of the source code of the project file to be tested, which can avoid the analysis results being not targeted. By extracting the code calling method and removing duplicates, the length of the question can be effectively controlled to avoid consuming too many resources or analyzing abnormalities. Through the targeted generation and tuning of prompt words, the model's answer content is more accurate and more targeted. Based on the knowledge base accumulated and optimized based on actual repair situations, the questions accurately refined based on actual calling situations, combined with the prompt words that are targeted and tuned, accurate and practical compatibility analysis results can be provided for real repair scenarios, and effective repair code samples can be generated.

[0170] The embodiment of the present application also provides an electronic device, the electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the above open source component vulnerability upgrade compatibility analysis method when executing the computer program. The electronic device can be any smart terminal including a tablet computer, a car computer, etc.

[0171] See also Fig.10 , Fig.10 : is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application, the electronic device includes:

[0172] The processor 1001 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0173] The memory 1002 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store an operating system and other applications. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1002, and the processor 1001 calls and executes the open source component vulnerability upgrade compatibility analysis method of the embodiment of this application;

[0174] Input / output interface 1003, used to implement information input and output;

[0175] The communication interface 1004 is used to realize the communication interaction between the device and other devices. The communication can be realized through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WI FI, Bluetooth, etc.);

[0176] A bus 1005 , which transmits information between various components of the device (e.g., the processor 1001 , the memory 1002 , the input / output interface 1003 , and the communication interface 1004 );

[0177] The processor 1001 , the memory 1002 , the input / output interface 1003 and the communication interface 1004 are connected to each other in communication within the device via the bus 1005 .

[0178] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0179] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0180] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0181] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0182] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0183] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0184] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0185] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0186] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0187] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0188] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and substance of the present invention should be within the scope of the rights of the present invention.

Claims

1. A method for analyzing the compatibility of open source component vulnerability upgrades, characterized in that: The method comprises: Obtain the vulnerable components in the open source components called by the project file; Performing automated pre-upgrade verification on the vulnerable component to obtain upgrade compatibility information of the vulnerable component; Integrate the upgrade compatibility information of each vulnerability component corresponding to different project files, and construct a knowledge base of a large model, which includes the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method, calling code snippet and repair code sample corresponding to each vulnerability component; The large model is used to perform upgrade compatibility analysis on vulnerable components with vulnerabilities in the open source components called by the project file to be tested, and obtain upgrade compatibility results corresponding to each vulnerable component.

2. The method according to claim 1, characterized in that The open source components called by the project file to obtain the vulnerability components include: Performing open source component analysis on the project file by using a software component analysis tool to obtain a number of open source components called by the project file; Each of the open source components is scanned by the software component analysis tool to obtain vulnerable components with vulnerabilities.

3. The method according to claim 1, characterized in that The step of performing automated pre-upgrade verification on the vulnerable component to obtain upgrade compatibility information of the vulnerable component includes: Scanning source code of the project files to extract component dependency chains; Determine the introduction method of each vulnerable component based on the component dependency chain; According to the introduction method of the vulnerable component, the corresponding vulnerable component is upgraded; After upgrading each of the vulnerable components, redeploying the project based on the project file; If there are any abnormalities in the deployment, the upgrade compatibility of each vulnerable component is determined by rolling back the upgraded and fixed vulnerable components one by one, redeploying the project, and checking whether the deployment is abnormal. If there is no abnormality in the deployment, the deployed project is tested through the automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerable component.

4. The method according to claim 3, characterized in that The step of upgrading the corresponding vulnerability component according to the introduction method of the vulnerability component includes: If the vulnerability component is introduced in a direct manner, the version number of the vulnerability component contained in the configuration file corresponding to the project file is modified to a repair version number, so as to upgrade and repair the vulnerability component; If the vulnerable component is introduced by indirect dependency, the parent component of the vulnerable component is obtained according to the component dependency chain; Get the current version number of the parent component, and find the latest version number of the parent component under the current major version number; Determine whether the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the fixed version number of the vulnerable component; If the version number of the vulnerable component referenced by the parent component under the latest version number is greater than or equal to the repair version number, then the current version number of the parent component is upgraded to the latest version number to upgrade and repair the vulnerable component; If the version number of the vulnerable component referenced by the parent component under the latest version number is smaller than the repair version number, a new declaration introducing the component name of the vulnerable component and the corresponding repair version number is added to the configuration file corresponding to the project file to upgrade and repair the vulnerable component.

5. The method according to claim 3, characterized in that: The upgrade compatibility of each vulnerability component is determined by rolling back the upgraded and fixed vulnerability components one by one, then redeploying the project and checking whether the deployment is abnormal. The results include: Obtain all the vulnerability components that have been upgraded and fixed, and build a vulnerability component set; Randomly select a target vulnerable component from the vulnerable component set, and return the target vulnerable component to its original state before the upgrade; After returning the target vulnerability component to its original state before the upgrade, redeploy the project based on the project file, and detect whether the deployment is abnormal; If there is no abnormality in the deployment, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and the other vulnerability components in the vulnerability component set except the target vulnerability component are compatible with the upgrade; If there is an exception in the deployment, determine whether the error message of the current exception is consistent with the error message of the first exception, wherein the first exception is an exception that occurs when the project is redeployed based on the project file after each of the vulnerability components is upgraded; If the error message of the current exception is consistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is compatible with the upgrade, but there are other vulnerability components in the vulnerability component set that are not compatible with the upgrade; After the target vulnerability component is upgraded and repaired again, the target vulnerability component is excluded from the vulnerability component set to update the vulnerability component set; Returning to the step of arbitrarily selecting a target vulnerability component from the set of vulnerability components and returning the target vulnerability component to its original state before the upgrade; If the error message of the current exception is inconsistent with the error message of the first exception, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, and there are other vulnerability components in the vulnerability component set that are incompatible with the upgrade; Excluding the target vulnerability component from the vulnerability component set to update the vulnerability component set; Return to the step of arbitrarily selecting a target vulnerability component from the component set and returning the target vulnerability component to its original state before the upgrade.

6. The method according to claim 3, characterized in that If there is an abnormality in the deployment, the method further includes: Count the incompatibility possibilities of each upgraded and fixed vulnerability component; The upgraded and repaired vulnerability components are rolled back one by one in the order of the incompatibility possibility from greatest to least, and then the project is redeployed to detect whether the deployment is abnormal to determine the upgrade compatibility result of each vulnerability component.

7. The method according to claim 3, characterized in that The deployed project is tested through the automated regression test cases corresponding to the project files to determine the upgrade compatibility of each vulnerable component. The results include: Testing the redeployed project using automated regression test cases corresponding to the project files; If the automated regression test case passes, it is determined that each of the vulnerability components is upgrade compatible; If the automated regression test case fails, the upgrade compatibility results of each vulnerability component are determined by rolling back the upgraded and fixed vulnerability components one by one and then retesting them using the automated regression test case.

8. The method according to claim 7, characterized in that If the automated regression test case fails, the method further includes: Count the incompatibility possibilities of each upgraded and fixed vulnerability component; The upgraded and repaired vulnerability components are rolled back one by one in the order of the incompatibility possibility from greatest to least, and then retested using the automated regression test case to determine the upgrade compatibility result of each vulnerability component.

9. The method according to claim 1, characterized in that: When the automated pre-upgrade verification is performed on the vulnerable component and it is determined that the upgrade compatibility result of the vulnerable component is incompatible with the upgrade, a repair code sample is also generated; Correspondingly, when the upgrade compatibility result of the vulnerable component output by the large model is upgrade incompatibility, the large model also outputs a corresponding repair code sample.

10. An electronic device, characterized in that: The electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 9 when executing the computer program.

Images