Vulnerability fixing method and device, and electronic equipment

Abstract

The application provides a vulnerability repair method and device and electronic equipment. The method comprises: obtaining vulnerability information and converting the vulnerability information into a structured data model; determining an audit object according to the structured data model; analyzing the structured data model to obtain a vulnerability type, and obtaining a code segment corresponding to the structured data model and historical code change data; generating a repair patch based on the vulnerability type, the code segment and the historical code change data; displaying the repair patch to the audit object to enable the audit object to review the repair patch and generate a review instruction; and repairing the vulnerability based on the repair patch in response to the review instruction. Thus, the technical problem that the existing vulnerability repair method involves frequent switching and cooperation between multiple roles and multiple systems, each link is heavily dependent on manual operation and subjective judgment, resulting in a long overall vulnerability repair link, low efficiency, and the introduction of new problems due to operation errors or information asynchronization can be solved.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a vulnerability repair method, apparatus and electronic device. Background Technology

[0002] In the software development process, as functional modules increase and become more complex, different functions often share underlying code or common components. When such shared code contains runtime errors or security vulnerabilities, fixing these vulnerabilities often involves multiple functional modules that depend on that code, making the fixing process broad in scope and complex in impact analysis, further increasing the difficulty and risk of the fix.

[0003] In related technologies, existing vulnerability remediation methods mainly rely on manual processes: after testers discover a defect, they need to manually create a record in the defect management system (such as Jira, TAPD, Bugly, etc.) and assign it to developers; developers locate the code and analyze the root cause based on the defect description, and manually create a remediation branch, modify the code, and submit a merge request; subsequently, after a series of manual steps such as code review and build verification, the testers finally confirm the remediation results and close the defect. This vulnerability remediation method involves frequent switching and collaboration between multiple roles and systems, and each step relies heavily on manual operation and subjective judgment, resulting in a lengthy and inefficient overall vulnerability remediation chain, which is also prone to introducing new problems due to operational errors or information asynchrony. Summary of the Invention

[0004] The purpose of this application is to provide a vulnerability remediation method, apparatus, and electronic device to achieve automated vulnerability remediation. This addresses the technical problems of existing vulnerability remediation methods, which involve frequent switching and collaboration between multiple roles and systems, with each step heavily reliant on manual operation and subjective judgment. These methods result in a lengthy and inefficient overall vulnerability remediation process, and are prone to introducing new problems due to operational errors or information asynchrony. The specific technical solution is as follows: In a first aspect of this application, a vulnerability remediation method, apparatus, and electronic device are provided, the method comprising: Obtain vulnerability information and convert the vulnerability information into a structured data model; The audit targets are determined based on the structured data model. The structured data model is analyzed to obtain the vulnerability type, and the code snippets and historical code change data corresponding to the structured data model are obtained. Based on the vulnerability type, the code snippet, and the historical code change data, a fix patch is generated. The patch is displayed to the reviewer, who then reviews the patch and generates a review instruction. In response to the review instructions, the vulnerability is fixed based on the patch.

[0005] In an optional implementation, converting the vulnerability information into a structured data model includes: The vulnerability information is preprocessed to generate standardized data; Get the preset structured template; The standardized data is filled into the corresponding fields of the preset structured template to obtain the structured data model.

[0006] In an optional implementation, determining the audit object based on the structured data model includes: Retrieve the preset audit object mapping table; Obtain the object that matches the structured data model from the preset audit object mapping table, and use it as the audit object.

[0007] In an optional implementation, obtaining the code snippet corresponding to the structured data model and historical code change data includes: Based on the module information in the structured data model, locate at least one code file from the preset project repository; The content of at least one of the code files shall be used as the code fragment; The change records and differences corresponding to the code snippet are retrieved from the preset code repository and used as the historical code change data.

[0008] In an optional implementation, after obtaining the code snippet corresponding to the structured data model and the historical code change data, the method further includes: The target vulnerability is determined based on the vulnerability type, the code snippet, and the historical code change data. The target vulnerability is evaluated, and evaluation results are generated; Based on the evaluation results, determine whether the target vulnerability meets the preset automatic repair conditions; If the target vulnerability meets the preset automatic repair conditions, then the step of generating a repair patch based on the vulnerability type, the code snippet, and the historical code change data is executed.

[0009] In an optional implementation, generating a patch based on the vulnerability type, the code snippet, and the historical code change data includes: The vulnerability type, the code snippet, and the historical code change data are integrated to generate remediation context data; The repair context data is input into a preset code repair model to generate the modified content of the code snippet; The modified content of the code snippet is adjusted according to the preset code difference format to generate the repair patch.

[0010] In an optional implementation, displaying the patch to the audit target includes: Create an initial code branch based on the aforementioned fix patch; A merge request is generated based on the initial code branch; The link corresponding to the merge request is displayed to the auditing object.

[0011] In an optional implementation, after converting the vulnerability information into a structured data model, the method further includes: Create a defect tracking ticket corresponding to the vulnerability information; The defect tracking work order corresponding to the vulnerability information is bound to the structured data model.

[0012] In a second aspect of this application, a vulnerability remediation apparatus is also provided, the apparatus comprising: The vulnerability information conversion module is used to acquire vulnerability information and convert the vulnerability information into a structured data model; The audit target determination module is used to determine the audit target based on the structured data model; The model analysis module is used to analyze the structured data model, obtain the vulnerability type, and acquire the code snippets and historical code change data corresponding to the structured data model. The patch generation module is used to generate a patch based on the vulnerability type, the code snippet, and the historical code change data. The review instruction generation module is used to display the repair patch to the review object so that the review object can review the repair patch and generate a review instruction; The vulnerability remediation module is used to remediate vulnerabilities based on the remediation patch in response to the review instructions.

[0013] In a third aspect of the embodiments of this application, an electronic device is also provided, 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; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the vulnerability remediation method described in any one of the first aspects above.

[0014] In a fourth aspect of the embodiments of this application, a storage medium is also provided, wherein the storage medium stores instructions that, when run on a computer, cause the computer to execute any of the vulnerability remediation methods described in the first aspect above.

[0015] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the vulnerability repair methods described in the first aspect above.

[0016] The technical solution provided in this application involves acquiring vulnerability information and converting it into a structured data model; determining the audit target based on the structured data model; analyzing the structured data model to obtain the vulnerability type and acquiring the corresponding code snippet and historical code change data; generating a patch based on the vulnerability type, code snippet, and historical code change data; displaying the patch to the audit target for review and generating an audit instruction; and performing vulnerability repair based on the patch in response to the audit instruction. By converting vulnerability information into a structured data model to generate a patch, and then performing vulnerability repair based on the audit instruction, automated vulnerability repair can be achieved. This solves the technical problems of existing vulnerability repair methods, which involve frequent switching and collaboration between multiple roles and systems, heavy reliance on manual operation and subjective judgment in each step, resulting in a lengthy and inefficient overall vulnerability repair chain, and susceptibility to new problems introduced due to operational errors or information asynchrony. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1 A schematic diagram illustrating the implementation process of a vulnerability remediation method provided in this application embodiment; Figure 2A schematic diagram illustrating the implementation process of another vulnerability remediation method provided in this application embodiment; Figure 3 A schematic diagram illustrating the implementation process of another vulnerability remediation method provided in this application embodiment; Figure 4 A schematic diagram illustrating the implementation process of an automatic repair detection method provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of a vulnerability repair device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0023] To address the technical problems of existing vulnerability remediation methods involving frequent switching and collaboration among multiple roles and systems, heavy reliance on manual operation and subjective judgment in each stage, resulting in a lengthy and inefficient overall vulnerability remediation chain, and susceptibility to new problems due to operational errors or information asynchrony, this application provides a vulnerability remediation method, apparatus, and electronic device. The method involves: acquiring vulnerability information and converting it into a structured data model; determining the review target based on the structured data model; analyzing the structured data model to obtain the vulnerability type and acquiring the corresponding code snippet and historical code change data; generating a remediation patch based on the vulnerability type, code snippet, and historical code change data; displaying the remediation patch to the review target for review and generating a review instruction; and performing vulnerability remediation based on the remediation patch in response to the review instruction. By converting vulnerability information into a structured data model to generate a remediation patch, and then performing vulnerability remediation based on review instructions, automated vulnerability remediation can be achieved.

[0024] like Figure 1 The diagram shown illustrates the implementation flow of a vulnerability remediation method provided in this application embodiment, which may specifically include the following steps: S101: Obtain vulnerability information and convert it into a structured data model.

[0025] The aforementioned vulnerability information refers to descriptions of program errors, defects, or abnormal behaviors discovered during software testing or operation, which may include titles, descriptions, reproduction steps, logs, etc.

[0026] The aforementioned structured data model refers to the conversion of unstructured vulnerability information (such as natural language descriptions) into a computer-processable data structure with fixed fields and formats.

[0027] In this embodiment of the application, vulnerability information is acquired and converted into a structured data model. This step involves receiving unstructured or semi-structured vulnerability information input from testers or monitoring systems and converting it into a machine-understandable structured data model.

[0028] Specifically, the execution results of the testing framework can be monitored or polled. When a test case fails, stack traces, error messages, screenshots, etc., can be automatically captured as vulnerability information. Alternatively, a web interface or IDE plugin can be provided for testers or developers to manually fill in the vulnerability title, detailed description, reproduction steps, expected / actual results, log fragments, system environment, etc., as vulnerability information. Alarm events from application performance monitoring (APM), log aggregation systems (such as ELK), or online anomaly capture platforms (such as Sentry, Bugly) can also be received and their contents used as vulnerability information; however, this embodiment does not limit this aspect.

[0029] S102, Determine the audit targets based on the structured data model.

[0030] The aforementioned review targets refer to the responsible persons who are responsible for reviewing and confirming the repair content, such as developers or testers. This is used to introduce a human supervision step into the automated repair process to ensure the accuracy and security of the repair and to avoid introducing new problems through automated repair.

[0031] In this embodiment, the review object is determined based on a structured data model. This step is used to assign a final responsible reviewer to the automatically generated fix patches to determine the accuracy of the fixes and the standardization of the code.

[0032] Specifically, the audit target can be determined by a preset module-responsible person mapping table based on module information or file paths in the structured data model; or by analyzing the recent modification records of relevant files in the code repository, the most recent major contributor can be set as the default audit target; it is also possible to manually specify the auditer when submitting a vulnerability, and if no auditer is specified, the auditer will be automatically assigned according to the above rules. This application embodiment does not limit this.

[0033] S103 analyzes the structured data model to obtain the vulnerability type and acquires the code snippets and historical code change data corresponding to the structured data model.

[0034] The above vulnerability types refer to the categorization of vulnerabilities, such as null pointer exceptions, logical errors, and data validation issues. Understanding the nature of the vulnerability allows for the selection of appropriate remediation strategies and tools.

[0035] The code snippet mentioned above refers to the source code portion related to the vulnerability. It can be a single function, class, or module, representing the specific target code area for vulnerability remediation operations.

[0036] The aforementioned historical code change data refers to the previous modification records of this code segment, which may include commit information, difference comparisons, and the person who made the changes. This data is used to provide context for automated vulnerability remediation, helping to understand the code evolution logic and assisting in generating more reasonable remediation solutions.

[0037] In this embodiment, the structured data model is analyzed to determine the vulnerability type, and the corresponding code snippets and historical code change data are obtained. This step provides contextual data for the generation of subsequent patch fixes.

[0038] Specifically, vulnerability descriptions can be categorized using natural language processing models or matched based on anomaly types in logs to determine the vulnerability type; code snippets related to the vulnerability can be located by parsing stack traces or semantically retrieving code repositories; and historical code change data can be constructed by obtaining the commit history, differences, and modifier information of the snippet through the code repository interface.

[0039] S104 generates a patch based on the vulnerability type, code snippet, and historical code change data.

[0040] The aforementioned patch refers to the code modification scheme generated for the vulnerability, which can be represented in the form of a differential file. This file details how to modify the code to fix the vulnerability and is the core output of automated remediation.

[0041] In this embodiment, a patch is generated based on the vulnerability type, code snippet, and historical code change data. This step is used to generate a code modification plan, i.e., a patch.

[0042] Specifically, a pre-trained code generation model can be invoked, taking the vulnerability description, vulnerability type, related code snippets, and historical change context as input to generate the repaired code or directly output the difference patch; or, for common vulnerability patterns, the corresponding repair template can be matched through the rule engine to automatically generate the repair patch.

[0043] It's worth noting that after generating the patch, you can perform simple syntax checks and code formatting in memory or a sandbox to ensure the generated code conforms to project specifications. You can also further test the relevant unit tests in a temporary environment to verify whether the patch passes the tests.

[0044] S105, the patch is displayed to the auditing entity so that the auditing entity can review the patch and generate an audit instruction.

[0045] The aforementioned review instructions refer to the reviewer's assessment of the patch, such as "Approved," "Rejected," or "Requires Modification." These instructions are used to provide feedback to the reviewer to determine whether to continue the patching process or make adjustments.

[0046] In this embodiment of the application, the repair patch is displayed to the review object so that the review object can review the repair patch and generate a review instruction.

[0047] S106, in response to the review directive, performs vulnerability remediation based on the patch.

[0048] In this embodiment of the application, in response to the review instructions, vulnerability repair is performed based on the patch. Vulnerability repair refers to the actual code modification operation, which may include applying the patch to the codebase, merging branches, updating the version, etc., to ultimately eliminate the defects in the software and complete the closed-loop process.

[0049] Specifically, if the review instruction is "passed", the repair branch will be automatically merged into the target branch, and the vulnerability status in the defect management system will be updated to "repaired" after the merging is successful, and the testers will be notified to verify. If the review instruction is "rejected" or "needs modification", the relevant developers will be notified to handle it manually, and the execution information can be recorded for optimization of the repair model. After the repair is completed, the temporary branch will be automatically cleaned up, and the entire repair process log will be recorded for auditing and analysis.

[0050] Based on the above description of the technical solution provided in the embodiments of this application, vulnerability information is obtained and converted into a structured data model; the audit object is determined according to the structured data model; the structured data model is analyzed to obtain the vulnerability type, and code snippets and historical code change data corresponding to the structured data model are obtained; a patch is generated based on the vulnerability type, code snippets, and historical code change data; the patch is displayed to the audit object so that the audit object can review the patch and generate an audit instruction; in response to the audit instruction, vulnerability repair is performed based on the patch. By converting vulnerability information into a structured data model to generate a patch, and then performing vulnerability repair based on the audit instruction, automated vulnerability repair can be achieved. This solves the technical problems of existing vulnerability repair methods involving frequent switching and collaboration between multiple roles and systems, heavy reliance on manual operation and subjective judgment in each step, resulting in a lengthy and inefficient overall vulnerability repair chain, and susceptibility to new problems introduced due to operational errors or information asynchrony.

[0051] like Figure 2 The diagram shown illustrates the implementation flow of another vulnerability remediation method provided in this application embodiment, which may specifically include the following: S201: Obtain vulnerability information and convert it into a structured data model.

[0052] In this embodiment of the application, vulnerability information can be obtained and converted into a structured data model.

[0053] The process of converting vulnerability information into a structured data model can specifically include the following steps: Step 11: Preprocess the vulnerability information to generate standardized data.

[0054] In this embodiment, vulnerability information is preprocessed to generate standardized data. Preprocessing may include: removing irrelevant characters, standardizing encoding formats, extracting key text fields, slicing and de-identifying logs, and converting attachments such as images and screen recordings into storable links or text summaries. This embodiment does not limit the scope of this process.

[0055] Step 12: Obtain the preset structured template.

[0056] In this embodiment of the application, a preset structured template is obtained. The preset structured template is a predefined JSONSchema or similar data contract, which specifies the fields, types, constraints and default values ​​that the vulnerability model should include. For example, the preset structured template includes fields such as bug_id (string), title (string), module (enumeration type), severity (enumeration type), reproduce_steps (array), and logs (text).

[0057] Step 13: Fill the standardized data into the corresponding fields of the preset structured template to obtain the structured data model.

[0058] In this embodiment, standardized data is populated into the corresponding fields of a preset structured template to obtain a structured data model. Specifically, the standardized data generated in step 11 can be automatically populated into the corresponding fields of the template using field mapping rules or lightweight natural language parsing.

[0059] For example, the module keywords are identified from the description and filled into the corresponding module field of the preset structured template. The error_type field is automatically set according to whether the log contains "NullPointerException". Finally, a complete structured data object is output.

[0060] S202, obtain the preset audit object mapping table.

[0061] In this embodiment of the application, a preset audit object mapping table is obtained. This preset audit object mapping table is a configurable data table or configuration file that stores the mapping relationship between project modules, code paths, service names, and corresponding audit objects (i.e., responsible persons or teams).

[0062] S203: Obtain the object that matches the structured data model from the preset audit object mapping table and use it as the audit object.

[0063] In this embodiment of the application, an object matching the structured data model is obtained from the preset audit object mapping table obtained in the above steps, and is used as the audit object.

[0064] It should be noted that if there are multiple matching items, they can be selected according to the priority rules or specified as the audit objects at the same time.

[0065] S204 analyzes the structured data model to determine the vulnerability type.

[0066] In this embodiment of the application, this step is similar to step S103 above, and will not be described in detail here.

[0067] S205, based on the module information in the structured data model, locate at least one code file from the preset project repository.

[0068] The aforementioned pre-defined project repository refers to a version control system (such as a Git repository) that stores the project's source code. It is used to provide target code sources for code analysis, historical tracing, and automatic modification.

[0069] The aforementioned code file refers to a text file containing software source code, that is, a source code file associated with the current vulnerability.

[0070] In this embodiment, at least one code file is located from a preset project repository based on module information in the structured data model. Specifically, a search and matching process can be performed in the preset project repository based on the module, class name, method name, or interface path mentioned in the vulnerability information to locate at least one code file.

[0071] For example, when the module field in the structured data model is payment-core, you can search for directories (such as src / payment / core / ) or files containing the module identifier in the code repository; or, based on the fully qualified class name com.example.payment.Processor mentioned in the stack trace, you can directly locate the corresponding Java source file as the code file.

[0072] S206, take the contents of at least one code file as a code snippet.

[0073] In this embodiment of the application, the content of at least one code file is used as a code fragment.

[0074] Specifically, the entire contents of the located code file can be read directly as a code fragment; or, based on the line number information in the vulnerability description or stack information, specific functions, code blocks, or class definitions in the file can be extracted as more precise code fragments.

[0075] S207: Retrieve the change records and differences corresponding to the code snippets from the preset code repository as historical code change data.

[0076] In this embodiment of the application, change records and differences corresponding to code snippets can be obtained from a preset code repository as historical code change data.

[0077] Specifically, you can use commands or APIs of a version control system (such as Git) to query historical commit records related to the file containing the aforementioned code snippet. The retrieved information includes, but is not limited to: the hash values ​​of the most recent N commits (N being a positive integer, such as 10), the committer, the commit time, the commit message, and the specific code differences resulting from each commit. This data collectively constitutes historical code change data used to understand the context of vulnerability introduction and remediation patterns.

[0078] S208 generates a patch based on the vulnerability type, code snippet, and historical code change data.

[0079] In this embodiment of the application, this step is similar to step S104 above, and will not be described in detail here.

[0080] S209 displays the patch to the auditing entity so that the auditing entity can review the patch and generate an audit instruction.

[0081] In this embodiment of the application, this step is similar to step S105 above, and will not be described in detail here.

[0082] S210, in response to review directives, performs vulnerability fixes based on patching.

[0083] In this embodiment of the application, this step is similar to step S106 above, and will not be described in detail here.

[0084] like Figure 3 The diagram shown illustrates the implementation flow of another vulnerability remediation method provided in this application, which may specifically include the following: S301: Obtain vulnerability information and convert it into a structured data model.

[0085] In this embodiment of the application, vulnerability information is obtained and converted into a structured data model.

[0086] After converting vulnerability information into a structured data model, the process may also include: creating a defect tracking ticket corresponding to the vulnerability information; and binding the defect tracking ticket corresponding to the vulnerability information to the structured data model.

[0087] Among them, defect tracking work orders refer to task documents automatically created in external project management (PMS) or issue tracking systems (such as Jira) for formally tracking and managing the lifecycle of a vulnerability. They are used to anchor the vulnerability in the organization's established management processes and achieve the connection between automated systems and manual processes.

[0088] The aforementioned binding of vulnerability information to defect tracking work orders with structured data models refers to establishing a bidirectional association between the structured data model and the identifiers corresponding to defect tracking work orders. This ensures that the automated processing status (such as completion of repair) can be synchronously written back to the management work order, achieving a closed-loop status mechanism.

[0089] S302, Determine the audit targets based on the structured data model.

[0090] In this embodiment of the application, this step is similar to step S102 above, and will not be described in detail here.

[0091] After identifying the target for review, the structured data model can be input into a preset judgment model to make a preliminary judgment on the current vulnerability and whether it can be automatically repaired by the model; alternatively, the structured data model can be analyzed based on preset review rules to make a preliminary judgment on the current vulnerability and whether it can be automatically repaired by the model.

[0092] If automatic repair is possible, the preliminary assessment is that automatic repair is feasible; otherwise, the preliminary assessment is that automatic repair is feasible. Simultaneously, vulnerability description information is obtained from the structured data model, and a defect tracking work order is determined based on the structured data model. The vulnerability description information, preliminary assessment, and defect tracking work order are then converted into structured data and communicated to the review recipient.

[0093] S303 analyzes the structured data model to determine the vulnerability type and obtains the code snippets corresponding to the structured data model, as well as historical code change data.

[0094] In this embodiment of the application, this step is similar to step S103 above, and will not be described in detail here.

[0095] After obtaining the code snippets and historical code change data corresponding to the above structured data model, it is possible to determine whether automated vulnerability remediation can be achieved based on the vulnerability type, code snippets, and historical code change data. For details, please refer to... Figure 4 The method shown. (As illustrated) Figure 4 The diagram shown is a schematic representation of the implementation flow of an automatic repair detection method provided in this application embodiment, which may specifically include the following steps: S401 identifies the target vulnerability based on the vulnerability type, code snippet, and historical code change data.

[0096] In this embodiment of the application, the target vulnerability is determined based on the vulnerability type, code snippet, and historical code change data. The target vulnerability refers to the vulnerability entity to be processed, whose type, location, and related code context have been clearly identified after the aforementioned analysis steps.

[0097] S402 assesses the target vulnerability and generates assessment results.

[0098] In this embodiment of the application, the target vulnerability is evaluated, and an evaluation result is generated.

[0099] The evaluation can be based on predefined rules or machine learning models, and considers factors including but not limited to: the known fixability of the vulnerability type, the complexity of the code snippet (e.g., cyclomatic complexity), the frequency of historical changes, the existence of a clear remediation pattern (e.g., similar historical remediations), and related test coverage. The output evaluation result can be a score or a classification label (e.g., high auto-remediable, medium, low), which is not limited in this embodiment.

[0100] S403, based on the assessment results, determines whether the target vulnerability meets the preset automatic repair conditions.

[0101] In this embodiment of the application, based on the evaluation results generated by the above steps, it is determined whether the target vulnerability meets the preset automatic repair conditions. The preset automatic repair conditions can be one or a set of thresholds. For example, if the "automatic repair confidence" score in the evaluation results is higher than a preset threshold (e.g., 0.7), and the vulnerability type belongs to a preset "list of types that support automatic repair" (e.g., null pointer, simple data validation error), then the preset automatic repair conditions are met; otherwise, the preset automatic repair conditions are not met.

[0102] S404 If the target vulnerability meets the preset automatic repair conditions, then the step of generating a repair patch based on the vulnerability type, code snippet, and historical code change data is executed.

[0103] In this embodiment, if the target vulnerability meets the preset automatic repair conditions, a step of generating a repair patch based on the vulnerability type, code snippet, and historical code change data is executed. That is, step S103, which in this embodiment refers to executing the following step S304.

[0104] S304 integrates vulnerability types, code snippets, and historical code change data to generate remediation context data.

[0105] In this embodiment of the application, vulnerability types, code snippets, and historical code change data are integrated to generate remediation context data.

[0106] Specifically, vulnerability types, code snippets, and historical code change data can be integrated according to a preset template or structure (such as JSON format) to generate remediation context data.

[0107] S305: Input the repair context data into the preset code repair model to generate the modified content of the code snippet.

[0108] In this embodiment, repair context data is input into a preset code repair model to generate modified code snippets. The preset code repair model refers to a trained AI model capable of generating repaired code or modification instructions based on the code context, such as a Large Language Model (LLM) based on the Transformer architecture or a model specifically tuned for code repair tasks.

[0109] S306: Adjust the modified content of the code snippet according to the preset code difference format and generate a repair patch.

[0110] In this embodiment, the modifications to the code snippet are adjusted according to a preset code diff format to generate a repair patch. The preset code diff format refers to a standardized code change representation format, such as the Unix diff format or Git patch format. This step converts the modifications to the code snippet output by the model into a repair patch conforming to this standard format. Specifically, by comparing the modifications to the original code snippet with those generated by the model, the added, deleted, and modified lines of code are automatically calculated, encapsulated and output in a specified diff format, generating the final repair patch.

[0111] S307, creates an initial code branch based on the fix patch.

[0112] In this embodiment, an initial code branch is created based on the patch. This initial code branch hosts the patch to be applied. The initial code branch can be named according to conventions, such as including a defect tracking ticket identifier or an internal vulnerability identifier. This creation operation can be automated by calling the API of a version control system (such as Git).

[0113] Specifically, a new branch can be created based on the target branch of the code repository (such as main or develop), and the generated fixes can be automatically committed to that branch. The commit message can be automatically generated and can include the associated vulnerability identifier and a brief fix description.

[0114] S308 generates a merge request based on the initial code branch.

[0115] In this embodiment, a merge request is generated based on the initial code branch. The merge request is used to propose a code merge to the target branch (e.g., main) of the code repository, facilitating subsequent code review, automated test integration, and ultimately, incorporating the patched code into the main development process. The description of the merge request may include an overview of the patched vulnerability, a brief description of the patch, a link to the associated defect tracking ticket, and identification tags added by the automated system.

[0116] S309 displays the link corresponding to the merge request to the auditing entity so that the auditing entity can review the patch and generate an audit instruction.

[0117] In this embodiment of the application, the link corresponding to the merge request is displayed to the review object so that the review object can review the patch and generate a review instruction.

[0118] Specifically, the webpage link for the merge request created in step S308 above can be sent to the review recipient through various channels such as email, instant messaging bots, site messages, or notifications linked with the defect tracking system. The review recipient can click the link to review the code differences in detail on the code hosting platform's web interface, understand the specific modifications, and generate clear review instructions on this interface through actions such as "Approve," "Comment," "Request Change," or "Merge," ensuring a convenient and transparent review process and leaving a traceable review record.

[0119] S310, in response to review directives, performs vulnerability fixes based on patching.

[0120] In this embodiment of the application, this step is similar to step S106 above, and will not be described in detail here.

[0121] Corresponding to the above method embodiments, this application also provides a vulnerability repair device, such as... Figure 5 As shown, the device may include a vulnerability information conversion module 501, an audit object determination module 502, a model analysis module 503, a patch generation module 504, an audit instruction generation module 505, and a vulnerability repair module 506.

[0122] The vulnerability information conversion module 501 is used to acquire vulnerability information and convert it into a structured data model. The audit target determination module 502 is used to determine the audit target based on the structured data model; The model analysis module 503 is used to analyze the structured data model, obtain the vulnerability type, and acquire the code snippets corresponding to the structured data model and historical code change data. The patch generation module 504 is used to generate patch repairs based on vulnerability type, code snippets, and historical code change data. The review instruction generation module 505 is used to display the repair patch to the review object so that the review object can review the repair patch and generate a review instruction; Vulnerability remediation module 506 is used to remediate vulnerabilities based on remediation patches in response to review instructions.

[0123] This application also provides an electronic device, such as... Figure 6As shown, it includes a processor 601, a communication interface 602, a memory 603, and a communication bus 604, wherein the processor 601, the communication interface 602, and the memory 603 communicate with each other through the communication bus 604. Memory 603 is used to store computer programs; In one embodiment of this application, when the processor 601 executes a program stored in the memory 603, it performs the following steps: Obtain vulnerability information and convert it into a structured data model; determine the audit targets based on the structured data model; analyze the structured data model to obtain the vulnerability type and obtain the corresponding code snippets and historical code change data; generate a patch based on the vulnerability type, code snippets, and historical code change data; display the patch to the audit targets so they can review it and generate an audit instruction; and in response to the audit instruction, perform vulnerability repair based on the patch.

[0124] The communication bus mentioned in the above electronic devices 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 indicate that there is only one bus or one type of bus.

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

[0126] The memory may include random access memory (RAM) or non-volatile memory, 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.

[0127] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0128] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the vulnerability remediation methods described in the above embodiments.

[0129] 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 vulnerability remediation methods described in the above embodiments.

[0130] 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 in the form of 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 storage medium or transmitted from one 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 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)).

[0131] 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.

[0132] 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 embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0133] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.

Claims

1. A vulnerability remediation method, characterized in that, The method includes: Obtain vulnerability information and convert the vulnerability information into a structured data model; The audit targets are determined based on the structured data model. The structured data model is analyzed to obtain the vulnerability type, and the code snippets and historical code change data corresponding to the structured data model are obtained. Based on the vulnerability type, the code snippet, and the historical code change data, a fix patch is generated. The patch is displayed to the reviewer, who then reviews the patch and generates a review instruction. In response to the review instructions, the vulnerability is fixed based on the patch.

2. The method according to claim 1, characterized in that, The step of converting the vulnerability information into a structured data model includes: The vulnerability information is preprocessed to generate standardized data; Get the preset structured template; The standardized data is filled into the corresponding fields of the preset structured template to obtain the structured data model.

3. The method according to claim 1, characterized in that, The step of determining the audit target based on the structured data model includes: Retrieve the preset audit object mapping table; Obtain the object that matches the structured data model from the preset audit object mapping table, and use it as the audit object.

4. The method according to claim 1, characterized in that, The step of obtaining the code snippets and historical code change data corresponding to the structured data model includes: Based on the module information in the structured data model, locate at least one code file from the preset project repository; The content of at least one of the code files shall be used as the code fragment; The change records and differences corresponding to the code snippet are retrieved from the preset code repository and used as the historical code change data.

5. The method according to claim 1, characterized in that, After obtaining the code snippets and historical code change data corresponding to the structured data model, the method further includes: The target vulnerability is determined based on the vulnerability type, the code snippet, and the historical code change data. The target vulnerability is evaluated, and evaluation results are generated; Based on the evaluation results, determine whether the target vulnerability meets the preset automatic repair conditions; If the target vulnerability meets the preset automatic repair conditions, then the step of generating a repair patch based on the vulnerability type, the code snippet, and the historical code change data is executed.

6. The method according to claim 1, characterized in that, The process of generating a patch based on the vulnerability type, the code snippet, and the historical code change data includes: The vulnerability type, the code snippet, and the historical code change data are integrated to generate remediation context data; The repair context data is input into a preset code repair model to generate the modified content of the code snippet; The modified content of the code snippet is adjusted according to the preset code difference format to generate the repair patch.

7. The method according to claim 1, characterized in that, The step of displaying the patch to the review recipient includes: Create an initial code branch based on the aforementioned fix patch; A merge request is generated based on the initial code branch; The link corresponding to the merge request is displayed to the auditing object.

8. The method according to claim 1, characterized in that, After converting the vulnerability information into a structured data model, the method further includes: Create a defect tracking ticket corresponding to the vulnerability information; The defect tracking work order corresponding to the vulnerability information is bound to the structured data model.

9. A vulnerability repair device, characterized in that, The device includes: The vulnerability information conversion module is used to acquire vulnerability information and convert the vulnerability information into a structured data model; The audit target determination module is used to determine the audit target based on the structured data model; The model analysis module is used to analyze the structured data model, obtain the vulnerability type, and acquire the code snippets and historical code change data corresponding to the structured data model. The patch generation module is used to generate a patch based on the vulnerability type, the code snippet, and the historical code change data. The review instruction generation module is used to display the repair patch to the review object so that the review object can review the repair patch and generate a review instruction; The vulnerability remediation module is used to remediate vulnerabilities based on the remediation patch in response to the review instructions.

10. 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-8.

Images