A vulnerability fixing method, system and device

Abstract

This application provides a vulnerability remediation method, system, and device, relating to the field of computer technology and applicable to network scenarios such as FTTR where Linux operating systems are deployed. In this vulnerability remediation system, an issue ticket subsystem acquires vulnerability issue tickets in a blocked state and sends them to a vulnerability tracking subsystem. The vulnerability tracking subsystem acquires the remediation status of each code vulnerability included in the issue ticket from the upstream open-source community. If the remediation status of each code vulnerability is "not affecting" or "remediated," the vulnerability issue ticket is set to a "downloadable" state. When the vulnerability issue ticket is in a downloadable state, if there are code vulnerabilities in a "remediated" state, the code synchronization subsystem pulls the patch code corresponding to the remediated code vulnerabilities from the upstream open-source community and merges the patch code into the internal code repository. This solution can reduce the manual intervention cost in code vulnerability remediation in scenarios such as FTTR.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a vulnerability repair method, system, and device. Background Technology

[0002] The Linux operating system is widely used in devices within carrier networks, enterprise networks, data center networks, and Fiber to the Room (FTTR) networks. However, during the evolution of the Linux operating system, the complexity of user-space software packages has increased explosively, leading to a surge in the number of code vulnerabilities. Compared to kernel-level code vulnerabilities, patching user-space code vulnerabilities presents challenges such as dependency complexity and fragmentation, making them a high-risk attack surface in the system's security defense chain. Therefore, timely and efficient patching of user-space code vulnerabilities is extremely important.

[0003] Currently, the patching of user-space code vulnerabilities mainly relies on manual intervention. In this model, developers need to monitor the vulnerability patching status across multiple open-source communities, promptly pull patches, and fix vulnerabilities in internal code repositories. This presents a problem of high manual intervention costs. Summary of the Invention

[0004] The purpose of this application is to provide a vulnerability remediation method, system, and device to reduce the cost of manual intervention in vulnerability remediation. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a vulnerability remediation method, the method comprising:

[0006] Obtain vulnerability issue reports that are in a blocked state, wherein the vulnerability issue reports include description information of code vulnerabilities;

[0007] When the status of the vulnerability issue ticket is blocked, obtain the repair status of each code vulnerability included in the vulnerability issue ticket in the upstream open source community;

[0008] If the fix status of each code vulnerability is either "not affected" or "fixed", then the vulnerability issue will be switched from "blocked" to "downloadable".

[0009] When the status of the vulnerability issue form is "downloadable", if the fix status of each code vulnerability is "fixed", or if the fix status of some code vulnerabilities in each code vulnerability is "fixed" and the fix status of the remaining code vulnerabilities is "not affected", then the patch code corresponding to the fixed code vulnerabilities is pulled from the upstream open source community; and the patch code is merged into the internal code repository.

[0010] In some embodiments, the method further includes:

[0011] If the code merge is successful, the vulnerability issue request will be switched from an available status to a completed status; a Request Map (MR) corresponding to the code merge will be created, and a downlink notification for the vulnerability issue request will be sent to the preset device; or,

[0012] When the vulnerability issue form is in the downlinkable state, if the fix status of each code vulnerability is in the non-impact state, then the vulnerability issue form is switched from the downlinkable state to the completed state; and the downlink notification is sent to the preset device.

[0013] In some embodiments, the method further includes: during the process of merging the patch code into an internal code repository, if a first code block in the patch code conflicts with a second code block in the internal code repository, determining the conflict type between the first code block and the second code block; and processing the first code block and the second code block according to the determined conflict type.

[0014] In some embodiments, the step of processing the first code block and the second code block according to the determined conflict type includes: if the determined conflict type indicates that both the first code block and the second code block are open-source vulnerable code, then the first code block is used to override the second code block in the internal code repository; if the determined conflict type indicates that the first code block and the second code block are release version numbers, then the first code block is used to override the second code block in the internal code repository.

[0015] The method further includes: if the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first code block and the second code block are not release version numbers, then generating a visualization report, the visualization report including the first code block and the second code block; and sending the visualization report to a preset device.

[0016] In some embodiments, the method further includes:

[0017] If the first code block in the patch code conflicts with the second code block in the internal code repository, determine whether the number of conflicts is greater than a preset number; if not, determine the conflict type between the first code block and the second code block; if so, send the code merge failure message to a preset device.

[0018] In some embodiments, the method further includes: detecting the type of the vulnerability issue ticket; if the vulnerability issue ticket is a user-mode issue ticket, then performing the step of pulling the patch code corresponding to the patched code vulnerability from the upstream open source community when the status of the vulnerability issue ticket is downlinkable, if the repair status of each code vulnerability is patched, or if the repair status of some code vulnerabilities in each code vulnerability is patched and the repair status of the remaining code vulnerabilities is unaffected.

[0019] In some embodiments, the method further includes:

[0020] After switching the vulnerability issue list from the actionable state to the completed state, record the fix status of each code vulnerability.

[0021] Secondly, embodiments of this application provide a vulnerability remediation system, which includes an issue log subsystem, a vulnerability tracking subsystem, and a code synchronization subsystem;

[0022] The issue ticket subsystem is used to obtain vulnerability issue tickets that are in a blocked state, the vulnerability issue tickets including description information of code vulnerabilities; and to send the vulnerability issue tickets to the vulnerability tracking subsystem.

[0023] The vulnerability tracking subsystem is used to obtain the repair status of each code vulnerability included in the vulnerability issue list in the upstream open source community when the status of the vulnerability issue list is blocked; if the repair status of each code vulnerability is "not affected" or "repaired", then the vulnerability issue list is switched from the blocked state to the downlinkable state; when the status of the vulnerability issue list is downlinkable, if the repair status of each code vulnerability is "repaired", or if the repair status of some code vulnerabilities in each code vulnerability is "repaired" and the repair status of the remaining code vulnerabilities is "not affected", then the code synchronization subsystem is triggered.

[0024] The code synchronization subsystem is used to pull patch code corresponding to the fixed code vulnerabilities from the upstream open source community and merge the patch code into the internal code repository.

[0025] In some embodiments, if the code merging is successful, the code synchronization subsystem switches the vulnerability issue ticket from the ready-to-go state to the completed state; creates a Request Map (MR) corresponding to the code merging, and sends a downlink notification of the vulnerability issue ticket to a preset device;

[0026] The vulnerability tracking subsystem is further configured to, when the status of the vulnerability issue form is "downloadable", if the repair status of each code vulnerability is "non-impact", switch the vulnerability issue form from "downloadable" to "complete" and send the downlink notification to the preset device.

[0027] In some embodiments, the code synchronization subsystem is further configured to, during the process of merging the patch code into the internal code repository, if a first code block in the patch code conflicts with a second code block in the internal code repository, determine the conflict type between the first code block and the second code block; and process the first code block and the second code block according to the determined conflict type.

[0028] In some embodiments, the code synchronization subsystem is specifically configured to, if the determined conflict type indicates that both the first code block and the second code block are open-source vulnerable code, use the first code block to overwrite the second code block in the internal code repository; if the determined conflict type indicates that both the first code block and the second code block are release version numbers, use the first code block to overwrite the second code block in the internal code repository.

[0029] The code synchronization subsystem is further configured to generate a visualization report if the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first code block and the second code block are not release version numbers; and send the visualization report to a preset device.

[0030] In some embodiments, the code synchronization subsystem is further configured to, if a first code block in the patch code conflicts with a second code block in the internal code repository, determine whether the number of conflicts is greater than a preset number; if not, determine the conflict type between the first code block and the second code block; if so, send the code merge failure message to a preset device.

[0031] In some embodiments, the vulnerability tracking subsystem is further configured to detect the type of the vulnerability issue ticket; if the vulnerability issue ticket is a user-mode issue ticket, then the step of triggering the code synchronization subsystem is executed when the status of the vulnerability issue ticket is downlinkable, if the repair status of each code vulnerability is repaired, or if the repair status of some code vulnerabilities in each code vulnerability is repaired and the repair status of the remaining code vulnerabilities is unaffected.

[0032] In some embodiments, the code synchronization subsystem is further configured to record the remediation status of each code vulnerability after the vulnerability issue form is switched from an available state to a completed state;

[0033] The vulnerability tracking subsystem is also used to record the remediation status of each code vulnerability after the vulnerability issue form is switched from an actionable state to a completed state.

[0034] Thirdly, embodiments of this application provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0035] Memory, used to store computer programs;

[0036] The processor, when executing a program stored in memory, implements any of the methods provided in the first aspect.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods provided in the first aspect.

[0038] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods provided in the first aspect.

[0039] Beneficial effects of the embodiments in this application:

[0040] The technical solution provided in this application embodiment can collect vulnerability issue reports during the development and localization phase (i.e., vulnerability issue reports in a blocked state), and connect with upstream open-source communities to monitor the remediation status of code vulnerabilities in the upstream open-source communities. Based on the remediation status of code vulnerabilities in the upstream open-source communities, if it is determined that all code vulnerabilities in the vulnerability issue report (i.e., code vulnerabilities in the internal code repository) are remediable, the vulnerability issue report is switched from a blocked state to a remediable state, and the retrieval and merging of patch code is triggered to fix the code vulnerabilities in the vulnerability issue report. In this application embodiment, the remediation status of code vulnerabilities in one or more upstream open-source communities can be monitored in real time, vulnerability issue reports during the development and localization phase can be managed, the status of vulnerability issue reports can be updated in a timely manner, and code merging can be triggered, reducing the manual intervention cost in code vulnerability remediation in scenarios such as FTTR.

[0041] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0043] Figure 1 A schematic diagram of a vulnerability remediation system provided in an embodiment of this application;

[0044] Figure 2 This is a first schematic diagram of a vulnerability remediation method provided in an embodiment of this application;

[0045] Figure 3 This is a second schematic diagram of the vulnerability repair method provided in the embodiments of this application;

[0046] Figure 4 A schematic diagram of the vulnerability remediation process provided in the embodiments of this application;

[0047] Figure 5 A schematic diagram of the code synchronization process provided in an embodiment of this application;

[0048] Figure 6 This is a third schematic diagram of the vulnerability repair method provided in the embodiments of this application;

[0049] Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0051] The traditional manual vulnerability repair method has the following bottlenecks:

[0052] (1) High cost of manual intervention.

[0053] There are multiple upstream open-source communities. For vulnerabilities in the internal code repository, developers need to continuously monitor the patching status of these vulnerabilities across these multiple open-source communities, and promptly pull patches to fix the vulnerabilities in the internal code repository. This results in high maintenance costs.

[0054] (2) Inefficient code management.

[0055] The code vulnerability patching process involves merging multiple branches. Currently, the manual vulnerability patching model lacks an automated synchronization mechanism. Manually traversing multiple branches to perform merge operations results in an average time of ≥30 minutes per package branch, leading to low synchronization efficiency across multiple packages and references.

[0056] Furthermore, code conflicts can occur when merging multiple branches. Resolving these conflicts primarily relies on developers analyzing the conflicting code line by line based on experience. This approach is prone to human error, such as accidentally deleting internally modified code, leading to secondary defects.

[0057] (3) Lack of closed-loop management.

[0058] The disconnect between the vulnerability patch status on the developer's local machine and the vulnerability issue sheet status prevents developers from confirming vulnerability patches in a timely manner, delays the release of user-space software packages, and affects product delivery efficiency.

[0059] To address the aforementioned issues, embodiments of this application provide a vulnerability remediation system, such as... Figure 1 As shown, it includes an issue tracking subsystem 110, a vulnerability tracking subsystem 120, and a code synchronization subsystem 130.

[0060] Issue ticket subsystem 110 is used to retrieve vulnerability issue tickets that are in a blocked state. The vulnerability issue tickets include description information of code vulnerabilities; and to send vulnerability issue tickets to vulnerability tracking subsystem 120.

[0061] The vulnerability tracking subsystem 120 is used to obtain the fixation status of each code vulnerability included in the vulnerability issue ticket in the upstream open source community when the status of the vulnerability issue ticket is blocked; if the fixation status of each code vulnerability is in an unaffected state or a fixed state, the vulnerability issue ticket is switched from the blocked state to the downlinkable state; when the status of the vulnerability issue ticket is downlinkable, if the fixation status of each code vulnerability is in a fixed state, or if the fixation status of some code vulnerabilities in each code vulnerability is in a fixed state and the fixation status of the remaining code vulnerabilities is in an unaffected state, the code synchronization subsystem 130 is triggered.

[0062] The code synchronization subsystem 130 is used to pull patch code for fixed code vulnerabilities from the upstream open source community and merge the patch code into the internal code repository.

[0063] The technical solution provided in this application embodiment includes a vulnerability remediation system comprising an issue ticket subsystem, a vulnerability tracking subsystem, and a code synchronization subsystem. The issue ticket subsystem collects vulnerability issue tickets during the development and localization phase (i.e., those in a blocked state) and synchronizes them to the vulnerability tracking subsystem. The vulnerability tracking subsystem interfaces with upstream open-source communities, monitoring the remediation status of code vulnerabilities in these communities. Based on the remediation status, if it determines that all code vulnerabilities in the issue ticket (i.e., those in the internal code repository) are manageable, it switches the issue ticket from a blocked state to a processable state and triggers the code synchronization subsystem to pull and merge patch code to remediate the vulnerabilities in the issue ticket. In this application embodiment, the vulnerability tracking subsystem can monitor the remediation status of code vulnerabilities in one or more upstream open-source communities in real time, manage vulnerability issue tickets during the development and localization phase, update the status of the issue tickets promptly, and trigger code merging, reducing the manual intervention cost in code vulnerability remediation in scenarios such as FTTR.

[0064] In this embodiment of the application, each code vulnerability has a standard unique number, such as a Common Vulnerabilities and Exposures (CVE) number. Code vulnerabilities with CVE numbers can also be referred to as CVE vulnerabilities.

[0065] The issue ticket subsystem 110 is a company-level issue management platform that provides standardized vulnerability tracking capabilities for development and testing teams, enabling the tracking and management of vulnerability issue tickets during the development and localization phase. In this embodiment, the issue ticket subsystem 110 acts as a data source for vulnerability issues, supporting the testing team in periodically submitting and managing the lifecycle of user-space code vulnerabilities in the Linux operating system. In this embodiment, the issue ticket subsystem 110 exports vulnerability issue tickets from the development and localization phase and synchronizes them uniformly to the vulnerability tracking subsystem 120.

[0066] The issue ticket subsystem 110 can establish a linkage mechanism with the status of vulnerability issue tickets. For example, it can set a blocked status for a vulnerability issue ticket and display vulnerability issue tickets that are in the completed status.

[0067] The vulnerability tracking subsystem 120 manages pending vulnerability issue tickets, periodically monitors the patching status of code vulnerabilities in upstream open-source communities, and updates the status of pending vulnerability issue tickets. Pending vulnerability issue tickets are those that are blocked or those that are in the development and localization stage.

[0068] The code synchronization subsystem 130 is used to automate the merging of patch code. In this embodiment, the code synchronization subsystem 130 can rely on existing GitLab code repositories to complete the processes of pulling, merging, conflict handling, and pushing patch code corresponding to code vulnerabilities to a specified remote repository.

[0069] Based on the processing results of the code synchronization subsystem 130, the vulnerability tracking subsystem 120 can synchronously update the status of the vulnerability issue form and the status of the code vulnerability, and send a downlink notification to the development manager. In this way, the development manager can promptly access the vulnerability issue form in the issue form subsystem 110, thereby achieving end-to-end closed-loop management of code vulnerabilities.

[0070] The main processing stages of a vulnerability issue ticket include: development location stage -> project manager review stage -> modification and implementation stage -> implementation review stage. In this embodiment, the downstream processing of the vulnerability issue ticket can be understood as follows: the vulnerability issue ticket process is transferred from the development location stage to the project manager review stage, and subsequent stages are not affected by the code vulnerability status, and can be closed looped up to the software package version archiving.

[0071] In the technical solution provided in this application embodiment, the vulnerability tracking subsystem 120 periodically synchronizes the code vulnerability repair status with the upstream open source community, reducing manpower input costs, improving the efficiency of code vulnerability repair status perception, and improving vulnerability repair efficiency. Furthermore, the vulnerability tracking subsystem 120 triggers the code synchronization subsystem 130 to perform code merging based on the vulnerability issue ticket status, achieving a strong correlation between the vulnerability issue ticket status and code merging, realizing full-link tracking of vulnerability repair, and end-to-end closed-loop management.

[0072] Based on the aforementioned vulnerability remediation system, this application also provides a vulnerability remediation method, such as... Figure 2 As shown, it includes the following steps:

[0073] Step S201: The issue ticket subsystem 110 obtains a vulnerability issue ticket that is in a blocked state. The vulnerability issue ticket includes a description of the code vulnerability.

[0074] In this embodiment of the application, a vulnerability issue form may include descriptions of one or more code vulnerabilities. The issue form subsystem 110 may incorporate an issue form synchronization script to periodically push vulnerability issue forms from the development and localization phase to the vulnerability tracking subsystem 120 to initiate monitoring of the code vulnerability remediation status.

[0075] The above-mentioned issue single synchronization script can have the following functions:

[0076] 1) Filter and export the vulnerability issue list. This vulnerability issue list can be in spreadsheet (Excel) format or other formats, listing the vulnerability issues.

[0077] 2) Read and parse information from the vulnerability issue form.

[0078] The information parsed by the issue ticket subsystem 110 may include, but is not limited to, issue ticket identifier (ID), name of development manager (name), product version number (version), package name (package), and code vulnerability number (such as cve_id).

[0079] 3) Call the issue ticket synchronization interface on the vulnerability tracking subsystem 120 to synchronize the information parsed in 2) to the vulnerability tracking subsystem 120. The issue ticket synchronization interface can be encapsulated as a Representational State Transfer Application Programming Interface (RESTfulAPI) or other types of interfaces.

[0080] Step S202: Issue ticket subsystem 110 sends a vulnerability issue ticket to vulnerability tracking subsystem 120;

[0081] Step S203: When the status of the vulnerability issue ticket is blocked, the vulnerability tracking subsystem 120 obtains the fixation status of each code vulnerability included in the vulnerability issue ticket in the upstream open source community;

[0082] In this embodiment, the number of upstream open-source communities can be one or more. An upstream open-source community can be understood as the official open-source community for a code vulnerability. Upstream open-source communities update the patching status of code vulnerabilities periodically. The patching status of code vulnerabilities in upstream open-source communities can be recorded in the standard fields of the National Vulnerability Database (NVD). The patching status of a code vulnerability can include Fixed, Unaffected, and Fixing statuses. A Fixed status indicates that the corresponding code vulnerability has been patched, and the upstream open-source community's code repository stores the corresponding patch code. An Unaffected status indicates that the impact of the corresponding code vulnerability on the software package's execution is negligible. A Fixing status indicates that the corresponding code vulnerability has not yet been patched.

[0083] For vulnerability issue tickets in a blocked state, the vulnerability tracking subsystem 120 can periodically poll upstream open source communities through query interfaces (such as RESTful APIs) based on the ID (such as cve_id) of each code vulnerability included in the vulnerability issue ticket to obtain the remediation status of each code vulnerability included in the vulnerability issue ticket.

[0084] Step S204: If the fixation status of each code vulnerability is either unaffected or fixed, the vulnerability tracking subsystem 120 will switch the vulnerability issue from blocked to ready to proceed.

[0085] After obtaining the remediation status of each code vulnerability included in the vulnerability issue list, the vulnerability tracking subsystem 120 checks whether the remediation status of the code vulnerabilities included in the vulnerability issue list meets any one of the following specified conditions 1 to 3. Specified condition 1: The remediation status of all code vulnerabilities included in the vulnerability issue list is "not affected"; Specified condition 2: The remediation status of all code vulnerabilities included in the vulnerability issue list is "remediated"; Specified condition 3: In the vulnerability issue list, a portion of the code vulnerabilities are in the "remediated" status, and the remaining portion of the code vulnerabilities are in the "not affected" status.

[0086] If any one of the specified conditions 1 to 3 above is met (e.g., condition 3 is met), it means that all code vulnerabilities in the vulnerability issue form are handleable vulnerabilities. The vulnerability tracking subsystem 120 sets the status of the vulnerability issue form to the downlinkable state, thus switching the status of the vulnerability issue form from the blocked state to the downlinkable state. If none of the specified conditions 1 to 3 above are met, the vulnerability tracking subsystem 120 keeps the status of the vulnerability issue form in the blocked state.

[0087] In this embodiment, the vulnerability tracking subsystem 120 can also provide a user interface to support manual updates to the vulnerability issue ticket status via a webpage. For example, the vulnerability tracking subsystem 120 displays the remediation status of each code vulnerability included in the vulnerability issue ticket on the user interface. Based on the information displayed on the user interface, the developer receives an input on the user interface indicating that the vulnerability issue ticket status is ready to be updated. After receiving the information input by the developer, the vulnerability tracking subsystem 120 sets the vulnerability issue ticket status to the ready-to-be-updated state.

[0088] Step S205: When the status of the vulnerability issue form is in the "ready to proceed" state, if the repair status of each code vulnerability is "repaired", or if the repair status of some code vulnerabilities in each code vulnerability is "repaired" and the repair status of the remaining code vulnerabilities is "unaffected", then the vulnerability tracking subsystem 120 triggers the code synchronization subsystem 130.

[0089] The vulnerability tracking subsystem 120 can call the issue ticket query interface on its own platform to query the status of vulnerability issue tickets. When a vulnerability issue ticket is found to be in a "ready to proceed" state, the vulnerability tracking subsystem 120 checks the remediation status of each code vulnerability in the issue ticket. If the remediation status of the code vulnerabilities included in the issue ticket meets any of the specified conditions 2 to 3 (e.g., condition 3), the code synchronization subsystem 130 is triggered to perform code synchronization. The issue ticket query interface can be encapsulated as a RESTful API or other types of interfaces.

[0090] In this embodiment of the application, the problem ticket query function and the problem ticket synchronization function can be encapsulated into a RESTful API for other subsystems or this subsystem to call.

[0091] Step S206: The code synchronization subsystem 130 pulls the patch code corresponding to the fixed code vulnerability from the upstream open source community;

[0092] In step S207, the code synchronization subsystem 130 merges the patch code into the internal code repository.

[0093] In this embodiment, the internal code repository is a local code repository of the vulnerability remediation system, used to store the code of the software package corresponding to the vulnerability issue slip. The code synchronization subsystem 130 can pull the patch code corresponding to each code vulnerability in the vulnerability issue slip that has been patched from the code repository of the upstream open source community, and merge the pulled patch code into the internal code repository.

[0094] The technical solution provided in this application includes a vulnerability remediation system comprising an issue ticket subsystem, a vulnerability tracking subsystem, and a code synchronization subsystem. The issue ticket subsystem collects vulnerability issue tickets during the development and localization phase (i.e., those in a blocked state) and synchronizes them to the vulnerability tracking subsystem. The vulnerability tracking subsystem interfaces with upstream open-source communities, monitoring the remediation status of code vulnerabilities in these communities. Based on the remediation status, if it determines that all code vulnerabilities in the issue ticket (i.e., those in the internal code repository) are manageable, it switches the issue ticket from a blocked state to a processable state and triggers the code synchronization subsystem to pull and merge patch code to remediate the vulnerabilities in the issue ticket. In this application embodiment, the vulnerability tracking subsystem can monitor the remediation status of code vulnerabilities in one or more upstream open-source communities in real time, manage vulnerability issue tickets during the development and localization phase, update the status of the issue tickets promptly, and trigger code merging, reducing the manual intervention cost in code vulnerability remediation in scenarios such as FTTR.

[0095] In some embodiments, a vulnerability remediation method is also provided, such as Figure 3 As shown, the process may include the following steps S301 to S311. Among them, steps S301 to S307 are the same as steps S201 to S207, and will not be described again here.

[0096] Step S308: If the code merging is successful, the code synchronization subsystem 130 will switch the vulnerability issue form from the ready-to-go state to the completed state.

[0097] After merging all the patch code corresponding to the code vulnerabilities into the internal code repository, the code synchronization subsystem 130 confirms that the code merging is successful, and then sets the status of the vulnerability issue ticket to the completed status, thus changing the status of the vulnerability issue ticket from the ready-to-go status to the completed status.

[0098] In this embodiment of the application, after the code synchronization subsystem 130 sets the status of the vulnerability issue form to the completed status, it can also record the repair status of each code vulnerability in the vulnerability issue form, that is, synchronously update the repair status of the code vulnerabilities in the local vulnerability repair system.

[0099] In step S309, the code synchronization subsystem 130 creates a request MR corresponding to code merging and sends a downlink notification of the vulnerability issue form to the preset device.

[0100] In this embodiment, the downlink notification can be a GitLab Continuous Integration (CI) notification. The preset device can be the device of the person reviewing the vulnerability issue report in the next stage.

[0101] After setting the vulnerability issue ticket to a completed status, the code synchronization subsystem 130 can create a corresponding merge request (MR), triggering GitLab continuous integration (CI) pipeline processing, such as static code analysis and commit verification. After the GitLab CI pipeline processing is complete, the code synchronization subsystem 130 can also send a GitLab CI pipeline processing result notification to a preset device.

[0102] After creating a MapReduce (MR), the code synchronization subsystem 130 can send a downlink notification to a preset device. This downlink notification includes the aforementioned MR information, allowing the development manager on the preset device to send a problem ticket from the problem ticket subsystem 110. Furthermore, based on the GitLab CI pipeline processing results and the downlink notification, the development manager can manually review and confirm the patch code, then push it to a designated remote repository, thus merging the patch code into the main branch.

[0103] In this embodiment of the application, if the code merging is successful, but the status of the vulnerability issue form is set to the completed status and fails, the code synchronization subsystem 130 will detect that no new code has been added when it performs the code synchronization operation next time, and directly execute step S308 to update the status of the vulnerability issue form.

[0104] Step S310: If the fix status of each code vulnerability is "not affected", then the vulnerability tracking subsystem 120 will switch the vulnerability issue from the "ready to proceed" status to the "completed" status.

[0105] Step S311: The vulnerability tracking subsystem 120 sends a downlink notification of the vulnerability issue form to the preset device.

[0106] After executing step S304, when the vulnerability tracking subsystem 120 finds that the status of a vulnerability issue ticket is "ready to proceed," it checks the remediation status of each code vulnerability in the vulnerability issue ticket. If the remediation status of the code vulnerabilities included in the vulnerability issue ticket meets the aforementioned specified condition 1, the vulnerability tracking subsystem 120 can set the status of the vulnerability issue ticket to "completed," thus switching the status of the vulnerability issue ticket from "ready to proceed" to "completed." Furthermore, after setting the status of the vulnerability issue ticket to "completed," the vulnerability tracking subsystem 120 sends a downlink notification of the vulnerability issue ticket to a preset device to notify the relevant development manager to downlink the issue ticket in the issue ticket subsystem 110.

[0107] In this embodiment of the application, after the vulnerability tracking subsystem 120 sets the status of the vulnerability issue form to the completed status, it can also record the repair status of each code vulnerability in the vulnerability issue form, that is, synchronously update the repair status of the code vulnerabilities in the local vulnerability repair system.

[0108] In this embodiment, the vulnerability tracking subsystem 120 and the code synchronization subsystem 130 can synchronously update the status of vulnerability issue tickets and code vulnerabilities in the vulnerability tracking subsystem 120, and send downlink notifications to the development manager. This achieves automated association between vulnerability remediation status and vulnerability issue ticket status, and automated linkage between vulnerability issue ticket status and code merging operation, thereby realizing end-to-end closed-loop management of code vulnerabilities and solving the problem of the disconnect between vulnerability remediation status and vulnerability issue ticket status, resulting in version release delays and affecting product delivery efficiency.

[0109] In some embodiments, during the process of merging patch code into the internal code repository, if a first code block in the patch code conflicts with a second code block in the internal code repository, the code synchronization subsystem 130 determines the conflict type between the first code block and the second code block; and processes the first code block and the second code block according to the determined conflict type.

[0110] In this embodiment, the first code block is one or more lines of code in the patch code. The second code block is one or more lines of code in the internal code repository.

[0111] If a conflict occurs between the first code block and the second code block during the process of merging patch code into the internal code repository, the code synchronization subsystem 130 can use the rule engine and functions such as git blame to parse the conflict area (i.e., the conflicting code) line by line to determine the type of code conflict.

[0112] The code synchronization subsystem 130 has preset handling methods for different conflict types. After the conflict type is determined, the code synchronization subsystem 130 can automatically handle the conflicting code, namely the first code block and the second code block, according to the handling method corresponding to the determined conflict type. This achieves conflict self-healing based on the rule engine and automatic vulnerability repair.

[0113] In this embodiment of the application, the types of code conflicts can be divided into the following three categories.

[0114] The first scenario involves no internal modification conflicts, such as a conflict type indicating that both the first and second code blocks are open-source vulnerable code. If the determined conflict type indicates that both the first and second code blocks are open-source vulnerable code, then the code synchronization subsystem 130 can use the first code block to override the second code block in the internal code repository.

[0115] In this embodiment, the code synchronization subsystem 130 can parse the email suffix of the committer in the conflict area based on the rule engine, perform regular expression matching between the email suffix and the preset enterprise domain name, and determine whether the conflict content contains an internal developer identifier. If it is determined that each line of code in the conflicting code does not contain an internal developer identifier, the conflict type can be determined to be a conflict without internal modifications, and then `git merge-file --theirs` can be executed.<head_file><base_file><theirs_file> This command forces the source branch patch code (i.e., the first code block) to be applied to the conflicted area in order to maintain the original open-source fix.

[0116] The second type involves simple internal modification conflicts, such as conflict types indicating that the first and second code blocks are release version numbers. If the determined conflict type indicates that the first and second code blocks are release version numbers, then the first code block overrides the second code block in the internal code repository.

[0117] In this embodiment, the code synchronization subsystem 130 can parse the conflicting region as a release version based on a rule engine, and perform regular expression matching between the release version header in the first code block and the second code block. If the conflicting content is determined to be a release version number, the code synchronization subsystem 130 can determine that the conflict type is a simple internal modification conflict, and then can execute `git merge-file --theirs`.<head_file><base_file><theirs_file> This command forces the source branch's commits to be preserved, maintaining the original open-source fixes.

[0118] The third type is complex logical conflict, where the conflict type indicates that the second code block is an internally modified code block, and the first and second code blocks are not release version numbers; that is, a conflict type other than the first and second conflict types. If the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first and second code blocks are not release version numbers, then the code synchronization subsystem 130 generates a visualization report, which includes the first and second code blocks; and sends the visualization report to a preset device.

[0119] In this embodiment of the application, when complex logical conflicts occur, the code synchronization subsystem 130 can generate a visual report and notify the responsible person through the GitLab MR process so that the code conflict can be resolved manually and the code can be merged.

[0120] In practical applications, the first type of scenario without internal modification conflicts accounts for 55% of code conflict scenarios, the second type of scenario with simple internal modification conflicts accounts for 35%, and the third type of scenario with complex logic conflicts accounts for only 10%. In this embodiment, the code synchronization subsystem 130 can automate more than 95% of code vulnerability repairs through baseline intelligent calibration, patch tracing mechanism, and conflict classification strategy (i.e., conflict type differentiation strategy), while retaining key manual review nodes, thus achieving a balance between security and efficiency.

[0121] In some embodiments, if the first code block in the patch code conflicts with the second code block in the internal code repository, the code synchronization subsystem 130 can determine whether the number of conflicts is greater than a preset number; if not, it determines the conflict type between the first code block and the second code block; if so, it sends a code merge failure message to a preset device.

[0122] In this embodiment, the preset number of times can be set according to actual needs, for example, the preset number of times can be 5, 10, 12, etc. The code synchronization subsystem 130 can pull multiple-committed patch code from the upstream open source community. The code synchronization subsystem 130 can merge the multiple-committed patch code into the internal code repository according to the order of patch code submission time. When merging a single-committed patch code into the internal code repository, if a code conflict occurs, such as a conflict between the first code block and the second code block, the conflict count is incremented by 1, and the code synchronization subsystem 130 determines whether the conflict count is greater than the preset number of times.

[0123] If the number of conflicts is less than or equal to a preset number, the code synchronization subsystem 130 can determine the conflict type between the first code block and the second code block, and then process the first code block and the second code block according to the determined conflict type. After that, the code synchronization subsystem 130 attempts to merge the next committed patch code into the internal code repository until all the obtained multiple committed patch codes have been merged into the internal code repository, or the number of conflicts exceeds the preset number.

[0124] If the number of conflicts exceeds the preset limit, the code merge fails. The code synchronization subsystem 130 generates a code merge failure message and sends it to the preset device. This message may include the reason for the failure. The person in charge on the preset device can manually merge the code based on the reason provided in the message, thus transferring vulnerability patching to manual processing. The last successfully committed patch code is pushed to the designated branch, triggering GitLab CI pipeline processing and sending a vulnerability issue notification to the preset device. After GitLab CI pipeline processing is complete and manually reviewed and confirmed, the patch code can be pushed to the designated remote repository, merging it into the main branch.

[0125] In this embodiment of the application, by setting a preset number of times, the code conflict handling is prevented from falling into an infinite loop.

[0126] In some embodiments, after the vulnerability tracking subsystem 120 switches a vulnerability issue ticket from a blocked state to a downlinkable state, it can detect the type of the vulnerability issue ticket; if the vulnerability issue ticket is a user-mode issue ticket, then step S205 is executed.

[0127] In this embodiment of the application, vulnerability issue forms are divided into user-mode issue forms and kernel-mode issue forms. User-mode issue forms are issue forms corresponding to user-mode software packages, and kernel-mode issue forms are issue forms corresponding to kernel-mode software packages.

[0128] The issue ticket subsystem 110 can send all vulnerability issue tickets to the vulnerability tracking subsystem 120. The vulnerability tracking subsystem 120 obtains the remediation status of each code vulnerability included in these all vulnerability issue tickets, and sets the status of each vulnerability issue ticket based on the obtained remediation status of each code vulnerability. The vulnerability tracking subsystem 120 filters out kernel-mode issue tickets that are in a downdatable state. For the remaining user-mode issue tickets, the issue ticket subsystem 110 executes step S205, or the vulnerability tracking subsystem 120 executes step S310.

[0129] In this embodiment, the vulnerability remediation system only needs to process user-mode problem slips, saving vulnerability processing time and improving vulnerability remediation efficiency.

[0130] The following is combined with Figure 4 The vulnerability remediation process shown is as follows: Figure 5 The code synchronization process shown provides a detailed explanation of the vulnerability remediation method provided in this application embodiment.

[0131] The vulnerability remediation process may include the following steps:

[0132] Step 1: Synchronize the vulnerability issue report.

[0133] In step 1, the issue ticketing subsystem collects vulnerability issue tickets and periodically synchronizes the full set of vulnerability issue tickets to the vulnerability tracking subsystem. The full set of vulnerability issue tickets includes both user-space and kernel-space issue tickets. These vulnerability issue tickets are all in the development and localization phase and are in a blocked state.

[0134] Step 2: Determine whether each vulnerability issue request can be submitted.

[0135] In step 2, the vulnerability tracking subsystem periodically retrieves the remediation status of code vulnerabilities in each vulnerability issue request from the upstream open-source community. For each vulnerability issue request, the subsystem determines whether it contains only vulnerabilities in the Fixed state, only vulnerabilities in the Unaffected state, or only vulnerabilities in both Fixed and Unaffected states. If yes, meaning the vulnerability issue request contains only vulnerabilities in the Fixed and / or Unaffected states, then the vulnerability issue request is ready to proceed, and the subsystem sets its status to "ready to proceed" and executes step 3. If no, meaning the vulnerability issue request also contains vulnerabilities in states other than Fixed and Unaffected, then the vulnerability issue request is not ready to proceed, and the vulnerability issue request remains in a blocked state, with step 2 being executed repeatedly.

[0136] Step 3: Vulnerability issue filtering.

[0137] In step 3, for vulnerability issue requests in the outgoing state, the vulnerability tracking subsystem filters out vulnerability issue requests involving user-space software packages (i.e., user-space issue requests). This eliminates interference from kernel-space issue requests and saves vulnerability processing time.

[0138] Step 4: Check the fixation status of the code vulnerabilities in the vulnerability issue report.

[0139] In step 4, for each user-mode issue ticket filtered in step 3, the vulnerability tracking subsystem checks the patching status of the code vulnerabilities in that user-mode issue ticket. If all the code vulnerabilities in the user-mode issue ticket are in the Unaffected state, it means that the user-mode issue ticket does not require code merging, and the vulnerability tracking subsystem proceeds to step 5. If all the code vulnerabilities in the user-mode issue ticket are in the Fixed state, or some of the code vulnerabilities are in the Fixed state, it means that the user-mode issue ticket needs code merging, and the vulnerability tracking subsystem proceeds to step 6, that is, triggering the code synchronization subsystem to perform code synchronization operations.

[0140] Step 5: Mark the vulnerability issue form as completed.

[0141] If the vulnerability tracking subsystem detects in step 4 that the user-mode issue ticket does not require code merging, it marks the user-mode issue ticket as completed. At the same time, it can also record the fixation status of the code vulnerability in the user-mode issue ticket locally as Unaffected, triggering a notification mechanism to notify the development manager to forward the issue ticket to the issue ticket subsystem.

[0142] In this embodiment of the application, the local record of the code vulnerability repair status can be in the form of "problem number, code vulnerability CVE number, repair status", such as "1, CVE_1, Unaffected".

[0143] Step 6: Code synchronization.

[0144] In step 6, the code synchronization subsystem automatically pulls patch code from the upstream open-source community's code repository and merges it into the local internal code repository. Code conflicts are automatically handled according to a tiered strategy. For detailed code synchronization procedures, please refer to [link to relevant documentation]. Figure 5 As shown.

[0145] Step 7, Status Feedback and Notification.

[0146] After successfully merging the patch code into the internal code repository, the code synchronization subsystem commits the patch code and pushes it to the designated branch. Simultaneously, it automatically creates MR and GitLab CI pipelines to trigger GitLab CI pipeline processing. The code synchronization subsystem can also execute step 5, marking the user-mode issue ticket as completed, while locally recording the vulnerability fixation status (e.g., Fixed or Unaffected) and triggering notification mechanisms, such as sending merge follow-up notifications and CI pipeline processing result notifications to the development lead, who then forwards the issue ticket to the issue ticket subsystem. If the status update of a user-mode issue ticket fails, but the code has been successfully merged into the internal code repository, the issue ticket with the failed status update will be detected as having no new code during the next code synchronization, and its status will be updated again.

[0147] If the code merge fails, the code synchronization subsystem can output an operation log for manual intervention. This operation log includes the reason for the failure.

[0148] The code synchronization process may include the following steps:

[0149] Step 1: Environment initialization.

[0150] In step 1, the code synchronization subsystem performs parameter validity checks and reads the metadata of the package list associated with the code vulnerability and the test issue form. The code synchronization subsystem can synchronously clone the upstream open source community's code repository (i.e., the source branch) and the internal code repository (i.e., the destination branch) to the local working area of ​​the vulnerability remediation system by executing the git clone function in parallel, thus establishing a dual code tree base environment.

[0151] Step 2: Baseline alignment detection.

[0152] In step 2, the code synchronization subsystem executes the `git log` function on the internal code repository branch to trace back the log of historical commits and extract the commit ID of the most recently synchronized source branch. The code synchronization subsystem verifies the existence of the commit ID across repositories: if the most recent commit ID exists in the source branch, it is used as the synchronization starting point; if the commit ID does not exist in the source branch (e.g., internal historical commits have been reset), the latest release tag of the source branch is used as the synchronization starting point. This avoids the risk of baseline misalignment.

[0153] Step 3: Incremental patch synchronization.

[0154] The code synchronization subsystem can use `git cherry-pick --keep-redundant-commits` <commitid>The `<source branch> -m 1 -x` function precisely extracts the sequence of patch code to be synchronized from the source branch, i.e., the sequence of patch code from the synchronization start point to the current point. It forces the retention of redundant commit information to ensure the integrity of patch metadata, preserves commit history and context information, avoids skipping critical patches due to duplicate commits, and provides a complete context for subsequent conflict analysis.

[0155] Step 4: Conflict source analysis.

[0156] The code synchronization subsystem executes `git add`, `git commit`, and `git cherry-pick --continue` functions in the commit order to gradually merge the patch code sequence into the local internal code repository. If the patch code sequence is merged without any code conflicts, the code synchronization subsystem proceeds to step 7, pushing the successfully committed patch code to the specified branch. If the patch code triggers a code conflict, the code synchronization subsystem can use the `git diff` function to display the conflicting code blocks and determine the conflict type. For example, it can use the `git blame` function to parse the committer's email suffix line by line in the conflict area and perform regular expression matching against a pre-defined enterprise domain name. If all conflicting lines do not contain internal developer identifiers (such as pre-defined enterprise domain names), the code synchronization subsystem can determine it as a conflict caused by modifications made in the pure open-source community. If internal developer identifiers are included, indicating internal modification traces, the code synchronization subsystem can initiate a differentiated processing procedure.

[0157] Step 5: Hierarchical conflict resolution.

[0158] In this embodiment, the patch code conflicts for user-space software package vulnerabilities mainly originate from the `<package>.spec` file. This embodiment designs solutions for three conflict scenarios for this file: Solution 1 (no internal modification conflicts), Solution 2 (simple internal modification conflicts), and Solution 3 (complex logic conflicts). The solutions for these three conflict scenarios are described above and will not be repeated here.

[0159] Step 6: Merge the code.

[0160] After successful conflict resolution, the code synchronization subsystem continues to execute the functions `git add`, `git commit`, and `gitcherry-pick --continue` in sequence. If a code conflict occurs again, and the number of conflicts is less than or equal to the preset number, the conflict type is determined, and step 5 is repeated until the conflict is completely resolved, and then step 7 is executed. If a code conflict occurs again, but the number of conflicts exceeds the preset number, the code merge fails, the code synchronization subsystem outputs the reason for the failure, and manual handling is initiated. This automatic code synchronization process is now complete.

[0161] Step 7: Push the patch code.

[0162] The code synchronization subsystem will push the successfully committed patch code to the designated branch, and simultaneously automatically create the MR and GitLab CI pipelines, sending merge follow-up notifications (as shown in the following notification) and GitLab CI processing result notifications to the development manager. At this point, the automatic code synchronization process is complete.

[0163] Throughout the entire automatic vulnerability remediation process, the vulnerability remediation system can locate faults through abnormal log recording and context tracing, ensuring automated closed-loop management of code vulnerability handling for user-space software packages.

[0164] Verification has shown that the technical solution provided in this application for vulnerability repair solves the problems of high cost of manual intervention, inefficient code management, and lack of closed-loop management in the traditional manual vulnerability repair mode. It also achieves excellent results in terms of vulnerability repair cycle, manpower cost, and backlog of problem orders, as shown in Table 1 below.

[0165] Table 1

[0166]

[0167] Corresponding to the above-described vulnerability remediation system embodiments, this application also provides a vulnerability remediation method, such as... Figure 6 As shown, it includes the following steps:

[0168] Step S601: Obtain the vulnerability issue form that is in a blocked state. The vulnerability issue form includes the description information of the code vulnerability.

[0169] Step S602: When the status of the vulnerability issue ticket is blocked, obtain the fixation status of each code vulnerability included in the vulnerability issue ticket in the upstream open source community;

[0170] Step S603: If the fixation status of each code vulnerability is either unaffected or fixed, then switch the vulnerability issue from blocked to ready to proceed.

[0171] Step S604: When the status of the vulnerability issue ticket is "downloadable", if the fix status of each code vulnerability is "fixed", or if the fix status of some code vulnerabilities in each code vulnerability is "fixed" and the fix status of the remaining code vulnerabilities is "not affected", then pull the patch code corresponding to the code vulnerabilities in the "fixed" status from the upstream open source community.

[0172] Step S605: Merge the patch code into the internal code repository.

[0173] In some embodiments, the above-described vulnerability remediation method may further include:

[0174] If the code merge is successful, the vulnerability issue ticket will be switched from the "ready to go" status to the "complete" status; a Request Map (MR) corresponding to the code merge will be created, and a downlink notification for the vulnerability issue ticket will be sent to the preset device; or,

[0175] When the vulnerability issue ticket is in the downlinkable state, if the fix status of each code vulnerability is in the non-impact state, then the vulnerability issue ticket will be switched from the downlinkable state to the completed state; a downlink notification will be sent to the preset device.

[0176] In some embodiments, the above-described vulnerability remediation method may further include:

[0177] During the process of merging patch code into the internal code repository, if the first code block in the patch code conflicts with the second code block in the internal code repository, the conflict type between the first code block and the second code block is determined.

[0178] The first and second code blocks are processed according to the determined conflict type.

[0179] In some embodiments, the step of processing the first code block and the second code block according to the determined conflict type may include: if the determined conflict type indicates that both the first code block and the second code block are open-source vulnerable code, then the first code block is used to override the second code block in the internal code repository; if the determined conflict type indicates that both the first code block and the second code block are release version numbers, then the first code block is used to override the second code block in the internal code repository.

[0180] In this case, the above-mentioned vulnerability remediation methods may also include:

[0181] If the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first code block and the second code block are not release version numbers, then a visualization report is generated, which includes the first code block and the second code block; the visualization report is then sent to the preset device.

[0182] In some embodiments, the above-described vulnerability remediation method may further include:

[0183] If the first code block in the patch code conflicts with the second code block in the internal code repository, determine whether the number of conflicts exceeds the preset number; if not, determine the conflict type between the first and second code blocks; if so, send a code merge failure message to the preset device.

[0184] In some embodiments, the above-described vulnerability remediation method may further include:

[0185] Detect the type of vulnerability issue ticket; if the vulnerability issue ticket is a user-space issue ticket, then execute step S604.

[0186] In some embodiments, the above-described vulnerability remediation method may further include: after switching the vulnerability issue list from an actionable state to a completed state, recording the remediation status of each code vulnerability.

[0187] The technical solution provided in this application embodiment can collect vulnerability issue reports during the development and localization phase (i.e., vulnerability issue reports in a blocked state), and connect with upstream open-source communities to monitor the remediation status of code vulnerabilities in the upstream open-source communities. Based on the remediation status of code vulnerabilities in the upstream open-source communities, if it is determined that all code vulnerabilities in the vulnerability issue report (i.e., code vulnerabilities in the internal code repository) are remediable, the vulnerability issue report is switched from a blocked state to a remediable state, and the retrieval and merging of patch code is triggered to fix the code vulnerabilities in the vulnerability issue report. In this application embodiment, the remediation status of code vulnerabilities in one or more upstream open-source communities can be monitored in real time, vulnerability issue reports during the development and localization phase can be managed, the status of vulnerability issue reports can be updated in a timely manner, and code merging can be triggered, reducing the manual intervention cost in code vulnerability remediation in scenarios such as FTTR.

[0188] This application also provides an electronic device, such as... Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0189] Memory 703 is used to store computer programs;

[0190] The processor 701, when executing a program stored in the memory 703, implements any of the above-mentioned vulnerability remediation methods.

[0191] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0192] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0193] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0194] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0195] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the above-described vulnerability repair methods.

[0196] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the above-described vulnerability remediation methods.

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

[0198] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0199] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system, electronic device, storage medium, and program product embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0200] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.< / commitid>

Claims

1. A vulnerability remediation method, characterized in that, The method includes: Obtain vulnerability issue reports that are in a blocked state, wherein the vulnerability issue reports include description information of code vulnerabilities; When the status of the vulnerability issue ticket is blocked, obtain the repair status of each code vulnerability included in the vulnerability issue ticket in the upstream open source community; If the fix status of each code vulnerability is either "not affected" or "fixed", then the vulnerability issue will be switched from "blocked" to "downloadable". When the status of the vulnerability issue form is "downloadable", if the fix status of each code vulnerability is "fixed", or if the fix status of some code vulnerabilities in each code vulnerability is "fixed" and the fix status of the remaining code vulnerabilities is "not affected", then the patch code corresponding to the code vulnerabilities in the "fixed" status is pulled from the upstream open source community. The patch code was merged into the internal code repository.

2. The method according to claim 1, characterized in that, The method further includes: If the code merge is successful, the vulnerability issue request will be switched from an available status to a completed status; a Request Map (MR) corresponding to the code merge will be created, and a downlink notification for the vulnerability issue request will be sent to the preset device; or, When the vulnerability issue form is in the downlinkable state, if the fix status of each code vulnerability is in the non-impact state, then the vulnerability issue form is switched from the downlinkable state to the completed state; and the downlink notification is sent to the preset device.

3. The method according to claim 1 or 2, characterized in that, The method further includes: During the process of merging the patch code into the internal code repository, if the first code block in the patch code conflicts with the second code block in the internal code repository, the conflict type between the first code block and the second code block is determined. The first code block and the second code block are processed according to the determined conflict type.

4. The method according to claim 3, characterized in that, The step of processing the first code block and the second code block according to the determined conflict type includes: if the determined conflict type indicates that both the first code block and the second code block are open-source vulnerable code, then the first code block is used to overwrite the second code block in the internal code repository; if the determined conflict type indicates that the first code block and the second code block are release version numbers, then the first code block is used to overwrite the second code block in the internal code repository. The method further includes: If the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first code block and the second code block are not release version numbers, then a visualization report is generated, the visualization report including the first code block and the second code block; and the visualization report is sent to a preset device.

5. The method according to claim 3, characterized in that, The method further includes: If the first code block in the patch code conflicts with the second code block in the internal code repository, determine whether the number of conflicts is greater than a preset number. If not, determine the conflict type between the first code block and the second code block; If so, the code merging failure message is sent to the preset device.

6. The method according to claim 1 or 2, characterized in that, The method further includes: Detect the type of the vulnerability issue report; If the vulnerability issue request is a user-mode issue request, then the following step is executed: when the status of the vulnerability issue request is in the downlinkable state, if the fix status of each code vulnerability is in the fixed state, or if the fix status of some code vulnerabilities in each code vulnerability is in the fixed state and the fix status of the remaining code vulnerabilities is in the unaffected state, then the patch code corresponding to the fixed code vulnerabilities is pulled from the upstream open source community.

7. The method according to claim 2, characterized in that, The method further includes: After switching the vulnerability issue list from the actionable state to the completed state, record the fix status of each code vulnerability.

8. A vulnerability repair system, characterized in that, The vulnerability remediation system includes an issue log subsystem, a vulnerability tracking subsystem, and a code synchronization subsystem. The issue ticket subsystem is used to obtain vulnerability issue tickets that are in a blocked state, the vulnerability issue tickets including description information of code vulnerabilities; and to send the vulnerability issue tickets to the vulnerability tracking subsystem. The vulnerability tracking subsystem is used to obtain the repair status of each code vulnerability included in the vulnerability issue list in the upstream open source community when the status of the vulnerability issue list is blocked; if the repair status of each code vulnerability is "not affected" or "repaired", then the vulnerability issue list is switched from the blocked state to the downlinkable state; when the status of the vulnerability issue list is downlinkable, if the repair status of each code vulnerability is "repaired", or if the repair status of some code vulnerabilities in each code vulnerability is "repaired" and the repair status of the remaining code vulnerabilities is "not affected", then the code synchronization subsystem is triggered. The code synchronization subsystem is used to pull patch code corresponding to the fixed code vulnerabilities from the upstream open source community and merge the patch code into the internal code repository.

9. The system according to claim 8, characterized in that, If the code merging is successful, the code synchronization subsystem will switch the vulnerability issue ticket from the ready-to-go state to the completed state; create a Request Map (MR) corresponding to the code merging; and send a downlink notification of the vulnerability issue ticket to a preset device. The vulnerability tracking subsystem is also used to switch the vulnerability issue form from the "ready to proceed" state to the "completed" state when the status of the vulnerability issue form is "ready to proceed" and the repair status of each code vulnerability is "not affected". Send the downlink notification to the preset device.

10. The system according to claim 8 or 9, characterized in that, The code synchronization subsystem is further configured to, during the process of merging the patch code into the internal code repository, if a first code block in the patch code conflicts with a second code block in the internal code repository, determine the conflict type between the first code block and the second code block; and process the first code block and the second code block according to the determined conflict type.

11. The system according to claim 10, characterized in that, The code synchronization subsystem is specifically used to, if the determined conflict type indicates that both the first code block and the second code block are open-source vulnerable code, then use the first code block to overwrite the second code block in the internal code repository; if the determined conflict type indicates that both the first code block and the second code block are release version numbers, then use the first code block to overwrite the second code block in the internal code repository. The code synchronization subsystem is further configured to generate a visualization report if the determined conflict type indicates that the second code block is an internally modified code block, and the determined conflict type indicates that the first code block and the second code block are not release version numbers. The visualization report includes the first code block and the second code block. Send the visualization report to the preset device.

12. The system according to claim 10, characterized in that, The code synchronization subsystem is further configured to determine whether the number of conflicts exceeds a preset number if the first code block in the patch code conflicts with the second code block in the internal code repository; if not, determine the conflict type between the first code block and the second code block; if so, send the code merge failure message to a preset device.

13. The system according to claim 8 or 9, characterized in that, The vulnerability tracking subsystem is also used to detect the type of the vulnerability issue ticket; if the vulnerability issue ticket is a user-mode issue ticket, then the following steps are executed: when the status of the vulnerability issue ticket is downlinkable, if the repair status of each code vulnerability is repaired, or if the repair status of some code vulnerabilities in each code vulnerability is repaired and the repair status of the remaining code vulnerabilities is unaffected, then the code synchronization subsystem is triggered.

14. The system according to claim 9, characterized in that, The code synchronization subsystem is also used to record the repair status of each code vulnerability after the vulnerability issue form is switched from the actionable state to the completed state. The vulnerability tracking subsystem is also used to record the remediation status of each code vulnerability after the vulnerability issue form is switched from an actionable state to a completed state.

15. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

Images