Software vulnerability detection method, device, equipment and storage medium

Abstract

The present application discloses a software vulnerability detection method, apparatus, device, and storage medium, relating to the field of network security, including: determining an initial software version interval of target software from a target system, and correcting the initial software version interval based on the file change time of the target file and the version release time of the target software to obtain a corrected version interval; training a pre-trained model using a preset vulnerability database, and determining a version probability distribution based on a target large language model obtained by the training; determining a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and testing the target system based on the target vulnerability test script, adjusting the corrected version interval using the obtained test results to obtain a target version interval; and determining the probability of vulnerability existence in the target system based on the version probability distribution and the target version interval. Therefore, the present application can improve the accuracy of vulnerability detection.

Description

Technical Field

[0001] The present invention relates to the field of network security, and in particular to a software vulnerability detection method, device, equipment and storage medium. Background Art

[0002] In the field of network security, vulnerability scanning and risk assessment are crucial to defending against network attacks, and accurately identifying the target system software version is the key to matching vulnerabilities.

[0003] However, existing technologies suffer from numerous flaws. For one thing, fuzz testing and version analysis techniques based on large language models focus on generating test cases to improve vulnerability detection coverage. Their core logic is to "discover the existence of vulnerabilities," resulting in ambiguous version location and limited association to version ranges. This leads to low vulnerability matching accuracy and a high risk of false positives and negatives. Furthermore, this technology relies on a single data source and lacks multi-source feature fusion. It cannot leverage dynamic information such as temporal features and proof-of-concept (PoC) test results, resulting in insufficient ability to modify version ranges. PoC verification is decoupled from version ranges, making it impossible to effectively narrow the version range. Furthermore, the failure to incorporate temporal features into analysis leads to redundant version ranges and inefficient vulnerability matching.

[0004] Therefore, how to improve the accuracy of vulnerability detection is a technical problem that needs to be solved urgently. Summary of the Invention

[0005] In view of this, the present invention aims to provide a software vulnerability detection method, apparatus, device, and storage medium that can improve the accuracy of vulnerability detection. The specific solution is as follows:

[0006] In a first aspect, the present application provides a software vulnerability detection method, comprising:

[0007] Determining an initial software version range of target software from a target system using a port scanning tool and a Web service identification tool, and revising the initial software version range based on a file modification time of the target file and a version release time of the target software to obtain a revised version range; wherein the target software includes the target file;

[0008] Use the preset vulnerability database to train the pre-trained model based on the Transformer architecture, and determine the version probability distribution based on the trained target large language model;

[0009] Determining a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and testing the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval;

[0010] The probability of a vulnerability existing in the target system is determined based on the version probability distribution and the target version interval.

[0011] Optionally, the determining the initial software version range of the target software from the target system using a port scanning tool and a Web service identification tool includes:

[0012] Use port scanning tools and Web service identification tools to determine the network protocol identification, response header information and service type of the target software from the target system;

[0013] Determining a first software version interval based on the network protocol identifier, the response header information, and the service type by the port scanning tool;

[0014] Determining a second software version interval based on the network protocol identifier, the response header information, and the service type by the Web service identification tool;

[0015] An intersection interval of the first software version interval and the second software version interval is determined, and the intersection interval is determined as an initial software version interval.

[0016] Optionally, the step of correcting the initial software version interval based on the file change time of the target file and the version release time of the target software to obtain a corrected version interval includes:

[0017] Determining a version release time of the target software from the preset vulnerability database and preset manufacturer information;

[0018] Determine a target static file from the target software, and determine the file change time of the target static file that is most recent to the current time using a preset hypertext transfer protocol request;

[0019] A version timeline is determined based on the version release time and the file change time, and the initial software version interval is revised using the version timeline to obtain a revised version interval.

[0020] Optionally, the method of training a pre-trained model based on a Transformer architecture using a preset vulnerability database and determining a version probability distribution based on a target large language model obtained through training includes:

[0021] Configuring a multi-source feature encoding layer for an input layer of a pre-trained model based on a Transformer architecture, and configuring a normalized exponential function for an output layer of the pre-trained model to obtain a configured model;

[0022] Acquire training data from the preset vulnerability database and the preset manufacturer information, and train the configured model based on the training data to obtain a target large language model;

[0023] Determine the website request return information about the target software and the time information of the target static file obtained from the target system by using the port scanning tool and the Web service identification tool to determine the first input information;

[0024] Determining the version usage data and version priority of the target software as second input information;

[0025] The first input information and the second input information are input into the target large language model, so that the target large language model outputs a version probability distribution.

[0026] Optionally, the testing the target system based on the target vulnerability test script to adjust the corrected version range using the obtained test results to obtain a target version range includes:

[0027] Determining an attack payload based on the target vulnerability test script, and sending the attack payload to the target system to obtain a system response result;

[0028] Matching the system response result with a preset vulnerability feature to obtain a matching result;

[0029] If the matching result indicates that there is a vulnerability in the target system, determining the impact scope of the vulnerability in the target system;

[0030] The corrected version interval is adjusted based on the vulnerability impact range to obtain a target version interval.

[0031] Optionally, determining the probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval includes:

[0032] Searching for a target vulnerability from the preset vulnerability database based on the target version interval;

[0033] The version coverage of the target vulnerability is determined, and the probability of the vulnerability existing in the target system is determined based on the version probability distribution and the version coverage.

[0034] Optionally, after determining the probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval, the method further includes:

[0035] Scoring the target vulnerability using a preset universal vulnerability scoring system to obtain a scoring result;

[0036] Determining a vulnerability exploitation status of the target vulnerability; the vulnerability exploitation status indicates whether there is vulnerability exploitation code for the target vulnerability;

[0037] A corresponding risk level is generated based on the scoring result and the vulnerability exploitation status, and a corresponding preset risk response operation is performed using the risk level.

[0038] In a second aspect, the present application provides a software vulnerability detection device, comprising:

[0039] a first interval determination module, configured to determine an initial software version interval of target software from a target system using a port scanning tool and a Web service identification tool, and to modify the initial software version interval based on a file modification time of the target file and a version release time of the target software to obtain a modified version interval; wherein the target software includes the target file;

[0040] The probability determination module is used to train the pre-trained model based on the Transformer architecture using a preset vulnerability database and determine the version probability distribution based on the trained target large language model;

[0041] a second interval determination module, configured to determine a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and test the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval;

[0042] A risk determination module is configured to determine a probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval.

[0043] In a third aspect, the present application provides an electronic device, comprising:

[0044] Memory, used to store computer programs;

[0045] The processor is used to execute the computer program to implement the aforementioned software vulnerability detection method.

[0046] In a fourth aspect, the present application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned software vulnerability detection method is implemented.

[0047] In this application, the initial software version interval of the target software is determined from the target system using a port scanning tool and a Web service identification tool, and the initial software version interval is corrected based on the file change time of the target file and the version release time of the target software to obtain a corrected version interval; wherein the target software contains the target file; a pre-trained model based on the Transformer architecture is trained using a preset vulnerability database, and a version probability distribution is determined based on the target large language model obtained by training; a target vulnerability test script is determined from the preset vulnerability database based on the corrected version interval, and the target system is tested based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval; the probability of the existence of a vulnerability in the target system is determined based on the version probability distribution and the target version interval. As can be seen from the above, in the process of software vulnerability detection, the present application first analyzes the target system with the help of a port scanning tool and a Web service identification tool to obtain the initial software version interval of the target software. On this basis, the initial software version interval is further optimized and corrected based on the file change time of the target file and the version release time of the target software, thereby obtaining a more accurate corrected version interval. Next, the pre-trained model based on the Transformer architecture is trained using the preset vulnerability database. Through the training process, the model continuously learns and masters the correlation between the software version and various features, and finally forms a target large language model, and uses the target large language model to determine the version probability distribution of the target software. Then, based on the corrected version interval, the adapted target vulnerability test script is screened out from the preset vulnerability database. The target system is tested using the target vulnerability test script, and based on the test results, the corrected version interval is dynamically adjusted again, thereby obtaining a target version interval that is more in line with reality. Finally, the probability of the actual existence of each vulnerability in the target system is determined by the version probability distribution and the target version interval, providing certain data support for subsequent vulnerability risk assessment and disposal. In this way, the present application can improve the efficiency of vulnerability detection, thereby quickly locating risks and reducing system security risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0049] Figure 1 A flowchart of a software vulnerability detection method disclosed in this application;

[0050] Figure 2 A flowchart of a specific software vulnerability detection method disclosed in this application;

[0051] Figure 3 This is a schematic diagram of the structure of a software vulnerability detection device disclosed in this application;

[0052] Figure 4 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0053] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0054] Currently, existing technologies have many flaws. On the one hand, fuzz testing and version analysis technology based on large language models focuses on generating test cases to improve vulnerability detection coverage. Its core logic is to "discover the existence of vulnerabilities," resulting in ambiguous version positioning and limited association to version ranges. This leads to low vulnerability matching accuracy and is prone to false positives and missed detections. On the other hand, this technology relies on a single data source and lacks multi-source feature fusion. It is unable to utilize dynamic information such as time features and POC test (Proof of Concept) test results, resulting in insufficient version range correction capabilities. POC verification is decoupled from version ranges, making it impossible to effectively narrow the version range. Furthermore, time features are not included in the analysis, resulting in redundant version ranges and low vulnerability matching efficiency. To this end, the present application provides a software vulnerability detection method, apparatus, device, and storage medium that can improve the accuracy of vulnerability detection.

[0055] See also Figure 1 As shown, an embodiment of the present invention discloses a software vulnerability detection method, comprising:

[0056] Step S11: Determine the initial software version interval of the target software from the target system using a port scanning tool and a Web service identification tool, and correct the initial software version interval based on the file change time of the target file and the version release time of the target software to obtain a corrected version interval; wherein the target software includes the target file.

[0057] In this embodiment, it is understood that in actual software vulnerability detection scenarios, due to the complexity and diversity of the target system, a single detection tool is often unable to accurately determine the target software version. Therefore, a port scanning tool and a web service identification tool can be used in combination to obtain more comprehensive information about the target software.

[0058] Specifically, when scanning a target system, a port scanning tool will detect the network protocol identifiers, response header information, and service types of open ports. For example, when Nmap (a port scanning tool) scans a server, Nmap will detect the received network protocol identifier, which may include a protocol fingerprint. At the same time, Nmap will parse the HTTP response header (i.e., the information returned by the server to the client based on the Hypertext Transfer Protocol), such as "Server:Apache / 2.4.x." This initially provides information that the target software is Apache (a type of web server software) and is in the 2.4 series. In addition, port scanning tools can also identify service types, such as web services, and this information is of great reference value for determining the type and version range of the target software.

[0059] At the same time, web service identification tools analyze the target system's page elements, script features, and other aspects from a web service perspective. For example, Wappalyzer (a web service identification tool) determines the type and version of the target software based on information such as library files and script code referenced in the page. For example, by analyzing the version information of specific libraries referenced in a page, combined with other page element features, Wappalyzer can determine the version range of the target software. When analyzing the aforementioned server, Wappalyzer might further determine that the Apache software is in the 2.4 series based on Apache-related features in the page.

[0060] After obtaining relevant information using the port scanning tool and the Web service identification tool respectively, the initial software version range of the target software is determined next. The specific operation is to compare the first software version range obtained by the port scanning tool with the second software version range obtained by the Web service identification tool and take the intersection of the two. For example, if the first software version range determined by the port scanning tool is v2.4.30-2.4.50, and the second software version range determined by the Web service identification tool is v2.4.x, then by taking the intersection, the initial software version range can be obtained as v2.4.30-2.4.50. This method of comprehensively analyzing the detection results of multiple tools effectively integrates the detection advantages of different tools, avoids the limitations of a single tool, and significantly narrows the version range.

[0061] After obtaining the initial software version range, in order to further improve the accuracy of version determination, it is necessary to modify it by combining information from the time dimension. This process is mainly achieved by analyzing the version release time of the target software and the file modification time of the target file.

[0062] First, collect the release dates of each version of the target software from a pre-defined vulnerability database and the manufacturer's official release channels. The pre-defined vulnerability database can be the CVE (Common Vulnerabilities and Exposures) database. For example, in the CVE database, it can be clearly seen that version 2.4.49 was released on September 1, 2021, and version 2.4.50 was released on October 15, 2021. This accurate version release date information constructs the target software's version timeline.

[0063] At the same time, the static files in the target software are analyzed, and the preset Hypertext Transfer Protocol request is used to determine the most recent file change time of the target static file compared to the current time. Specifically, an HTTP request is sent to obtain the file's Last-Modified (an HTTP response header field used to indicate the last modification time of a resource on the server) timestamp, thereby determining the latest modification time of the file. In actual detection, suppose that when scanning the target system, it is found that the last modification time of the target file is September 10, 2021. Combined with the constructed version timeline, since the change time of this file is after the release of Apache version 2.4.49, it can be inferred that the lower limit of the target software version is 2.4.49.

[0064] Finally, based on the version timeline determined by release date and file change time, the initial software version range is revised to obtain a more accurate revised version range. For example, if the initial software version range is v2.4.30-2.4.50, after the above analysis, the revised version range can be narrowed to v2.4.49-2.4.50. This process fully utilizes time characteristics to dynamically adjust the version range, making the version range more closely aligned with the actual situation of the target software.

[0065] Step S12: Use the preset vulnerability database to train the pre-trained model based on the Transformer architecture, and determine the version probability distribution based on the trained target large language model.

[0066] In this embodiment, first, the structural configuration of the pre-trained model based on the Transformer architecture is optimized. The pre-trained model can be a BERT model (i.e., Bidirectional Encoder Representations from Transformers, a pre-trained language model). A multi-source feature encoding layer is configured at the input layer of the model. This encoding layer can effectively integrate and encode feature information from different channels and in different formats. For example, for network protocol identifiers, response header information, etc. obtained from port scanning tools, as well as page element features obtained by Web service identification tools, the multi-source feature encoding layer can convert them into a vector form that the model can understand, thereby achieving a unified expression of multi-source data. A normalized exponential function (i.e., Softmax) is configured at the output layer. This function can convert the original numerical value output by the model into a probability distribution form, making the output result more interpretable and practical, and facilitating intuitive judgment of the possibility of each version. After the above configuration, the configured model is obtained.

[0067] Next, training data is obtained from the preset vulnerability database and preset vendor information. The preset vulnerability database stores a large number of records related to software versions and vulnerabilities. These records contain information such as vulnerability characteristics existing in different software versions, while the preset vendor information provides detailed descriptions of software version releases, version update content, and other data. This data is organized and annotated to form a training dataset covering the "version-feature" correspondence. The configured model is trained based on this training dataset. During the training process, the model continuously adjusts its internal parameters to learn the potential correlation between multi-source features and software versions. After multiple rounds of iterative training, the target large language model that can accurately capture the relationship between features and versions is ultimately obtained.

[0068] Furthermore, the information used to input the target large language model is determined. On the one hand, the website request return information about the target software obtained from the target system using port scanning tools and Web service identification tools is collected. This information contains various details exposed by the target software during network interaction, such as the software identifier in the response header and the software features reflected by the page elements. At the same time, the time information of the target static file is obtained. This time information reflects the changes in the file in the target software and is closely related to the software version. This information is integrated and determined as the first input information. On the other hand, the version usage data and version priority of the target software are determined as the second input information. Version usage data can be obtained from channels such as market research and user statistics, reflecting the popularity of different versions in actual applications; version priority is determined based on factors such as the software manufacturer's maintenance strategy for the version and the vulnerability repair status. For example, versions that repair major security vulnerabilities have a higher priority.

[0069] After obtaining the first input information and the second input information, the first input information and the second input information are input into the target large language model. It should be noted that if a version fixes a major vulnerability, its probability weight will be increased, and this increase in probability weight can be regarded as the version priority. The target large language model will comprehensively consider the software feature clues provided by multi-source features, the actual application reflected by the version usage, and the importance reflected by the version priority. Through internal calculation and processing, it will eventually output the version probability distribution. For example, the output result may be {v2.4.49: 65%, v2.4.50: 35%}. This probability distribution clearly shows the probability of each version, which helps to more accurately match vulnerabilities and conduct risk assessments.

[0070] Step S13: determining a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and testing the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval.

[0071] In this embodiment, a pre-set vulnerability database is first screened based on the corrected version range to determine the target vulnerability test script. Specifically, based on the target software version range defined by the corrected version range, the database is searched for vulnerabilities associated with the software versions within that range and the corresponding test scripts are extracted. For example, if the corrected version range is Apache 2.4.49-2.4.50, the vulnerability database is searched for all vulnerabilities affecting Apache software within that version range and test scripts for these vulnerabilities are retrieved. These scripts may contain specific code and operational steps for verifying the existence of the vulnerability.

[0072] Furthermore, the attack payload is determined based on the target vulnerability test script, and the attack payload is sent to the target system to obtain the system response result. The attack payload is a set of specific data or instructions generated according to the requirements of the test script, which is used to simulate the attacker's operation to exploit the vulnerability of the target system. For example, for an Apache path traversal vulnerability test script, the attack payload may be a special HTTP request that contains malicious path parameters and attempts to access files or directories that should not be made public in the system. After the attack payload is sent to the target system, the system will process these requests and return a response result. The response result contains various information returned by the server, such as HTTP response code, response header content, response body data, etc. This information is the key basis for determining whether there is a vulnerability in the target system.

[0073] Then, the system response results are matched with the preset vulnerability features to obtain a matching result. The preset vulnerability features are pre-defined standards or patterns used to determine whether the target system has a specific vulnerability. These features are usually based on the analysis of the vulnerability principles and the summary of actual test data, and may include specific error prompt information, the returned file content format, the response code combination, etc. For example, for the above-mentioned Apache path traversal vulnerability, the preset vulnerability feature may be the content of a system-sensitive file appearing in the response body, or the return of an error message in a specific format. The system will compare and analyze the obtained system response results with these preset vulnerability features one by one. If the response result contains the content described by the preset vulnerability feature, it is considered a successful match, otherwise the match fails, thereby obtaining an accurate matching result.

[0074] In a specific embodiment, if the matching result indicates that there is a vulnerability in the target system, the scope of the vulnerability in the target system is further determined. Different vulnerabilities may affect different version ranges of the software. By analyzing the vulnerability-related information and combining it with the actual situation of the target system, the software version range that the vulnerability specifically affects is determined. For example, an Apache vulnerability may clearly record that it affects versions 2.4.40-2.4.49, while the corrected version range of the current target system is 2.4.49-2.4.50. After analysis, it is found that the vulnerability is still valid in version 2.4.49, so the scope of the vulnerability's impact intersects with the current version range.

[0075] Finally, the corrected version range is adjusted based on the vulnerability impact range to obtain the target version range. That is, based on the relationship between the vulnerability impact range and the corrected version range, the version range is correspondingly reduced or corrected. If the vulnerability impact range is completely contained in the corrected version range, the version range is adjusted to be consistent with the vulnerability impact range; if the vulnerability impact range only partially covers the corrected version range, the intersection of the two is taken as the new version range. For example, if the corrected version range is 2.4.49-2.4.50 and the vulnerability impact range is 2.4.40-2.4.49, the adjusted target version range is 2.4.49. Through such an adjustment, the version range more accurately reflects the actual situation of the vulnerability in the target system.

[0076] Step S14: Determine the probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval.

[0077] In this embodiment, first, the target vulnerability is searched from the preset vulnerability database based on the target version interval. The target version interval limits the possible version range of the target software, and the search is performed in the vulnerability database based on this range. For example, when the target version interval is determined to be Apache2.4.49, all records in the database will be traversed to filter out vulnerability entries that affect the Apache2.4.49 version. These entries contain key information such as the vulnerability number (such as CVE-2021-41773), vulnerability description, and impact range, forming a target vulnerability set related to the target system.

[0078] Then, in this embodiment, the version coverage of the target vulnerability is determined, and the probability of the vulnerability existing in the target system is determined based on the version probability distribution and the version coverage. Each target vulnerability is recorded in the database with the version range it affects. Taking the CVE-2021-41773 vulnerability as an example, which covers version 2.4.49 with a probability of 65%, the probability of the vulnerability existing is directly taken as the version probability, that is, 65%. If a vulnerability such as CVE-2021-40438 affects v2.4.40-2.4.49, and the candidate versions are {v2.4.49:65%,v2.4.50:35%}, due to the relationship between the impact range and the version probability distribution, the probability of the vulnerability existing is 65%. When a vulnerability such as CVE-2021-42013 affects versions 2.4.49 and 2.4.50, because these two versions are completely covered in the candidate versions, the probability of the vulnerability existing is 100%. For other similar vulnerabilities, if their affected versions cover versions 2.4.49 and 2.4.50, the vulnerability impact probability is 100%. However, for vulnerabilities affecting versions earlier than 2.4.49, since they fall outside the main range of the current version probability distribution, the vulnerability probability is 0%. This quantitative calculation method deeply combines version information with the vulnerability impact range to achieve a precise assessment of the vulnerability's likelihood of existence.

[0079] Furthermore, the target vulnerability is scored using the pre-set Common Vulnerability Scoring System (CVSS) to generate a score. For example, a high-risk vulnerability that is remotely exploitable and does not require special permissions might receive a base score of 9.8. If the vulnerability already has public exploit code and has not yet been patched, the time score will be further increased. Based on the specific attributes of the vulnerability, the system inputs the corresponding parameters into the CVSS scoring model and automatically generates a standardized score that directly reflects the severity of the vulnerability.

[0080] At the same time, determine the exploitation status of the target vulnerability. This status indicates whether public or private exploit code (i.e., EXP) exists for the target vulnerability. This information can be obtained from security community reports, vulnerability intelligence platforms, and other sources. For example, certain popular vulnerabilities, which have seen a large number of public exploits in a short period of time, may have an exploitation status of "Public EXP Exists." Meanwhile, some less-researched vulnerabilities may have a "No Public EXP" status. Clarifying the exploitation status further assesses the risk of the vulnerability being exploited.

[0081] Finally, a corresponding risk level is generated based on the scoring results and vulnerability exploitation status, and the corresponding preset risk response actions are executed using the risk level. For example, a set of mapping rules can be established to convert the score and exploitation status into a risk level: when the CVSS score is greater than or equal to 9.0 and there is a public EXP, it is judged as a "high risk" risk; when the score is between 7.0-8.9 and there is an EXP, or the score is greater than or equal to 9.0 but there is no public EXP, it is judged as "medium risk"; when the score is less than 7.0 and there is no public EXP, it is judged as "low risk." For different risk levels, corresponding response strategies are preset: for high-risk vulnerabilities, the emergency repair process is immediately triggered, notifying operations and maintenance personnel to suspend related services and deploy patches; for medium-risk vulnerabilities, the repair plan assessment and implementation must be completed within 48 hours; and low-risk vulnerabilities can be included in the regular inspection plan and handled during the next system maintenance. Through this graded response mechanism, efficient management of vulnerability risks is achieved, minimizing the impact of security threats on the target system.

[0082] As can be seen above, during the software vulnerability detection process, this application first analyzes the target system using port scanning tools and web service identification tools to obtain the initial software version range of the target software. Based on this, the initial software version range is further optimized and corrected based on the target file's file change time and the target software's version release time, thereby obtaining a more accurate corrected version range. Next, a pre-trained model based on the Transformer architecture is trained using a preset vulnerability database. Through the training process, the model continuously learns and grasps the correlation between software versions and various features, ultimately forming a target large language model. This target large language model is then used to determine the version probability distribution of the target software. Then, based on the corrected version range, an adapted target vulnerability test script is selected from the preset vulnerability database. The target system is tested using the target vulnerability test script, and based on the test results, the corrected version range is dynamically adjusted again, thereby obtaining a more realistic target version range. Finally, the version probability distribution and the target version range are used to determine the actual probability of each vulnerability in the target system, providing data support for subsequent vulnerability risk assessment and mitigation. In this way, this application can improve the efficiency of vulnerability detection, thereby quickly locating risks and reducing system security risks.

[0083] The following combination Figure 2 The schematic diagram shown in FIG. 1 specifically illustrates the technical solution of the embodiment of the present application.

[0084] Specifically, the system first performs multi-source detection and fusion. The system concurrently invokes professional tools such as Nmap and Wappalyzer to conduct a comprehensive detection of the target system. As a powerful port scanning tool, Nmap interacts with the target system's network to collect data such as network protocol identifiers, response headers, and service types. For example, when scanning a web server, Nmap obtains the protocol identifier "SSH-2.0-OpenSSH_8.2p1" and the HTTP response header "Server: Apache / 2.4.x," providing preliminary clues to the server's software and version. Wappalyzer focuses on the web service layer, analyzing page elements, script features, and resource references to determine target software information from another perspective. After the two tools derive the first and second software version ranges, the system intersects them to obtain the initial version range. For example, the initial version range for Apache software is determined to be v2.4.30 - 2.4.50. This effectively integrates multi-source data and narrows the version range.

[0085] Next comes the time feature anchoring step. The system collects the release dates of each version of the target software from a pre-set vulnerability database (also known as a public vulnerability database) and the manufacturer's official channels to construct a detailed version timeline. At the same time, the system analyzes static files in the target system. For example, by sending an HTTP request to the file / api / v2 / docs, its Last-Modified time is obtained as 2021-09-16. Comparing this time with the version timeline, it is found that the file has not been modified since version v2.4.49. Therefore, the lower limit of the version is determined to be v2.4.49, further refining the version range.

[0086] The large-scale model inference phase then begins. Feature information, such as response headers and protocol fingerprints, acquired through multi-source detection is fed into a pre-trained model based on the Transformer architecture. Trained on a large amount of version-feature data, the model can deeply explore the correlation between features and versions. Furthermore, the probability distribution is adjusted based on version usage (i.e., version downloads). If a version fixes a major vulnerability, its probability weight is increased. Through model calculation and analysis, the final version probability distribution is output. For example, the probability of Apache software v2.4.49 being the default is 65%, and the probability of v2.4.50 being the default is 35%, providing a quantitative basis for version judgment.

[0087] Next, proceed to the POC dynamic correction step. Based on the previously determined version range, select POC test scripts for relevant vulnerabilities from the vulnerability database, such as executing a POC test for CVE-2021-41773. After sending a carefully constructed attack payload to the target system, the system response is matched against the pre-set vulnerability signature. If the vulnerability is confirmed, the original version range is revised from v2.4.40 - 2.4.50 to v2.4.49 based on the scope of the vulnerability, achieving further precise adjustment of the version range.

[0088] Finally, we conducted a vulnerability probability and risk assessment. Based on the identified version v2.4.49, we searched the vulnerability database for all vulnerabilities affected by that version. Since v2.4.49 falls completely within the scope of the relevant vulnerabilities, we determined the probability of the vulnerability existing was 100% and assessed its risk level as high.

[0089] Accordingly, see Figure 3 As shown, the embodiment of the present application provides a software vulnerability detection device, comprising:

[0090] a first interval determination module 11 for determining an initial software version interval of target software from a target system using a port scanning tool and a Web service identification tool, and correcting the initial software version interval based on a file modification time of the target file and a version release time of the target software to obtain a corrected version interval; wherein the target software includes the target file;

[0091] A probability determination module 12 is configured to train a pre-trained model based on a Transformer architecture using a preset vulnerability database, and determine a version probability distribution based on a target large language model obtained through training;

[0092] A second interval determination module 13 is configured to determine a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and test the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval;

[0093] The risk determination module 14 is configured to determine a probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval.

[0094] As can be seen above, during the software vulnerability detection process, this application first analyzes the target system using port scanning tools and web service identification tools to obtain the initial software version range of the target software. Based on this, the initial software version range is further optimized and corrected based on the target file's file change time and the target software's version release time, thereby obtaining a more accurate corrected version range. Next, a pre-trained model based on the Transformer architecture is trained using a preset vulnerability database. Through the training process, the model continuously learns and grasps the correlation between software versions and various features, ultimately forming a target large language model. This target large language model is then used to determine the version probability distribution of the target software. Then, based on the corrected version range, an adapted target vulnerability test script is selected from the preset vulnerability database. The target system is tested using the target vulnerability test script, and based on the test results, the corrected version range is dynamically adjusted again, thereby obtaining a more realistic target version range. Finally, the version probability distribution and the target version range are used to determine the actual probability of each vulnerability in the target system, providing data support for subsequent vulnerability risk assessment and mitigation. In this way, this application can improve the efficiency of vulnerability detection, thereby quickly locating risks and reducing system security risks.

[0095] In some specific implementations, the first interval determination module 11 specifically includes:

[0096] A software information determination unit is used to determine the network protocol identifier, response header information and service type of the target software from the target system using a port scanning tool and a Web service identification tool respectively;

[0097] A first interval determining unit, configured to determine a first software version interval based on the network protocol identifier, the response header information, and the service type using the port scanning tool;

[0098] A second interval determining unit, configured to determine a second software version interval based on the network protocol identifier, the response header information, and the service type using the Web service identification tool;

[0099] The initial interval determining unit is configured to determine an intersection interval of the first software version interval and the second software version interval, and determine the intersection interval as an initial software version interval.

[0100] In some specific implementations, the first interval determination module 11 specifically includes:

[0101] A release time determination unit, configured to determine the version release time of the target software from the preset vulnerability database and preset manufacturer information;

[0102] a change time determining unit, configured to determine a target static file from the target software, and determine a file change time of the target static file that is most recent to the current time using a preset hypertext transfer protocol request;

[0103] The interval correction unit is used to determine a version timeline based on the version release time and the file change time, and use the version timeline to correct the initial software version interval to obtain a corrected version interval.

[0104] In some specific implementations, the probability determination module 12 specifically includes:

[0105] A model configuration unit, configured to configure a multi-source feature encoding layer for the input layer of a pre-trained model based on a Transformer architecture, and to configure a normalized exponential function for the output layer of the pre-trained model, so as to obtain a configured model;

[0106] A model training unit, configured to obtain training data from the preset vulnerability database and the preset manufacturer information, and train the configured model based on the training data to obtain a target large language model;

[0107] A first information determining unit is configured to determine the website request return information about the target software and the time information of the target static file obtained from the target system using the port scanning tool and the Web service identification tool to determine the first input information;

[0108] a second information determining unit, configured to determine the version usage data and version priority of the target software as second input information;

[0109] An information input unit is configured to input the first input information and the second input information into the target large language model so that the target large language model outputs a version probability distribution.

[0110] In some specific implementations, the second interval determination module 13 specifically includes:

[0111] A payload sending unit, configured to determine an attack payload based on the target vulnerability test script, and send the attack payload to the target system to obtain a system response result;

[0112] A result matching unit, configured to match the system response result with a preset vulnerability feature to obtain a matching result;

[0113] a range determining unit, configured to determine an impact range of the vulnerability in the target system if the matching result indicates that a vulnerability exists in the target system;

[0114] The target interval determination unit is configured to adjust the corrected version interval based on the vulnerability impact range to obtain a target version interval.

[0115] In some specific implementations, the risk determination module 14 specifically includes:

[0116] A vulnerability search unit, configured to search for a target vulnerability from the preset vulnerability database based on the target version interval;

[0117] A probability determination unit is configured to determine a version coverage of the target vulnerability and determine a probability of the vulnerability existing in the target system based on the version probability distribution and the version coverage.

[0118] In some specific implementations, the risk determination module 14 further includes:

[0119] A vulnerability scoring unit, configured to score the target vulnerability using a preset universal vulnerability scoring system to obtain a scoring result;

[0120] A state determination unit, configured to determine a vulnerability exploitation state of the target vulnerability; the vulnerability exploitation state indicates whether there is vulnerability exploitation code for the target vulnerability;

[0121] The risk response unit is configured to generate a corresponding risk level based on the scoring result and the vulnerability exploitation status, and perform a corresponding preset risk response operation using the risk level.

[0122] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation on the scope of use of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the software vulnerability detection method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0123] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0124] In addition, the memory 22 as a carrier for resource storage can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0125] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, and can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of implementing the software vulnerability detection method executed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of implementing other specific tasks.

[0126] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned software vulnerability detection method. The specific steps of this method can be referred to the corresponding contents disclosed in the aforementioned embodiments and will not be repeated here.

[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0128] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0130] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0131] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A software vulnerability detection method, characterized in that: include: Determining an initial software version range of target software from a target system using a port scanning tool and a Web service identification tool, and revising the initial software version range based on a file modification time of the target file and a version release time of the target software to obtain a revised version range; wherein the target software includes the target file; Use the preset vulnerability database to train the pre-trained model based on the Transformer architecture, and determine the version probability distribution based on the trained target large language model; Determining a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and testing the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval; Determining a probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval; The pre-trained model based on the Transformer architecture is trained using a preset vulnerability database, and the version probability distribution is determined based on the trained target large language model, including: Configuring a multi-source feature encoding layer for an input layer of a pre-trained model based on a Transformer architecture, and configuring a normalized exponential function for an output layer of the pre-trained model to obtain a configured model; Acquire training data from the preset vulnerability database and preset manufacturer information, and train the configured model based on the training data to obtain a target large language model; Determine the website request return information about the target software and the time information of the target static file obtained from the target system by using the port scanning tool and the Web service identification tool to determine the first input information; Determining the version usage data and version priority of the target software as second input information; The first input information and the second input information are input into the target large language model, so that the target large language model outputs a version probability distribution.

2. The software vulnerability detection method according to claim 1, characterized in that: The method of using a port scanning tool and a Web service identification tool to determine the initial software version range of the target software from the target system includes: Use port scanning tools and Web service identification tools to determine the network protocol identification, response header information and service type of the target software from the target system; Determining a first software version interval based on the network protocol identifier, the response header information, and the service type by the port scanning tool; Determining a second software version interval based on the network protocol identifier, the response header information, and the service type by the Web service identification tool; An intersection interval of the first software version interval and the second software version interval is determined, and the intersection interval is determined as an initial software version interval.

3. The software vulnerability detection method according to claim 1, characterized in that: The step of correcting the initial software version interval based on the file change time of the target file and the version release time of the target software to obtain a corrected version interval includes: Determining a version release time of the target software from the preset vulnerability database and preset manufacturer information; Determine a target static file from the target software, and determine the file change time of the target static file that is most recent to the current time using a preset hypertext transfer protocol request; A version timeline is determined based on the version release time and the file change time, and the initial software version interval is revised using the version timeline to obtain a revised version interval.

4. The software vulnerability detection method according to claim 1, wherein: The testing of the target system based on the target vulnerability test script to adjust the corrected version interval using the obtained test results to obtain a target version interval includes: Determining an attack payload based on the target vulnerability test script, and sending the attack payload to the target system to obtain a system response result; Matching the system response result with a preset vulnerability feature to obtain a matching result; If the matching result indicates that there is a vulnerability in the target system, determining the impact scope of the vulnerability in the target system; The corrected version interval is adjusted based on the vulnerability impact range to obtain a target version interval.

5. The software vulnerability detection method according to any one of claims 1 to 4, characterized in that: Determining the probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval includes: Searching for a target vulnerability from the preset vulnerability database based on the target version interval; The version coverage of the target vulnerability is determined, and the probability of the vulnerability existing in the target system is determined based on the version probability distribution and the version coverage.

6. The software vulnerability detection method according to claim 5, characterized in that: After determining the probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval, the method further includes: Scoring the target vulnerability using a preset universal vulnerability scoring system to obtain a scoring result; Determining a vulnerability exploitation status of the target vulnerability; the vulnerability exploitation status indicates whether there is vulnerability exploitation code for the target vulnerability; A corresponding risk level is generated based on the scoring result and the vulnerability exploitation status, and a corresponding preset risk response operation is performed using the risk level.

7. A software vulnerability detection device, characterized in that: include: a first interval determination module, configured to determine an initial software version interval of target software from a target system using a port scanning tool and a Web service identification tool, and to modify the initial software version interval based on a file modification time of the target file and a version release time of the target software to obtain a modified version interval; wherein the target software includes the target file; The probability determination module is used to train the pre-trained model based on the Transformer architecture using a preset vulnerability database and determine the version probability distribution based on the trained target large language model; a second interval determination module, configured to determine a target vulnerability test script from the preset vulnerability database based on the corrected version interval, and test the target system based on the target vulnerability test script, so as to adjust the corrected version interval using the obtained test results to obtain a target version interval; a risk determination module, configured to determine a probability of a vulnerability existing in the target system based on the version probability distribution and the target version interval; Wherein, the probability determination module includes: A model configuration unit, configured to configure a multi-source feature encoding layer for the input layer of a pre-trained model based on a Transformer architecture, and to configure a normalized exponential function for the output layer of the pre-trained model, so as to obtain a configured model; A model training unit, configured to obtain training data from the preset vulnerability database and preset manufacturer information, and train the configured model based on the training data to obtain a target large language model; A first information determining unit is configured to determine the website request return information about the target software and the time information of the target static file obtained from the target system using the port scanning tool and the Web service identification tool to determine the first input information; a second information determining unit, configured to determine the version usage data and version priority of the target software as second input information; An information input unit is configured to input the first input information and the second input information into the target large language model so that the target large language model outputs a version probability distribution.

8. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the software vulnerability detection method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that Used to store a computer program; wherein, when the computer program is executed by a processor, the software vulnerability detection method according to any one of claims 1 to 6 is implemented.

Images