A security vulnerability test report generation method, system and electronic equipment

Abstract

The application relates to the technical field of data processing, and provides a security vulnerability test report generation method, a system and electronic equipment. The method comprises the following steps: analyzing 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; 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 of the unfilled fields according to the content of the filled fields, and calling a first large language model based on the first prompt word to obtain a first model output; supplementing the content of the unfilled fields 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. Therefore, the processing efficiency of the test report is improved.

Description

Technical Field

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

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

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

[0004] To improve the processing efficiency of test reports, this application provides a method for generating security vulnerability test reports. The method includes the following steps: parsing vulnerability records in a user-input test record document, 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 parsing the vulnerability records in the user-input test record document includes extracting test code based on a regular expression engine and semantic understanding; scanning the first vulnerability dictionary list to determine the filled and unfilled fields corresponding to each vulnerability record; constructing a first prompt word for generating supplementary content for the unfilled fields based on the content of the filled fields, and calling a first large language model based on the first prompt word to obtain the output of a first model; wherein the content of the filled fields includes at least test code and test results; supplementing the content of the unfilled fields based on the output of the first model to obtain a second vulnerability dictionary list; and filling the content of 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 log document containing at least the test code and test results. The system can then complete the remaining fields based on the content of the filled fields and directly generate a security vulnerability test report that meets the format requirements based on a preset report template, greatly improving the efficiency of test report writing. Simultaneously, by parsing the Markdown format test log document to construct a corresponding 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, the step of constructing a first prompt word for generating supplementary content for the unfilled fields based on the content of the filled fields includes: calling a code library to analyze the test code and obtain analysis text; verifying the correctness of the content of other filled fields based on the analysis text; and constructing the first prompt word based on the analysis text and the content of the other filled fields if the correctness verification passes.

[0007] Based on the above technical solution, by analyzing the test code, the analysis text is obtained, and the content of other filled fields is verified based on the analysis text. This not only enables automatic verification of the accuracy of manually input content and timely detection of problems in manual output, but also ensures the accuracy of the information in the constructed first prompt word, thereby ensuring the effectiveness of the supplementary content obtained based on the output of the first model.

[0008] In one implementation, the method further includes: analyzing 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 tests 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, it can automatically improve the test coverage gaps. On the one hand, it can help complete the missing test items, and on the other hand, it can proactively identify vulnerability risks, improve the second vulnerability dictionary, and thus improve the test report content.

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

[0011] Based on the above technical solution, by combining a regular expression engine and semantic understanding, the boundaries of the test code can be accurately located, thereby accurately extracting the complete test code and providing a good data foundation for subsequent processing.

[0012] In one implementation, filling the vulnerability records from 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, by limiting the filling position of vulnerability records and test target information by pre-setting placeholders, the 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 preset format requirements.

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

[0017] Furthermore, this application also provides an electronic device, which includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the above-described method.

[0018] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

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

[0021] Figure 1A A schematic diagram illustrating the structure of the security vulnerability test report generation system provided in the embodiments of this application is shown.

[0022] Figure 1B A schematic diagram illustrating the structure of the server provided in the embodiments of this application is shown.

[0023] Figure 2 A flowchart illustrating a security vulnerability test report generation method provided in an embodiment of this application is shown.

[0024] Figure 3 A flowchart illustrating the method for constructing the first prompt word in an embodiment of this application is shown.

[0025] Figure 4 A flowchart illustrating a security vulnerability test report generation method provided in another embodiment of this application is shown. Detailed Implementation

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

[0027] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, and "first", "second" and various numerical designations are only for the convenience of description and are not used to limit the scope of the embodiments of this application.

[0028] The features, structures, or characteristics in this application can be combined in any suitable manner in one or more embodiments. In the various embodiments of this application, the sequence number of each process does not imply 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 this application can be implemented independently without relying on other features in certain scenarios to solve the corresponding technical problems and achieve the corresponding effects. They can also be combined with other features according to needs in certain scenarios.

[0030] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referred to each other. In the various embodiments of this application, unless otherwise specified or there is a logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on 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 this application will be described in detail below with reference to the figures.

[0032] This application provides a method for generating security vulnerability test reports. Testers only need to provide a Markdown (MD) file containing the necessary test records to automatically generate a complete test report. The method is based on a security vulnerability test report system; please refer to [link / reference]. 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 via a webpage or application, providing an input interface to obtain user-uploaded test log documents, report templates, format requirements, and test target information. The test log document is an MD document that records vulnerability information, including but not limited to test code, test results, links, and other information that accurately records the testing process. The report template can be selected by the user from the target options provided by the system, or it can be uploaded by the user. The format requirements can be selected by the user from the options provided by the system according to the report requirements, or they can be determined based on relevant parameters actively set by the user. The test target information includes basic information related to the test project, such as the name of the system under test, the test scope, the organization information, the test time, and the testers.

[0034] Please refer to Figure 1B The server-side module 120 includes a document reading module 121, a content supplementation module 122, a template filling module 123, and a report generation module 124. Specifically, the document reading module 121 reads the vulnerability information recorded in the MD document and records it in a preset data structure; the content supplementation module 122 supplements incomplete content in the structured data; the template filling module 123 fills the complete structured data and test target information into the report template; and the report generation module 124 adjusts the format of the filled report template and outputs the test report.

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

[0036] S210: Parse the vulnerability records in the test record document input by the user, create a vulnerability dictionary based on the vulnerability records, and generate the first vulnerability dictionary list.

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

[0038] In one implementation, testers fill in at least one vulnerability record into the MD document according to the fixed syntax of the MD document. In one example, the vulnerability record includes fields such as vulnerability name, risk description, test module, test address, test process, risk analysis, and remediation suggestions. The test process includes the test code and test results. It is understandable that different test reports have different content requirements, therefore the fields included in the vulnerability record will also differ. In other words, in practical applications, the fields included in the vulnerability record can be adjusted according to actual needs.

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

[0040] In implementation, a regular expression engine refers to a processor that performs text pattern matching through predefined syntax rules. Specifically, it can be implemented using the PCRE library or the RE2 library to quickly locate the start and end markers of each field in an MD document. The start and end markers can be determined based on the syntax of the MD document.

[0041] To achieve accurate extraction of code blocks, when the code block fields are identified based on the start marker, semantic understanding can be further combined to parse the code context logic. Specifically, an abstract syntax tree generator or a control flow analyzer can be used to identify deep semantic features such as variable definitions and function call relationships.

[0042] Specifically, the vulnerability records in the test log document undergo a preliminary scan using a regular expression engine. Pattern matching rules are used to identify boundary markers of code blocks, such as the three-backtick syntax structure. After locating the code snippet, lexical analysis and syntax parsing are performed to construct an abstract syntax tree to identify logical relationships such as variable scope and function call chains, thereby accurately pinpointing the boundaries of the code block.

[0043] Based on this, the regular expression engine and semantic understanding form a collaborative working mechanism. The former ensures the coverage of code block location, while the latter verifies the effectiveness of the code structure. Together, they can accurately identify nested code and multilingual mixed code, thereby enabling accurate extraction of test code.

[0044] In this application, a vulnerability dictionary is created for each extracted vulnerability record, and these dictionaries are stored in a first vulnerability dictionary list. The vulnerability dictionary is implemented based on Python's built-in dictionary structure, storing the vulnerability record data in key-value pair format. Specifically, this can be implemented using JSON objects to standardize the storage of each field and content within the vulnerability record.

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

[0046] In practice, the identification of filled and unfilled fields is achieved by traversing dictionary key values. For example, if a field value is empty or a placeholder, it is marked as an unfilled field.

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

[0048] In practice, the content of the filled fields can be converted into natural language query statements, and the first prompt words can be automatically generated according to the pre-built output requirements.

[0049] In one example, the first prompt can be constructed based on some of the already filled fields. For instance, if the already filled field is the vulnerability name, and the fields that need to be supplemented include risk description, risk analysis, and remediation suggestions, the first prompt can be constructed as follows:

[0050] "You are a senior cybersecurity engineer. Please complete the following fields (using Chinese characters) based on the vulnerability names:"

[0051] Vulnerability Name: {vuln['VulnerabilityName']} # Extracted from the vulnerability dictionary

[0052] Fields that need to be added: {','.join(fields_needed)} # Fields not filled in

[0053] Generation requirements:

[0054] 1. The description must include the vulnerability's underlying principles, attack methods, and scope of impact.

[0055] 2. Risk analysis should include possibilities such as data breaches and privilege escalation.

[0056] 3. Repair recommendations should list specific protective measures point by point.

[0057] 4. Use technical terms but keep it concise.

[0058] 5. The output format is plain JSON, containing only the fields that need to be added.

[0059] In another example, the test code and results can be analyzed and converted into natural language to construct the initial prompt. For instance, if the analysis determines the test code is vulnerable to SQL injection, the attack was successful, and the unfilled fields represent remediation solutions, the initial prompt could include: "The following code segment is known to have an SQL injection vulnerability. The test results show a successful attack. Please generate a remediation solution." By directly constructing the initial prompt based on the analysis of the test code and results, the problem of inaccurate initial output due to errors in manually entered text can be avoided to some extent.

[0060] In yet another example, to ensure the accuracy of the first prompt word, please refer to... Figure 3 The method for constructing the first prompt word based on the content of the filled fields in this embodiment of the application specifically includes the following steps.

[0061] S310 calls the code library to analyze the test code and outputs the analysis text.

[0062] In implementation, the test code is the code segment used to trigger vulnerability detection. It can be implemented using Python scripts or Java unit test code, and its role is to provide executable input conditions for vulnerability testing.

[0063] The test results are the response data generated during the vulnerability detection process. Specifically, they can be stored in JSON format to provide a basis for verifying the correctness of the test logic.

[0064] A code repository is a collection of resources that stores code analysis tools and rule sets. Specifically, it can be implemented using static scanning tools such as SonarQube or Fortify, and is used to perform syntax checks and logical path analysis on test code.

[0065] The analysis text is used to record the structured analysis results output by the code repository. Specifically, it can be recorded in XML or Markdown format and is used to verify the logical consistency of the fields filled in the vulnerability record.

[0066] Specifically, after the test code is input into the code repository, 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 to determine the execution results corresponding to the test targets. Based on the execution results, it is determined whether there are potential vulnerabilities. Finally, an analysis text containing potential vulnerabilities is generated.

[0067] For example, when the test code is a query request, the codebase 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 can be determined whether the system has escaped or filtered the user input. If not, the potential risks corresponding to the text records are analyzed.

[0068] Based on this, potential vulnerabilities are identified by directly analyzing the test code and recorded in the analysis text.

[0069] S320, verify the correctness of other filled fields based on the analyzed text.

[0070] In practice, correctness verification involves matching the content recorded in the analyzed text with the content of other filled fields, or by calling a large language model, to identify whether there are any contradictions between the analyzed text and the content of other filled fields, thereby determining the correctness of the content of other filled fields and realizing automatic detection of manually entered content.

[0071] In one example, semantic analysis can be used to determine whether the meaning of the content in the analyzed text is consistent with the content of other filled fields. If they are 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.

[0072] In another example, the analysis text and the filled content of each other field can be analyzed and verified by calling the second language model, and the output of the second language model can be used to determine whether there are any contradictions between the analysis text and the filled content of each other field. The second language model can be a general model or a pre-trained expert model.

[0073] If the correctness verification passes, proceed to step S331; if the verification fails, proceed to step S332.

[0074] S331, construct the first prompt word based on the analyzed text and other filled field contents.

[0075] In practice, the first prompt word can be constructed by combining the analyzed text with the content of other filled fields as known information.

[0076] S332, output the manual confirmation interface to receive the user's confirmation results for other filled fields and analysis text, and select the analysis text or other filled fields to construct the first prompt word based on the confirmation results.

[0077] In implementation, when the result confirms that the analyzed text is inaccurate, a first prompt word is constructed based on the content of other filled fields. At the same time, according to the user's instructions, the content of filled fields with inaccurate content can be automatically supplemented, that is, the field is output as an unfilled field in the first prompt word.

[0078] 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 the accuracy of the content provided in the first prompt word and improving the accuracy of the first model's output. Simultaneously, it enables timely correction of problems in manually input content.

[0079] It is understandable that the content generated for the first prompt word can be adjusted according to actual needs and is not limited to this.

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

[0081] S240, based on the output of the first model, the content of the unfilled fields is supplemented to obtain the second vulnerability dictionary list.

[0082] In practice, after obtaining the output of the first model, the corresponding content can be added to the first vulnerability dictionary list to obtain a more complete second vulnerability dictionary list.

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

[0084] S250: Fill the contents of the second vulnerability dictionary list into the preset report template to obtain a security vulnerability test report.

[0085] In one implementation, a first preset placeholder can be set in the preset report template to locate the content filling position. In this way, the first target filling position can be determined based on the first preset placeholder in the preset report template, and the vulnerability record can be filled into the first target filling position.

[0086] The first preset placeholder refers to a marker or identifier pre-set in the preset report template. In one example, it can be implemented using keywords or specific strings enclosed in square brackets, such as "[Vulnerability Number]" or "{{Vulnerability Level}}". Its function is to provide clear guidance on the filling position of the fields in the vulnerability record.

[0087] The first target filling position refers to the specific area located in the template by parsing the first preset placeholder. This can be achieved through text matching algorithms or the placeholder parsing function of the template engine. For example, regular expressions can be 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.

[0088] In a specific example, anchor point positioning and XML manipulation techniques can be used to achieve precise content injection. By pre-marking paragraphs (such as "Test Result Details") in the Word template, the underlying XML interface of the python-docx library can be used to dynamically insert elements such as hierarchical headings and vulnerability details. Since the placeholders correspond one-to-one with the field names of the vulnerability records, there is no need for manual identification of the template structure during the filling process, avoiding field misalignment or formatting chaos caused by manual operation.

[0089] In another implementation, a second preset placeholder is also set in the preset report template to determine the second target filling position, wherein the second target filling position is used to insert the test target information input by the user.

[0090] The second preset placeholder refers to an identifier predefined in the template for inserting standard information. It can be a specific symbol or label marking the position, such as "{{System Name Under Test}}" or "##Test Time##". Based on this, a correspondence between the test target information and the template structure can be established, avoiding incorrect information insertion.

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

[0092] 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 under test, the applicable compliance standards, and the test time range. Next, the system parses the second preset placeholder in the report template, for example, identifying the location of the "{{compliance standards}}" tag, and determining the corresponding table or paragraph area as the second target filling location. Finally, the system fills the extracted target information sequentially into the specified locations; for example, filling "ISO 27001" into the compliance standards field and "January-March 2024" into the test time field. Through this process, standard information does not require manual searching and copying / pasting; it is automatically associated with the template structure, eliminating the risk of information omissions caused by manual operation and ensuring the standardization of the report format.

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

[0094] The preset formatting requirements refer to a predefined set of document layout rules, which can be implemented using configuration files or template files. These rules specify layout elements such as heading levels, font styles, and paragraph spacing. Preset formatting requirements ensure that reports generated from different vulnerability records maintain a consistent layout structure.

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

[0096] In this way, the problem of format misalignment or inconsistent style caused by manual operation can be eliminated by adjusting the content format. At the same time, it can adapt to different format adjustment needs. Users only need to set the preset format requirements to achieve uniform adjustment of the report format.

[0097] 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, PDF and Word dual-format reports can be output to meet the document circulation and audit archiving needs in different scenarios.

[0098] Based on the above technical solutions, this application achieves automated conversion of test records into standard reports. Structured parsing reduces the complexity of manual processing, intelligent generation technology reduces content error rates, and automatic filling of missing fields is implemented. Automatic identification of missing fields avoids resource waste from full data processing, and context-based prompts ensure the technical relevance of generated content to test results. The combination of preset templates and dynamic filling mechanisms ensures both standardized report formats and adaptability to the diverse content needs of different testing scenarios.

[0099] In some embodiments of this application, in order to ensure the completeness of the test report content, a second vulnerability dictionary list is also included.

[0100] Please refer to Figure 4 Another embodiment of this application provides a method for generating security vulnerability test reports, which specifically includes the following steps.

[0101] S410 parses the vulnerability records in the test log document input by the user, creates a vulnerability dictionary based on the vulnerability records, and generates the first vulnerability dictionary list.

[0102] S420: Scan the first vulnerability dictionary list to determine the filled and unfilled fields for each vulnerability record.

[0103] S430: Construct a first prompt word based on the content of the filled fields to generate supplementary content for the unfilled fields, and call the first large language model based on the first prompt word to obtain the output of the first model.

[0104] S440: Based on the output of the first model, the content of the unfilled fields is supplemented to obtain the second vulnerability dictionary list.

[0105] S450 analyzes the second vulnerability dictionary list to determine if there are any test coverage gaps. If there are test coverage gaps, it builds supplementary test code to address the gaps, performs supplementary tests, and records the results of the supplementary tests in the second vulnerability dictionary.

[0106] In implementation, determining whether there are missing test items involves 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 pre-set test case library or coverage analysis tool. Specifically, this can be achieved using AST abstract syntax tree analysis or interface coverage statistics methods to proactively identify test coverage gaps.

[0107] If a coverage gap is identified, the corresponding detection script can be automatically generated based on the type of missing test item. This can be achieved by using a template engine combined with a vulnerability pattern library. For example, for SQL injection vulnerabilities, detection test cases containing specific attack vectors can be generated, which is to supplement the test code.

[0108] Then, the generated supplementary test code is injected into the automated testing framework for verification. Specifically, this can be achieved using the test executor in the continuous integration toolchain, such as triggering the execution of new test cases through Jenkins to obtain supplementary test results.

[0109] If the supplementary test results indicate a vulnerability risk, a third warning word is constructed based on the supplementary test code and results. Then, by calling the third language model, supplementary content in other fields of the vulnerability record is obtained, thus creating a new vulnerability record.

[0110] Finally, the new vulnerability records generated by the supplementary tests are merged into the original data structure, thus updating and improving the second dictionary list. This can be achieved using data version control or incremental update mechanisms, such as using Git for differentiated management of vulnerability records.

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

[0112] Compared to existing technologies, traditional manual test report writing requires testers to manually check the test item list and vulnerability record table, easily overlooking hidden test points. This solution proactively detects test coverage gaps through automated analysis tools and quickly builds supplementary test cases using code generation technology, significantly improving efficiency compared to manual test code writing. For example, in a web service testing scenario, the system can complete coverage analysis of 100 API interfaces within 30 seconds and automatically generate missing XSS detection scripts, while manually completing the same workload would take more than 2 hours.

[0113] S460 populates the contents of the second vulnerability dictionary list into the preset report template to obtain a security vulnerability test report.

[0114] The specific implementation methods of steps S410, S420, S430, S450 and S460 are the same as those of steps S210, S220, S230, S240 and S250, and will not be described again.

[0115] Through the above technical solutions, this application achieves automated verification of the integrity of test projects, avoiding oversights that may occur during manual inspection. The automatic test code generation mechanism effectively solves the problem of low efficiency in test case writing in traditional methods, especially in quickly generating corresponding detection solutions when facing new attack techniques. The dynamic execution mechanism of the supplementary testing phase ensures timely capture of previously uncovered security vulnerabilities, while the continuous updating function of the vulnerability dictionary enables the system to have self-optimization capabilities, providing more comprehensive data support for the generation of subsequent test reports.

[0116] Furthermore, this application also provides an electronic device, which includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the method in any of the implementations in this application. The processor may be 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, used to execute related programs to implement the method in any of the implementations in this application.

[0117] The processor can also be an integrated circuit electronic device with signal processing capabilities. In implementation, each step of the method in any of the embodiments of this application can be completed by the integrated logic circuitry in the processor's hardware or by software instructions.

[0118] The aforementioned 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 gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.

[0119] The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in the memory. The processor reads information from the memory and, in conjunction with its hardware, performs the functions required by the units included in the data processing apparatus of this application embodiment, or executes the methods in any implementation of this application embodiment.

[0120] Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the embodiments of the above-described method.

[0121] Those skilled in the art will understand that all or part of the steps in the above-described embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0122] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for generating a security vulnerability test report, characterized in that, The method includes the following steps: Parse the vulnerability records in the test record document input by the user, create a vulnerability dictionary based on the vulnerability records, and generate a first vulnerability dictionary list; wherein the test record document is in Markdown format, and parsing the vulnerability records in the test record document input by the user includes extracting test code based on a regular expression engine and semantic understanding; Scan the first vulnerability dictionary list to determine the filled and unfilled fields for each vulnerability record; Based on the content of the filled fields, a first prompt word is constructed to generate supplementary content for the unfilled fields, and a first large language model is called based on the first prompt word to obtain the output of the first model; wherein, the content of the filled fields includes at least test code and test results; Based on the output of the first model, the content of the unfilled fields is supplemented to obtain a second vulnerability dictionary list; Fill the contents of the second vulnerability dictionary list into the preset report template to obtain a security vulnerability test report; The test code is analyzed by calling the code library to obtain the analysis text; The correctness of other filled fields is verified based on the analyzed text. If the correctness verification passes, the first prompt word is constructed based on the analyzed text and the contents of the other filled fields; The step of filling the vulnerability records from the second vulnerability dictionary list into the preset report template to obtain a security vulnerability test report includes: The first target filling position is determined based on the first preset placeholder in the preset report template; Fill the vulnerability record into the first target filling position; The method further includes: performing analysis based on the second vulnerability dictionary list to determine whether there are any test coverage gaps; In the case of test coverage gaps, supplementary test code is built to address the test coverage gaps, and supplementary tests are performed based on the supplementary test code to obtain supplementary test results. If the supplementary test results show that there is a vulnerability risk, a new vulnerability record is generated based on the supplementary test code and the supplementary test results, and recorded in the second vulnerability dictionary.

2. The method according to claim 1, characterized in that, The test code based on regular expression engine and semantic understanding extraction includes: The test log document is scanned for vulnerability records using a regular expression engine. Boundary identifiers of code snippets are identified and located using pattern matching rules. After locating the code snippets, lexical analysis and syntax parsing are performed on the code snippets to construct an abstract syntax tree to identify variable scope and function call chains, thereby locating the boundaries of the test code.

3. The method according to claim 1, characterized in that, The method further includes: Obtain test target information; The second target filling position is determined based on the second preset placeholder in the preset report template; The test target information is filled into the second target filling position.

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

5. 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 4.

6. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any one of claims 1 to 4.

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

Images