Open source component vulnerability upgrade compatibility analysis methods and electronic devices

Abstract

This application proposes a method and electronic device for open-source component vulnerability upgrade compatibility analysis, belonging to the field of upgrade compatibility analysis technology. This method performs automated pre-upgrade verification on vulnerable components in open-source components called by project files, obtaining upgrade compatibility information for these vulnerable components. By integrating the upgrade compatibility information of various vulnerable components corresponding to different project files, a large-scale model knowledge base can be constructed. This 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 example for each vulnerable component. This allows the large-scale model to rely on this knowledge base to perform upgrade compatibility analysis on vulnerable components in open-source components called by the project file under test, obtaining upgrade compatibility results for each vulnerable component. In other words, the large-scale model ensures the accuracy and comprehensiveness of compatibility analysis while effectively improving upgrade efficiency.

Description

Technical Field

[0001] This application relates to the field of upgrade compatibility analysis technology, and in particular to an open-source component vulnerability upgrade compatibility analysis method and electronic device. Background Technology

[0002] With open-source components becoming a global trend, upgrades to open-source components are inevitable. However, upgrading frameworks and components often leads to compatibility and security issues. Therefore, addressing compatibility issues between different versions of open-source components has become an urgent problem to be solved.

[0003] Currently, SCA (Software Component Analysis) tools can identify vulnerabilities in open-source components in projects, and most of their remediation suggestions recommend upgrading the version. 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 version number difference (such as whether it crosses a major version 1.0.1, if it is 2.0.1, it crosses a major version). However, there is no necessary correlation between upgrading a component across major versions and incompatibility.

[0004] Without definitive compatibility analysis results, in order to ensure the normal and stable operation of the upgraded functions, development and testing personnel still need to invest extra time and effort in preliminary research and analysis and post-upgrade testing and verification. This results in low repair efficiency and significant resistance to the upgrade. Summary of the Invention

[0005] The main objective of this application is to propose a method and electronic device for analyzing the vulnerability upgrade compatibility of open-source components. The aim is to automatically pre-upgrade vulnerable components within open-source components to obtain upgrade compatibility information for each vulnerable component. This information is then integrated to construct a large-scale knowledge base. This large-scale model can then perform upgrade compatibility analysis on vulnerable components based on the knowledge base, ensuring the accuracy and comprehensiveness of the upgrade compatibility analysis results and effectively improving upgrade efficiency.

[0006] To achieve the above objectives, a first aspect of this application proposes a method for compatibility analysis of open-source component vulnerability upgrades, the method comprising:

[0007] Identify vulnerable components among the open-source components called by the project files;

[0008] Automated pre-upgrade verification is performed on the vulnerable components to obtain upgrade compatibility information for the vulnerable components;

[0009] The upgrade compatibility information of each vulnerability component corresponding to different project files is integrated, and a knowledge base of a large model is constructed. The knowledge base includes the component name, version number before upgrade, version number after upgrade, upgrade compatibility result, calling method, calling code snippet, and repair code example corresponding to each vulnerability component.

[0010] The large model is used to perform upgrade compatibility analysis on the vulnerable components in the open-source components called by the project file under test, and the upgrade compatibility results for each vulnerable component are obtained.

[0011] In one embodiment of this application, the vulnerable component among the open-source components called by the project file that contains vulnerabilities includes:

[0012] The project files were analyzed using a software component analysis tool to identify the open-source components called by the project files.

[0013] The software component analysis tool was used to scan each of the open-source components to identify the vulnerable components.

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

[0015] Scan the source code of the project files to extract the component dependency chain;

[0016] Based on the component dependency chain, determine the introduction method of each vulnerable component;

[0017] Based on the method in which the vulnerability component was introduced, the corresponding vulnerability component is upgraded;

[0018] After upgrading each of the aforementioned vulnerable components, the project is redeployed based on the aforementioned project files;

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

[0020] If the deployment proceeds without issues, the deployed project will be tested using 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 this application, determining the upgrade method adopted by each of the vulnerability components based on the way the vulnerability components were introduced includes:

[0022] If the vulnerability component is introduced directly, the version number of the vulnerability component in the configuration file corresponding to the project file is modified to the fix version number in order to upgrade and fix the vulnerability component.

[0023] If the vulnerable component is introduced via indirect dependency, then 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 patch 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 fix version number, then the current version number of the parent component is upgraded to the latest version number to upgrade and fix the vulnerable component.

[0027] If the version number of the vulnerable component referenced by the parent component under the latest version number is less than the fix version number, then a new declaration is added to the configuration file corresponding to the project file to introduce the component name and the corresponding fix version number of the vulnerable component, so as to upgrade and fix the vulnerable component.

[0028] In one embodiment of this application, the upgrade compatibility result of each vulnerability component is determined by rolling back the upgraded and patched vulnerability components one by one, redeploying the project, and checking whether the deployment is abnormal.

[0029] Obtain all upgraded and patched vulnerability components, and build a vulnerability component set;

[0030] Randomly select a target vulnerability component from the set of vulnerability components, and revert the target vulnerability component to its original state before the upgrade;

[0031] After reverting the target vulnerable component to its original state before the upgrade, redeploy the project based on the project files and check whether the deployment is abnormal.

[0032] If the deployment is normal, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, while the other vulnerability components in the vulnerability component set, excluding the target vulnerability component, are compatible with the upgrade.

[0033] If an anomaly occurs during deployment, it is determined whether the error message of the current anomaly is consistent with the error message of the first anomaly. The first anomaly is the anomaly that occurs when the project is redeployed based on the project file after upgrading each of the vulnerability components.

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

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

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

[0037] If the error message of the current anomaly is inconsistent with the error message of the first anomaly, 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] The target vulnerable component is excluded from the vulnerable component set to update the vulnerable component set;

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

[0040] In one embodiment of this application, if an anomaly occurs during deployment, the method further includes:

[0041] Calculate the incompatibility probability of each upgraded and patched vulnerability component;

[0042] The upgrade compatibility results of each vulnerability component are determined by rolling back the upgrades one by one according to the incompatibility probability from highest to lowest, redeploying the project, and checking whether the deployment is abnormal.

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

[0044] The redeployed project was tested using the automated regression test cases corresponding to the project files.

[0045] If the automated regression test cases pass, then the upgrade compatibility of each of the vulnerability components is confirmed.

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

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

[0048] Calculate the incompatibility probability of each upgraded and patched vulnerability component;

[0049] The upgrade compatibility results of each vulnerability component are determined by rolling back the upgrade in descending order of incompatibility probability for each upgraded and then retesting using the automated regression test cases.

[0050] In one embodiment of this application, when the upgrade compatibility result of the vulnerable component is determined to be upgrade incompatible after automated pre-upgrade verification of the vulnerable component, a sample of fix code is also generated;

[0051] Correspondingly, when the upgrade compatibility result of the vulnerability component output by the large model is that the upgrade is incompatible, the large model also outputs a corresponding fix code example.

[0052] To achieve the above objectives, a second aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in any embodiment of this application.

[0053] In one embodiment of the technical solution provided in this application, automated pre-upgrade verification is performed on vulnerable components in the open-source components called by the project files to obtain upgrade compatibility information of the vulnerable components. Then, by integrating the upgrade compatibility information of each vulnerable component corresponding to different project files, a knowledge base for a large model can be constructed. 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 example for each vulnerable component. This allows the large model to rely on this knowledge base to perform upgrade compatibility analysis on vulnerable components in the open-source components called by the project files under test, obtaining upgrade compatibility results for each vulnerable component. In other words, the large model's compatibility analysis based on the knowledge base ensures the accuracy and comprehensiveness of the component upgrade compatibility analysis results, while effectively improving upgrade efficiency. Attached Figure Description

[0054] Figure 1 This is a flowchart of an open-source component vulnerability upgrade compatibility analysis method provided in an embodiment of this application;

[0055] Figure 2 This is a flowchart of the steps for obtaining a vulnerable component from an open-source component called by a project file, according to an embodiment of this application.

[0056] Figure 3 This is a flowchart of the steps for automatically pre-upgrading a vulnerable component to obtain upgrade compatibility information of the vulnerable component, according to an embodiment of this application.

[0057] Figure 4This is a flowchart illustrating the steps of upgrading a corresponding vulnerable component based on the method of introducing the vulnerable component, according to an embodiment of this application.

[0058] Figure 5 This is a flowchart provided in one embodiment of the present application, which shows how to determine the upgrade compatibility results of each vulnerability component by rolling back the upgraded and patched vulnerability components one by one, redeploying the project, and checking whether the deployment is abnormal.

[0059] Figure 6 This is a flowchart of the steps performed when a project is redeployed after upgrading various vulnerable components, but an anomaly occurs during deployment, as provided in one embodiment of this application.

[0060] Figure 7 This is a flowchart of the steps provided in one embodiment of the present application to test the deployed project using automated regression test cases corresponding to the project files in order to determine the upgrade compatibility results of each vulnerable component;

[0061] Figure 8 This is a flowchart of an embodiment of the present application, which shows how to determine the upgrade compatibility results of each vulnerability component by rolling back the upgraded and patched vulnerability components one by one and then retesting them using automated regression test cases.

[0062] Figure 9 This is a flowchart of the steps to be executed when test case tests fail after upgrading and successfully redeploying the project for each vulnerable component, according to an embodiment of this application.

[0063] Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] It should be noted that although functional modules are divided in the device schematic diagram and a 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 aforementioned 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 commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0067] Open-source components are widely used in software development, which, while improving development efficiency, also increases the security risks to software. Given the proliferation of vulnerabilities in open-source software, the industry has begun to pay attention to and address the security governance of open-source components.

[0068] However, in actual open-source component security governance, we generally face problems such as high remediation costs and low remediation efficiency. The main reason is that vulnerability remediation of open-source components is usually achieved by upgrading the version. The component upgrade operation is not complicated; it only requires modifying the version number in the corresponding configuration file. However, component upgrades can 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] To ensure component upgrade compatibility and reliability, developers spend a significant amount of time conducting research and analysis before implementing the upgrade. After the upgrade, testers need to perform regression testing on the relevant functions, which greatly prolongs the vulnerability patching process for open-source components.

[0070] In related technologies, upgrade compatibility is often simply assessed by whether a component undergoes a major version upgrade, or by comparing the interface changes of the open-source component before and after the upgrade. However, major version upgrades do not necessarily guarantee incompatibility. Comparing interface changes only reveals compatibility variations specific to the component itself and does not represent the actual compatibility of a particular project. Consequently, without definitive compatibility analysis results, developers and testers still need to invest additional time and effort in preliminary research and analysis, as well as post-upgrade testing and verification, to ensure stable functionality after the upgrade. This results in low fix efficiency and significant upgrade resistance.

[0071] Based on this, this application proposes an open-source component vulnerability upgrade compatibility analysis method. By automatically pre-upgrading and verifying the vulnerable components in the open-source components, the upgrade compatibility information of each vulnerable component is obtained. Then, the information is integrated and constructed to obtain a knowledge base of a large model. The large model can then perform upgrade compatibility analysis on the vulnerable components based on this knowledge base, which can ensure the accuracy and comprehensiveness of the upgrade compatibility analysis results and effectively improve upgrade efficiency.

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

[0073] Step S110: Obtain the vulnerable components among the open-source components called by the project files.

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

[0075] Reference Figure 2 , Figure 2 This is a flowchart of the steps for obtaining a vulnerable component in an open-source component called by a project file, as provided in an embodiment of this application, including but not limited to steps S210 to S220.

[0076] Step S210: Perform open source component analysis on the project file using a software component analysis tool to obtain several open source components called by the project file.

[0077] Step S220: Scan each open-source component using a software component analysis tool to identify vulnerable components.

[0078] In this embodiment, open-source component analysis of project files is performed using a Software Composition Analysis (SCA) tool to obtain several open-source components called by each project file. Scanning these open-source components with SCA then identifies vulnerable components. Specifically, SCA can be integrated into the CI / CD pipeline to perform open-source component analysis, thereby obtaining the various open-source components called by the project files. Scanning further reveals vulnerable components within these open-source components. For example, if an SCA scan reveals 10 vulnerable components in project A, the current version number of these 10 vulnerable components, along with the version number to which they should be upgraded (i.e., the patched version number), is recorded.

[0079] Step S120: Perform automated pre-upgrade verification on the vulnerable components to obtain upgrade compatibility information for the vulnerable components.

[0080] In this embodiment, after determining the list of vulnerable components corresponding to the project files, automated pre-upgrade verification can be performed on each vulnerable component to obtain its upgrade compatibility results. Furthermore, if the upgrade compatibility result of a vulnerable component is determined to be incompatible, corresponding patch code examples can be generated. This reduces the workload of manual analysis and lowers the cost of vulnerability patching.

[0081] Reference Figure 3 , Figure 3 This is a flowchart of steps for automatically pre-upgrading a vulnerable component to obtain upgrade compatibility information of the vulnerable component, provided by an embodiment of this application, including but not limited to steps S310 to S360.

[0082] Step S310: Scan the source code of the project files to extract the component dependency chain;

[0083] Step S320: Determine the import method of each vulnerable component based on the component dependency chain;

[0084] Step S330: Upgrade the corresponding vulnerable component according to the way the vulnerable component was introduced;

[0085] Step S340: After upgrading each vulnerable component, redeploy the project based on the project files;

[0086] Step S350: If there is an anomaly in the deployment, the upgrade compatibility result of each vulnerability component is determined by rolling back the upgraded and patched vulnerability components one by one, redeploying the project, and checking whether the deployment is abnormal.

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

[0088] In this embodiment, the source code of the project files can first be scanned using a Software Composition Analysis (SCA) tool to extract component dependency chains. For example, by analyzing configuration files such as pom.xml and build.gradle in the project file's source code, component dependency chains can be extracted. Based on these dependency chains, the import method of each vulnerable component can be determined, and thus, the upgrade method for each vulnerable component can be determined based on its different import methods. Therefore, the corresponding vulnerable component can be upgraded based on the determined upgrade method. If the vulnerable component is directly imported, it can be directly upgraded and fixed. If the vulnerable component is indirectly imported, it can be fixed by upgrading its parent component or by upgrading the vulnerable component itself.

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

[0090] Step S410: If the vulnerability component is imported directly, the version number of the vulnerability component in the configuration file corresponding to the project file is modified to the repair version number in order to upgrade and repair the vulnerability component.

[0091] Step S420: If the vulnerable component is introduced via indirect dependency, then obtain the parent component of the vulnerable component based on the component dependency chain.

[0092] Step S430: Obtain the current version number of the parent component and find the latest version number of the parent component under the current major version number;

[0093] Step S440: 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 patch 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, then upgrade the current version number of the parent component 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 less than the fix version number, then add a declaration of the component name and the corresponding fix version number of the imported vulnerable component in the configuration file corresponding to the project file, so as to upgrade and fix the vulnerable component.

[0096] In this embodiment, if the vulnerable component to be patched is directly imported, the declaration in the project file's configuration file will contain information such as the component name and current version number of the vulnerable component. In this case, after locating the vulnerability through regular expression matching or tag number parsing, the current version number of the vulnerable component in the project file's configuration file can be directly modified to the patched version number. This means that during the actual project build, the patched version (higher version) will replace the original version (lower version) of the vulnerable component, thus upgrading and patching the vulnerable component. However, if the vulnerable component to be patched is indirectly imported via dependency, it is necessary to further obtain the parent component of the vulnerable component based on the component dependency chain. The parent component is a component directly imported by the project, which in turn depends on and imports the vulnerable component to be patched. For example, if the vulnerable component to be patched is component A, the parent component of component A is component C obtained through the component dependency chain. Component C is a component directly imported by the project, and component C depends on and imports component A. Then, the current version number of the parent component is obtained, and the latest version number of the parent component under the current major version number is searched and found. If the current version number of the parent component is 1.1, then the latest version of the parent component under the current major version number (i.e., under major version 1.0) is searched. For example, 1.8 is the latest version of the parent component under major version 1.0. Next, it is determined 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 patch 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 patch version number, then the vulnerable component can be patched by upgrading the parent component. This means upgrading the current version number of the parent component to the latest version number to patch the vulnerable component. For example, if the patch version number of the vulnerable component A to be patched is 1.7, and the version number of the vulnerable component A referenced by the parent component C under the latest version number (e.g., version 1.8) 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), which will correspondingly upgrade the version number of the vulnerable component A to 1.8 (greater than the patch version number 1.7), thus patching the vulnerable component A. If the version number of a vulnerable component referenced by a parent component (under the latest version number) is lower than the patch version number, upgrading the parent component will not fix the vulnerable component. Therefore, the vulnerable component needs to be patched directly. Since the vulnerable component is imported via indirect dependency, its information will not be included in the project's configuration file. In this case, the vulnerable component can be upgraded and patched by adding a declaration to the project's configuration file specifying the component name and corresponding patch version number that imports it.If the patch version number of the vulnerability component A to be patched 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 version 1.8) is 1.6, since 1.6 is less than 1.7, upgrading the current version number (1.1) of the parent component C to the latest version number (1.8) will not patch the vulnerability component. Therefore, it is necessary to add a declaration to the configuration file of the project file to import the component name and patch version number of the vulnerability component A in order to patch the vulnerability component A.

[0097] After upgrading and patching each vulnerable component, the project is redeployed based on the project files, and the deployment is checked for any anomalies. If anomalies are found, it indicates that some vulnerable components have upgrade compatibility issues. The upgrade compatibility results for each modified vulnerable component can be determined by checking for deployment anomalies. If the deployment is normal, there may not be any vulnerable components with upgrade compatibility issues. In this case, the deployed project can be further tested using automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerable component. Specifically, if deployment anomalies are found, the upgrade compatibility results of each vulnerable component can be determined by reverting the upgraded and patched vulnerable components one by one, redeploying the project, and checking for deployment anomalies. If the deployment is normal, the upgrade compatibility results of each vulnerable component can be determined by reverting the upgraded and patched vulnerable components one by one and retesting them using automated regression test cases.

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

[0099] Step S510: Obtain all upgraded and patched vulnerability components and build a vulnerability component set;

[0100] Step S520: Randomly select a target vulnerability component from the vulnerability component set and revert the target vulnerability component to its original state before the upgrade;

[0101] Step S530: Redeploy the project based on the project files;

[0102] Step S540: Check if the deployment is abnormal;

[0103] Step S550: If there are no abnormalities in the deployment, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, while the other vulnerability components in the vulnerability component set are compatible with the upgrade.

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

[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 for upgrade, but there are other vulnerability components in the vulnerability component set that are incompatible for upgrade.

[0106] Step S580: After upgrading and repairing the target vulnerability component again, remove the target vulnerability component from the vulnerability component set, update the vulnerability component set, and then return 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: Remove the target vulnerable component from the vulnerable component set, update the vulnerable component set, and then return to step S520.

[0109] In this embodiment, after all vulnerable components in the current project have been upgraded and patched, the project can be rebuilt and redeployed based on the upgraded components. If a deployment anomaly is detected, the upgrade compatibility of each vulnerable component can be determined by reverting the upgraded and patched components one by one, redeploying the project, and checking for deployment anomalies. For example, if the current project calls three vulnerable open-source components (components A, B, and C), and after upgrading and patching these three components, redeploying the project results in a deployment anomaly, it indicates that one of these three components has upgrade compatibility issues. In this case, any one of these three vulnerable components can be selected. If component A is selected, it can be reverted from its upgraded state to its original state before the upgrade. For example, if component A's version number before the upgrade is 1.1 and the upgraded version is 1.5, then component A's version number can be reverted from 1.5 back to 1.1. At this point, only components B and C have been upgraded, while component A has not. Next, rebuild and redeploy the project. If the deployment proceeds without issues, it indicates that component A can be deployed normally after the upgrade, and components B and C are compatible. The initial anomaly was caused by incompatibility in component A, thus concluding that component A is incompatible while components B and C are compatible. However, if the anomaly persists after redeploying component A, it's necessary to further check if the current error message matches the initial one. If they match, the cause of the anomaly persists after the upgrade, indicating that component A is not the cause of the anomaly. This means component A is compatible, and the anomaly is likely caused by incompatibility in other components. In this case, it's necessary to arbitrarily select one of the remaining vulnerable components (including components B and C), for example, component B, and revert it from its upgraded state to its pre-upgrade state. For instance, if component B's version number was 1.1 before the upgrade and 1.5 after, revert component B's version number from 1.5 back to 1.1. Furthermore, since component A has been confirmed to be compatible for the upgrade, it can be upgraded again using the previous upgrade method. For example, to fix a vulnerability in component A, it was upgraded from version 1.1 to version 1.5. After reverting the upgrade (reverting component A from version 1.5 back to 1.1) and confirming compatibility, component A needs to be upgraded from version 1.1 to version 1.5 again. At this point, components A and C are in their upgraded state, while component B is in its pre-upgrade state. The project is then rebuilt and deployed. If the deployment is error-free, it indicates that component B can be deployed normally after the upgrade revert, and the initial error was caused by incompatibility in component B. Therefore, it can be concluded that component B is incompatible, while components A and C are compatible.If the anomaly persists after redeploying component B following the upgrade, further investigation is needed to verify if the current error message matches the initial error message. If they match, meaning the error message causing the anomaly hasn't changed after the upgrade, it indicates the cause isn't component B's upgrade incompatibility. This suggests component B is compatible, and the anomaly is likely due to incompatibility with other components, leading to the conclusion that component C's upgrade is incompatible. To further verify if component C is indeed incompatible, it can be reverted from its upgraded state to its pre-upgrade state. For example, if component C's version number was 1.1 before the upgrade and 1.5 after, revert it back to 1.1. Furthermore, since component A and component B are now confirmed to be compatible, they can be upgraded again using the previous upgrade method. At this point, components A and B are in their upgraded state, while component C has reverted to its pre-upgrade state. The project is then rebuilt and deployed. If the deployment proceeds without errors, it indicates that component C can be deployed normally after the upgrade, and the initial anomaly was caused by incompatibility in component C. Therefore, the upgrade compatibility results for these three vulnerable components in the current project can be determined as follows: components A and B are compatible, while component C is incompatible. Since component C is incompatible, sample code to fix the vulnerability in component C can be generated.

[0110] If component A still exhibits anomalies after being rolled back and redeployed, and the current error message differs from the initial error message (meaning that while deployment remains abnormal after rollback, the error message has changed), it indicates that the anomaly is not solely caused by component A's incompatibility; other component upgrade incompatibilities also contribute. In this case, it can be confirmed that component A is incompatible, and that other components also exhibit incompatibility. To determine which remaining vulnerable components are incompatible, it is necessary to arbitrarily select one more vulnerable component (including components B and C). For example, if component B is selected, it should be rolled back from its upgraded state to its pre-upgrade state. For instance, if component B's version number was 1.1 before the upgrade and 1.5 after, its version number should be rolled back from 1.5 to 1.1. Furthermore, since component A's upgrade incompatibility has been confirmed, it should be maintained in its pre-upgrade state. At this point, components A and B are in their pre-upgrade state, and component C is in its post-upgrade state. Next, the project is rebuilt and redeployed. If the deployment proceeds without errors, it indicates that components A and B can be deployed normally after the upgrade, and the initial error was caused by incompatibility between components A and B. Therefore, it can be concluded that components A and B are incompatible after the upgrade, while component C is compatible. However, if the error persists after redeploying components A and B, it's necessary to further check if the current error message matches the initial error message. If they match, meaning the error message causing the error after the upgrade of components A and B hasn't changed, it indicates that component B is compatible. The cause of the error is likely incompatibility with other components, meaning the error is caused by incompatibility between components A and C. Therefore, it can be concluded that components A and C are incompatible after the upgrade, while component B is compatible. If components A and B still exhibit anomalies after being rolled back and redeployed, and the current error messages differ from the initial error messages (meaning the rollback caused a change in the error messages), it indicates that component B is incompatible with the upgrade. Furthermore, other components (i.e., component C) are also incompatible, leading to the conclusion that components A, B, and C are incompatible. To further verify whether all three components are incompatible, component C can be rolled back from its upgraded state to its pre-upgrade state. Now, components A, B, and C are all in their pre-upgrade states. Rebuild and redeploy the project. If the deployment proceeds without anomalies, it indicates that components A, B, and C can be deployed normally after the rollback, and the initial anomaly was caused by the incompatibility of these three components. Therefore, the upgrade compatibility result for these three vulnerable components in the current project is: components A, B, and C are all incompatible with the upgrade.At this point, sample code for fixing vulnerabilities in component A, component B, and component C can be generated.

[0111] It should be noted that the initial anomaly refers to the anomaly that occurs when redeploying the project based on the project files after upgrading each vulnerable component. Taking the scenario where the vulnerable components of the current project include component A, component B, and component C as an example, the initial anomaly refers to the anomaly that occurs when redeploying the current project after upgrading and fixing components A, B, and C, that is, when deploying the project in the upgraded state.

[0112] In some embodiments, to improve the efficiency of determining the upgrade compatibility results of each vulnerable component, the incompatibility probability of each vulnerable component corresponding to the current project can be analyzed to determine the incompatibility probability of each vulnerable component. This allows for the determination of the upgrade compatibility results of each vulnerable component by sequentially reverting the upgraded and patched vulnerable components to their lowest incompatibility probability, redeploying the project, and checking for deployment anomalies. This improves the efficiency of vulnerable component upgrade compatibility analysis.

[0113] Reference Figure 6 , Figure 6 This is a flowchart of the steps to be executed when the project is redeployed after upgrading each vulnerable component, but the deployment is abnormal, as provided in one embodiment of this application, including but not limited to steps S610 to S620.

[0114] Step S610: Calculate the incompatibility probability of each upgraded and patched vulnerability component;

[0115] Step S620: Determine the upgrade compatibility results of each vulnerability component by rolling back the upgraded and patched components one by one in descending order of incompatibility probability, redeploying the project, and checking whether the deployment is abnormal.

[0116] In this embodiment of the application, when the project is redeployed after upgrading each vulnerable component, but an anomaly occurs during deployment, the incompatibility probability of each upgraded and patched vulnerable component can be statistically analyzed. The incompatibility probability of a vulnerable component can be represented by an incompatibility score. Specifically, the statistical analysis of the component incompatibility score can include three aspects:

[0117] (1) Analyze the error messages that can be parsed to extract potential component information. Search using the names of the components that the project depends on. If a relevant record exists, it indicates that the component may be incompatible. If the component is in the list of components to be upgraded, add 4 points to the component; if the component is not in the list of components to be upgraded, further search in the project's component dependencies, checking its parent components layer by layer. If a corresponding parent component exists in the upgrade list, add 4 points to the parent component.

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

[0119] i. When the compatibility status is incompatible, the knowledge base records the corresponding incompatible calling methods. Therefore, it is possible to check whether the project uses this method to call the corresponding method. Download the project source code and parse it. If the corresponding call exists in the project source code and the version number matches, the component will be awarded 5 points.

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

[0121] iii. If there are records of compatible calling methods for this version of the component used in the project, then -2 points will be awarded.

[0122] (3) Check whether the component has been upgraded across major versions. If so, 1 point will be awarded.

[0123] After calculation, the incompatibility scores of each component can be counted and sorted from high to low. This allows for the determination of the upgrade compatibility results of each vulnerability component by reverting to the previous upgrade in order of incompatibility probability (i.e., incompatibility score) from high to low, redeploying the project, and checking for abnormal deployment. This improves the efficiency of upgrade compatibility analysis for each vulnerability component.

[0124] Taking the scenario where the vulnerable components in the current project include components A, B, and C as an example, if the incompatibility probability of components A, B, and C is calculated to be ranked as follows: component A is more likely to be incompatible than component B, which is more likely to be incompatible than component C, then the optimal execution for rolling back the upgraded and patched vulnerable components would be to first roll back component A and verify it, then roll back component B and verify it, and finally roll back component C and verify it. Since component A has the highest incompatibility probability, a significant cause of deployment anomalies is likely due to incompatibility in component A. Therefore, a single rollback verification can determine the upgrade compatibility of each vulnerable component, thereby improving the efficiency of upgrade compatibility analysis for each vulnerable component.

[0125] In this embodiment of the application, after upgrading each vulnerable component and rebuilding and deploying the project, if there are no abnormalities in the deployment, the deployed project can be further tested using the automated regression test cases corresponding to the project files to determine the upgrade compatibility results of each vulnerable component.

[0126] Reference Figure 7 , Figure 7 This application provides a flowchart of steps for testing a deployed project using automated regression test cases corresponding to the project file to determine the upgrade compatibility results of each vulnerable component, including but not limited to steps S710 to S730.

[0127] Step S710: Test the redeployed project using the automated regression test cases corresponding to the project files;

[0128] Step S720: If the automated regression test cases pass, then determine the upgrade compatibility of each vulnerability component;

[0129] Step S730: If the automated regression test case fails, the upgrade compatibility result of each vulnerability component is determined by reverting the upgraded and patched vulnerability components one by one and then retesting them using the automated regression test cases.

[0130] In this embodiment, after upgrading each vulnerable component and rebuilding and redeploying the project, if the deployment is error-free, the deployed project can execute automated regression test cases. If the automated regression test cases pass, it can be determined that each vulnerable component is upgraded and compatible. If the automated regression test cases fail, the upgrade compatibility results of each vulnerable component can be determined by reverting the upgraded and patched vulnerable components one by one and then retesting them using automated regression test cases.

[0131] Reference Figure 8 , Figure 8 This is a flowchart provided by an embodiment of the present application, which describes a method for determining the upgrade compatibility results of each vulnerability component by rolling back the upgraded and patched 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: Obtain all upgraded and patched vulnerability components and build a vulnerability component set;

[0133] Step S820: Randomly select a target vulnerability component from the vulnerability component set and revert the target vulnerability component to its original state before the upgrade;

[0134] Step S830: Retest the project based on automated regression test cases;

[0135] Step S840: Check whether the test case has passed;

[0136] Step S850: If successful, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, while the other vulnerability components in the vulnerability component set are compatible with the upgrade.

[0137] Step S860: If the error does not pass, determine whether the current error message is consistent with the initial error message.

[0138] Step S870: If the current error message is consistent with the initial error message, it is determined that the target vulnerability component in the vulnerability component set is compatible for upgrade, but there are other vulnerability components in the vulnerability component set that are incompatible for upgrade.

[0139] Step S880: After upgrading and repairing the target vulnerability component again, remove the target vulnerability component from the vulnerability component set, update the vulnerability component set, and return to step S820.

[0140] Step S890: If the current error message is inconsistent with the initial 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: Remove the target vulnerable component from the vulnerable component set, update the vulnerable component set, and then return to step S820.

[0142] In this embodiment, after all vulnerable components in the current project have been upgraded and patched, the project can be rebuilt and deployed based on the upgraded components. If no deployment anomalies are detected, but the automated regression test cases fail, the upgrade compatibility results of each vulnerable component can be determined by reverting the upgraded and patched vulnerable components one by one and then retesting them using automated regression test cases. For example, if there are three vulnerable components (component A, component B, and component C) among the open-source components called by the current project, after upgrading and patching these three vulnerable components and rebuilding and deploying the project, it is found that the deployment is normal, but the automated regression test cases fail. This indicates that one of these three vulnerable components has upgrade compatibility issues. In this case, any one of these three vulnerable components can be selected. For example, if component A is selected, component A can be reverted from its upgraded state to its original state before the upgrade. For example, if component A's version number before the upgrade is 1.1 and the upgraded version is 1.5, then component A's version number can be reverted from 1.5 back to 1.1. At this point, only components B and C have been upgraded in the current project, while component A has not been upgraded. Next, the project is retested using automated regression test cases. If the test passes, meaning component A passes the upgrade test, it indicates that components B and C are compatible. The initial test failure was due to incompatibility with component A, concluding that component A is incompatible while components B and C are compatible. However, if component A still fails the retest after the upgrade, the current error message in the logs needs to be checked against the initial error message. If they match, the cause of the test failure after the upgrade hasn't disappeared, indicating that the failure is not due to component A's incompatibility. This means component A is compatible, and the failure is likely caused by incompatibility with other components. In this case, another vulnerable component (including components B and C) needs to be randomly selected from the remaining vulnerable components. For example, if component B is selected, it needs to be reverted from its upgraded state to its pre-upgrade state. For instance, if component B's version number was 1.1 before the upgrade and 1.5 after, its version number should be reverted from 1.5 back to 1.1. Furthermore, since component A has been confirmed to be compatible for the upgrade, it can be upgraded again using the previous upgrade method. For example, if component A was upgraded from version 1.1 to version 1.5 to fix a vulnerability, and then rolled back (reverting component A from version 1.5 to 1.1) to confirm compatibility, component A needs to be upgraded from version 1.1 to version 1.5 again.At this point, components A and C are in their upgraded state, while component B has reverted to its pre-upgrade state. The test cases are then rerun. If the test passes, meaning component B passes after the upgrade, the initial test failure was due to incompatibility with the component B upgrade. This indicates that component B is incompatible, while components A and C are compatible. However, if component B still fails the test after the upgrade, the current error message in the logs needs to be checked against the initial error message. If they match, the error message causing the test failure hasn't changed after the upgrade, indicating that the cause isn't component B's incompatibility. This means component B is compatible, and the failure is likely due to incompatibility with other components. Therefore, the cause of the anomaly is likely component C's incompatibility. To further verify if component C is indeed incompatible, it can be reverted from its upgraded state to its pre-upgrade state. For example, if component C's version number was 1.1 before the upgrade and 1.5 after, the version number can be reverted from 1.5 back to 1.1. Furthermore, since component A and component B have been confirmed to be upgrade-compatible, they can be upgraded again using the previous upgrade method. At this point, components A and B are in their upgraded state, while component C is reverted to its pre-upgrade state. Test cases are then run again. If the test passes (meaning component C passes the reverted upgrade test), it indicates that the initial test failure was due to component C's upgrade incompatibility. Therefore, the upgrade compatibility results for these three vulnerable components in the current project can be determined as follows: component A and component B are upgrade-compatible, while component C is upgrade-incompatible. Since component C is upgrade-incompatible, sample code for fixing the vulnerability in component C can be generated.

[0143] If component A fails the test again after being rolled back from the upgrade, and the current error message in the log is inconsistent with the initial error message (meaning the test still fails but the error message changes), it indicates that the test failure is not solely due to component A's incompatibility, but also to incompatibility with other components. In this case, it can be determined that component A is incompatible, and that other components also have incompatibility issues. To determine which of the remaining vulnerable components is incompatible, we need to arbitrarily select one more vulnerable component (including components B and C), for example, component B. We then roll back component B from its upgraded state to its pre-upgrade state. For instance, if component B's version number was 1.1 before the upgrade and 1.5 after, we roll back component B's version number from 1.5 to 1.1. Furthermore, since component A has been identified as incompatible, it must be kept in its pre-upgrade state. At this point, components A and B are in their pre-upgrade state, and component C is in its post-upgrade state. Next, test cases are run again. If the test passes, it means that the test cases for components A and B passed after the upgrade, and the initial test failure was due to incompatibility between components A and B after the upgrade. Therefore, we can conclude that components A and B are incompatible after the upgrade, while component C is compatible. However, if components A and B still fail the retest after the upgrade, we need to further check if the current error message in the logs matches the initial error message. If they match, meaning the error message causing the test failure for components A and B hasn't changed after the upgrade, it indicates that component B is compatible. The cause of the anomaly is likely incompatibility with other components, meaning the anomaly is caused by incompatibility between components A and C. Therefore, we can conclude that components A and C are incompatible after the upgrade, while component B is compatible. If components A and B fail the test again after being rolled back from the upgrade, and the current error message in the log is inconsistent with the initial error message, indicating that the error message causing the test failure has changed after the upgrade, it suggests that component B is incompatible with the upgrade. Furthermore, other components (i.e., component C) are also incompatible, leading to the conclusion that components A, B, and C are incompatible. To further verify whether all three components are incompatible, component C can be rolled back from its upgraded state to its pre-upgrade state. Now, components A, B, and C are all in their pre-upgrade states. Re-executing the test results shows that if the test passes, it means that components A, B, and C pass the test after the upgrade, and the initial failure was caused by the incompatibility of all three components. Therefore, the upgrade compatibility result for these three vulnerable components in the current project is: components A, B, and C are all incompatible with the upgrade.At this point, sample code for fixing vulnerabilities in component A, component B, and component C can be generated.

[0144] It should be noted that the initial error message refers to the error message that occurs after upgrading and successfully redeploying the project for each vulnerable component, and the test cases still fail. Taking the example of the current project containing vulnerable components A, B, and C, the initial error message refers to the error message that occurs after upgrading and fixing all three components and successfully redeploying the project, and the test cases still fail. In other words, the error message indicates that the test cases fail even after all three components (A, B, and C) have been upgraded.

[0145] In some embodiments, to improve the efficiency of determining the upgrade compatibility results of each vulnerable component, the incompatibility probability of each vulnerable component corresponding to the current project can be analyzed to determine the incompatibility probability of each vulnerable component. This allows for the determination of the upgrade compatibility results of each vulnerable component by sequentially reverting the upgraded and patched vulnerable components to an incompatibility probability ranking from highest to lowest, and then retesting them using automated regression test cases. This improves the efficiency of vulnerable component upgrade compatibility analysis.

[0146] Reference Figure 9 , Figure 9 This is a flowchart of the steps to be executed when the test case fails after upgrading and successfully redeploying the project for each vulnerable component, as provided in an embodiment of this application. These steps include, but are not limited to, steps S910 to S920.

[0147] Step S910: Calculate the incompatibility probability of each upgraded and patched vulnerability component;

[0148] Step S920: The upgrade compatibility results of each vulnerability component are determined by rolling back the upgrade one by one according to the order of incompatibility probability from highest to lowest, and then retesting using automated regression test cases.

[0149] In this embodiment of the application, after upgrading and successfully redeploying the project for each vulnerable component, but the test cases fail, the incompatibility probability of each upgraded and patched vulnerable component can be statistically analyzed. The incompatibility probability of a vulnerable component can be represented by an incompatibility score. Specifically, the statistical analysis of the component incompatibility score can include three aspects:

[0150] (1) Extract the interface information corresponding to the automated test cases, then pull the source code, analyze the interface code, and check whether there are any calls to open source components in the upgrade list. If so, add 4 points to the corresponding component incompatibility score.

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

[0152] i. When the compatibility status is incompatible, the knowledge base records the corresponding incompatible calling methods. Therefore, it is possible to check whether the project uses this method to call the corresponding method. Download the project source code and parse it. If the corresponding call exists in the project source code and the version number matches, the component will be awarded 5 points.

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

[0154] iii. If there are records of compatible calling methods for this version of the component used in the project, then -2 points will be awarded.

[0155] (3) Check whether the component has been upgraded across major versions. If so, 1 point will be awarded.

[0156] After calculation, the incompatibility scores of each component can be counted and sorted from high to low. This allows for the rollback of upgraded and patched vulnerability components in descending order of incompatibility probability, followed by retesting using automated regression test cases to determine the upgrade compatibility results of each vulnerability component. This improves the efficiency of upgrade compatibility analysis for each vulnerability component.

[0157] In this embodiment, after automatically pre-upgrading and verifying each vulnerability component corresponding to different projects, upgrade compatibility results for each vulnerability component can be obtained. When the upgrade compatibility result of a vulnerability component is upgrade compatible, the corresponding vulnerability component is marked as having good upgrade compatibility, and the component name, version number before upgrade, version number after upgrade, upgrade compatibility result, calling method, and sample fix code are recorded. For example, when component A is upgrade compatible, the following information can be recorded: Component A - 1.1.0 (version number before upgrade) - 1.2.1 (version number after upgrade) - compatible (upgrade compatibility result) - JSON Array.parseArray(str) (calling method) - none (sample fix code). When the upgrade compatibility result of a vulnerability component is upgrade incompatible, developers need to modify the code, i.e., create a sample fix code. The unique identifier (commit_id) of the corresponding code submission is recorded through system process association. The corresponding code is pulled for analysis to extract the methods or classes of the open-source components involved. If incompatibility arises when component e is upgraded from version 1.2.5 to 1.3.1, and the developers confirm this, they supplement the code sample with modifications. The process automatically associates the unique identifier (component_id) corresponding to the code sample, then pulls and analyzes the modified code. If it involves methods or classes provided by open-source components, the corresponding code snippets will be recorded. For example, when component e is incompatible after the upgrade, the following information can be recorded: Component e - 1.2.5 (version number before upgrade) - 1.3.1 (version number after upgrade) - Incompatibility (upgrade compatibility result) - JSON Array.parseArray(str) (call method) - code sample for repair.

[0158] Step S130: Integrate the upgrade compatibility information of each vulnerability component corresponding to different project files, and build a knowledge base of a large model. The knowledge base includes the component name, version number before upgrade, version number after upgrade, upgrade compatibility result, calling method, calling code snippet, and repair code example corresponding to each vulnerability component.

[0159] In this embodiment, by performing automated pre-upgrade verification on vulnerable components in open-source components called by different project files, upgrade compatibility information for each vulnerable component corresponding to different project files can be obtained. Then, by integrating the upgrade compatibility information of each vulnerable component corresponding to different project files, a knowledge base for a large model can be constructed. The knowledge base may include the component name, pre-upgrade version number, post-upgrade version number, upgrade compatibility result, calling method, and sample fix code for each vulnerable component. By constructing this knowledge base, the speed and accuracy of obtaining component upgrade compatibility results can be improved during the automated pre-upgrade verification stage. Furthermore, the knowledge base can also be used for large model analysis. Moreover, by constructing this knowledge base, the large model can quickly and accurately output the upgrade compatibility results of vulnerable components in the open-source components called by the project file under test.

[0160] It should be noted that the knowledge base contains sample code fixes for incompatible vulnerability component upgrades across different projects. These fixes primarily document how various projects handle incompatible scenarios, providing a reference for developers. Additionally, a "like / dislike" mechanism is provided to allow developers to provide feedback on the code's accuracy, and to periodically remove poorly performing code fixes.

[0161] Step S140: Using a large model, perform upgrade compatibility analysis on the vulnerable components in the open-source components called by the project file under test, and obtain the upgrade compatibility results for each vulnerable component.

[0162] In this embodiment, after constructing the knowledge base of the large model, the upgrade compatibility analysis of vulnerable components in the open-source components called by the project file under test can be performed using the large model to obtain the upgrade compatibility results corresponding to each vulnerable component. Specifically, the project file under test can first be scanned using a Software Composition Analysis (SCA) tool to obtain vulnerable components in the open-source components called by the project file under test, and to obtain the current version number and patch version number of each vulnerable component. The source code of the project file under test is scanned and analyzed to extract the relevant parts that call each vulnerable component, that is, to extract the call code fragments of the source code that call the vulnerable components. Based on the extracted call code fragments of the source code that call the vulnerable components, problems can be assembled and generated. Specifically, the source code of the project file under test is pulled, and the code files are analyzed one by one. Using the methods called in the code as nodes, a method call tree is generated based on code abstraction. The generated method call tree is then traversed. When the method corresponding to a node is provided by a vulnerable component, the code fragment of the corresponding node is recorded. After the traversal is complete, the components are categorized by name and version number. The calling methods in the code are extracted. That is, for the same method within the same component, if the number of parameters, parameter types, and parameter order are consistent, it can be considered the same type of call, and only one of these calls needs to be retained. In this way, the code snippets calling the vulnerable component can be extracted from the source code. For example, a vulnerable component to be fixed in a project file under test includes component f. The source code of the project file under test is pulled and analyzed, and the code snippets calling component f are extracted. These code snippets are then assembled to generate an issue, such as "Please analyze whether there are any incompatibilities in upgrading component f. If there are incompatibilities, please provide a code fix example."

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

[0164] i. Define your role and objectives. For example: You are an open-source component vulnerability upgrade and compatibility analysis assistant, and you will analyze the compatibility of the specific version of the component and its calling method specified by the questioner, or provide remediation 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 - sample repair code;

[0166] iii. Clarify the context based on the question content: Since our questions are based on actual code calls and are more targeted than ordinary questions, and the knowledge base design also has corresponding fields, we can set them up as follows: 1. First, learn the method call compatibility and repair code examples of various versions of open-source components based on the knowledge base. 2. The question specifies the specific open-source component and version number, including the specific calling method; learn and understand the version and calling method used in the question. 3. Analyze whether the current calling method is compatible based on the compatibility records of the corresponding version of the component in the knowledge base. If not, modify and provide the corresponding repair code based on the questioner's code.

[0167] i v. Specify the output requirements, such as: whether the output includes: whether the component upgrade given in the problem is compatible, if not, provide the specific reasons, and provide a sample of the fix code.

[0168] In this embodiment, based on the constructed knowledge base and manually tuned prompts, the generated questions are sent to a large model for analysis to obtain the upgrade compatibility results of the vulnerable components analyzed by the large model. If the upgrade compatibility result of the vulnerable component output by the large model is upgrade compatible, then the vulnerable component is marked as upgrade compatible. If the upgrade compatibility result of the vulnerable component output by the large model is upgrade incompatible, the large model also outputs corresponding sample remediation code.

[0169] In this embodiment, a large model question is generated based on the actual call details of the source code of the project file under test, thus avoiding non-specific analysis results. By extracting and deduplicating code call methods, the question length can be effectively controlled, avoiding excessive resource consumption or analysis anomalies. Targeted generation and optimization of prompts make the model's responses more accurate and targeted. Based on a knowledge base accumulated and optimized from actual repair scenarios, questions accurately extracted from actual call details, and targeted optimization of prompts, accurate and feasible compatibility analysis results can be provided for real-world repair scenarios, generating effective repair code examples.

[0170] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned open-source component vulnerability upgrade compatibility analysis method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0171] Please see Figure 10 , Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device includes:

[0172] The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, 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 this application.

[0173] The memory 1002 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 using the open-source component vulnerability upgrade compatibility analysis method of the embodiments of this application.

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

[0175] The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

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

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

[0178] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by one embodiment of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by one embodiment of this application are also applicable to similar technical problems.

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

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

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

[0182] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0183] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0184] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0186] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0187] If the integrated unit is implemented as 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 this application, in essence, 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. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0188] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. An open source component vulnerability escalation compatibility analysis method, characterized in that, The method includes: Identify vulnerable components among the open-source components called by the project files; Automated pre-upgrade verification is performed on the vulnerable components to obtain upgrade compatibility information for the vulnerable components; The automated pre-upgrade verification of the vulnerable component to obtain upgrade compatibility information of the vulnerable component includes: Scan the source code of the project files to extract the component dependency chain; Based on the component dependency chain, determine the introduction method of each vulnerable component; If the vulnerability component is introduced directly, the version number of the vulnerability component in the configuration file corresponding to the project file is modified to the fix version number in order to upgrade and fix the vulnerability component. If the vulnerable component is introduced via indirect dependency, then the parent component of the vulnerable component is obtained according to the component dependency chain, the current version number of the parent component is obtained, and the latest version number of the parent component under the current major version number is found. It is then determined 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 patch 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 patch version number, then the current version number of the parent component is upgraded to the latest version number to upgrade and patch the vulnerable component. If the version number of the vulnerable component referenced by the parent component under the latest version number is less than the patch version number, then a new declaration of the component name and corresponding patch version number for introducing the vulnerable component is added to the configuration file corresponding to the project file to upgrade and patch the vulnerable component. After upgrading each of the aforementioned vulnerable components, the project is redeployed based on the aforementioned project files; If there are any abnormalities in the deployment, the upgrade compatibility results of each vulnerability component are determined by rolling back the upgraded and patched vulnerability components one by one, redeploying the project, and checking whether the deployment is abnormal. If the deployment proceeds without error, the deployed project will be tested using the automated regression test cases corresponding to the project files. If the automated regression test cases pass, then the upgrade compatibility of each of the vulnerability components is confirmed. If the automated regression test case fails, the upgrade compatibility result of each vulnerability component is determined by rolling back the upgraded and patched vulnerability components one by one and then retesting them using the automated regression test case. When the automated pre-upgrade verification of the vulnerable component determines that the upgrade compatibility result of the vulnerable component is upgrade incompatible, a corresponding fix code example is also generated. The upgrade compatibility information of each vulnerability component corresponding to different project files is integrated, and a knowledge base of a large model is constructed. The knowledge base includes the component name, version number before upgrade, version number after upgrade, upgrade compatibility result, calling method, calling code snippet, and repair code example corresponding to each vulnerability component. For the project file to be tested, the large model, based on the knowledge base, and combined with the calling code snippets of the vulnerable components extracted from the source code of the project file to be tested, performs upgrade compatibility analysis to obtain the upgrade compatibility results corresponding to each vulnerable component. When the upgrade compatibility result of the vulnerability component output by the large model is that the upgrade is incompatible, the large model also outputs a corresponding fix code example.

2. The method of claim 1, wherein, The vulnerable components that exist in the open-source components used to obtain the project files include: The project files were analyzed using a software component analysis tool to identify the open-source components called by the project files. The software component analysis tool was used to scan each of the open-source components to identify the vulnerable components.

3. The method of claim 1, wherein, The upgrade compatibility results for each vulnerability component were determined by rolling back the upgraded and patched components one by one, redeploying the project, and checking for deployment anomalies. Obtain all upgraded and patched vulnerability components, and build a vulnerability component set; Randomly select a target vulnerability component from the set of vulnerability components, and revert the target vulnerability component to its original state before the upgrade; After reverting the target vulnerable component to its original state before the upgrade, redeploy the project based on the project files and check whether the deployment is abnormal. If the deployment is normal, it is determined that the target vulnerability component in the vulnerability component set is incompatible with the upgrade, while the other vulnerability components in the vulnerability component set, excluding the target vulnerability component, are compatible with the upgrade. If an anomaly occurs during deployment, it is determined whether the error message of the current anomaly is consistent with the error message of the first anomaly. The first anomaly is the anomaly that occurs when the project is redeployed based on the project file after upgrading each of the vulnerability components. If the error message of the current anomaly is consistent with the error message of the first anomaly, then it is determined that the target vulnerability component in the vulnerability component set is compatible for upgrade, but there are other vulnerability components in the vulnerability component set that are incompatible for upgrade; After upgrading and fixing the target vulnerability component again, the target vulnerability component is excluded from the vulnerability component set to update the vulnerability component set; Return to the step of arbitrarily selecting a target vulnerability component from the vulnerability component set and reverting the target vulnerability component to its original state before the upgrade; If the error message of the current anomaly is inconsistent with the error message of the first anomaly, 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. The target vulnerable component is excluded from the vulnerable component set to update the vulnerable component set; Return to the step of arbitrarily selecting a target vulnerability component from the set of vulnerability components and reverting the target vulnerability component to its original state before the upgrade.

4. The method of claim 1, wherein, If an anomaly occurs during deployment, the method further includes: Calculate the incompatibility probability of each upgraded and patched vulnerability component; The upgrade compatibility results of each vulnerability component are determined by rolling back the upgrades one by one according to the incompatibility probability from highest to lowest, redeploying the project, and checking whether the deployment is abnormal.

5. The method according to claim 1, characterized in that, If the automated regression test case fails, the method further includes: Calculate the incompatibility probability of each upgraded and patched vulnerability component; The upgrade compatibility results of each vulnerability component are determined by rolling back the upgrade in descending order of incompatibility probability for each upgraded and then retesting using the automated regression test cases.

6. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 5.

Images