Security vulnerability test report generation method and system and electronic equipment

Abstract

The invention relates to the technical field of data processing, and provides a security vulnerability test report generation method and system and electronic device.The method comprises the steps that vulnerability records in a test record document input by a user are analyzed, a vulnerability dictionary is created based on the vulnerability records, and a first vulnerability dictionary list is generated; scanning the first vulnerability dictionary list, and determining filled fields and non-filled fields corresponding to each vulnerability record; according to the content of the filled field, constructing a first cue word used for generating the supplementary content of the non-filled field, and calling a first large language model based on the first cue word to obtain first model output; based on the first model output, performing content supplement on the unfilled fields to obtain a second vulnerability dictionary list; and filling the content in the second vulnerability dictionary list into a preset report template to obtain the security vulnerability test report, thereby improving the processing efficiency of the test report.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method, system and electronic device for generating a security vulnerability test report. Background Art

[0002] In the field of system security testing, the generation and management of vulnerability reports has become an important part of the enterprise security protection system.

[0003] In the existing technology, security engineers mainly rely on manually writing reports using office software such as Word. This method is highly flexible but extremely inefficient. The generation cycle of a single report is long and there are problems such as a high content error rate. Even though there are some automated tools that can assist in completing reports, such as MailMerge, the content of the report still relies on manual filling. Summary of the invention

[0004] In order to improve the processing efficiency of test reports, an embodiment of the present application provides a method for generating a security vulnerability test report, the method comprising the steps of: parsing vulnerability records in a test record document input by a user, creating a vulnerability dictionary based on the vulnerability records, and generating a first vulnerability dictionary list; wherein the test record document is in markdown format, and the parsing of the vulnerability records in the test record document input by the user includes extracting test codes based on a regular expression engine and semantic understanding; scanning the first vulnerability dictionary list to determine filled fields and unfilled fields corresponding to each vulnerability record; constructing a first prompt word for generating supplementary content for the unfilled field based on the content of the filled field, and calling a first large language model based on the first prompt word to obtain a first model output; wherein the content of the filled field includes at least a test code and a test result; supplementing the unfilled field with content based on the first model output to obtain a second vulnerability dictionary list; and filling the content in the second vulnerability dictionary list into a preset report template to obtain a security vulnerability test report.

[0005] Based on the above technical solution, testers only need to provide a test record document containing at least the test code and test results. The system can then complete other unfilled fields based on the content of the filled fields, and directly generate a security vulnerability test report that meets the format requirements based on the preset report template, greatly improving the efficiency of writing test reports. At the same time, by parsing the test record document in markdown format to build a vulnerability dictionary, it is possible to convert unstructured text into a standardized dictionary list containing complete vulnerability attributes (threat level, description, test process, etc.), providing high-quality data input for subsequent processing.

[0006] In one implementation, constructing the first prompt word for generating supplementary content for the unfilled field based on the content of the filled field includes: calling a code library to analyze the test code to obtain an analysis text; verifying the correctness of the content of other filled fields based on the analysis text; and if the correctness verification passes, constructing the first prompt word based on the analysis text and the content of the other filled fields.

[0007] Based on the above technical solution, by analyzing the test code to obtain the analysis text, the content of other filled fields can be verified according to the analysis text. This can not only realize automatic verification of the accuracy of manually input content and timely discover problems in manual output, but also ensure the accuracy of the information in the constructed first prompt word, thereby ensuring the validity of the supplementary content obtained based on the first model output.

[0008] In one implementation, the method also includes: performing analysis based on the second vulnerability dictionary list to determine whether there is a test coverage gap; if there is a test coverage gap, constructing supplementary test code for the test coverage gap, and performing supplementary testing based on the supplementary test code to obtain supplementary test results; if the supplementary test results show that there is a vulnerability risk, generating a new vulnerability record based on the supplementary test code and the supplementary test results, and recording it in the second vulnerability dictionary.

[0009] Based on the above technical solution, the test coverage gaps can be automatically improved. On the one hand, it can assist in completing the missed test items, and on the other hand, it can realize the active identification of vulnerability risks and improve the second vulnerability dictionary, thereby improving the test report content.

[0010] In one implementation, the test code extraction based on the regular expression engine and semantic understanding includes: scanning the vulnerability records in the test record document through the regular expression engine, identifying and locating the boundary identifier of the code snippet through the pattern matching rule, and after locating the code snippet, performing lexical analysis and syntax parsing on the code snippet, constructing an abstract syntax tree to identify the variable scope and function call chain, thereby locating the boundary of the test code.

[0011] Based on the above technical solution, the test code boundary can be accurately located by combining the regular expression engine and semantic understanding, so as to accurately extract the complete test code and provide a good data foundation for subsequent processing.

[0012] In one implementation, filling the vulnerability records in the second vulnerability dictionary list into a preset report template to obtain a security vulnerability test report includes: determining a first target filling position based on a first preset placeholder in the preset report template; and filling the vulnerability records into the first target filling position.

[0013] In one implementation, the method further includes: acquiring test target information; determining a second target filling position based on a second preset placeholder in the preset report template; and filling the test target information into the second target filling position.

[0014] Based on the above technical solution, the filling positions of vulnerability records and test target information are limited by presetting placeholders, so that structured filling of report content can be achieved.

[0015] In one implementation, the method further includes: adjusting the content format of the security vulnerability test report based on a preset format requirement.

[0016] Another embodiment of the present application provides a security vulnerability test report generation system for implementing the above method.

[0017] In addition, an embodiment of the present application also provides an electronic device, which includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, and the program or instruction implements the above method when executed by the processor.

[0018] The embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the above method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings constituting a part of the present application are used to provide further understanding of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute improper limitations on the present application.

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1A A schematic diagram of the structure of a security vulnerability test report generation system provided in an embodiment of the present application is shown.

[0022] Figure 1B A schematic diagram of the structure of the server provided in the embodiment of the present application is shown.

[0023] Figure 2 A flow chart of a method for generating a security vulnerability test report provided by an embodiment of the present application is shown.

[0024] Figure 3 A flow chart of a method for constructing a first prompt word in an embodiment of the present application is shown.

[0025] Figure 4 A flow chart of a method for generating a security vulnerability test report provided by another embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, and "first", "second" and various digital numbers are only distinguished for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0028] The features, structures or characteristics in this application may be combined in one or more embodiments in any suitable manner. In various embodiments of this application, the size of the sequence number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0029] Some optional features in the embodiments of the present application may be implemented independently in some scenarios without relying on other features to solve corresponding technical problems and achieve corresponding effects. They may also be combined with other features in some scenarios as needed.

[0030] In this application, unless otherwise specified, the same or similar parts between the various embodiments can refer to each other. In the various embodiments of this application, if there is no special description and logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships. The implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0031] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0032] The present application embodiment provides a method for generating a security vulnerability test report. The tester only needs to provide a Markdown (hereinafter referred to as MD) file containing the necessary test record content to automatically assist in generating a complete test report. The method is implemented based on the security vulnerability test report system. Please refer to Figure 1A The security vulnerability test report generation system 100 includes a client 110 and a server 120 .

[0033] In implementation, the client 110 can be implemented based on a web page or application program, and can obtain the test record document, report template, format requirements and test target information uploaded by the user by providing an input interface. Among them, the test record document is an MD document, which records vulnerability information, including but not limited to test code, test results, links and other information that can truly record the test process; the report template can be determined based on the user's selection from the target options provided by the system, or it can be uploaded by the user on his own; the format requirements can be selected by the user from the options provided by the system according to the report requirements, or it can be determined based on the relevant parameters actively set by the user; the test target information includes the name of the system under test, the test scope, unit information, test time, test personnel and other basic information related to the test project.

[0034] Please refer to Figure 1B The server 120 includes a document reading module 121, a content supplementing module 122, a template filling module 123 and a report generating module 124. The document reading module 121 is used to read the vulnerability information recorded in the MD document and record it in a preset data structure; the content supplementing module 122 is used to supplement the incomplete content in the structure data; the template filling module 123 is used to fill the complete structure data and test target information into the report template; the report generating module 124 is used to adjust the format of the filled report template and output the test report.

[0035] In one implementation, please refer to Figure 2 The security vulnerability test report generation method based on the above system implementation specifically includes the following steps.

[0036] S210, parsing vulnerability records in the test record document input by the user, creating a vulnerability dictionary based on the vulnerability records, and generating a first vulnerability dictionary list.

[0037] The test record document is in markdown format.

[0038] In one implementation, the tester fills in at least one vulnerability record in the MD document according to the fixed syntax of the MD document. In one example, the vulnerability record includes vulnerability name, risk description, test module, test address, test process, risk analysis, rectification opinion fields, etc., wherein the test process includes test code and test results. It is understandable that different test reports have different requirements for content, so the fields included in the vulnerability record are also different. That is to say, in the actual application process, the fields included in the vulnerability record can be adjusted according to actual needs.

[0039] The document reading module can implement structured parsing of the MD document content based on the regular expression engine, thereby extracting the content of each field. When the content of the test code field is identified, the three backquotes can be first identified based on the regular expression engine, and the corresponding code block content can be extracted. At the same time, in order to avoid misidentification, it can be further combined with semantic analysis to determine the meaning of the characters appearing before and after the code block to clarify the boundaries of the code block, thereby achieving accurate extraction.

[0040] In implementation, a regular expression engine refers to a processor that matches text patterns using predefined grammar rules, and can be implemented using a PCRE library or a RE2 library to quickly locate the start and end tags of each field in an MD document, where the start and end tags can be determined based on the syntax of the MD document.

[0041] In order to achieve accurate extraction of code blocks, when the code block fields are identified based on the start tag, the code context logic can be further parsed in combination with semantic understanding. Specifically, this can be achieved by using an abstract syntax tree generator or a control flow analyzer to identify deep semantic features such as variable definitions and function call relationships.

[0042] Specifically, the vulnerability records in the test record document are initially scanned by the regular expression engine, and the boundary identifiers of the code blocks are identified through pattern matching rules, such as the three backquote syntax structures. After locating the code snippet, the code is lexically analyzed and parsed, and an abstract syntax tree is constructed to identify logical relationships such as variable scope and function call chain, so as to accurately locate the boundaries of the code blocks.

[0043] Based on this, the regular expression engine and semantic understanding form a collaborative working mechanism. The former ensures the coverage of code block positioning, and the latter verifies the validity of the code structure. The combination of the two can achieve accurate identification of nested code and multi-language mixed code, thereby realizing accurate extraction of test code.

[0044] In the implementation of this application, a vulnerability dictionary is created for each extracted vulnerability record, and each vulnerability dictionary is stored in the first vulnerability dictionary list. Among them, the vulnerability dictionary is implemented based on the built-in dictionary structure of Python, and the data structure of the vulnerability record is stored in the form of key-value pairs. Specifically, it can be implemented through a JSON object, which is used to standardize the storage of various fields and contents in the vulnerability record.

[0045] S220, scanning the first vulnerability dictionary list to determine filled fields and unfilled fields corresponding to each vulnerability record.

[0046] In implementation, identification of filled fields and unfilled fields is achieved by traversing dictionary key values, for example, when a field value is detected to be empty or a placeholder, it is marked as an unfilled field.

[0047] S230: construct a first prompt word for generating supplementary content for the unfilled field according to the content of the filled field, and call a first large language model based on the first prompt word to obtain a first model output.

[0048] In implementation, the first prompt word may be automatically generated by converting the filled-in field content into a natural language query statement and according to a pre-built output requirement.

[0049] In one example, the first prompt word can be constructed based on some of the filled fields. For example, the filled field is the vulnerability name, and the fields to be supplemented include risk description, risk analysis, and repair suggestions. The first prompt word is constructed as follows: “You are a senior network security engineer. Please fill in the following fields according to the vulnerability name (in Chinese): Vulnerability name: {vuln['VulnerabilityName']}#Extract from the vulnerability dictionary Fields that need to be added: {','.join(fields_needed)}#Fields not filled in Build requirements: 1. The description must include the vulnerability principle, attack method, and impact scope 2. Risk analysis must include the possibility of data leakage, privilege escalation, etc. 3. Repair suggestions need to list specific protective measures in points 4. Use technical terms but keep it simple 5. The output format is pure JSON, containing only the fields that need to be supplemented" In another example, the test code and the test result may be analyzed first and converted into natural language, and then the first prompt word may be constructed. For example, when the test code and the test result are analyzed to determine that the test code is used for a SQL injection vulnerability, the test result is that the attack is successful, and the unfilled field is a repair plan, the first prompt word may include: "The code segment known to have a SQL injection vulnerability is as follows, and the test result shows that the attack is successful. Please generate a repair plan." In this way, the first prompt word may be constructed directly based on the analysis of the test code and the test result, which can avoid, to a certain extent, the problem of deviation in the first output result obtained due to errors in the manually filled text content.

[0050] In another example, to ensure the accuracy of the first prompt word, please refer to Figure 3 In the embodiment of the present application, the method for constructing the first prompt word according to the content of the filled field specifically includes the following steps.

[0051] S310, calling the code library to analyze the test code and outputting the analysis text.

[0052] In implementation, the test code is used to trigger the code segment of vulnerability detection, which can be implemented by Python script or Java unit test code, and its role is to provide executable input conditions for vulnerability testing.

[0053] The test result is the response data generated during the vulnerability detection process, which can be stored in JSON format to provide a basis for verifying the correctness of the test logic.

[0054] The code repository is a collection of resources that stores code analysis tools and rule sets. It can be implemented using SonarQube or Fortify static scanning tools to perform syntax checking and logical path analysis on test codes.

[0055] The analysis text is used to record the structured analysis results output by the code base. It can be recorded in XML or Markdown format to verify the logical consistency of the filled-in field content in the vulnerability record.

[0056] Specifically, after the test code is entered into the code base, the control flow and data flow information in the code is extracted through static scanning to determine the test targets contained in the test code. Then, the test targets are verified based on the test results, and the execution results corresponding to the test targets are determined. Based on the execution results, it is determined whether potential vulnerability points are included. Finally, an analysis text containing potential vulnerability points is generated.

[0057] For example, when the test code is a query request, the code library can identify whether there are special characters. Based on this, the test target can be determined to be the risk of unescaped input parameters. Then, based on the test results, it is determined whether the system has escaped or filtered the user input. If not, the potential risks corresponding to the text record are analyzed.

[0058] Based on this, the test code is directly analyzed to identify potential vulnerability points and record them in the analysis text.

[0059] S320, verifying the correctness of the contents of other filled fields based on the analyzed text.

[0060] In implementation, correctness verification includes matching the content recorded in the analysis text with the content of other filled-in fields, or implementing it by calling a large language model to identify whether there is a contradiction between the analysis text and the content of other filled-in fields, thereby determining the correctness of the content of other filled-in fields to achieve automatic detection of manually input content.

[0061] In one example, semantic analysis can be used to determine whether the meaning of the content in the analysis text is consistent with the content of other filled fields. If consistent, it is determined that there is no contradiction and the correctness verification passes; otherwise, it is determined that there is a contradiction and the correctness verification fails.

[0062] In another example, the second largest language model can be called to analyze and verify the analysis text and the filled content of each other field, and determine whether there is a contradiction between the analysis text and the filled content of each other field according to the second model output of the second largest language model. The second largest language model can be a general model or a pre-trained expert model.

[0063] If the correctness verification passes, execute step S331; if the verification fails, execute step S332.

[0064] S331, constructing a first prompt word based on the analyzed text and other filled-in field contents.

[0065] In implementation, the first prompt word may be constructed based on the analyzed text and other filled-in field contents as known contents.

[0066] S332, outputting a manual confirmation interface to receive the user's confirmation results of other filled-in field contents and the analysis text, and selecting the analysis text or other filled-in field contents to construct a first prompt word according to the confirmation results.

[0067] During implementation, when the confirmation result is that the analysis text is inaccurate, the first prompt word is constructed based on the contents of other filled fields. When the confirmation result is that the contents of other filled fields are inaccurate, the first prompt word is constructed based on the analysis text. At the same time, according to the user's instructions, the contents of the filled fields with inaccurate contents can be automatically supplemented, that is, in the first prompt word, the field is output as an unfilled field.

[0068] Based on this, by directly analyzing the test code to obtain the corresponding analysis text, the content of other filled fields can be verified, thereby ensuring that the content provided in the first prompt word is accurate, thereby improving the accuracy of the first model output. At the same time, problems in the manually input content can be corrected in a timely manner.

[0069] It is understandable that the generated content of the first prompt word can be adjusted according to actual needs, and is not limited thereto.

[0070] After the generation of the first prompt word is completed, the large language model can be accessed through the API interface to obtain the first model output. In the implementation of this application, the large language model can be an expert model obtained by pre-training the general model.

[0071] S240: Supplement the unfilled fields with content based on the first model output to obtain a second vulnerability dictionary list.

[0072] In implementation, after obtaining the first model output, the corresponding content can be added to the first vulnerability dictionary list, thereby obtaining a second vulnerability dictionary list with more complete content.

[0073] It is worth noting that in some application scenarios, the filled content can also be verified through the first model output obtained by the above steps, thereby further realizing automatic verification of manually filled content.

[0074] S250, filling the content in the second vulnerability dictionary list into a preset report template to obtain a security vulnerability test report.

[0075] In one implementation, a first preset placeholder may be provided in the preset report template for locating the content filling position. Thus, a first target filling position may be determined based on the first preset placeholder in the preset report template, and the vulnerability record may be filled into the first target filling position.

[0076] The first preset placeholder refers to a mark symbol or identifier pre-set in the preset report template. In one example, it can be implemented by using keywords or specific strings enclosed in square brackets, such as "[vulnerability number]" or "{{vulnerability level}}". Its function is to provide clear filling position guidance for the fields of the vulnerability record.

[0077] The first target filling position refers to the specific area located in the template by parsing the first preset placeholder, which can be achieved through a text matching algorithm or a placeholder parsing function of the template engine. For example, a regular expression is used to scan the template and extract the insertion point coordinates corresponding to the placeholder, thereby ensuring that each field in the vulnerability record can accurately correspond to the logical position in the template.

[0078] In a specific example, anchor positioning and XML operation technology can be used to achieve accurate content injection. By presetting a marked paragraph (such as "Test Result Details") in the Word template, the underlying XML interface of the python-docx library is used to dynamically insert elements such as hierarchical titles and vulnerability details. Since the placeholders correspond to the field names of the vulnerability records one by one, there is no need to manually identify the template structure during the filling process, avoiding field dislocation or format confusion caused by manual operation.

[0079] In another implementation, a second preset placeholder is further provided in the preset report template for determining a second target filling position, wherein the second target filling position is used to insert the test target information input by the user.

[0080] The second preset placeholder refers to an identifier predefined in the template for inserting standard information. Specifically, a specific symbol or label can be used to mark the position, such as "{{name of the system under test}}" or "##test time##". Based on this, a correspondence between the test target information and the template structure can be established to avoid incorrect information insertion positions.

[0081] The second target filling position refers to the specific area in the template where the target information needs to be inserted, which can be achieved by parsing the position coordinates or hierarchical relationship of the placeholder. The function of this feature is to ensure that the standard information can be accurately embedded according to the template format requirements.

[0082] In one example, when generating a security vulnerability test report, the system first extracts test target information from user configuration or external data sources, such as the name of the system being tested, the compliance standards applicable to the test, and the test time range. Next, the system parses the second preset placeholder in the report template, such as identifying the position of the "{{Compliance Standard}}" label, and determining the corresponding table or paragraph area as the second target fill position. Finally, the system fills the extracted target information into the specified position in sequence, such as filling "ISO 27001" into the compliance standard field, and filling "January-March 2024" into the test time field. Through this process, standard information does not need to be manually searched and copied and pasted, and is automatically associated with the template structure, which not only eliminates the risk of information omissions caused by manual operations, but also ensures the standardization of the report format.

[0083] After completing the filling of the template content, in order to achieve a unified setting of the report format, in some embodiments of the present application, before outputting the test report, the content format of the security vulnerability test report is also adjusted based on the preset format requirements.

[0084] The preset format requirements refer to a set of predefined document layout rules, which can be implemented using configuration files or template files to specify layout elements such as title levels, font styles, paragraph spacing, etc. The preset format requirements can ensure that the reports generated by different vulnerability records maintain uniformity in layout structure.

[0085] In implementation, adjusting the content format includes matching the text data in the vulnerability dictionary with preset format rules. In one example, this can be implemented using a document processing library or a typesetting engine to automatically apply preset fonts and paragraph styles to the target text location.

[0086] In this way, unified content format adjustment can eliminate format dislocation or style inconsistency caused by manual operation, and can adapt to different format adjustment needs. Users only need to set the preset format requirements to achieve unified adjustment of the report format.

[0087] During implementation, the output format of the test report can also be set to output a compliance report that can be delivered directly. For example, reports can be output in both PDF and Word formats to meet the document circulation and audit archiving requirements in different scenarios.

[0088] Based on the above technical solution, this application realizes the automatic conversion of test records to standard reports, reduces the complexity of manual processing through structured analysis, reduces the content error rate by using intelligent generation technology, and realizes the automatic filling of unfilled field contents. Automatic identification of unfilled fields avoids the waste of resources caused by full data processing, and the context-based prompt word construction ensures the technical relevance of the generated content to the test results. The combination of preset templates and dynamic filling mechanisms not only ensures the standardization of report formats, but also adapts to the content diversity requirements of different test scenarios.

[0089] In some implementations of the present application, in order to ensure the completeness of the test report content, the second vulnerability dictionary list is also supplemented.

[0090] Please refer to Figure 4 , a security vulnerability test report generation method provided in another embodiment of the present application specifically includes the following steps.

[0091] S410, parsing vulnerability records in a test record document input by a user, creating a vulnerability dictionary based on the vulnerability records, and generating a first vulnerability dictionary list.

[0092] S420, scanning the first vulnerability dictionary list to determine filled fields and unfilled fields corresponding to each vulnerability record.

[0093] S430: construct a first prompt word for generating supplementary content for the unfilled field according to the content of the filled field, and call a first language model based on the first prompt word to obtain a first model output.

[0094] S440: Supplement the unfilled fields with content based on the first model output to obtain a second vulnerability dictionary list.

[0095] S450, analyzing based on the second vulnerability dictionary list to determine whether there is a test coverage gap, if there is a test coverage gap, constructing supplementary test code for the test coverage gap, performing supplementary testing, and recording the supplementary test results in the second vulnerability dictionary.

[0096] In implementation, determining whether there are missing test items includes checking whether the test items corresponding to the test code in the second vulnerability dictionary cover all potential attack surfaces of the target system through a preset test case library or coverage analysis tool. This can be achieved by using AST abstract syntax tree analysis or interface coverage statistics methods to actively identify test coverage gaps.

[0097] When it is determined that there is a coverage gap, the corresponding detection script is automatically generated according to the type of missing test items. This can be achieved by using a template engine combined with a vulnerability pattern library. For example, a detection case containing a specific attack vector is generated for a SQL injection vulnerability, i.e., supplementary test code.

[0098] Then, the generated supplementary test code is injected into the automated test framework for verification. Specifically, it can be implemented using the test executor in the continuous integration tool chain, for example, by triggering the running of new test cases through Jenkins to obtain supplementary test results.

[0099] If the supplementary test result indicates that there is a vulnerability risk, a third prompt word is constructed based on the supplementary test code and the supplementary test result, and the third language model is called to obtain the supplementary content of other fields in the vulnerability record, thereby obtaining a new vulnerability record.

[0100] Finally, the new vulnerability records generated by the supplementary test are merged into the original data structure to update and improve the second dictionary list. Specifically, data version control or incremental update mechanism can be used to achieve this, such as using Git for differentiated management of vulnerability records.

[0101] In one example, after obtaining the second vulnerability dictionary list, the coverage analysis tool is first called to scan the vulnerability records to identify uncovered API interfaces or undetected input parameter types. For example, when it is found that the amount field of a payment interface lacks an out-of-bounds value test, the system automatically selects a numerical boundary detection script from the test template library, injects test parameters to generate test code containing maximum value overflow cases, that is, supplementary test code. After the supplementary test code is deployed to the automated testing platform, supplementary tests are performed on the target interface, and a detailed record containing attack vectors and stack information is generated when an integer overflow vulnerability is captured. After the newly discovered vulnerability data is format-checked, it is updated to the corresponding category of the second vulnerability dictionary through the data merging interface, forming a closed-loop test optimization mechanism.

[0102] Compared with the existing technology, when writing test reports manually, testers need to manually check the test item list and vulnerability record table, which can easily miss hidden test points. This solution actively detects test coverage gaps through automated analysis tools and uses code generation technology to quickly build supplementary test cases, which significantly improves efficiency compared to manually writing test codes. For example, in the Web service test scenario, the system can complete the coverage analysis of 100 API interfaces within 30 seconds and automatically generate missing XSS detection scripts, while it takes more than 2 hours to complete the same workload manually.

[0103] S460, filling the content in the second vulnerability dictionary list into a preset report template to obtain a security vulnerability test report.

[0104] Among them, the specific implementation methods of the above steps S410, S420, S430, S450 and S460 are the same as those of the corresponding steps S210, S220, S230, S240 and S250, and will not be repeated here.

[0105] Through the above technical solutions, this application realizes the automated verification of the integrity of the test items, avoiding the omissions that may occur in manual inspection. The automatic generation mechanism of test code effectively solves the problem of inefficient test case writing in traditional methods, especially when facing new attack methods, it can quickly generate corresponding detection solutions. The dynamic execution mechanism of the supplementary test link ensures that previously uncovered security vulnerabilities are captured in a timely manner, and the continuous update function of the vulnerability dictionary enables the system to have the ability to self-optimize, providing more comprehensive data support for the generation of subsequent test reports.

[0106] In addition, an embodiment of the present application also provides an electronic device, which includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements a method as in any one of the implementations in the embodiments of the present application; wherein the processor may adopt a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), a graphics processing unit (GPU), or one or more integrated circuits, for executing relevant programs to implement the method in any one of the implementations in the embodiments of the present application.

[0107] The processor may also be an integrated circuit electronic device with signal processing capability. In the implementation process, each step of the method in any implementation of the embodiments of the present application may be completed by an integrated logic circuit of hardware in the processor or by instructions in software form.

[0108] The above-mentioned processor can also be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor can be combined and executed.

[0109] The software module may be located in a random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register or other mature storage media in the art. The storage medium is located in the memory, and the processor reads the information in the memory, and combines its hardware to complete the functions required to be performed by the units included in the data processing device of the embodiment of the present application, or executes the method in any one of the implementation modes in the embodiment of the present application.

[0110] Another embodiment of the present application relates to a computer-readable storage medium storing a computer program, which implements the above method when executed by a processor.

[0111] Those skilled in the art can understand that all or part of the steps in the above-mentioned implementation method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of each implementation method of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0112] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for generating a security vulnerability test report, characterized in that: The method comprises the steps of: Parsing vulnerability records in a test record document input by a user, creating a vulnerability dictionary based on the vulnerability records, and generating a first vulnerability dictionary list; wherein the test record document is in a markdown format, and parsing the vulnerability records in the test record document input by the user includes extracting test codes based on a regular expression engine and semantic understanding; Scan the first vulnerability dictionary list to determine filled fields and unfilled fields corresponding to each vulnerability record; Constructing a first prompt word for generating supplementary content of the unfilled field according to the content of the filled field, and calling a first language model based on the first prompt word to obtain a first model output; wherein the content of the filled field includes at least a test code and a test result; Supplement the unfilled fields with content based on the first model output to obtain a second vulnerability dictionary list; Fill the content in the second vulnerability dictionary list into the preset report template to obtain a security vulnerability test report.

2. The method according to claim 1, characterized in that The step of constructing a first prompt word for generating supplementary content of the unfilled field according to the content of the filled field comprises: Calling a code library to analyze the test code to obtain an analysis text; Verify the correctness of other filled-in field contents based on the analyzed text; When the correctness verification is passed, the first prompt word is constructed based on the analyzed text and the contents of other filled fields.

3. The method according to claim 1, characterized in that The method further comprises: Performing analysis based on the second vulnerability dictionary list to determine whether there is a test coverage gap; In the case where there is a test coverage gap, constructing a supplementary test code for the test coverage gap, and performing a supplementary test based on the supplementary test code to obtain a supplementary test result; If the supplementary test result shows that there is a vulnerability risk, a new vulnerability record is generated based on the supplementary test code and the supplementary test result, and recorded in a second vulnerability dictionary.

4. The method according to claim 1, characterized in that: The test code extraction based on regular expression engine and semantic understanding includes: The vulnerability records in the test record document are scanned by a regular expression engine, and the boundary identifier of the code snippet is identified and located by pattern matching rules. After the code snippet is located, the code snippet is lexically analyzed and parsed, and an abstract syntax tree is constructed to identify the variable scope and function call chain, thereby locating the boundary of the test code.

5. The method according to claim 1, characterized in that The step of filling the vulnerability records in the second vulnerability dictionary list into a preset report template to obtain a security vulnerability test report includes: determining a first target fill position based on a first preset placeholder in the preset report template; Fill the vulnerability record into the first target filling position.

6. The method according to claim 1, characterized in that The method further comprises: Get test target information; determining a second target fill position based on a second preset placeholder in the preset report template; Fill the test target information into the second target filling position.

7. The method according to claim 1, characterized in that The method further comprises: Based on the preset format requirements, the content format of the security vulnerability test report is adjusted.

8. A security vulnerability test report generation system, characterized in that: The system is used to implement the method according to any one of claims 1 to 7.

9. An electronic device, characterized in that: The method comprises a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction implements the method according to any one of claims 1 to 7 when executed by the processor.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images