A vulnerability detection method, apparatus, device, medium, and product

Abstract

This application relates to a vulnerability detection method, apparatus, device, medium, and product, and pertains to the field of cloud computing technology. The method includes: splitting an encrypted version string to obtain encrypted ciphertext, sending timestamp information, and obfuscation feature string; verifying the encrypted ciphertext, sending timestamp information, and obfuscation feature string to obtain a verification result, and retrieving the decryption key if the result passes; decrypting the encrypted ciphertext with the decryption key to obtain target format version information; retrieving the software name, major version number, minor version number, and patch version number from the target format version information, and matching the software name against a pre-stored rule base list of target vulnerability data; obtaining a vulnerability risk assessment result and a remediation result based on the major version number, minor version number, patch version number, vulnerability impact scope, and the target version for remediation; and generating a vulnerability detection report based on the vulnerability risk assessment result and the remediation result. Decrypting the encrypted version string and matching the vulnerability scope effectively improves the timeliness of vulnerability detection.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a vulnerability detection method, apparatus, device, medium, and product. Background Technology

[0002] In industry scenarios with extremely high security requirements, middleware, as the underlying component supporting core business systems, undertakes key functions such as data transmission, service invocation, and resource allocation. Its version information is directly related to the system's vulnerability exposure surface.

[0003] Currently, most mainstream vulnerability scanning tools rely on publicly available proof-of-concept (POC) scripts to identify middleware-related vulnerabilities. There is an average gap of over 45 days between the disclosure of a high-risk vulnerability and the availability of a usable POC, resulting in low timeliness of vulnerability detection. Summary of the Invention

[0004] This application provides a vulnerability detection method, apparatus, device, medium, and product to solve the technical problem of low timeliness in vulnerability detection caused by existing technologies.

[0005] In a first aspect, embodiments of this application provide a vulnerability detection method, the method being applied to a vulnerability scanning terminal, comprising:

[0006] Receive the encrypted version string, and split the encrypted version string according to a preset format to obtain the encrypted ciphertext, the sending timestamp information, and the obfuscation feature string;

[0007] Data verification is performed based on the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string to obtain a verification result. When the verification result is detected as passing, the decryption key is obtained.

[0008] The encrypted ciphertext is decrypted using the decryption key to obtain the target format version information;

[0009] The software name, major version number, minor version number, and patch version number are extracted from the target format version information, and the target vulnerability data list is matched from the pre-stored rule base according to the software name; wherein, the target vulnerability data list includes the scope of vulnerability impact and the target version for fixing the vulnerability;

[0010] The vulnerability risk assessment result and the remediation result are obtained based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for patching the vulnerability;

[0011] A vulnerability detection report is obtained based on the vulnerability risk assessment results and the remediation results.

[0012] In one possible implementation, the data verification process based on the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string to obtain the verification result includes:

[0013] The obfuscated feature string is restored to obtain the first hash digest value;

[0014] Obtain the received timestamp information, and when the absolute difference between the received timestamp information and the sent timestamp information is less than or equal to a preset time threshold, concatenate and hash the encrypted ciphertext and the sent timestamp information to obtain a second hash digest value.

[0015] The verification result is obtained based on the first hash digest value and the second hash digest value.

[0016] In one possible implementation, obtaining the vulnerability risk assessment result and remediation result based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for patching the vulnerability includes:

[0017] Based on the major version number, the minor version number, and the patch version number, determine whether the target version is within the scope of the vulnerability's impact. If it is, the vulnerability risk assessment result is "existence confirms vulnerability risk"; if it is not, the vulnerability risk assessment result is "non-existence confirms vulnerability risk".

[0018] Based on the major version number, the minor version number, and the patch version number, determine whether the target version is lower than the target version for fixing the vulnerability. If yes, the repair result is that no repair was performed; otherwise, the repair result is that the vulnerability was fixed.

[0019] In one possible implementation, when the vulnerability risk assessment result indicates that there is no confirmed vulnerability risk, the method further includes:

[0020] Obtain each adjacent version of the target version, and the vulnerability risk assessment results of each adjacent version;

[0021] Based on the vulnerability risk assessment results of each adjacent version and the preset weights corresponding to each adjacent version, the probability of the existence of vulnerability risk in the target version is obtained.

[0022] When the probability of the vulnerability risk is greater than or equal to a preset probability threshold, the vulnerability risk assessment result is that there is a suspected vulnerability risk.

[0023] When the vulnerability risk assessment result indicates the existence of a suspected vulnerability risk, the target version is reviewed to obtain the review result;

[0024] If the verification result indicates that the target version has a vulnerability risk, the vulnerability risk assessment result of the target version is changed to "confirmed vulnerability risk".

[0025] In one possible implementation, when the vulnerability risk assessment result of the target version indicates the existence of a confirmed vulnerability risk, and the remediation result indicates that no remediation has been performed, the method further includes:

[0026] Obtain a list of candidate upgrade versions and the vulnerability risk assessment results for each candidate upgrade version;

[0027] Based on the vulnerability risk assessment results of each candidate upgrade version, a selection process is performed to obtain each candidate upgrade version that does not have any confirmed vulnerability risks.

[0028] Obtain compatibility data between each candidate upgrade version that does not have confirmed vulnerability risks and the target version;

[0029] Obtain upgrade cost data for each candidate upgrade version that does not have confirmed vulnerability risks;

[0030] The target upgrade version is obtained based on various compatibility data and upgrade cost data, and the target version is then upgraded and repaired.

[0031] In one possible implementation, obtaining the target upgrade version based on the compatibility data and upgrade cost data includes:

[0032] The compatibility data and upgrade cost data are weighted and summed to obtain the weighted scores of each candidate upgrade version that does not have confirmed vulnerability risks.

[0033] The target upgrade version is obtained by weighting the scores of each candidate upgrade version that does not have a confirmed vulnerability risk.

[0034] Secondly, embodiments of this application provide a vulnerability detection method, the method being applied to an encryption terminal, comprising:

[0035] Obtain the original version information and preprocess the original version information to obtain the target format version information;

[0036] Obtain the encryption key, and encrypt the target format version information according to the encryption key to obtain encrypted ciphertext;

[0037] Obtain the sending timestamp information, and concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain a first hash digest value;

[0038] The first hash digest value is subjected to a preset character replacement process to obtain a replaced version string;

[0039] The replacement version string is obfuscated to obtain an obfuscated feature string;

[0040] The encrypted ciphertext, the sending timestamp information, and the obfuscated feature string are integrated according to a preset format to obtain an encrypted version string, which is then sent to the vulnerability scanning terminal.

[0041] Thirdly, embodiments of this application provide a vulnerability detection device, which is applied to a vulnerability scanning terminal and includes:

[0042] The splitting module is used to receive the encrypted version string and split the encrypted version string according to a preset format to obtain encrypted ciphertext, sending timestamp information, and obfuscation feature string;

[0043] The verification module is used to perform data verification processing based on the encrypted ciphertext, the sending timestamp information and the obfuscated feature string, obtain the verification result, and obtain the decryption key when the verification result is detected as passing.

[0044] The decryption module is used to decrypt the encrypted ciphertext according to the decryption key to obtain the target format version information;

[0045] The matching module is used to extract the software name, major version number, minor version number, and patch version number from the target format version information, and match the target vulnerability data list from the pre-stored rule base according to the software name; wherein, the target vulnerability data list includes the scope of vulnerability impact and the target version for fixing the vulnerability;

[0046] The result acquisition module is used to obtain vulnerability risk assessment results and remediation results based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for remediation.

[0047] The report acquisition module is used to obtain a vulnerability detection report based on the vulnerability risk assessment results and the remediation results.

[0048] Fourthly, embodiments of this application provide a vulnerability detection device, which is applied to an encryption terminal and includes:

[0049] The preprocessing module is used to obtain the original version information and preprocess the original version information to obtain the target format version information;

[0050] An encryption module is used to obtain an encryption key and encrypt the target format version information according to the encryption key to obtain encrypted ciphertext;

[0051] The hash processing module is used to obtain the sending timestamp information, and to concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain a first hash digest value;

[0052] The replacement module is used to perform preset character replacement processing on the first hash digest value to obtain a replacement version string;

[0053] The obfuscation processing module is used to obfuscate the replacement version string to obtain an obfuscated feature string;

[0054] The integration module is used to integrate the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string according to a preset format to obtain an encrypted version string, and then send the encrypted version string to the vulnerability scanning terminal.

[0055] Fifthly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0056] The memory stores computer-executed instructions;

[0057] The processor executes computer execution instructions stored in the memory to implement the vulnerability detection method provided in the first aspect of this application or the vulnerability detection method provided in the second aspect of this application.

[0058] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the vulnerability detection method provided in the first aspect of this application or the vulnerability detection method provided in the second aspect of this application.

[0059] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the vulnerability detection method provided in the first aspect of this application or the vulnerability detection method provided in the second aspect of this application.

[0060] This application provides a vulnerability detection method, apparatus, device, medium, and product, comprising: receiving an encrypted version string and splitting the encrypted version string according to a preset format to obtain encrypted ciphertext, sending timestamp information, and obfuscation feature string; performing data verification processing based on the encrypted ciphertext, sending timestamp information, and obfuscation feature string to obtain a verification result, and obtaining a decryption key when the verification result is detected as passing; decrypting the encrypted ciphertext based on the decryption key to obtain target format version information; extracting the software name, major version number, minor version number, and patch version number from the target format version information, and matching the target vulnerability data list from a pre-stored rule base based on the software name; obtaining a vulnerability risk assessment result and a remediation result based on the major version number, minor version number, patch version number, vulnerability impact scope, and target version for remediation; and obtaining a vulnerability detection report based on the vulnerability risk assessment result and the remediation result. The above method achieves the following technical effects: by receiving the encrypted version string, decrypting it, and matching the vulnerability scope, the vulnerability identification time can be advanced from after the vulnerability is disclosed and a usable POC appears to the moment the encrypted version string is received, without waiting for the POC. This enables near real-time discovery and response to known vulnerabilities, significantly shortens the defense window, and effectively improves the timeliness of vulnerability detection. Attached Figure Description

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

[0062] Figure 1 This is a schematic diagram illustrating an application scenario of a vulnerability detection method provided in an embodiment of this application.

[0063] Figure 2 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 1 ;

[0064] Figure 3 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 2 ;

[0065] Figure 4 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 3 ;

[0066] Figure 5 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 4 ;

[0067] Figure 6 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 5 ;

[0068] Figure 7 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 6 ;

[0069] Figure 8 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 7 ;

[0070] Figure 9 A schematic diagram of the structure of a vulnerability detection device provided in this application embodiment. Figure 1 ;

[0071] Figure 10 A schematic diagram of the structure of a vulnerability detection device provided in this application embodiment. Figure 2 ;

[0072] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0073] Explanation of reference numerals in the attached figures:

[0074] 110 - Terminal; 120 - Server; 910 - Processor; 920 - Memory; 930 - Communication Components; 940 - Bus.

[0075] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0076] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0077] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0078] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the vulnerability detection method provided in the embodiments of this application is merely an example, and vulnerability detection methods may include more or fewer elements.

[0079] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0080] The model designed in this application provides users with corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0081] To clearly understand the technical solution of this application, some terms will be explained in detail first.

[0082] Encrypted Version Release Module: The core component in the encrypted terminal that processes and encrypts version information.

[0083] Dynamic encryption strategy: An encryption method that combines Base64+ROT13 encoding and timestamp hashing.

[0084] Version-Vulnerability Association Rule Base: A database of pre-defined version and vulnerability mapping relationships.

[0085] Improved Levenshtein fuzzy algorithm: an intelligent matching algorithm for handling version number distortion.

[0086] Elliptic Curve Diffie–Hellman Key Exchange (ECDH): A temporary session key exchange mechanism that ensures the use of an independent key for each scan.

[0087] Version Markov Chain Model: A mathematical model that predicts intermediate versions from a known version sequence.

[0088] In order to clearly understand the technical solution of this application, the solutions of the prior art are introduced.

[0089] In current technologies, mainstream vulnerability scanning tools generally rely on Proof-of-Concept (POC) to identify middleware-related vulnerabilities. There is an average gap of over 45 days between the disclosure of a high-risk vulnerability and the emergence of a usable POC, resulting in low timeliness of vulnerability detection.

[0090] In summary, how to design a technical solution to the problem of low timeliness of vulnerability detection caused by existing technologies is the problem that this application urgently needs to solve.

[0091] Therefore, in view of the above-mentioned technical problems existing in the prior art, the embodiments of this application provide a vulnerability detection method, apparatus, device, medium and product, aiming to effectively improve the timeliness of vulnerability detection.

[0092] The following describes the application scenarios of the vulnerability detection methods, apparatus, devices, media, and products provided in the embodiments of this application. These application scenarios are merely examples, intended to help those skilled in the art understand the technical content of this application, but do not imply that the embodiments of this application cannot be used in other devices, systems, environments, or scenarios.

[0093] Software Development: Security testing is an integral part of the software development lifecycle. During the testing and verification phase, the vulnerability detection methods, apparatuses, devices, media, and products provided in this application's embodiments can be used to scan running applications for vulnerabilities and investigate risks associated with third-party components. This effectively improves the timeliness of vulnerability detection and significantly shortens the defense window.

[0094] Figure 1 This is a schematic diagram illustrating an application scenario of a vulnerability detection method provided in an embodiment of this application, such as... Figure 1 As shown, it includes: terminal 110 and server 120.

[0095] Terminal 110 can be a client under a vulnerability scanning terminal or an encryption terminal. Server 120 is used to control the receipt of vulnerability detection reports.

[0096] Figure 2 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 1 The execution entity in this embodiment can be Figure 1 The server 120 in this embodiment can also be other computer-related devices; this embodiment is not particularly limited in its application. The vulnerability detection method provided in this embodiment is applied to a vulnerability scanning terminal and includes the following steps:

[0097] S101. Receive the encrypted version string and split the encrypted version string according to the preset format to obtain the encrypted ciphertext, the sending timestamp information, and the obfuscation feature string.

[0098] In this embodiment, the vulnerability scanning end is a vulnerability scanning system. After receiving the encrypted version string sent by the encryption processing engine through a secure communication channel, the vulnerability scanning system first splits the encrypted version string according to a preset format to obtain the encrypted ciphertext, the sending timestamp information, and the obfuscation feature string.

[0099] S102. Perform data verification processing based on the encrypted ciphertext, sending timestamp information, and obfuscated feature string to obtain the verification result, and obtain the decryption key when the verification result is detected as passing.

[0100] In this embodiment, the decryption key is obtained when the verification result is detected as passing.

[0101] S103. Decrypt the encrypted ciphertext using the decryption key to obtain the target format version information.

[0102] In this embodiment, after obtaining the decryption key, the encrypted ciphertext is decrypted using the decryption key to obtain the target format version information.

[0103] The vulnerability scanning system's processing flow includes two key stages: decryption and rule matching. S101-S103 execute the decryption process, and S104-S106 execute the rule matching process.

[0104] After receiving the encrypted version string, the vulnerability scanning system uses a rule parsing engine to match and analyze it against the vulnerability rule base. The rule base contains three core components: a version range matcher, a patch status analyzer, and a future remediation plan prediction module. Finally, a vulnerability detection report is generated.

[0105] S104. Extract the software name, major version number, minor version number, and patch version number from the target format version information, and match the target vulnerability data list from the pre-stored rule base according to the software name.

[0106] In this embodiment, the target vulnerability data list includes the vulnerability's impact scope and the target versions for patching the vulnerability. The pre-stored rule base is a pre-stored vulnerability rule base.

[0107] In this embodiment, the software name is used to match the corresponding target vulnerability data list from the pre-stored rule base.

[0108] S105. Based on the major version number, minor version number, patch version number, vulnerability impact scope, and target version for vulnerability remediation, obtain the vulnerability risk assessment result and remediation result.

[0109] In this embodiment, the vulnerability risk assessment results include confirmed vulnerability risk, suspected vulnerability, and secure version, and the remediation results include no remediation and remediation.

[0110] S106. Obtain a vulnerability detection report based on the vulnerability risk assessment and remediation results.

[0111] In this embodiment, the vulnerability detection report includes the vulnerability risk assessment result and the remediation result.

[0112] By receiving encrypted version strings and decrypting and matching them with vulnerability scopes, the vulnerability identification time can be advanced from after the vulnerability is disclosed and a usable POC appears to the moment the encrypted version string is received, without waiting for the POC. This enables near real-time discovery and response to known vulnerabilities, significantly shortens the defense window, and effectively improves the timeliness of vulnerability detection.

[0113] This application provides a vulnerability detection method, comprising: receiving an encrypted version string and splitting the encrypted version string according to a preset format to obtain encrypted ciphertext, sending timestamp information, and obfuscation feature string; performing data verification processing based on the encrypted ciphertext, sending timestamp information, and obfuscation feature string to obtain a verification result, and obtaining a decryption key when the verification result is detected as passing; decrypting the encrypted ciphertext based on the decryption key to obtain target format version information; extracting the software name, major version number, minor version number, and patch version number from the target format version information, and matching the target vulnerability data list from a pre-stored rule base based on the software name; obtaining a vulnerability risk assessment result and a remediation result based on the major version number, minor version number, patch version number, vulnerability impact scope, and target version for remediation; and obtaining a vulnerability detection report based on the vulnerability risk assessment result and the remediation result. The above method achieves the following technical effects: by receiving the encrypted version string, decrypting it, and matching the vulnerability scope, the vulnerability identification time can be advanced from after the vulnerability is disclosed and a usable POC appears to the moment the encrypted version string is received, without waiting for the POC. This enables near real-time discovery and response to known vulnerabilities, significantly shortens the defense window, and effectively improves the timeliness of vulnerability detection.

[0114] Figure 3A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 2 The vulnerability detection method provided in this embodiment, in step S102, performs data verification processing based on the encrypted ciphertext, sending timestamp information, and obfuscated feature string to obtain the verification result, including the following steps:

[0115] S201. Perform restoration processing on the obfuscated feature string to obtain the first hash digest value.

[0116] In this embodiment, the obfuscated feature string is first deobfuscated to obtain a replacement version string, and then the replacement version string is reverse-replaced to obtain a first hash digest value.

[0117] S202. Obtain the received timestamp information, and when the absolute difference between the received timestamp information and the sent timestamp information is less than or equal to a preset time threshold, concatenate and hash the encrypted ciphertext and the sent timestamp information to obtain a second hash digest value.

[0118] In this embodiment, the received timestamp information is obtained. When it is detected that |received timestamp - sent timestamp| is less than or equal to a preset time threshold, the encrypted ciphertext and the sent timestamp information are concatenated to obtain a second concatenated version string. Then, the encryption processing engine performs hash processing on the second concatenated version string to obtain a second hash digest value. Checking whether the received timestamp information is within a reasonable window can effectively prevent replay attacks.

[0119] S203. Obtain the verification result based on the first hash digest value and the second hash digest value.

[0120] In this embodiment, when the first hash digest value and the second hash digest value are detected to be the same, the verification result is passed, indicating that the data has not been swapped; otherwise, the verification result is failed, indicating that the data has been swapped.

[0121] By quickly verifying the integrity of the hash digest value, the system ensures that the received encrypted version string has not been tampered with or swapped, thus providing a reliable data foundation for the subsequent vulnerability detection process. This enables the system to achieve near real-time vulnerability matching and response based on real and complete version information, avoiding misjudgments or omissions caused by data contamination, and improving the accuracy and timeliness of overall security detection.

[0122] Figure 4 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 3 In the vulnerability detection method provided in this embodiment, S105 includes the following steps:

[0123] S301. Determine whether the target version exists within the scope of the vulnerability based on the major version number, minor version number, and patch version number. If it exists, the vulnerability risk assessment result is "existence confirms vulnerability risk"; if it does not exist, the vulnerability risk assessment result is "non-existence confirms vulnerability risk".

[0124] In this embodiment, step S301 is executed by the version range matcher, and the target version is the version corresponding to the major version number, minor version number, and patch version number. If the target version exists within the scope of the vulnerability's impact, the vulnerability risk assessment result is that a vulnerability risk exists and is confirmed; if the target version does not exist within the scope of the vulnerability's impact, the vulnerability risk assessment result is that a vulnerability risk does not exist and is confirmed.

[0125] The vulnerability rules are expressed using a multi-dimensional matching model that combines version range, time conditions, and confidence weights.

[0126] S302. Determine whether the target version is lower than the target version for fixing the vulnerability based on the major version number, minor version number, and patch version number. If yes, the fix result is "not fixed"; otherwise, the fix result is "fixed".

[0127] In this embodiment, S302 is executed by the patch status analyzer. The target version for patching the vulnerability is the minimum version for patching the vulnerability. If the target version is less than the minimum version for patching the vulnerability, then the version is not patched; if the target version is greater than or equal to the minimum version for patching the vulnerability, then the version has been patched.

[0128] Version matching is performed based on a pre-stored rule base, which can quickly and automatically determine whether the current version has known vulnerabilities without waiting for a Proof of Concept (POC), thereby significantly shortening the vulnerability confirmation time and significantly improving the response speed and proactive defense against known vulnerabilities.

[0129] Figure 5 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 4 The vulnerability detection method provided in this embodiment, when the vulnerability risk assessment result indicates that no confirmed vulnerability risk exists, also includes the following steps:

[0130] S401. Obtain the adjacent versions of the target version, as well as the vulnerability risk assessment results of each adjacent version.

[0131] In this embodiment, for example, if the target version is 2.3.1, then the adjacent versions of the target version can be 2.3.0 (previous patch version), 2.3.2 (next patch version), 2.2.9 (previous minor version), 2.4.0 (next minor version), 1.9.9 (previous major version), and 3.0.0 (next major version).

[0132] The method for obtaining the vulnerability risk assessment results of each adjacent version is similar to the method for obtaining the vulnerability risk assessment results of the target version, and will not be repeated here.

[0133] S402. Based on the vulnerability risk assessment results of each adjacent version and the preset weights corresponding to each adjacent version, the probability of vulnerability risk existing in the target version is obtained.

[0134] In this embodiment, the correlation between the previous patch version and the next patch version in each adjacent version and the target version is extremely high, so the corresponding preset weight is a high weight, such as 40%; the correlation between the previous minor version and the next minor version in each adjacent version and the target version is relatively high, so the corresponding preset weight is a medium weight, such as 25%; the correlation between the previous major version and the next major version in each adjacent version and the target version is moderate, so the corresponding preset weight is a low weight, such as 10%. No specific restrictions are placed on the preset weights corresponding to each adjacent version.

[0135] For example, if version 2.3.0 has a confirmed vulnerability risk, version 2.3.2 does not have a confirmed vulnerability risk, version 2.2.9 has a confirmed vulnerability risk, version 2.4.0 does not have a confirmed vulnerability risk, version 1.9.9 does not have a confirmed vulnerability risk, and version 3.0.0 does not have a confirmed vulnerability risk, then the probability of the vulnerability risk existing in the target version is 1×40%+0×40%+1×25%+0×25%+0×10%+0×10%=0.65.

[0136] S403. When the probability of a vulnerability risk is greater than or equal to a preset probability threshold, the vulnerability risk assessment result is that there is a suspected vulnerability risk.

[0137] In this embodiment, for example, if the preset probability threshold is 60%, and 0.65 > 0.6, then the vulnerability risk assessment result of the target version is that there is a suspected vulnerability risk.

[0138] When the probability of a vulnerability exists is less than a preset probability threshold, the vulnerability risk assessment result is that there is no vulnerability risk, and the target version is marked as a secure version.

[0139] S404. When the vulnerability risk assessment result indicates that there is a suspected vulnerability risk, the target version is reviewed to obtain the review result.

[0140] In this embodiment, when the vulnerability risk assessment result of the target version is detected as having a suspected vulnerability risk, the target version is reviewed to obtain the review result.

[0141] S405. When the verification result indicates that the target version has a vulnerability risk, change the vulnerability risk assessment result of the target version to "confirmed vulnerability risk".

[0142] In this embodiment, if the review result indicates that the target version has a vulnerability risk, the vulnerability risk judgment result of the target version is changed to have a confirmed vulnerability risk.

[0143] By using the vulnerability risk assessment results of each adjacent version and the preset weights corresponding to each adjacent version, the vulnerability risk of the target version is indirectly and probabilistically estimated. In the absence of direct vulnerability information or public POCs for this version, early warning and speculative judgment of vulnerability risk can be achieved, providing a decision-making basis for proactive defense that precedes the confirmation of explicit vulnerabilities.

[0144] Figure 6 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 5 The vulnerability detection method provided in this embodiment, when the vulnerability risk assessment result of the target version is that a confirmed vulnerability risk exists, and the remediation result is that no remediation has been performed, also includes the following steps:

[0145] S501. Obtain the list of candidate upgrade versions and the vulnerability risk assessment results for each candidate upgrade version.

[0146] In this embodiment, the candidate upgrade version list is a list composed of various candidate upgrade versions. Optionally, the minimum version that fixes the vulnerability can be obtained from the target vulnerability data list as the candidate upgrade version, or the latest stable version number from the official source can be selected as the candidate upgrade version. No specific restrictions are imposed here.

[0147] The method for obtaining the vulnerability risk assessment results of each candidate upgrade version is similar to the method for obtaining the vulnerability risk assessment results of the target version, and will not be repeated here.

[0148] S502. Based on the vulnerability risk assessment results of each candidate upgrade version, a screening process is performed to obtain each candidate upgrade version that does not have a confirmed vulnerability risk.

[0149] In this embodiment, versions with confirmed vulnerability risks are removed from each candidate upgrade version to obtain candidate upgrade versions without confirmed vulnerability risks.

[0150] S503. Obtain compatibility data between the target version and each candidate upgrade version that does not have confirmed vulnerability risks.

[0151] S504. Obtain upgrade cost data for each candidate upgrade version that does not have confirmed vulnerability risks.

[0152] In this embodiment, compatibility data and upgrade cost data of each candidate upgrade version that does not have confirmed vulnerability risks are obtained.

[0153] S505. Based on the compatibility data and upgrade cost data, obtain the target upgrade version and upgrade and fix the target version.

[0154] In this embodiment, S501-S505 are executed by the future repair scheme prediction module.

[0155] An automated closed loop is established from vulnerability detection to remediation response. When the vulnerability risk assessment result of the target version is confirmed to be present and the remediation result is that no remediation has been performed, a secure target upgrade version is immediately obtained, which greatly shortens the vulnerability exposure window and effectively reduces the risk of being exploited by attacks.

[0156] Figure 7 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 6 The vulnerability detection method provided in this embodiment, step S505, which obtains the target upgrade version based on various compatibility data and upgrade cost data, includes the following steps:

[0157] S601. Perform weighted summation on each compatibility data and each upgrade cost data to obtain the weighted score of each candidate upgrade version that does not have a confirmed vulnerability risk.

[0158] In this embodiment, for example, the candidate upgrade versions without confirmed vulnerability risks are version A, version B, and version C. Version A has a compatibility score of 85 and an upgrade cost score of 75; version B has a compatibility score of 70 and an upgrade cost score of 60; version C has a compatibility score of 50 and an upgrade cost score of 40. The weight corresponding to the compatibility score is 0.6, and the weight corresponding to the upgrade cost score is 0.4. Therefore, the weighted score for version A is 85 × 0.6 + 75 × 0.4 = 81, the weighted score for version B is 70 × 0.6 + 60 × 0.4 = 66, and the weighted score for version C is 50 × 0.6 + 40 × 0.4 = 46.

[0159] S602. Obtain the target upgrade version based on the weighted scores of each candidate upgrade version that does not have a confirmed vulnerability risk.

[0160] In this embodiment, among versions A, B, and C, version A has the highest weighted score. Therefore, version A is selected as the target upgrade version to upgrade the target version.

[0161] By comprehensively analyzing the feasibility and implementation cost of the target upgrade version through quantitative methods, and ensuring security repair, we can guide the selection of the target upgrade version with the best compatibility and the lowest upgrade cost. This will maximize the protection of business continuity and system stability while patching vulnerabilities, and achieve a balance between security hardening and smooth transition.

[0162] Optionally, the optimal remediation solution can be calculated by simultaneously predicting the version after vulnerability patching of the target version and whether other vulnerabilities are involved after patching.

[0163] The vulnerability scanning system employs a distributed key query mechanism for its decryption process. First, the scanning system obtains the encrypted version string from the encryption end and then sends an authenticated key request to the key management service. This process uses the ECDH key exchange protocol to ensure secure transmission. After obtaining a valid decryption key, the scanning system executes the decryption steps in reverse order: first, it restores the character replacement and obfuscation processes; then, it verifies the integrity of the hash digest value; and finally, it uses the decryption key to obtain the target format version information. In the rule matching phase, the system uses an intelligent deduction algorithm based on semantic version specifications. This algorithm not only checks the current exact version but also analyzes potential vulnerabilities in adjacent versions. For example, when version 9.5.1 is detected, it automatically checks all known vulnerabilities in the range of 9.5.0 to 9.5.4 and determines the vulnerability remediation status based on the patch date, providing the optimal remediation suggestion to ensure a one-time fix and avoiding the need for multiple cascading fixes after fixing the currently discovered vulnerability. The fuzzy algorithm used in the matching process can handle various variations of version numbers, such as development versions and release candidate versions.

[0164] Figure 8 A flowchart illustrating a vulnerability detection method provided in this application embodiment. Figure 7 The vulnerability detection method provided in this embodiment is applied to the encryption end and includes the following steps:

[0165] S701. Obtain the original version information and preprocess it to obtain the target format version information.

[0166] In this embodiment, the encryption end includes a middleware system, an encrypted version release module, and an encryption processing engine. After obtaining the original version information, the middleware system sends it to the encrypted version release module. The encrypted version release module preprocesses the original version information, converting the "major version number.minor version number.patch number" format into a specific encoding format, i.e., the target format version information. For example, "9.5.1" is converted to a "9|5|1" separator. Then, the encrypted version release module sends the target format version information to the encryption processing engine, which performs triple encryption on the target format version information.

[0167] S702. Obtain the encryption key and encrypt the target format version information according to the encryption key to obtain the encrypted ciphertext.

[0168] In this embodiment, optionally, the first layer uses the AES-256 algorithm for basic encryption. The encryption processing engine obtains the encryption key through the dynamic key management module, that is, it uses the periodically rotated encryption key to encrypt the target format version information to obtain encrypted ciphertext.

[0169] S703. Obtain the sending timestamp information, and concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain the first hash digest value.

[0170] In this embodiment, optionally, the second layer applies the SHA3-512 hash algorithm to generate a fixed-length hash digest value. The encryption processing engine obtains the sending timestamp information and concatenates the encrypted ciphertext and the sending timestamp information to obtain a first concatenated version string; then, the encryption processing engine performs hash processing on the first concatenated version string to obtain a first hash digest value.

[0171] S704. Perform preset character replacement processing on the first hash digest value to obtain the replaced version string.

[0172] In this embodiment, the third layer implements custom character replacement rules, such as replacing the hexadecimal character 'af' with a specific Unicode symbol. The encryption processing engine performs preset character replacement processing on the first hash digest value to obtain the replaced version string.

[0173] S705. Obfuscate the replacement version string to obtain the obfuscated feature string.

[0174] In this embodiment, the encryption processing engine performs version feature obfuscation processing on the replacement version string, such as inserting random interference characters to obtain an obfuscated feature string.

[0175] S706. The encrypted ciphertext, sending timestamp information, and obfuscation feature string are integrated and processed according to the preset format to obtain the encrypted version string, and the encrypted version string is sent to the vulnerability scanning terminal.

[0176] In this embodiment, the encryption processing engine integrates the encrypted ciphertext, sending timestamp information, and obfuscation feature string according to a preset format to obtain an unreadable encrypted version string, which is then sent to the vulnerability scanning terminal. Optionally, one or more characters that do not appear in the data field can be used as delimiters to concatenate the encrypted ciphertext, sending timestamp information, and obfuscation feature string; no specific restrictions are placed on the specific method of integration processing here.

[0177] The triple encryption process renders the final encrypted version string completely unreadable, while retaining all the relevant characteristics of the original version information. This version information encryption protection mechanism allows the encryption end to securely expose version characteristics without revealing specific information, thus enhancing data security.

[0178] The encrypted version release module processes the original version information to obtain the target format version information. This target format version information undergoes three layers of encryption to generate an encrypted version string. During the encryption process, the dynamic key management module is responsible for key generation and distribution, timestamp binding ensures information timeliness, and custom character replacement achieves feature obfuscation.

[0179] In the above embodiments, the key service is treated as an independent module, providing dynamic key support for the process of obtaining encryption and decryption keys, ensuring transmission security. The vulnerability scanning end and the encryption end obtain the decryption and encryption keys using the ECDH protocol.

[0180] The final vulnerability detection report includes: the vulnerability risk assessment result for the target version, the remediation result, and the target upgrade version.

[0181] During the transmission of the encrypted version string, access is provided through a dedicated Application Programming Interface (API). The API adopts a request-response model but incorporates multiple security measures. The requesting party needs to provide an access token containing a timestamp. The response content not only includes the encrypted version string but also attaches a feature code indicating the current patch status. For example, a complete response might include the encrypted version string and a hash value of the last patch date. All this data is formatted to ensure consistent parsing logic across different middleware products.

[0182] The dynamic key management system ensures that even if some keys are leaked, the security of the entire system will not be compromised through key segmentation storage and temporary session mechanisms.

[0183] The core of this application's embodiments lies in establishing a complete encrypted version identification system, and realizing non-POC-dependent vulnerability detection through a special version information processing mechanism.

[0184] This application's embodiments establish a mapping mechanism between encrypted version strings and a vulnerability rule base, enabling vulnerability scanners to identify potential vulnerabilities without relying on proof-of-concept (POC). Specifically, the encryption end encrypts the version information and provides it through a dedicated interface. The vulnerability scanner then matches this information using a pre-built version-vulnerability association rule base, making early detection of undisclosed vulnerabilities possible and improving the timeliness of vulnerability discovery and remediation.

[0185] A dynamic encryption strategy is adopted. The version number is Base64+ROT13 encoded and then combined with the timestamp to generate a SHA3-512 hash value. This makes the transmitted content impossible to reverse-engineer, ensuring that the vulnerability scanner can identify the accurate version number while also ensuring the security of the version number information.

[0186] By introducing an improved Levenshtein fuzzy algorithm and establishing a version number Markov chain model, the possible intermediate versions can be predicted through the known version sequence. The vulnerability detection method provided in this application can significantly improve the accuracy of vulnerability detection, especially the ability to quickly identify vulnerabilities in unreleased Proof-of-Concept (POC).

[0187] Regarding information security, this application employs a dynamic encryption mechanism to ensure that version information remains encrypted throughout transmission and storage. By combining timestamp binding and key rotation strategies, even if the encrypted data is intercepted, the true version number cannot be deduced, effectively blocking attackers from using version information for targeted attacks. Simultaneously, the fuzzy matching algorithm for the encrypted version number ensures that the scanning process does not require reconstructing the complete version information, further reducing the risk of sensitive data leakage.

[0188] Regarding detection coverage, the rule base architecture provided in this application, by establishing version range mapping and patch status marking, can identify all potential vulnerabilities associated with version numbers, including vulnerabilities for which Proof of Concept (POC) has not yet been disclosed and vulnerabilities discovered internally by vendors, significantly improving detection coverage. Rule base matching employs an improved Levenshtein fuzzy algorithm, establishing a version number Markov chain model. It predicts possible intermediate versions based on the acquired version sequence, and anticipates whether the version after the current vulnerability is patched and whether the patch involves other vulnerabilities. Through comprehensive analysis, it calculates the optimal patching solution, resolving the problem of repeated patching.

[0189] In terms of system compatibility, the embodiments of this application, through standardized encryption interfaces and a unified parsing engine, can be adapted to middleware products from different vendors. The key negotiation protocol supports multiple encryption algorithms, ensuring that the solution can be implemented in various deployment environments. This design significantly reduces the deployment complexity in hybrid environments, enabling security policies to quickly cover all business systems.

[0190] In terms of operation and maintenance costs, the automated rule base update mechanism in this application embodiment can reduce the workload of operation and maintenance. Extended functions such as dynamic key management and version sequence prediction further reduce the need for manual intervention, enabling the system to have self-evolving security protection capabilities. This design is particularly suitable for rapidly changing service architectures in cloud-native environments, providing a matching security guarantee mechanism for continuous delivery models.

[0191] Figure 9 A schematic diagram of the structure of a vulnerability detection device provided in this application embodiment. Figure 1 .like Figure 9 As shown, in this embodiment, the vulnerability detection device is applied to the vulnerability scanning end. The vulnerability detection device includes:

[0192] The splitting module 801 is used to receive the encrypted version string and split the encrypted version string according to the preset format to obtain the encrypted ciphertext, the sending timestamp information, and the obfuscation feature string.

[0193] The verification module 802 is used to perform data verification processing based on the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string, obtain the verification result, and obtain the decryption key when the verification result is detected as passing.

[0194] The decryption module 803 is used to decrypt the encrypted ciphertext according to the decryption key to obtain the target format version information.

[0195] Matching module 804 is used to extract the software name, major version number, minor version number, and patch version number from the target format version information, and match the target vulnerability data list from the pre-stored rule base according to the software name; wherein, the target vulnerability data list includes the scope of vulnerability impact and the target version for fixing the vulnerability.

[0196] The result acquisition module 805 is used to obtain vulnerability risk assessment results and remediation results based on the major version number, minor version number, patch version number, vulnerability impact scope, and target version for vulnerability remediation.

[0197] The report acquisition module 806 is used to obtain a vulnerability detection report based on the vulnerability risk assessment results and remediation results.

[0198] The vulnerability detection device provided in this embodiment can execute... Figure 2 The technical solution of the vulnerability detection method embodiment shown herein, its implementation principle and technical effect are similar to Figure 2 The vulnerability detection methods shown are similar in implementation, and will not be described in detail here.

[0199] Meanwhile, the vulnerability detection device provided by the present invention is a further refinement of the vulnerability detection device provided in the previous embodiment.

[0200] Optionally, in this embodiment, the verification module 802 is further configured to:

[0201] The obfuscated feature string is restored to obtain a first hash digest value; the received timestamp information is obtained, and when the absolute difference between the received timestamp information and the sent timestamp information is less than or equal to a preset time threshold, the encrypted ciphertext and the sent timestamp information are concatenated and hashed to obtain a second hash digest value; the verification result is obtained based on the first hash digest value and the second hash digest value.

[0202] Optionally, in this embodiment, the result acquisition module 805 is further configured to:

[0203] The vulnerability risk assessment results are as follows: 1) Determine if the target version exists within the scope of the vulnerability based on the major version number, minor version number, and patch version number. If it exists, the vulnerability risk assessment result is "existence confirmed vulnerability risk"; if it does not exist, the vulnerability risk assessment result is "non-existence confirmed vulnerability risk". 2) Determine if the target version is less than the version targeted for vulnerability repair based on the major version number, minor version number, and patch version number. If it is, the repair result is "not repaired"; if not, the repair result is "repaired".

[0204] Optionally, this embodiment further includes a probability acquisition module, which is used for:

[0205] When the vulnerability risk assessment result indicates that there is no confirmed vulnerability risk, obtain the vulnerability risk assessment results of each adjacent version of the target version; based on the vulnerability risk assessment results of each adjacent version and the preset weights corresponding to each adjacent version, obtain the probability of the vulnerability risk existing in the target version; when the probability of the vulnerability risk existing is greater than or equal to the preset probability threshold, the vulnerability risk assessment result is that there is a suspected vulnerability risk; when the vulnerability risk assessment result indicates that there is a suspected vulnerability risk, the target version is reviewed to obtain the review result; when the review result indicates that the target version has a vulnerability risk, the vulnerability risk assessment result of the target version is changed to that of a confirmed vulnerability risk.

[0206] Optionally, this embodiment also includes an upgrade module, which is used for:

[0207] When the vulnerability risk assessment result of the target version indicates the existence of a confirmed vulnerability risk, and the remediation result is that no remediation has been performed, a list of candidate upgrade versions and the vulnerability risk assessment result of each candidate upgrade version are obtained. Based on the vulnerability risk assessment results of each candidate upgrade version, a filtering process is performed to obtain candidate upgrade versions without confirmed vulnerability risks. Compatibility data between each candidate upgrade version without confirmed vulnerability risks and the target version is obtained. Upgrade cost data for each candidate upgrade version without confirmed vulnerability risks is obtained. Based on the compatibility data and upgrade cost data, the target upgrade version is obtained, and the target version is upgraded and remediated.

[0208] Optionally, in this embodiment, the upgrade module is also used for:

[0209] The compatibility data and upgrade cost data are weighted and summed to obtain the weighted score of each candidate upgrade version that has no confirmed vulnerability risk; the target upgrade version is obtained based on the weighted score of each candidate upgrade version that has no confirmed vulnerability risk.

[0210] Figure 10A schematic diagram of the structure of a vulnerability detection device provided in this application embodiment. Figure 2 .like Figure 10 As shown, in this embodiment, the vulnerability detection device is applied to the encryption end. The vulnerability detection device includes:

[0211] The preprocessing module 901 is used to obtain the original version information and preprocess the original version information to obtain the target format version information.

[0212] The encryption module 902 is used to obtain the encryption key and encrypt the target format version information according to the encryption key to obtain encrypted ciphertext.

[0213] The hash processing module 903 is used to obtain the sending timestamp information, and to concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain the first hash digest value.

[0214] Replacement module 904 is used to perform preset character replacement processing on the first hash digest value to obtain the replacement version string.

[0215] The obfuscation processing module 905 is used to obfuscate the replacement version string to obtain the obfuscated feature string.

[0216] The integration module 906 is used to integrate the encrypted ciphertext, sending timestamp information and obfuscation feature string according to a preset format to obtain an encrypted version string, and then send the encrypted version string to the vulnerability scanning terminal.

[0217] The vulnerability detection device provided in this embodiment can execute... Figure 8 The technical solution of the vulnerability detection method embodiment shown herein, its implementation principle and technical effect are similar to Figure 8 The vulnerability detection methods shown are similar in implementation, and will not be described in detail here.

[0218] Figure 11 This is a schematic diagram of an electronic device provided as an embodiment of this application. The electronic device is intended for various electronic devices capable of performing vulnerability detection methods, such as microcomputers, microcontrollers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0219] like Figure 11 As shown, the electronic device includes at least one processor 910 and a memory 920. The electronic device also includes a communication component 930. The processor 910, memory 920, and communication component 930 are connected via a bus 940.

[0220] In the specific implementation process, at least one processor 910 executes computer execution instructions stored in memory 920, causing at least one processor 910 to execute the vulnerability detection method executed on the electronic device side as described above.

[0221] The specific implementation process of processor 910 can be found in the above-described vulnerability detection method embodiment, which has a similar implementation principle and technical effect, and will not be repeated here.

[0222] In the above embodiments, it should be understood that the processor 910 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor 910 can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0223] The memory 920 may include high-speed RAM memory, and may also include non-volatile memory NVM, such as at least one disk storage.

[0224] Bus 940 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 940 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 940 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0225] The above description addresses the functions implemented by electronic devices and main control devices, and introduces the solutions provided in the embodiments of this application. It is understood that, in order to achieve the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments disclosed in this application, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of this application.

[0226] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described vulnerability detection method.

[0227] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0228] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. The readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0229] The memory 920 is the non-transitory computer-readable storage medium provided by this invention. The non-transitory computer-readable storage medium of this invention stores computer instructions that cause a computer to execute the vulnerability detection method provided by this invention.

[0230] The memory 920, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the vulnerability detection method in the embodiments of this application. The processor 910 executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory 920, thereby implementing the vulnerability detection method in the above method embodiments.

[0231] In addition, this embodiment also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the vulnerability detection method of the above embodiment.

[0232] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0233] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0234] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0235] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0236] When the integrated unit / module is implemented in hardware, the hardware can be digital or analog circuitry. The physical implementation of the hardware structure includes, but is not limited to, transistors and memristors. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, or ASIC. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random-Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), and Hybrid Memory Cube (HMC).

[0237] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0238] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0239] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0240] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A vulnerability detection method characterized by, The method is applied to the vulnerability scanning end, including: Receive the encrypted version string, and split the encrypted version string according to a preset format to obtain the encrypted ciphertext, the sending timestamp information, and the obfuscation feature string; Data verification is performed based on the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string to obtain a verification result. When the verification result is detected as passing, the decryption key is obtained. The encrypted ciphertext is decrypted using the decryption key to obtain the target format version information; The software name, major version number, minor version number, and patch version number are extracted from the target format version information, and the target vulnerability data list is matched from the pre-stored rule base according to the software name; wherein, the target vulnerability data list includes the scope of vulnerability impact and the target version for fixing the vulnerability; The vulnerability risk assessment result and the remediation result are obtained based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for patching the vulnerability; A vulnerability detection report is obtained based on the vulnerability risk assessment results and the remediation results.

2. The method according to claim 1, characterized in that, The step of performing data verification processing based on the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string to obtain a verification result includes: The obfuscated feature string is restored to obtain the first hash digest value; Obtain the received timestamp information, and when the absolute difference between the received timestamp information and the sent timestamp information is less than or equal to a preset time threshold, concatenate and hash the encrypted ciphertext and the sent timestamp information to obtain a second hash digest value. The verification result is obtained based on the first hash digest value and the second hash digest value.

3. The method according to claim 1, characterized in that, The process of obtaining vulnerability risk assessment and remediation results based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for patching the vulnerability includes: Based on the major version number, the minor version number, and the patch version number, determine whether the target version is within the scope of the vulnerability's impact. If it is, the vulnerability risk assessment result is "existence confirms vulnerability risk"; if it is not, the vulnerability risk assessment result is "no existence confirms vulnerability risk". Based on the major version number, the minor version number, and the patch version number, determine whether the target version is lower than the target version for fixing the vulnerability. If yes, the repair result is that no repair was performed; otherwise, the repair result is that the vulnerability was fixed.

4. The method according to claim 3, characterized in that, When the vulnerability risk assessment result indicates that there is no confirmed vulnerability risk, the following is also included: Obtain each adjacent version of the target version, and the vulnerability risk assessment results of each adjacent version; Based on the vulnerability risk assessment results of each adjacent version and the preset weights corresponding to each adjacent version, the probability of the existence of vulnerability risk in the target version is obtained. When the probability of the vulnerability risk is greater than or equal to a preset probability threshold, the vulnerability risk assessment result is that there is a suspected vulnerability risk. When the vulnerability risk assessment result indicates the existence of a suspected vulnerability risk, the target version is reviewed to obtain the review result; If the verification result indicates that the target version has a vulnerability risk, the vulnerability risk assessment result of the target version is changed to "confirmed vulnerability risk".

5. The method according to claim 4, characterized in that, When the vulnerability risk assessment result of the target version indicates the existence of a confirmed vulnerability risk, and the remediation result indicates that no remediation has been performed, the method further includes: Obtain a list of candidate upgrade versions and the vulnerability risk assessment results for each candidate upgrade version; Based on the vulnerability risk assessment results of each candidate upgrade version, a selection process is performed to obtain each candidate upgrade version that does not have any confirmed vulnerability risks. Obtain compatibility data between each candidate upgrade version that does not have confirmed vulnerability risks and the target version; Obtain upgrade cost data for each candidate upgrade version that does not have confirmed vulnerability risks; The target upgrade version is obtained based on various compatibility data and upgrade cost data, and the target version is then upgraded and repaired.

6. The method according to claim 5, characterized in that, The process of obtaining the target upgrade version based on various compatibility data and upgrade cost data includes: The compatibility data and upgrade cost data are weighted and summed to obtain the weighted scores of each candidate upgrade version that does not have confirmed vulnerability risks. The target upgrade version is obtained by weighting the scores of each candidate upgrade version that does not have a confirmed vulnerability risk.

7. A vulnerability detection method, characterized in that, The method is applied to the encryption end, including: Obtain the original version information and preprocess the original version information to obtain the target format version information; Obtain the encryption key, and encrypt the target format version information according to the encryption key to obtain encrypted ciphertext; Obtain the sending timestamp information, and concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain a first hash digest value; The first hash digest value is subjected to a preset character replacement process to obtain a replaced version string; The replacement version string is obfuscated to obtain an obfuscated feature string; The encrypted ciphertext, the sending timestamp information, and the obfuscated feature string are integrated according to a preset format to obtain an encrypted version string, which is then sent to the vulnerability scanning terminal.

8. A vulnerability detection device, characterized in that, The device is used in a vulnerability scanning terminal and includes: The splitting module is used to receive the encrypted version string and split the encrypted version string according to a preset format to obtain encrypted ciphertext, sending timestamp information, and obfuscation feature string; The verification module is used to perform data verification processing based on the encrypted ciphertext, the sending timestamp information and the obfuscated feature string, obtain the verification result, and obtain the decryption key when the verification result is detected as passing. The decryption module is used to decrypt the encrypted ciphertext according to the decryption key to obtain the target format version information; The matching module is used to extract the software name, major version number, minor version number, and patch version number from the target format version information, and match the target vulnerability data list from the pre-stored rule base according to the software name; wherein, the target vulnerability data list includes the scope of vulnerability impact and the target version for fixing the vulnerability; The result acquisition module is used to obtain vulnerability risk assessment results and remediation results based on the major version number, the minor version number, the patch version number, the vulnerability impact scope, and the target version for remediation. The report acquisition module is used to obtain a vulnerability detection report based on the vulnerability risk assessment results and the remediation results.

9. A vulnerability detection device, characterized in that, The device is used at the encryption end and includes: The preprocessing module is used to obtain the original version information and preprocess the original version information to obtain the target format version information; An encryption module is used to obtain an encryption key and encrypt the target format version information according to the encryption key to obtain encrypted ciphertext; The hash processing module is used to obtain the sending timestamp information, and to concatenate and hash the encrypted ciphertext and the sending timestamp information to obtain a first hash digest value; The replacement module is used to perform preset character replacement processing on the first hash digest value to obtain a replacement version string; The obfuscation processing module is used to obfuscate the replacement version string to obtain an obfuscated feature string; The integration module is used to integrate the encrypted ciphertext, the sending timestamp information, and the obfuscated feature string according to a preset format to obtain an encrypted version string, and then send the encrypted version string to the vulnerability scanning terminal.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the vulnerability detection method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the vulnerability detection method as described in any one of claims 1 to 7.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it is used to implement the vulnerability detection method as described in any one of claims 1 to 7.

Images