Vulnerability repairing method, electronic equipment and computer program product

Abstract

The invention provides a vulnerability repairing method, electronic equipment and a computer program product. The vulnerability repairing method comprises the steps that vulnerability information of a first file is analyzed, a second file is obtained, the vulnerability information is used for describing vulnerabilities in the first file, and the second file is a repairing result of the vulnerabilities; determining a difference portion between the first file and the second file; according to the vulnerability information and the difference part, a comprehensive score of the second file is determined, and the comprehensive score represents the vulnerability processing effect of the second file; under the condition that the comprehensive score is larger than a score threshold value, the second file is determined to be a target file, the target file and the first file have the same configuration, the target file does not have vulnerabilities, and the configuration comprises a code function and a code format.

Description

Technical Field

[0001] The present disclosure relates to technical fields such as data processing, and more particularly to a vulnerability repair method, an electronic device, and a computer program product. Background Art

[0002] Security vulnerability repair is an important part of the software development process. When developers complete code submission, security scanning tools are usually automatically triggered to check for possible security vulnerabilities in the code. Once a potential security issue is detected, the system will generate corresponding repair suggestions and provide a series of general repair cases for reference. However, many R&D personnel do not have the knowledge of security vulnerability repair, which requires them to spend a lot of time on vulnerability repair, greatly reducing the efficiency of repair. In addition, since the general repair cases provided are often difficult to fully match the special circumstances of specific vulnerabilities, this one-size-fits-all repair method will result in incomplete repairs and may even introduce new security risks during the repair process, further exacerbating the difficulty and complexity of code security management. Summary of the invention

[0003] The present disclosure provides a vulnerability repair method, an electronic device, and a computer program product.

[0004] According to one aspect of the present disclosure, a hole repair method is provided, including: analyzing vulnerability information of a first file to obtain a second file, wherein the vulnerability information is used to describe the vulnerability in the first file, and the second file is a repair result of the vulnerability; determining a difference between the first file and the second file; determining a comprehensive score of the second file according to the vulnerability information and the difference, wherein the comprehensive score represents a processing effect of the second file on the vulnerability; and determining, when the comprehensive score is greater than a score threshold, that the second file is a target file, wherein the target file has the same configuration as the first file and the target file does not have the vulnerability, wherein the configuration includes code function and code format.

[0005] In some embodiments, analyzing vulnerability information of a first file to obtain a second file includes: generating first prompt information for a first model based on the vulnerability information, the first model being able to repair the vulnerability of the first file, the first prompt information providing repair requirements for the first model; and controlling the first model to process the first file according to the first prompt information to obtain the second file.

[0006] In some embodiments, first prompt information for a first model is generated based on the vulnerability information, including: determining a to-be-repaired portion of the first file based on vulnerability location information in the vulnerability information, the to-be-repaired portion being the first complete code of the first file or the first code fragment having the vulnerability; searching a case collection for associated cases corresponding to the target vulnerability type based on a target vulnerability type in the vulnerability information, the case collection including repair codes and repair suggestions for a variety of vulnerability types, the associated cases being repair codes and repair suggestions for the target vulnerability type; constructing first prompt information including the vulnerability type, the vulnerability description in the vulnerability information, the associated cases, and the to-be-repaired portion, the first prompt information being able to trigger the first model to repair the vulnerability.

[0007] In some embodiments, determining the part to be repaired of the first file according to the vulnerability location information in the vulnerability information includes: determining the file repository recording the first file according to the file repository address in the vulnerability location information; determining a first complete code corresponding to the file identifier in the file repository according to the target branch and file identifier in the vulnerability location information, the first complete code being the file content of the first file, and the file identifier being used to mark the first file; and when the character length of the first complete code is less than a length threshold, using the first complete code as the part to be repaired.

[0008] In some embodiments, after determining the first complete code corresponding to the file identifier in the file repository, it also includes: when the character length of the first complete code is greater than or equal to a length threshold, determining the vulnerability area in the first complete code according to the target line in the vulnerability location information; and using a code parsing tool to determine a first code fragment containing the vulnerability area, and using the first code fragment as the part to be repaired, the first code fragment being a part of the first complete code that has complete logic and contains the vulnerability area.

[0009] In some embodiments, determining a comprehensive score of the second file based on the vulnerability information and the difference part includes: determining second prompt information for a second model based on the vulnerability information and the difference part, the second model being capable of determining a comprehensive score of the second file, the second prompt information providing scoring requirements for the second model, the second prompt information including the vulnerability type and vulnerability description in the vulnerability information, associated cases corresponding to the vulnerability type, and the difference part; and controlling the second model to analyze the second file according to the second prompt information to obtain the comprehensive score.

[0010] In some embodiments, controlling the second model to analyze the second file according to the second prompt information to obtain the comprehensive score includes: determining the degree of association between the difference portion and the vulnerability type and the related case; determining the similarity between the configuration of the second file and the configuration of the first file; and determining the comprehensive score of the second file based on the degree of association and the similarity, wherein the comprehensive score is proportional to the degree of association and the similarity.

[0011] In some embodiments, after determining the comprehensive score of the second file, it also includes: when the comprehensive score is less than or equal to the score threshold, generating a scoring reason for the second file; and synchronizing the scoring reason and the first prompt information to the first model to control the first model to generate a new second file.

[0012] In some implementations, the step further includes: configuring a first plug-in in a code editor, where the code editor is a tool for editing the first file, and the first plug-in is a component for pushing the target file to the code editor.

[0013] In some embodiments, after determining that the second file is the target file, the method includes: synchronizing the target file and the difference part to the code editor through the first plug-in, in which the difference part is highlighted in both the target file and the first file; and replacing the first file with the target file in response to a confirmation instruction for the target file.

[0014] According to one aspect of the present disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, so that the processor executes the vulnerability repair method of any one of the above-mentioned embodiments.

[0015] According to one aspect of the present disclosure, a computer program product is provided, including a computer program, wherein when the computer program is executed by a processor, the vulnerability repair method of any of the above embodiments is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings illustrate exemplary embodiments of the present disclosure and together with the description serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0017] Figure 1 It is a schematic diagram of an application scenario of the vulnerability repair method according to an embodiment of the present disclosure.

[0018] Figure 2It is a flow chart of a vulnerability repair method according to an embodiment of the present disclosure.

[0019] Figure 3 It is a schematic diagram of the architecture of the vulnerability repair method according to the implementation mode of the present disclosure.

[0020] Figure 4 4 is a schematic diagram of a second file acquisition process according to an embodiment of the present disclosure.

[0021] Figure 5 It is a schematic diagram of the process of obtaining the comprehensive score according to the embodiment of the present disclosure.

[0022] Figure 6 FIG. 4 is a diagram showing a difference portion displayed by a code editor according to an embodiment of the present disclosure.

[0023] Figure 7 It is a schematic block diagram of the structure of a vulnerability repair device according to an embodiment of the present disclosure.

[0024] Figure 8 It is a schematic block diagram of the structure of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] The present disclosure is further described in detail below in conjunction with the accompanying drawings and examples. It is understood that the specific examples described herein are only used to explain the relevant content, rather than to limit the present disclosure. It should also be noted that, for ease of description, only the parts related to the present disclosure are shown in the accompanying drawings.

[0026] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure can be combined with each other. The technical solution of the present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0027] In the related art, security scanning tools are usually used to check the security vulnerabilities of the code files to be put into production, where the security vulnerabilities can be types such as SQL (Structured Query Language) injection vulnerabilities, open redirection vulnerabilities, and path traversal vulnerabilities. In addition, general repair cases and repair suggestions corresponding to the vulnerability types are returned. However, some code developers do not have the knowledge of security vulnerability repair, which requires them to spend a lot of time on vulnerability repair, greatly reducing the efficiency of repair. In addition, since the general repair cases provided are often difficult to fully match the special circumstances of specific vulnerabilities, this one-size-fits-all repair method will result in incomplete repairs, and may even introduce new security risks during the repair process, further exacerbating the difficulty and complexity of code security management.

[0028] To this end, the present disclosure proposes a vulnerability repair method.

[0029] Figure 1 Schematic diagram of an application scenario of a vulnerability repair method according to an embodiment of the present disclosure. Figure 1 As shown, in this scenario, a server 100 and a terminal device 200 may be included. The server 100 and the terminal device 200 may be connected via a network or Bluetooth to exchange data. The server 100 may be a cloud server or a physical server, and the terminal device 200 may be a computer, a mobile phone, a tablet, etc., and may have a display screen. The server 100 is used to provide the basic data required to run the vulnerability repair method, and the terminal device 200 executes the vulnerability repair method of the present disclosure based on the basic data provided by the server 100.

[0030] Figure 2 Flowchart of a vulnerability repair method according to an embodiment of the present disclosure. Figure 2 As shown, the vulnerability repair method M200 of the present disclosure, the steps S201 to S204 involved in the method are described below. The basic data required to run the vulnerability repair method M200 can be stored in Figure 1 On the server 100, the method can be run on Figure 1 On the terminal device 200.

[0031] In step S201, vulnerability information of a first file is analyzed to obtain a second file.

[0032] The security scanning tool scans all files related to a project in the file warehouse, or scans the files involved in the newly written code. After being identified by the security scanning tool, the file with a vulnerability is called the first file. The first file records the program text, i.e., the code, that implements a specific function or solves a specific problem. For example, the project can be to build an e-commerce website or a small program. The file warehouse establishes multiple branches according to different threads to manage files that implement different functional tasks.

[0033] Vulnerability information includes at least the target vulnerability type, vulnerability description, file repository address, branch information, file identifier and target line. Vulnerability information is the output result after the security scanning tool scans the first file. Target vulnerability types may include SQL injection vulnerabilities, open redirection vulnerabilities, path traversal vulnerabilities, etc., which are not listed here one by one. The vulnerability description is used to introduce the meaning of the vulnerability, the impact of the vulnerability on the code operation and the results; for example, when the target vulnerability type is an open redirection vulnerability type, the vulnerability description can be "The application receives the data passed in by the user, does not perform parameter verification, and directly redirects the user to a malicious website. Attackers can use this vulnerability to trick users into clicking on malicious URLs, thereby jumping to malicious websites imitated by attackers. Users may be attacked by phishing", etc. The file repository address is the network address of the file repository that records the first file. The file repository address can be used to jump to the file repository; the file repository can be a Git repository, which is a code repository managed using the Git version control system. A branch is part of a file repository. Different branches are used to isolate different development tasks to avoid affecting the main process of a project when developing new features for a project. The branch information includes the branch identifier of the target branch. The target branch can be found through the branch identifier. The target branch is a development area provided in the file repository for developing or modifying the code in the first file. The file identifier is a unique identifier for marking the first file. Since the scanning object of the security scanning tool may be multiple files in the file repository, in order to identify the file with a vulnerability, the file identifier of the file to which the vulnerability belongs is recorded after the vulnerability is identified, so as to facilitate subsequent extraction of the code in the first file. The target line is the specific location of the vulnerability area in the first file. For example, a vulnerability appears in the i+1th line of the first file, and i can be 0 or any positive integer.

[0034] The second file is the result of fixing the vulnerability in the first file by analyzing the vulnerability information. The second file can be the result of manual adjustment or the result of the first model output; the first model can be a large language model with deep learning capabilities, which can obtain a repair file that meets the requirements based on the prompt information.

[0035] However, no matter the second file is the result of manual repair or the result of repair by the first model, in order to ensure its security and availability, the repair effect of the second file needs to be verified to avoid new problems or incomplete repair.

[0036] In step S202, the difference between the first file and the second file is determined.

[0037] The second file is the result of repairing the vulnerability based on the first file, so the second file will have different codes from the first file at least in the vulnerability area. Therefore, it is necessary to identify the difference between the first file and the second file.

[0038] In step S203, a comprehensive score of the second file is determined based on the vulnerability information and the difference portion.

[0039] The comprehensive score represents the processing effect of the second file on the vulnerability. The higher the comprehensive score, the better the processing effect of the second file on the vulnerability. On the contrary, it means that the second file may not completely solve the vulnerability problem, or the second file has new vulnerabilities that the first file does not have.

[0040] A second model may be used to determine the comprehensive score of the second file. The second model may be a large language model, which can obtain a comprehensive score and a scoring reason that conforms to the scoring rules according to the prompt information. The scoring reason is the reason why the second file obtains the comprehensive score, such as the difference part is less related to the vulnerability. The second model may be the first model.

[0041] The scoring rules can be: if the difference part is an unnecessary change that is not related to the vulnerability, then the comprehensive score is 0; if there is a part in the difference part that solves some vulnerability problems, but unnecessary changes are still made to some codes that are not related to the vulnerability, then the comprehensive score is 1; if the difference part solves most of the vulnerability problems, but there are still a small number of vulnerability problems to be solved, then the comprehensive score is 2; if the difference part solves all vulnerability problems and does not adjust the code in the non-vulnerability area, and the code function and code format of the second file are the same as the first type, then the comprehensive score is 3.

[0042] In step S204, when the comprehensive score is greater than the score threshold, the second file is determined to be the target file.

[0043] The score threshold is the lower limit of the comprehensive score allowed for the target file. Referring to the previous example, 1 can be used as the score threshold. When the comprehensive score is greater than 1, the corresponding second file can be used as the target file. That is, the second file with a comprehensive score of 2 or 3 can be the target file, while the second file with a comprehensive score of 0 or 1 cannot be used as the target file.

[0044] The target file has the same configuration as the first file and does not have a vulnerability. The configuration includes code functions and code formats. For example, if the code in the first file can implement function 1 after being run, then the second file after the vulnerability is fixed should also implement function 1 after being run, and the code format should be the same. The first file cannot be completely reset when fixing the vulnerability.

[0045] Vulnerability repair method M200 scores the second file after repair and selects the second file with a score greater than a threshold as the target file, thereby avoiding new vulnerabilities caused during the repair process and incomplete vulnerability repairs; at the same time, it verifies the similarity in configuration between the second file and the first file, ensuring its availability.

[0046] Figure 3 This is a schematic diagram of the vulnerability repair method architecture according to the embodiment of the present disclosure. Figure 3 The idea and specific implementation process of the vulnerability repair method are explained.

[0047] After R&D personnel use the code editor to write and submit the code, the code is organized into one or more files and stored in the file repository. The code is actually the program text used to implement specific functions or solve specific problems. The file repository contains different branches to manage the files involved in different development threads. After generating multiple files about the written code, the security scanning tool will be triggered to identify security vulnerabilities in these files. The security scanning tool can check multiple files related to the newly written code or all files in the file repository that belong to the same project as these codes. When the security scanning tool scans any file and finds a vulnerability, the file is the first file.

[0048] When the security scanning tool scans a file, it may find multiple vulnerabilities and obtain corresponding multiple vulnerability information. Then, these vulnerability information are recorded in the Kafka message queue and processed one by one according to the queue order. The following describes the vulnerability repair method by taking the vulnerability information at the top of the queue as the object to be processed.

[0049] Figure 4 This is a schematic diagram of the second file acquisition process according to an embodiment of the present disclosure. Figure 4 The process of obtaining vulnerability information, generating first prompt information, and then outputting the second file by the first model is described in more detail.

[0050] The obtained vulnerability information includes vulnerability type, vulnerability description, file repository address, branch information, file identifier, target line, etc. In addition, the security scanning tool will also provide the address of the case collection, which contains the repair code and repair suggestions for various vulnerability types.

[0051] The case set is found through the address of the case set. Then, the associated case corresponding to the target vulnerability type is found in the case set. The associated case shows the repair code and repair suggestion for the target vulnerability type. The associated case provides a general repair solution for the vulnerability repair process.

[0052] The file repository that records the vulnerability is located through the file repository address. Then, according to the branch identifier in the branch information, the target branch of the file corresponding to the vulnerability is located. Furthermore, according to the file identifier, the first file with the vulnerability and the first complete code of the first file are found.

[0053] In order to improve the processing speed of the first model, the character length of the part to be repaired input to the first model is restricted. When the character length of the part to be repaired is less than or equal to the length threshold, the processing efficiency of the first model is the highest and the accuracy is the highest. Therefore, it is necessary to determine whether the character length of the first complete code is greater than the length threshold. If the character length of the first complete code is less than or equal to the length threshold, the first complete code can be used as the part to be processed to maximize the integrity of the vulnerability context. However, if the character length of the first complete code is greater than the length threshold, the vulnerability area with the vulnerability in the first complete code is determined according to the target line. In addition, the first code fragment containing the vulnerability area is determined using a code parsing tool. The code parsing tool can parse the code syntax and has the ability to extract the first code fragment containing the complete logic and the vulnerability area from the first complete code; wherein the complete logic indicates that the functions implemented by the code block and the semantics expressed are complete. Finally, the first code fragment is used as the part to be processed.

[0054] Generate the first prompt information including the associated case, the target vulnerability type and vulnerability description in the vulnerability information, and the part to be processed. The first prompt information can be written as:

[0055] “~~~

[0056] You are an AI engineer fixing code with an open redirect vulnerability of type {{title}}.

[0057] The description is as follows:

[0058] {{bug_message}}

[0059] Related cases to fix this type of vulnerability are:

[0060] {{suggestion}}

[0061] Please modify the section below to fix the preceding vulnerability. Output the entire code block with the appropriate changes. Do not remove sections of the code that are not relevant to the vulnerability fix.

[0062] Parts to be repaired:

[0063] {{code_markdown}}

[0064] rule:

[0065] Pay attention to indentation! ! ! Make sure the output code is indented the same as the input code. Do not add extra blank lines. Optimize the code format.

[0066] Clean code should be written.

[0067] Do not use methods that may have security vulnerabilities.

[0068] The new code to be output should start with '~~~' and end with '~~~'. Write the new code according to the input code structure.

[0069] ~~~”

[0070] Among them, title is the title of the first prompt information; bug_message is the vulnerability description; suggestion is the specific repair suggestion and repair code of the associated case, which provides a reference for the first model; code_markdown is the code of the part to be repaired, and the part to be repaired is in markdown format. In addition, the output rules for the second file are also proposed in the first prompt information. These rules can be set according to the configuration requirements of the second file. The previous example only provides several rules for reference, and any rules fall within the protection scope of this disclosure.

[0071] Furthermore, the first prompt information is input into the first model, and the first model repairs the part to be repaired by referring to the repair suggestions and repair codes of the associated cases, as well as the rules and other contents, and outputs the second file. Of course, if the input part to be repaired is the first complete code, then the result after the repair is the second complete code of the second file. If the input part to be repaired is the first code fragment, then the second code fragment is obtained after the repair, and then the second code fragment is spliced ​​to the corresponding position of the first file to obtain the second complete code of the second file; the splicing process can be realized by configuring the corresponding rules to control the first model. Compared with manual repair, it reduces the knowledge reserve requirements for R&D personnel and improves the repair efficiency.

[0072] However, no matter it is manual repair or the first model repair, the obtained results may have the problem of incomplete repair or introduction of new vulnerabilities. In order to ensure the effect and usability of the repair, the second file needs to be scored.

[0073] Figure 5 FIG. 1 is a schematic diagram of a comprehensive score acquisition process according to an embodiment of the present disclosure. Figure 5 As shown, the process of obtaining the comprehensive score of the second file is described below.

[0074] Identify the difference between the first file and the second file. For example, if the i+1th line of code in the first file is A2, and after repair, the i+1th line of code in the second file becomes B2, while the codes of the remaining lines remain unchanged, then A2 and B2 are the difference.

[0075] Combine the vulnerability information and the difference part to determine the second prompt information. The second prompt information is the scoring requirement for the second model. The second prompt information may include the difference part, the target vulnerability type and vulnerability description in the vulnerability information, and the associated case. The method for obtaining the associated case can refer to the above and will not be repeated. The second prompt information can be expressed as:

[0076] "Please verify the code output by the first model, which has an open redirect vulnerability with the title {{title}}

[0077] The description is as follows:

[0078] {{bug_message}}

[0079] Related cases to fix this type of vulnerability are:

[0080] {{suggestion}}

[0081] The task is to generate a comprehensive score for the difference parts. The scoring rules are:

[0082] If the diff contains changes that are not relevant to the vulnerability and are unnecessary, the score is 0 (strong rejection).

[0083] If the diff contains some correct fixes but still unnecessarily modifies irrelevant code, it is scored as 1 (weak rejection).

[0084] If the difference is mostly fixed correctly but there is still room for improvement, the score is 2 (weakly accepted).

[0085] If the diff only fixes the vulnerability and has the same configuration as the original input code, the score is 3 (strong acceptance).

[0086] If you find that the addition or removal of code snippets is not relevant to the vulnerability, you can clearly rate it 0 (strongly reject). Of course, in very specific cases, if you can be sure that these additions or removals do not change the functional correctness of the code, you can make exceptions.

[0087] Only the scoring reasons and comprehensive scores of the differences below are output.

[0088] Differences {{diff_patch}}

[0089] Returns in json format. For example: {"score:1","reason":"reason"}".

[0090] The second prompt information includes vulnerability type, vulnerability description, related cases, scoring rules, and the difference part and its format. Further, the second prompt information is provided to the second model, and the second model scores the second file. The first model and the second model can be the same large language model, or different large language models can be used respectively. The second model determines the degree of association between the difference part and the vulnerability type and related cases based on the second prompt information; determines the similarity between the configuration of the second file and the configuration of the first file; and determines the comprehensive score of the second file based on the degree of association and similarity, and the comprehensive score is proportional to the degree of association and similarity.

[0091] If the comprehensive score of the second file is less than or equal to the score threshold, it means that the second file has not achieved the expected repair effect, has not solved the vulnerability, or has only solved a small part of the vulnerability; or, the code unrelated to the vulnerability has been adjusted so that the second file has a different configuration from the first file (for example, the code of the first file is used to implement function M, and the code of the second file is used to implement function N, etc.); or, after solving the vulnerability, the second file introduces a new vulnerability. In short, if the comprehensive score of the second file is less than or equal to the score threshold, the scoring reason for the second file is fed back to the first model, and the first model is controlled to generate a new second file in combination with the scoring reason and the first prompt information. Then the new second file is scored until the comprehensive score of the new second file is greater than the score threshold. The score threshold can be set according to demand. For example, the score threshold is set to 1. Then when the comprehensive score is 2 or 3, the second file can be used as the target file. When the comprehensive score is 0 or 1, the first model needs to be controlled to regenerate the second file. Of course, the score threshold and the scoring rules of the comprehensive score can be adjusted according to actual needs, and are not limited to the above.

[0092] If the comprehensive score of the second file is greater than the score threshold, it means that the second file has a good repair effect, at least solves most of the vulnerabilities and has the same configuration as the first file (i.e., has the same code function and the same code structure), and does not cause new problems. At this time, the second file is used as the target file and pushed to the code encoder through the first plug-in.

[0093] In the present disclosure, a first plug-in is also configured for the code editor. The code editor is a tool for R&D personnel to edit and repair code. In the related art, R&D personnel are required to manually repair the vulnerability area in the first file. However, the present disclosure configures a first plug-in for the code editor, which can directly push the target file and the difference part to the code editor, and highlight the difference part between the first file and the target file to prompt the R&D personnel the modified location and content in the target file. After the R&D personnel confirms, the position corresponding to the difference part in the first file is directly replaced, which improves the repair efficiency of the R&D personnel and simplifies the repair process.

[0094] Figure 6 FIG. 4 is a diagram showing a difference portion displayed by a code editor according to an embodiment of the present disclosure.

[0095] refer to Figure 6 , is a display diagram of the first plug-in pushing the target file and the difference part to the code editor page. The first file originally edited by the code editor is displayed on the left side of the page, and the target file is displayed on the right side of the page. The difference between the two is highlighted with color, which can be gray or other colors without restriction. For example, the i-th line of code in the first file is A1, and the i-th line of code in the second file is A1. Obviously, there is no difference between the two for the i-th line of code; similarly, the i+2th line of code is A3, and there is no difference between the two. However, in the i+1th code, the first file is A2 and the second file is B2, and there is a difference between the two. Then A2 and B2 are the difference between the two, and both are highlighted. In addition, a "<<" mark is set between the i+1th line of the first file and the second file, indicating "confirm replacement". When the R&D personnel confirm that there is no problem with the content of the i+1th line of code in the second file and that the vulnerability can be solved, they can click the "<<" mark to replace A2 in the i+1th line of code in the first file with B2. After confirming the replacement of all the different parts, the first file becomes the target file, completing the repair of the vulnerability and the multi-level review of the repair results, thereby minimizing the possibility of new vulnerabilities in new files or incomplete repairs. At the same time, it reduces the requirements for R&D personnel's repair capabilities and improves repair efficiency.

[0096] The vulnerability repair method disclosed in the present invention configures rich first prompt information for the first model according to the vulnerability information, controls the first model (large language model) to process the first prompt information, obtains the second file, avoids the requirement for the developer to reserve security repair knowledge, and improves the efficiency of repairing vulnerabilities. In addition, the second file is scored by the second model (the same or another large language model), which ensures that the final target file has the same configuration as the first file and can solve all or most of the vulnerabilities, avoiding the situation where the vulnerability is not completely solved or a new vulnerability is introduced.

[0097] Figure 7 It is a schematic block diagram of the structure of a vulnerability repair device according to an embodiment of the present disclosure.

[0098] like Figure 7 As shown, the vulnerability repair device 700 includes: a second file acquisition module 710, which is used to analyze the vulnerability information of the first file to obtain the second file, the vulnerability information is used to describe the vulnerability in the first file, and the second file is the repair result of the vulnerability; a difference identification module 720, which is used to determine the difference between the first file and the second file; a scoring module 730, which is used to determine the comprehensive score of the second file according to the vulnerability information and the difference, and the comprehensive score represents the processing effect of the second file on the vulnerability; and a target file determination module 740, which is used to determine that the second file is a target file when the comprehensive score is greater than the score threshold, the target file has the same configuration as the first file and the target file does not have a vulnerability, and the configuration includes code function and code format.

[0099] In some embodiments, the execution steps of the second file acquisition module 710 include: generating first prompt information for the first model based on the vulnerability information, the first model can repair the vulnerability of the first file, and the first prompt information provides repair requirements for the first model; and controlling the first model to process the first file according to the first prompt information to obtain the second file.

[0100] Specifically, based on the vulnerability information, first prompt information for the first model is generated, including: based on the vulnerability location information in the vulnerability information, determining the part to be repaired of the first file, the part to be repaired is the first complete code of the first file or the first code fragment with a vulnerability; based on the target vulnerability type in the vulnerability information, searching for associated cases corresponding to the target vulnerability type in the case collection, the case collection includes repair codes and repair suggestions for multiple vulnerability types, and the associated cases are repair codes and repair suggestions for the target vulnerability type; constructing the first prompt information including the vulnerability type, the vulnerability description in the vulnerability information, the associated cases and the part to be repaired, the first prompt information can trigger the first model to repair the vulnerability.

[0101] More specifically, according to the vulnerability location information in the vulnerability information, determining the part to be repaired of the first file, including: determining the file repository recording the first file according to the file repository address in the vulnerability location information; determining a first complete code corresponding to the file identifier in the file repository according to the target branch and file identifier in the vulnerability location information, the first complete code being the file content of the first file, and the file identifier being used to mark the first file; and when the character length of the first complete code is less than a length threshold, using the first complete code as the part to be repaired.

[0102] More specifically, when the character length of the first complete code is greater than or equal to a length threshold, the vulnerability area is determined in the first complete code according to the target line in the vulnerability location information; and a first code fragment containing the vulnerability area is determined using a code parsing tool, and the first code fragment is used as the part to be repaired. The first code fragment is a part of the first complete code that has complete logic and contains the vulnerability area.

[0103] In some embodiments, the execution steps of the scoring module 730 include: determining second prompt information for the second model based on the vulnerability information and the difference part, the second model can determine the comprehensive score of the second file, the second prompt information provides scoring requirements for the second model, the second prompt information includes the vulnerability type and vulnerability description in the vulnerability information, the associated cases corresponding to the vulnerability type, and the difference part; and controlling the second model to analyze the second file according to the second prompt information to obtain a comprehensive score.

[0104] In some embodiments, the execution steps of the scoring module 730 also include: determining the degree of association between the difference part and the vulnerability type and the related case; determining the similarity between the configuration of the second file and the configuration of the first file; and determining a comprehensive score of the second file based on the degree of association and the similarity, wherein the comprehensive score is proportional to the degree of association and the similarity.

[0105] In some embodiments, the scoring module 730 is also used to: generate a scoring reason for the second file when the comprehensive score is less than or equal to the score threshold; and synchronize the scoring reason and the first prompt information to the first model to control the first model to generate a new second file.

[0106] In some embodiments, a plug-in configuration module (not shown) is further included, which is used to configure the first plug-in in the code editor. The code editor is a tool for editing the first file, and the first plug-in is a component that pushes the target file to the code editor.

[0107] In some embodiments, the plug-in configuration module is also used to synchronize the target file and the difference part to the code editor through the first plug-in, in which the difference part is highlighted in both the target file and the first file; and in response to a confirmation instruction for the target file, replace the first file with the target file.

[0108] The vulnerability repairing device 700 may be in the form of computer software, and the above-mentioned modules may be in the form of software modules.

[0109] The various modules of the vulnerability repair device 700 are configured to implement the various steps of the vulnerability repair method. The execution principles and specific steps thereof can be referred to in the previous text and will not be described in detail.

[0110] Figure 8FIG. 1 is a schematic block diagram of the structure of an electronic device according to an embodiment of the present disclosure. Figure 8 As shown, the present disclosure also provides an electronic device 1000, including: a memory 1200 and a memory 1300, the memory 1300 stores execution instructions; the processor 1200 executes the execution instructions stored in the memory 1300, so that the processor 1200 executes the vulnerability repair method.

[0111] The hardware structure of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnected buses and bridges, depending on the specific application and overall design constraints of the hardware. The bus 1100 connects various circuits including one or more processors 1200, memory 1300 and / or hardware modules together. The bus 1100 can also connect various other circuits 1400 such as peripherals, voltage regulators, power management circuits, external antennas, etc.

[0112] The bus 1100 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the figure only uses one connecting line, but does not mean that there is only one bus or one type of bus.

[0113] The present disclosure also provides a readable storage medium, in which a computer program is stored, and the computer program is used to implement the above method when executed by a processor. "Readable storage medium" can be any device that can contain, store, communicate, propagate or transmit a program for use in an instruction execution system, device or equipment or in combination with these instruction execution systems, devices or equipment. More specific examples of readable storage media include the following: an electrical connection portion (electronic device) with one or more wirings, a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and editable read-only memory (EPROM or flash memory), an optical fiber device, and a portable read-only memory (CDROM), etc.

[0114] The present disclosure also provides a computer program product. The method of the present disclosure can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed, the process or function of the present disclosure is executed in whole or in part.

[0115] The computer program or instructions may be stored in a readable storage medium or transmitted from one readable storage medium to another readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The readable storage medium may be any available medium that can be accessed or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid state drive. The computer readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0116] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, electronic devices, readable storage media, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0118] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0119] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0120] In the description of this specification, the description with reference to the terms "one embodiment / method", "some embodiments / methods", "example", "specific example", or "some examples" etc. means that the specific features, structures, or characteristics described in conjunction with the embodiment / method or example are included in at least one embodiment / method or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment / method or example. Moreover, the specific features, structures, or characteristics described may be combined in any one or more embodiments / methods or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments / methods or examples described in this specification and features of different embodiments / methods or examples, unless they are contradictory.

[0121] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of the present disclosure, "plurality" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0122] Those skilled in the art should understand that the above embodiments are only for the purpose of clearly illustrating the present disclosure, and are not intended to limit the scope of the present disclosure. For those skilled in the art, other changes or modifications may be made based on the above disclosure, and these changes or modifications are still within the scope of the present disclosure.

Claims

1. A vulnerability repair method, characterized in that: include: Analyze vulnerability information of a first file to obtain a second file, wherein the vulnerability information is used to describe the vulnerability in the first file, and the second file is a repair result of the vulnerability; determining differences between the first file and the second file; Determine a comprehensive score of the second file according to the vulnerability information and the difference, wherein the comprehensive score represents an effect of the second file on the vulnerability; as well as When the comprehensive score is greater than the score threshold, the second file is determined to be a target file, the target file has the same configuration as the first file and the target file does not have the vulnerability, the configuration including code function and code format.

2. The vulnerability repair method according to claim 1, characterized in that: Analyze the vulnerability information of the first file to obtain the second file, including: generating first prompt information for a first model according to the vulnerability information, wherein the first model can repair the vulnerability of the first file, and the first prompt information provides a repair requirement for the first model; and Control the first model to process the first file according to the first prompt information to obtain the second file.

3. The vulnerability repair method according to claim 2, characterized in that: Generating first prompt information for a first model according to the vulnerability information includes: Determine, according to the vulnerability location information in the vulnerability information, a portion of the first file to be repaired, where the portion to be repaired is a first complete code of the first file or a first code fragment having the vulnerability; According to the target vulnerability type in the vulnerability information, searching for an associated case corresponding to the target vulnerability type in a case collection, the case collection including repair codes and repair suggestions for multiple vulnerability types, and the associated case being the repair code and repair suggestion for the target vulnerability type; Constructing first prompt information including the vulnerability type, the vulnerability description in the vulnerability information, the associated case and the part to be repaired, wherein the first prompt information can trigger the first model to repair the vulnerability.

4. The vulnerability repair method according to claim 3, characterized in that: Determining the part of the first file to be repaired according to the vulnerability location information in the vulnerability information includes: Determine, according to the file repository address in the vulnerability location information, a file repository recording the first file; Determine, in the file repository, according to the target branch and the file identifier in the vulnerability location information, a first complete code corresponding to the file identifier, wherein the first complete code is the file content of the first file, and the file identifier is used to mark the first file; and When the character length of the first complete code is less than a length threshold, the first complete code is used as the part to be repaired.

5. The vulnerability repair method according to claim 4, characterized in that: After determining the first complete code corresponding to the file identifier in the file repository, the method further includes: When the character length of the first complete code is greater than or equal to a length threshold, determining a vulnerability area in the first complete code according to a target row in the vulnerability location information; and A code parsing tool is used to determine a first code fragment containing the vulnerability area, and the first code fragment is used as the part to be repaired. The first code fragment is a part of the first complete code that has complete logic and contains the vulnerability area.

6. The vulnerability repair method according to claim 1, characterized in that: Determining a comprehensive score of the second file according to the vulnerability information and the difference portion includes: Determine second prompt information for a second model according to the vulnerability information and the difference, the second model being capable of determining a comprehensive score of the second file, the second prompt information providing a scoring requirement for the second model, the second prompt information including a vulnerability type and a vulnerability description in the vulnerability information, an associated case corresponding to the vulnerability type, and the difference; and Control the second model to analyze the second file according to the second prompt information to obtain the comprehensive score.

7. The vulnerability repair method according to claim 6, characterized in that: Controlling the second model to analyze the second file according to the second prompt information to obtain the comprehensive score includes: Determine the degree of correlation between the difference part and the vulnerability type and the related case; determining a similarity between a configuration of the second file and a configuration of the first file; A comprehensive score of the second file is determined according to the association degree and the similarity, wherein the comprehensive score is proportional to the association degree and the similarity.

8. The vulnerability repair method according to claim 2, characterized in that: After determining the comprehensive score of the second document, it also includes: If the comprehensive score is less than or equal to the score threshold, generating a scoring reason for the second file; and The scoring reason and the first prompt information are synchronized to the first model, and the first model is controlled to generate a new second file.

9. The vulnerability repair method according to claim 1, characterized in that: Also includes: A first plug-in is configured in a code editor, where the code editor is a tool for editing the first file, and the first plug-in is a component for pushing the target file to the code editor.

10. The vulnerability repair method according to claim 9, characterized in that: After determining that the second file is a target file, the method includes: Synchronizing the target file and the difference portion to the code editor through the first plug-in, wherein the difference portion is highlighted in both the target file and the first file in the code editor; and In response to a confirmation instruction for the target file, the first file is replaced with the target file.

11. An electronic device, characterized in that: include: A memory storing execution instructions; as well as A processor, wherein the processor executes the execution instruction stored in the memory, so that the processor executes the vulnerability repair method according to any one of claims 1 to 10.

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the vulnerability repair method according to any one of claims 1 to 10 is implemented.

Images