A double-judgment-based asset vulnerability matching method and system

Abstract

The application relates to the technical field of network security, in particular to an asset vulnerability matching method and system based on double arbitration. The method can retrieve candidate vulnerabilities through correlation score by obtaining a vulnerability list containing affected assets and impact ranges, output a three-value first arbitration result through a rule arbitrator, trigger a large model supplementary arbitration only when the result is unknown and the correlation meets the standard, and complete the matching by merging the results. The method replaces full matching with a double arbitration solution, effectively solving the computing power and efficiency bottleneck of massive data matching, balancing efficiency and comprehensiveness, and avoiding simple rule false negatives. Because of the establishment of double arbitrators, assets can be determined as not affected only when the arbitration is not applicable, eliminating the defect that no hit means health and reducing the risk of false negatives. The large model is used to supplement the processing of ambiguous scenarios that cannot be clearly defined by the rules, reducing misjudgment and artificial costs. In addition, the large model trigger condition can be reasonably set to avoid waste of computing power.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, specifically to an asset vulnerability matching method and system based on dual-judgment. Background Technology

[0002] In the field of cybersecurity technology, asset vulnerability matching is a core step in identifying asset security risks, carrying out vulnerability remediation, and risk prevention. The accuracy and efficiency of this matching directly determine the effectiveness of asset security management. In related technologies, simple rules are used to match vulnerabilities with assets; a match indicates the asset is affected by a vulnerability, while a match indicates the asset is healthy. However, with the continuous expansion of network asset scale and the massive growth of vulnerability intelligence (such as CVE vulnerabilities), asset-vulnerability matching scenarios face numerous challenges, including diverse asset types, inconsistent descriptions of vulnerability impact scope, and limited computing power for matching massive amounts of data. Existing asset vulnerability matching technologies are no longer sufficient to meet the needs of actual security management, revealing many obvious shortcomings.

[0003] First, matching massive amounts of data presents bottlenecks in computing power and efficiency. Matching with full-scale complex rules or large language models consumes too much computing power, while simple rule-based strong matching is prone to missed detections due to non-standard descriptions of asset and vulnerability information. Second, the "no match means healthy" rule can lead to hidden missed detection risks that cannot be avoided. Third, the ability to adjudicate ambiguous scenarios such as unresolvable vulnerability impact scope and missing fields is insufficient. Traditional rules are prone to misjudgment or require a lot of manual intervention, which significantly increases operation and maintenance costs. Summary of the Invention

[0004] In view of this, this application discloses an asset vulnerability matching method based on dual adjudication. The method includes: obtaining an asset to be matched and a vulnerability list; the vulnerability list includes multiple vulnerabilities, each vulnerability including the affected assets and the scope of its impact on the affected assets; retrieving candidate vulnerabilities related to the asset to be matched from the vulnerability list; the candidate vulnerabilities are vulnerabilities whose relevance score to the asset to be matched reaches a first preset threshold; the relevance score indicates the probability that the asset to be matched is the affected asset; when at least one candidate vulnerability is retrieved, a first adjudication result is obtained based on a rule adjudicator to determine whether the asset to be matched is subject to the scope of the candidate vulnerability's impact; the first adjudication result includes one of the following three: applicable, not applicable, unknown; when the first adjudication result is unknown and the relevance score reaches a second preset threshold, a second adjudication result and reasoning are obtained based on a large model adjudicator to determine whether the asset to be matched is subject to the scope of the candidate vulnerability's impact; the second adjudication result includes one of the following three: applicable, not applicable, unknown; and merging the first adjudication result and the second adjudication result.

[0005] In some embodiments, the method further includes standardizing the asset to be matched; the standardization of the asset to be matched includes: normalizing the component name of the asset to be matched to obtain a normalized name; and performing at least one of the following processing on the version number of the asset to be matched to generate at least one candidate version number: retaining the original string; removing irrelevant characters; and extracting the core numerical version.

[0006] In some embodiments, retrieving candidate vulnerabilities related to the asset to be matched from the vulnerability list includes: obtaining a search key of a preset type for the asset to be matched; selecting the top N vulnerabilities in the vulnerability list based on the search key and using a preset search strategy; wherein N is greater than or equal to 0; if the highest relevance score among the top N vulnerabilities is lower than a first preset threshold, determining that no candidate vulnerability has been matched; if the highest relevance score among the top N vulnerabilities reaches the first preset threshold, determining the vulnerabilities among the top N vulnerabilities whose relevance scores reach the first preset threshold as candidate vulnerabilities.

[0007] In some embodiments, determining vulnerabilities whose relevance scores reach the first preset threshold among the top N first vulnerabilities as candidate vulnerabilities includes: determining whether the number of vulnerabilities whose relevance scores reach the first preset threshold among the top N first vulnerabilities reaches a third preset threshold; if the number of vulnerabilities reaches the third preset threshold, determining the vulnerabilities whose relevance scores reach the first preset threshold among the top N first vulnerabilities as candidate vulnerabilities; if the number of vulnerabilities does not reach the third preset threshold, determining the vulnerabilities whose relevance scores reach the first preset threshold among the top N first vulnerabilities as candidate vulnerabilities, and selecting at least some vulnerabilities from the remaining vulnerabilities as candidate vulnerabilities to make up the difference.

[0008] In some embodiments, obtaining a first ruling result regarding whether the target asset is subject to the scope of influence of the candidate vulnerability based on a rule arbitrator includes: obtaining the candidate version number and platform of the target asset, and the scope of influence of the candidate vulnerability; the scope of influence includes the version range and platform range of the affected asset; in response to the target asset's candidate version number falling within the version range and the target asset's platform falling within the platform range, determining the first ruling result as applicable, the applicable indicating that the target asset is affected by the candidate vulnerability; in response to the target asset's candidate version number not falling within the version range and / or the target asset's platform not falling within the platform range, determining the first ruling result as inapplicable, the inapplicable indicating that the target asset is not affected by the candidate vulnerability; in response to the inability to obtain any of the following information, determining the first ruling result as unknown, the unknown indicating that the rule arbitrator cannot output an accurate ruling result: the target asset's candidate version number; the target asset's platform; the version range; the platform range.

[0009] In some embodiments, obtaining a second ruling result and reason regarding whether the target asset is subject to the influence of the candidate vulnerability based on the large model arbitrator includes: inputting a first prompt word template and generating a first prompt word based on the asset information of the target asset and the vulnerability description of the target candidate vulnerability whose first ruling result is unknown and whose correlation score with the target asset reaches a second preset threshold; the first prompt word is used to organize the asset information and the vulnerability description into a standard question and request the large model arbitrator to output a second ruling result and reason; the first prompt word is sent to the large model arbitrator to obtain the second ruling result and reason.

[0010] In some embodiments, the first prompt word template includes fixed content that does not need to be filled in and non-fixed content that needs to be filled in; the fixed content includes a decision result and reason for whether the asset to be matched is applicable to the candidate vulnerability, output in a preset format based on the asset information and the vulnerability description; the non-fixed content includes the asset information and the vulnerability description that need to be filled in; the process of inputting the asset information of the asset to be matched and the vulnerability description of the target candidate vulnerability whose first decision result is unknown and whose correlation score with the asset to be matched reaches a second preset threshold into the first prompt word template to generate the first prompt word includes: writing the asset information at the asset information position in the non-fixed content; and writing the vulnerability description at the vulnerability description position in the non-fixed content.

[0011] In some embodiments, after determining that the first ruling result is inapplicable, the method further includes: in response to the asset level of the asset to be matched being important, or the candidate vulnerability being high-risk, based on the asset information of the asset to be matched, the vulnerability description of the candidate vulnerability, the scope of impact of the candidate vulnerability, and the first ruling result, inputting a second prompt word template to generate a second prompt word; the second prompt word is used to verify whether the first ruling result is correct, and in the case of an incorrect result, to obtain a third ruling result, and to identify the missing description in the vulnerability description that causes the first ruling result to be incorrect, and to generate supplementary rules that the rule adjudicator can recognize based on the missing description; sending the second prompt word to a large model to obtain a verification result, and in the case of an incorrect verification result, obtaining a third ruling result and supplementary rules.

[0012] In some embodiments, the method further includes: determining the asset to be matched as a healthy asset in response to the verification result being correct; outputting a third adjudication result in response to the verification result being incorrect, and updating the scope of influence of the candidate vulnerability in the rule adjudicator based on the supplementary rule.

[0013] This application also proposes a dual-adjudication-based asset vulnerability matching system. The system includes: an acquisition module for acquiring a list of assets to be matched and a vulnerability list; the vulnerability list includes multiple vulnerabilities, each vulnerability including the affected assets and the scope of its impact on the affected assets; a retrieval module for retrieving candidate vulnerabilities related to the assets to be matched from the vulnerability list; the candidate vulnerabilities are vulnerabilities whose relevance score to the assets to be matched reaches a first preset threshold; the relevance score indicates the probability that the assets to be matched are the affected assets; a rule adjudicator module, when at least one candidate vulnerability is retrieved, obtaining a first adjudication result based on the rule adjudicator regarding whether the assets to be matched are subject to the scope of the candidate vulnerability's impact; the first adjudication result includes one of the following three: applicable, not applicable, unknown; a large-model adjudicator module, when the first adjudication result is unknown and the relevance score reaches a second preset threshold, obtaining a second adjudication result and reasoning regarding whether the assets to be matched are subject to the scope of the candidate vulnerability's impact; the second adjudication result includes one of the following three: applicable, not applicable, unknown; and a merging module for merging the first adjudication result and the second adjudication result.

[0014] In the aforementioned embodiment, the solution can obtain the asset to be matched and a list of vulnerabilities including the affected assets and the scope of impact, retrieve candidate vulnerabilities by relevance score, and then the rule adjudicator outputs a three-value first adjudication result of applicable, inapplicable, or unknown. Only when the first adjudication result is unknown and the relevance score reaches a second preset threshold is the large model adjudicator triggered to supplement the adjudication, and finally the two types of adjudication results are merged to achieve asset vulnerability matching. First, by replacing full matching with a dual-adjudication scheme using a rule-based adjudicator and a large-scale model adjudicator, the computational power and efficiency bottleneck of massive data matching is effectively solved, balancing matching efficiency and comprehensiveness, and avoiding false negatives caused by simple rule-based strong matching. Second, because of the dual adjudicator, assets can be deemed unaffected only when the adjudication is deemed inapplicable, eliminating the defect of "no match means healthy" and reducing the risk of false negatives. Third, for ambiguous scenarios where the rule-based adjudicator adjudicates unknown information, the large-scale model adjudicator can be used to handle them, reducing misjudgments and manual maintenance costs. Fourth, the large-scale model adjudicator is triggered to supplement the adjudication only when the first adjudication result is unknown and the relevance score reaches a second preset threshold. Reasonable triggering conditions for the large-scale model are set to avoid the waste of computational power caused by full candidate input. At the same time, the semantic understanding capability of the large-scale model is used to ensure the matching accuracy of complex and ambiguous scenarios, ultimately achieving accurate, comprehensive, and efficient matching of asset vulnerabilities. Attached Figure Description

[0015] The accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below.

[0016] Figure 1 This is a flowchart illustrating an asset vulnerability matching method based on dual adjudication, as shown in an embodiment of this application.

[0017] Figure 2 This is a flowchart illustrating a candidate vulnerability retrieval method as described in this application.

[0018] Figure 3 This is a flowchart illustrating a rule-based adjudication method as described in this application.

[0019] Figure 4 This is a schematic diagram illustrating a method for adjudicating large models, as shown in this application.

[0020] Figure 5 This is a flowchart illustrating a method for verifying the adjudication result, as shown in this application.

[0021] Figure 6 This is a schematic diagram illustrating the structure of an asset vulnerability matching system based on dual adjudication, as shown in this application.

[0022] Figure 7 This is a schematic diagram illustrating the asset matching method process described in this application. Detailed Implementation

[0023] 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 numbers 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 devices and methods consistent with some aspects of this application as detailed in the appended claims.

[0024] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items. It should also be understood that the word “if” as used herein, depending on the context, can be interpreted as “when,” “in response to a determination,” or “when…”.

[0025] In view of the problems existing in related technologies, this application discloses an asset vulnerability matching method based on dual adjudication. This method obtains the asset to be matched and a vulnerability list containing affected assets and their scope of impact. Candidate vulnerabilities are retrieved using a relevance score. A rule-based adjudicator outputs a three-valued first adjudication result. A large-scale model is triggered for supplementary adjudication only when the result is unknown and the relevance meets the standard. The results are then merged to complete the matching. This method replaces full-scale matching with a dual-adjudication scheme, effectively solving the computational and efficiency bottlenecks of matching massive amounts of data, balancing efficiency and comprehensiveness, and avoiding underreporting by simple rules. Because a dual adjudicator is built, assets can be considered unaffected only when the adjudication is inapplicable, eliminating the defect of "healthy even if no match is found," and reducing the risk of underreporting. The large-scale model is used to supplement and handle ambiguous scenarios where rules cannot be clearly defined, reducing misjudgments and manual costs. Furthermore, the triggering conditions of the large-scale model can be reasonably set to avoid wasting computational power, and its semantic understanding capabilities ensure matching accuracy, ultimately achieving accurate, comprehensive, and efficient matching of asset vulnerabilities.

[0026] The following description, in conjunction with the accompanying drawings, illustrates the embodiments. Please refer to the attached figures. Figure 1 , Figure 1 This is a flowchart illustrating an asset vulnerability matching method based on dual adjudication, as shown in an embodiment of this application.

[0027] Figure 1The illustrated dual-adjudication-based asset vulnerability matching method can be applied to electronic devices. These electronic devices can execute the method by incorporating software logic corresponding to the dual-adjudication-based asset vulnerability matching method. The type of electronic device can be a laptop, computer, server, mobile phone, PDA, etc. This application does not specifically limit the type of electronic device. The electronic device can also be a client device or a server device.

[0028] like Figure 1 As shown, the method may include steps S102-S110. Unless otherwise specified, this application does not specifically limit the order in which these steps are performed.

[0029] S102, Obtain the list of assets and vulnerabilities to be matched.

[0030] The assets to be matched refer to network assets that require vulnerability risk assessment, including core information such as asset name, component version, and operating platform. For example, assets to be matched could be servers (Apache component, version 2.4.49, Linux operating platform), mobile terminals (Android system component, version 11), or office software (Office component, version 2019). Assets to be matched can be a single asset or a category of assets from a batch. For example, if vulnerability matching is required for a batch of assets, the assets to be matched in this step could be a specific asset that needs to be assessed, or an asset of the same type with similar attributes.

[0031] The vulnerability list includes multiple vulnerabilities, each comprising the affected assets and the scope of their impact. The vulnerability list is a pre-compiled collection of all vulnerabilities. Each vulnerability may include the affected assets (i.e., the asset types, components, etc. that the vulnerability can affect) and the scope of its impact (i.e., the specific conditions under which the vulnerability affects the affected assets, such as component version range, runtime environment constraints, etc.). Subsequent vulnerability matching can be performed based on this list. For example, the list may include a CVE vulnerability whose affected assets are "Apache HTTP Server versions 2.4.49 and below".

[0032] In some methods, both vulnerabilities and assets can be preprocessed to facilitate subsequent retrieval and identify candidate vulnerabilities related to the asset to be matched. Preprocessing can follow a standardized workflow, processing the content to be retrieved, such as components, versions, and platforms, into a searchable (structured) format and storing it in a database. Subsequent embodiments feature improved preprocessing procedures that produce better results and prevent missed vulnerability detections; these will be described in subsequent embodiments.

[0033] S104, retrieve candidate vulnerabilities related to the asset to be matched from the vulnerability list.

[0034] The candidate vulnerability is a vulnerability whose correlation score with the asset to be matched reaches a first preset threshold; the correlation score indicates the probability that the asset to be matched is the affected asset.

[0035] The relevance score is a quantitative value that can be calculated by a preset algorithm (such as BM25, inverted key search, trigram search, etc.) to indicate the probability that "the asset to be matched is an asset affected by a vulnerability". The value range is usually 0-1. The higher the score, the stronger the relevance.

[0036] For example: the asset to be matched is "Chrome 100.0.4896.75", the affected asset of a certain vulnerability is "Chrome 99.0.4844.84-100.0.4896.75 version", and the calculated relevance score is 0.85; the affected asset of another vulnerability is "Apache component", and the relevance score is 0.12.

[0037] The first preset threshold, a preset relevance score threshold, can be used to define relevant vulnerabilities and irrelevant vulnerabilities. Only vulnerabilities with a relevance score ≥ the threshold are identified as candidate vulnerabilities. The threshold can be adjusted according to actual business needs, for example, it can be 0.5-0.7.

[0038] This step can use a preset relevance scoring algorithm (such as BM25, inverted key search, etc.) to calculate the relevance score between the asset to be matched and each vulnerability in the vulnerability list. This score directly indicates the probability that the asset to be matched belongs to the asset affected by the vulnerability. Only vulnerabilities with a relevance score that reaches the first preset threshold are retained as candidate vulnerabilities, while completely irrelevant vulnerabilities are filtered out, which greatly reduces the processing scope of subsequent adjudication, balances matching efficiency and relevance, and lays the foundation for accurate adjudication in the future.

[0039] Understandably, this step allows for an empty candidate vulnerability list, meaning that the relevance scores of the vulnerabilities in the vulnerability list and the asset to be matched are all below the first preset threshold. This can be interpreted as not hitting the vulnerability list, but the asset to be matched is not considered healthy at this time, because there may be omissions in the vulnerability list.

[0040] S106, if at least one candidate vulnerability is found, a first decision result is obtained based on the rule arbiter to determine whether the asset to be matched is subject to the scope of influence of the candidate vulnerability; the first decision result includes one of the following three: applicable, not applicable, unknown.

[0041] The rule adjudicator can automatically adjudicate candidate vulnerabilities and assets to be matched based on pre-defined standardized adjudication rules (such as version range comparison rules, platform constraint verification rules, etc.), and can output three results: applicable, inapplicable, and unknown. The rule adjudicator uses quantifiable and comparable rules derived from vulnerability descriptions in the vulnerability list. Rules can be extracted from vulnerability descriptions using regular expressions. For example, the version is 1.0-1.5, and the platform is Linux. By determining whether the version or platform of the asset to be matched falls within the rules, an applicable, inapplicable, or unknown adjudication result can be obtained.

[0042] The first ruling result refers to the preliminary ruling conclusion output by the rule-based adjudicator, including applicable, inapplicable, and unknown. This needs to be distinguished from the binary logic in related technologies that only outputs applicable and inapplicable; the purpose is to find ambiguous scenarios and supplement the ruling with a larger model.

[0043] "Applicable" means that the core information (version, platform, etc.) of the asset to be matched clearly falls within the scope of the vulnerability's impact, confirming that the asset is affected by the vulnerability. For example, if the asset to be matched is Chrome 100.0.4896.75, and the scope of a candidate vulnerability is Chrome versions 99.0.4844.84-100.0.4896.75, the rule adjudicator can determine that it is applicable.

[0044] "Not Applicable" means that the core information of the asset to be matched clearly does not fall within the scope of the vulnerability's impact (e.g., version out of range, platform incompatibility), thus determining that the asset is not affected by the vulnerability. For example, if the asset to be matched is Chrome 100.0.4896.75, and the scope of a candidate vulnerability is Chrome versions 98.0.4758.102-99.0.4844.84, the rule adjudicator can determine that it is not applicable.

[0045] "Unknown" refers to ambiguous scenarios where the scope of the vulnerability's impact cannot be resolved (e.g., the version range is vaguely described), or the core fields of the asset to be matched or the vulnerability are missing (e.g., the asset version is not labeled, or the vulnerability platform constraints are not clearly defined), making it impossible for the rule adjudicator to make a clear determination. For example, a candidate vulnerability might be described as "Chrome 100.x and below" (vague description, making it impossible to determine the specific version boundary), and the asset to be matched is Chrome 100.0.4896.75. The rule adjudicator cannot make a clear determination and outputs "Unknown".

[0046] S108, when the first ruling result is unknown and the correlation score reaches the second preset threshold, based on the large model adjudicator, a second ruling result and reason for whether the asset to be matched is applicable to the scope of influence of the candidate vulnerability are obtained; the second ruling result includes one of the following three: applicable, not applicable, unknown.

[0047] The first ruling result is unknown, indicating that the rule-based adjudicator cannot obtain an accurate ruling result for the candidate vulnerability, and a large model is needed to supplement the ruling.

[0048] The second preset threshold, which can be a preset relevance score threshold, is used to define highly relevant unknown vulnerabilities and low-relevance unknown vulnerabilities. It is one of the core conditions for triggering the large model adjudicator. The value can be higher than the first preset threshold (for example, it can be 0.7-0.9) to ensure that large model supplementation is only performed on highly relevant fuzzy scenarios, saving computing power. For example, if the second preset threshold is set to 0.8, and among the above three candidate vulnerabilities with unknown results, two have relevance scores of 0.85 and 0.9, and one has a relevance score of 0.7, then the first two reach the second preset threshold and trigger the large model supplementation adjudication, while the last one does not reach the threshold and does not trigger the large model supplementation adjudication.

[0049] The large model adjudicator can refer to a supplementary adjudication module built on a large language model (such as GPT, LLaMA, etc.). Leveraging its powerful semantic understanding capabilities, it can resolve ambiguous scenarios that rule-based adjudicators cannot handle, outputting clear adjudication results and detailed reasons, thus compensating for the limitations of rule-based adjudication. For example, the large model adjudicator can resolve ambiguous version range statements (such as "Chrome 100.x and below"), and, combined with the vulnerability's technical documentation and historical matching data, determine whether the asset to be matched (Chrome 100.0.4896.75) is within the affected range.

[0050] The second ruling result refers to the supplementary ruling conclusion output by the large model arbitrator. It is consistent with the three-value logic of the first ruling result (applicable, inapplicable, unknown) and can be accompanied by detailed ruling reasons (such as the version range parsing process and the platform constraint judgment basis to ensure that the ruling result and process are traceable).

[0051] For example, for a candidate vulnerability with a relevance score of 0.85 and an unknown first ruling, the vulnerability's impact scope is "Chrome 100.x and below". The large model adjudicator analyzes the vulnerability technical document and determines that "100.x and below" includes version 100.0.4896.75. It outputs that the second ruling is applicable because the vulnerability's impact scope "100.x and below" is understood to be all versions of the Chrome 100 series. The asset version 100.0.4896.75 to be matched falls within this scope, and the operating platform meets the requirements.

[0052] S110, merge the first ruling result with the second ruling result.

[0053] Merging adjudication results can refer to the process of integrating the first adjudication result and the second adjudication result according to the principle that supplementary adjudication takes precedence over preliminary adjudication. For example, for candidate vulnerabilities that do not trigger the large model adjudication (the first adjudication result is applicable, inapplicable, or unknown but does not reach the second preset threshold), the first adjudication result is directly retained; for candidate vulnerabilities that trigger the large model adjudication (the first adjudication result is unknown and reaches the second preset threshold), the original unknown first adjudication result is replaced with the second adjudication result; finally, the final adjudication results of all candidate vulnerabilities are summarized to form a vulnerability matching list for the assets to be matched. The list must be associated with the adjudication result and evidence chain (such as relevance score and adjudication reason) of each vulnerability.

[0054] By following the steps described in S102-S110, the asset to be matched and a vulnerability list containing the affected assets and scope of impact can be obtained. Candidate vulnerabilities can be retrieved by relevance score. The rule adjudicator then outputs a three-value first adjudication result: applicable, inapplicable, or unknown. The large model adjudicator is triggered to supplement the adjudication only when the first adjudication result is unknown and the relevance score reaches a second preset threshold. Finally, the two types of adjudication results are merged to achieve asset vulnerability matching. First, by replacing full matching with a dual-adjudication scheme using a rule-based adjudicator and a large-scale model adjudicator, the computational power and efficiency bottleneck of massive data matching is effectively solved, balancing matching efficiency and comprehensiveness, and avoiding false negatives caused by simple rule-based strong matching. Second, because of the dual adjudicator, assets can be deemed unaffected only when the adjudication is deemed inapplicable, eliminating the defect of "no match means healthy" and reducing the risk of false negatives. Third, for ambiguous scenarios where the rule-based adjudicator adjudicates unknown information, the large-scale model adjudicator can be used to handle them, reducing misjudgments and manual maintenance costs. Fourth, the large-scale model adjudicator is triggered to supplement the adjudication only when the first adjudication result is unknown and the relevance score reaches a second preset threshold. Reasonable triggering conditions for the large-scale model are set to avoid the waste of computational power caused by full candidate input. At the same time, the semantic understanding capability of the large-scale model is used to ensure the matching accuracy of complex and ambiguous scenarios, ultimately achieving accurate, comprehensive, and efficient matching of asset vulnerabilities.

[0055] For example, suppose a company needs to perform vulnerability matching on server A (the asset to be matched). The vulnerability list contains 300,000 CVE vulnerabilities (each vulnerability includes information such as affected assets and version range). The first preset threshold is set to 0.6, the second preset threshold is set to 0.8, the rule adjudicator presets version comparison and platform verification rules, and the large model adjudicator uses the GPT-4 model.

[0056] Execute S102: Obtain asset information of the server to be matched (e.g., "Server A: Apache component, version 2.4.49, running platform Linux") and a list of 300,000 CVE vulnerabilities, with each vulnerability clearly marked with the affected assets and scope of impact.

[0057] Execution S104: Calculate the relevance score using the inverted key + BM25 algorithm, and select 80 candidate vulnerabilities with a relevance ≥ 0.6. Filter out 299,920 irrelevant vulnerabilities (e.g., filter out Nginx-specific vulnerabilities for server A, and retain Apache-related vulnerabilities), significantly reducing the scope of adjudication, avoiding the computational cost of traversing all 300,000 vulnerabilities, and solving the efficiency bottleneck of matching massive amounts of data.

[0058] S106 execution: The rule adjudicator adjudicates each of the 80 candidate vulnerabilities, of which 5 are judged as "applicable", 70 as "not applicable", and 5 as "unknown" (e.g., if the vulnerability version range is marked as "Apache 2.4.x and below", the rule cannot parse the specific boundary).

[0059] Execution S108: For the 5 candidate vulnerabilities with a correlation ≥ 0.8 among the 5 unknown results, a supplementary decision is triggered by the large model. The large model combines the vulnerability technical documentation to analyze the ambiguous scenarios and finally outputs 4 "applicable" vulnerabilities, and generates detailed reasons (such as analyzing "Apache 2.4.x and below" including version 2.4.49). This solves the ambiguous scenarios that the rule decision cannot handle. Only 1 vulnerability remains unknown because the large model cannot understand the vulnerability description, requiring manual intervention.

[0060] Execute S110: Merge all rulings to form a report and chain of evidence for server A to be matched, identify the affected vulnerabilities, unaffected vulnerabilities, and unknown vulnerabilities of the server, and associate each conclusion with a relevance score and ruling reasoning, which can be directly used for vulnerability handling.

[0061] In this example, through the synergistic effect of each step, the dual-adjudication scheme ensures matching effectiveness and efficiency, significantly reduces the false negative rate, and avoids the waste of computing power by involving the full scale of a large model, ultimately achieving accurate, comprehensive, and efficient matching of asset vulnerabilities.

[0062] In some embodiments, in order to reduce the false negative rate, the assets can be standardized, which may include normalizing the component names of the assets to be matched to obtain normalized names.

[0063] The version number of the asset to be matched is processed by at least one of the following methods to generate at least one candidate version number: retaining the original string; removing irrelevant characters; and extracting the core numerical version.

[0064] The normalization process refers to unifying component names with different spellings and formats into a standardized and stable name form. It does not require absolute standardization, only stable matching during retrieval. This may include lowercase processing, removal of symbols, and synonym mapping. For example, asset component names to be matched, such as "Apache 2.4," "apachehttpd," and "HttpServer," would be unified as "apache" after normalization, facilitating stable retrieval of relevant vulnerabilities in the vulnerability list.

[0065] The version number of the asset may be unclear, so multiple candidate versions can be generated. It's better to have more candidates than to guess wrong, thus reducing false negatives. The candidate version number refers to a set of usable versions obtained by processing the original version number, used to match the vulnerability's impact scope. Processing methods include retaining the original string; removing irrelevant characters; and extracting the core numeric version number.

[0066] For example, if the original version number is "nginx-1.21.6-stable", we can obtain candidate versions. The original string is: nginx-1.21.6-stable; after removing irrelevant characters, it becomes: nginx 1.21.6; the core numeric version number is: 1.21.6. During subsequent vulnerability matching, any candidate version that falls within the scope of the vulnerability's impact is considered a match, reducing false negatives.

[0067] In some embodiments, candidate vulnerabilities can be retrieved using a search key. See also... Figure 2 , Figure 2 This is a flowchart illustrating a candidate vulnerability retrieval method as described in this application. Figure 2 As shown, the method may include S202-S208.

[0068] S202, Obtain the search key for the preset type of the asset to be matched.

[0069] The search key refers to the key identifier of the asset to be matched for matching vulnerabilities. Its type can be preset to ensure the standardization and consistency of the search.

[0070] The preset search key can include components, vendor products, platforms, etc. For example, if the asset to be matched is a server: component Apache, version 2.4.49, running platform Linux, vendor Apache Software Foundation, and the preset search key type is component, then the obtained search key is apache; if the preset search key type is "component name + platform", then the search key is "apache + linux".

[0071] S204, based on the search key, using a preset search strategy, select the first vulnerability ranked Nth in the vulnerability list according to relevance score; where N is greater than or equal to 0.

[0072] The preset retrieval strategy refers to the pre-defined algorithmic logic used to calculate the relevance between search keys and vulnerabilities. Its core is to quantify the degree of matching between the two. Common strategies include inverted key retrieval, BM25 algorithm, trigram retrieval, and alias expansion retrieval, which can be used individually or in combination to ensure retrieval accuracy. For example, the main channel might be inverted key retrieval (e.g., components, supplier products, platforms), while the supplementary channel might be BM25 and trigram retrieval.

[0073] The "top N vulnerabilities" refers to the top N vulnerabilities selected after calculation using the retrieval strategy, sorted by relevance score from high to low (N is a preset integer that can be adjusted according to the size of the vulnerability list, such as N=50 or 100). These vulnerabilities are the core objects of subsequent relevance verification. N≥0, and when N=0, it means that no relevant vulnerabilities were found.

[0074] The relevance score, as mentioned above, quantifies the degree of correlation between the search key (the asset to be matched) and the vulnerability. The higher the score, the greater the likelihood of the vulnerability being associated with the asset to be matched. The score ranges from 0 to 1.

[0075] For example, based on the search key "apache+linux", the search strategy of "inverted key + BM25" is used to search in a list containing 300,000 vulnerabilities. With N=50 preset, the top 50 vulnerabilities with the highest relevance scores are selected as the first vulnerabilities (relevance score range 0.5-0.95).

[0076] S206, if the highest correlation score among the top N first vulnerabilities is lower than the first preset threshold, it is determined that no candidate vulnerability was hit.

[0077] The first preset threshold, consistent with the previous text, is a preset relevance score threshold (usually ranging from 0.5 to 0.7), used to define highly relevant vulnerabilities and irrelevant vulnerabilities, and is the core criterion for determining whether a candidate vulnerability has been hit.

[0078] The term "missing candidate vulnerability" refers to the situation where, among the top N first vulnerabilities, the highest relevance score is still lower than the first preset threshold. This indicates that all the retrieved vulnerabilities have low relevance to the asset to be matched and do not meet the requirements for candidate vulnerabilities, thus they do not need to proceed to the subsequent adjudication stage.

[0079] For example, if the first preset threshold is 0.6, and the highest relevance score among the first N=50 vulnerabilities is 0.58, which is lower than 0.6, then it is determined that no candidate vulnerability has been hit, and the vulnerability retrieval process for the asset to be matched is directly terminated without the need to execute subsequent adjudication steps, thus saving computing power.

[0080] S208, if the highest relevance score among the top N first vulnerabilities reaches the first preset threshold, the vulnerabilities among the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities.

[0081] S208 also includes two scenarios. It determines whether the number of vulnerabilities in the first N vulnerabilities whose relevance scores reach the first preset threshold reaches a third preset threshold. If the number of vulnerabilities reaches a third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities. If the number of vulnerabilities does not reach the third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities, and at least some of the remaining vulnerabilities are selected as candidate vulnerabilities to make up the difference.

[0082] The third preset threshold is a preset minimum number of candidate vulnerabilities required to determine whether the number of highly relevant vulnerabilities that reach the first preset threshold is sufficient. The value can be adjusted according to the size of the vulnerability list and the type of asset to be matched. For example, when N=50, the third preset threshold can be set to 10 or 15, so as to avoid the number of candidate vulnerabilities being too small, which may lead to the omission of potentially affected vulnerabilities in subsequent decisions.

[0083] When the number of vulnerabilities that reach the first preset threshold is lower than the third preset threshold, vulnerabilities are selected from the remaining vulnerabilities to supplement them until the number of candidate vulnerabilities reaches the third preset threshold. The selection priority is based on the relevance score of the remaining vulnerabilities from high to low, thereby ensuring that vulnerabilities with a certain relevance are supplemented.

[0084] The solutions described in S202-S208 can improve the efficiency of massive vulnerability retrieval, prevent missed detections, and thus enhance security through reasonable retrieval logic.

[0085] In some embodiments, vulnerability matching can be performed based on candidate version numbers to prevent missed vulnerabilities due to incorrect asset version number identification, which could compromise security. Furthermore, it can identify unknown vulnerabilities in scenarios with ambiguous vulnerability descriptions, supplementing the decision-making process with a large candidate model. Please see [link to relevant documentation]. Figure 3 , Figure 3 This is a flowchart illustrating a rule-based adjudication method as described in this application. Figure 3 As shown, the method may include S302-S308.

[0086] S302, obtain the candidate version number and platform of the asset to be matched, as well as the scope of impact of the candidate vulnerability; the scope of impact includes the version range and platform range of the affected asset.

[0087] The platform refers to the operating environment of the asset to be matched (such as Windows 10, Linux CentOS 7, Android 11). The scope of impact refers to the boundary of the impact of the candidate vulnerability on the affected assets, including the version range (the range of asset versions that the vulnerability can affect) and the platform range (the asset operating platform that the vulnerability can affect).

[0088] For each candidate version number, its impact range can be compared with that of the candidate vulnerability to determine whether the asset uses the vulnerability. Rules in the rule adjudicator can be expressed using regular expressions.

[0089] S304, in response to the candidate version number of the asset to be matched falling within the version range and the platform of the asset to be matched falling within the platform range, a first ruling result is determined to be applicable, the applicable meaning indicating that the asset to be matched is affected by the candidate vulnerability.

[0090] S306, in response to the fact that the candidate version number of the asset to be matched does not fall within the version range, and / or the platform of the asset to be matched does not fall within the platform range, the first ruling result is determined to be inapplicable, the inapplicability indicating that the asset to be matched is not affected by the candidate vulnerability; S308, in response to the inability to obtain any of the following information, the first ruling result is determined to be unknown, wherein the unknown indicates that the rule arbiter cannot output an accurate ruling result: the candidate version number of the asset to be matched; the platform of the asset to be matched; the version range; the platform range.

[0091] S304-308 illustrates three possible rulings in this application. The first two rulings are relatively clear, while the third ruling is relatively ambiguous and requires supplementary rulings using a large model.

[0092] The information recorded in S302-S308 allows for vulnerability matching based on candidate version numbers, preventing missed vulnerabilities due to incorrect asset version number identification, which could affect security. Furthermore, it can identify vulnerabilities with vague descriptions as unknown and supplement the decision based on the candidate large model.

[0093] In some embodiments, a prompt word template can be preset, and then the prompt word input model can be reviewed for adjudication. See also Figure 4 , Figure 4 This is a schematic diagram illustrating a method for adjudicating large-scale models, as described in this application. Figure 4As shown, the method may include S402-S404.

[0094] S402, based on the asset information of the asset to be matched, and the vulnerability description of the target candidate vulnerability whose first ruling result is unknown and whose correlation score with the asset to be matched reaches the second preset threshold, input the first prompt word template and generate the first prompt word; the first prompt word is used to organize the asset information and the vulnerability description into a standard question and request the large model arbitrator to output the second ruling result and reason.

[0095] The target candidate vulnerability can refer to a candidate vulnerability whose first adjudication result is unknown and whose relevance score reaches a second preset threshold. This can filter out highly relevant vulnerabilities that cannot be determined by rules to trigger a large model, thus avoiding waste of computing power.

[0096] The asset information may refer to the core basic information of the asset to be matched, which may include the normalized component name, candidate version number, and operating platform (consistent with the information required for rule adjudication).

[0097] The vulnerability description may refer to detailed information about the target candidate vulnerability, including the affected assets, the scope of impact (such as unclear version range or unclear platform constraints), and the vulnerability principle.

[0098] The first prompt word template refers to a pre-defined, fixed template used to generate standardized prompt words, and it consists of two parts. The first prompt word template includes fixed content that does not need to be filled in, and non-fixed content that needs to be filled in. The fixed content includes a decision result and reasoning based on the asset information and the vulnerability description, outputting in a preset format whether the asset to be matched is applicable to the candidate vulnerability. The non-fixed content includes the asset information and the vulnerability description that need to be filled in. In this step, the asset information can be written in the asset information position within the non-fixed content; the vulnerability description can be written in the vulnerability description position within the non-fixed content.

[0099] The first prompt word can be a standardized question generated by filling asset information and vulnerability descriptions into non-fixed positions in the first prompt word template.

[0100] S404, the first prompt word is sent to the large model arbitrator to obtain the second arbitration result and reason.

[0101] For example, suppose the asset to be matched is an enterprise office server, the component is Apache, the version is labeled as 2.4.x-enterprise, the platform is Linux Cent OS8, and the target candidate vulnerability status is the first ruling result: unknown (because the vulnerability version range is labeled as "Apache 2.4.x and below", the rule cannot parse the specific boundary, and the asset version "2.4.x-enterprise" cannot be accurately matched by the rule; correlation score: 0.88 (reaching the second preset threshold of 0.8); vulnerability description: "This vulnerability affects Apache components, the version range is 2.4.x and below, the platform range is Linux server system, the vulnerability can lead to buffer overflow, and attackers can use this vulnerability to gain control of the server."

[0102] S402: Generate the first prompt word.

[0103] The component name of the asset is normalized to apache, and the candidate versions are 2.4.x-enterprise, 2.4.x, and 2.4, with the platform being Linux Cent OS8; Fill in the asset information and vulnerability description into the first prompt word template to generate standardized prompt words; S404: Large Model Decision.

[0104] The first hint is sent to the large model adjudicator. The large model parses the ambiguous information and parses Apache 2.4.x and below as including all 2.4 series versions. The asset candidate version number "2.4" falls within this range; the asset platform Linux CentOS8 is the Linux server system described in the vulnerability description.

[0105] The second ruling and its rationale are output: Applicable. The rationale is that the asset component to be matched is Apache, the candidate version number 2.4 falls within the version range of vulnerability 2.4.x and below, and the platform Linux Cent OS8 falls within the range of the vulnerable Linux server system platform. Therefore, it is determined to be applicable. The server is affected by this vulnerability and has a buffer overflow risk.

[0106] S402-S404 can automatically generate the first prompt word based on asset information and vulnerability description using prompt word templates, and complete the overall supplementary adjudication based on the large model, thereby improving the accuracy and efficiency of vulnerability matching.

[0107] In some scenarios, such as S306, if the version of the asset to be matched is not within the scope of the candidate vulnerability's version, it indicates that the asset does not match the rules generated based on the vulnerability description of the candidate vulnerability, suggesting that the asset is healthy and unaffected by the candidate vulnerability. However, in other cases, because the vulnerability description of the candidate vulnerability is actually quite complex, only part of the rules are parsed when generating the rules in the rule adjudicator using regular expressions, resulting in the asset not matching the vulnerability, which could actually lead to missed detections. To address this, the inventors discovered that it is necessary to perform adjudication verification for important assets and important vulnerabilities. If the verification fails, rules can be added, allowing for accurate adjudication results based on the rules, thus improving matching efficiency and security.

[0108] Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for verifying the adjudication result, as described in this application. Figure 5 As shown, the method may include S502-S508.

[0109] S502, in response to the asset level of the asset to be matched being important, or the candidate vulnerability being high-risk, based on the asset information of the asset to be matched, the vulnerability description of the candidate vulnerability, the impact scope of the candidate vulnerability, and the first ruling result, input a second prompt word template and generate a second prompt word.

[0110] The asset rating refers to the importance of the asset being matched. Typically, enterprise assets are rated, including critical assets, general assets, etc. Missing a vulnerability in these assets can lead to serious security losses, thus requiring additional verification. For example, enterprise e-commerce transaction servers and core database servers are considered critical assets; ordinary office terminals are not.

[0111] The term "high-risk" refers to a candidate vulnerability whose risk level is considered high. For example, vulnerabilities that can lead to remote code execution, server control leakage, or data leakage, such as high-risk CVE vulnerabilities, are extremely dangerous and must be carefully monitored to avoid missed detections due to oversights in the rules.

[0112] The second prompt word template refers to a pre-defined, fixed template used to generate standardized verification prompt words. It is used to verify whether the first ruling result is correct, and in cases where it is incorrect, to obtain a third ruling result. It also identifies any missing descriptions in the vulnerability description that cause the first ruling result to be incorrect, and generates supplementary rules that the rule adjudicator can recognize based on these missing descriptions. This template consists of fixed and non-fixed parts.

[0113] The fixed part does not need to be filled in. It clearly defines the verification logic and output requirements, including verifying whether the first ruling result is correct; if it is incorrect, output the third ruling result, identify the missing description in the vulnerability description, and generate supplementary rules that the rule arbitrator can recognize based on the missing description.

[0114] The non-fixed part refers to the variable content that needs to be filled in, and the reserved space for filling in asset information, vulnerability description, scope of impact, and first ruling result, to ensure that the large model obtains complete verification basis.

[0115] It should be noted that the generated rules can be in a preset format, such as a regular expression format, which can be recognized by the rule adjudicator and used as its rules.

[0116] For example, suppose the asset to be matched is classified as critical (e-commerce core server), the asset information is Apache component, candidate version number 2.4.49, platform Linux CentOS8. The candidate vulnerability is a high-risk vulnerability, described as affecting Apache versions 2.5.5 and above on Linux platforms with the mod_cgi module enabled; if the mod_cgi module is disabled, the affected version range is 2.4.0-2.4.50 on Linux platforms. The first ruling only identifies versions 2.5.5 and above on Linux platforms, with the asset version being 2.4.49, therefore the first ruling is inapplicable.

[0117] The second prompt template, a fixed part, asks you to verify whether the first ruling result is correct based on the following asset information, vulnerability description, vulnerability impact scope, and first ruling result; if incorrect, output the third ruling result (applicable / inapplicable / unknown), identify the missing description in the vulnerability description that caused the first ruling result to be incorrect, and generate supplementary rules for regular expression rules based on the missing description; if correct, only output "verification correct".

[0118] For non-fixed components: Asset Information: {Asset Information}; Vulnerability Description: {Vulnerability Description}; Scope of Vulnerability Impact: {Scope of Impact}; First Ruling Result: {First Ruling Result}.

[0119] Fill in the relevant information in a non-fixed location to generate a second prompt: Based on the following asset information, vulnerability description, vulnerability impact scope, and first ruling result, verify whether the first ruling result is correct; if incorrect, output the third ruling result (applicable / inapplicable / unknown), identify the missing description in the vulnerability description that caused the first ruling result to be incorrect, and generate supplementary rules for regular expression rules based on the missing description; if correct, only output "verification correct". Asset information: Component Apache, candidate version number 2.4.49, platform Linux Cent OS8; Vulnerability description: This vulnerability affects Apache 2.5.5 and above, Linux platform, and the mod_cgi module is enabled; if the mod_cgi module is disabled, the impact scope is version range 2.4.0-2.4.49, platform range Linux. Vulnerability impact scope: Version range Apache 2.5.5 and above, platform range Linux; First ruling result: Not applicable.

[0120] S504, the second prompt word is sent to the large model to obtain the verification result, and in the case that the verification result is incorrect, a third decision result and supplementary rules are obtained.

[0121] After the second prompt word is input into the large model, the large model will verify the first decision result based on its own understanding. If the verification is correct, execute S506; if incorrect, execute S508.

[0122] S506, in response to the verification result being correct, the asset to be matched is determined to be a healthy asset.

[0123] S508, in response to the verification result being incorrect, output a third ruling result and update the scope of influence of the candidate vulnerability in the rule arbiter based on the supplementary rule.

[0124] Taking the previous example, after inputting the large model, it will be identified as a verification error. It will also identify that the rule adjudicator failed to recognize vulnerability descriptions such as "If the mod_cgi module is disabled, the affected version range is 2.4.0-2.4.49, and the platform range is Linux." This information will be formatted into regular expressions to form supplementary rules, which will be added to the rule adjudicator, thus adding rules corresponding to the candidate vulnerabilities. Subsequent vulnerability matching and adjudication using the rule adjudicator will utilize these newly added rules to improve accuracy.

[0125] The solutions described in S502-S508 can verify the adjudication results of important assets or vulnerabilities. In the event of verification failure, the cause of the adjudication error can be identified and the rule can be added to the adjudicator. This completes the verification closed loop, improving the adjudication effect, efficiency, and security.

[0126] This application also proposes an asset vulnerability matching system based on dual adjudication. Please see [link to relevant documentation]. Figure 6 , Figure 6 This is a schematic diagram illustrating the structure of an asset vulnerability matching system based on dual adjudication, as described in this application. Figure 6 As shown, the asset vulnerability matching system 600 based on dual adjudication may include an acquisition module 610 to acquire a list of assets to be matched and a list of vulnerabilities; the vulnerability list includes multiple vulnerabilities, and each vulnerability includes the affected assets it impacts and the scope of its impact on the affected assets; The retrieval module 620 retrieves candidate vulnerabilities related to the asset to be matched from the vulnerability list; the candidate vulnerabilities are vulnerabilities whose relevance score to the asset to be matched reaches a first preset threshold; the relevance score indicates the probability that the asset to be matched is the affected asset. The rule arbitrator module 630, when at least one candidate vulnerability is retrieved, obtains a first ruling result based on the rule arbitrator to determine whether the asset to be matched is subject to the scope of influence of the candidate vulnerability; the first ruling result includes one of the following three: applicable, not applicable, unknown; The large model adjudicator module 640, when the first adjudication result is unknown and the relevance score reaches a second preset threshold, obtains a second adjudication result and reasoning as to whether the asset to be matched is subject to the influence scope of the candidate vulnerability based on the large model adjudicator; the second adjudication result includes one of the following three: applicable, not applicable, unknown; The merging module 650 merges the first ruling result with the second ruling result.

[0127] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating the asset matching method process described in this application. Figure 7 To Figure 6 The illustrated system's method flow description.

[0128] S701, Asset Normalization.

[0129] S702, Structured Intelligence Extraction.

[0130] S703, unified search. The main channel is inverted index search, and the supplementary channel is text search.

[0131] S704: Check if the highest score obtained from the vulnerability search is greater than or equal to the first preset threshold. If not, no vulnerability was found, and the matching ends. If the highest score is greater than or equal to the first preset threshold, proceed to S705.

[0132] S705, Rule Three-Value Decision. If the result is applicable or not applicable, proceed to S708. If the result is unknown, proceed to S706.

[0133] S706, determine whether the correlation score between the retrieved vulnerability and the asset to be matched is greater than or equal to the second threshold. If not, proceed to S708. If the correlation score is greater than or equal to the second threshold, proceed to S707.

[0134] S707, supplemented by a large model.

[0135] S708, Merged Inventory Audit.

[0136] S709, Final Match List.

[0137] Through the above steps and modules, the system can obtain the assets to be matched and a list of vulnerabilities including affected assets and scope of impact, retrieve candidate vulnerabilities by relevance score, and then the rule adjudicator outputs a three-value first adjudication result of applicable, inapplicable, or unknown. Only when the first adjudication result is unknown and the relevance score reaches a second preset threshold is the large model adjudicator triggered to supplement the adjudication. Finally, the two types of adjudication results are merged to achieve asset vulnerability matching. First, by replacing full matching with a dual-adjudication scheme using a rule-based adjudicator and a large-scale model adjudicator, the computational power and efficiency bottleneck of massive data matching is effectively solved, balancing matching efficiency and comprehensiveness, and avoiding false negatives caused by simple rule-based strong matching. Second, because of the dual adjudicator, assets can be deemed unaffected only when the adjudication is deemed inapplicable, eliminating the defect of "no match means healthy" and reducing the risk of false negatives. Third, for ambiguous scenarios where the rule-based adjudicator adjudicates unknown information, the large-scale model adjudicator can be used to handle them, reducing misjudgments and manual maintenance costs. Fourth, the large-scale model adjudicator is triggered to supplement the adjudication only when the first adjudication result is unknown and the relevance score reaches a second preset threshold. Reasonable triggering conditions for the large-scale model are set to avoid the waste of computational power caused by full candidate input. At the same time, the semantic understanding capability of the large-scale model is used to ensure the matching accuracy of complex and ambiguous scenarios, ultimately achieving accurate, comprehensive, and efficient matching of asset vulnerabilities.

[0138] In some embodiments, the system 600 further includes a standardization processing module for standardizing the assets to be matched; The standardization process for the assets to be matched includes: The component names of the assets to be matched are normalized to obtain normalized names; The version number of the asset to be matched is processed by at least one of the following methods to generate at least one candidate version number: retaining the original string; removing irrelevant characters; and extracting the core numerical version.

[0139] In some embodiments, the retrieval module 620 further includes: Obtain the search key that matches the preset type of the asset to be matched; Based on the search key, using a preset search strategy, the first vulnerability ranked among the top N in the vulnerability list by relevance score is selected; where N is greater than or equal to 0. If the highest relevance score among the top N first vulnerabilities is lower than the first preset threshold, it is determined that no candidate vulnerability was hit. If the highest relevance score among the top N first vulnerabilities reaches the first preset threshold, the vulnerabilities among the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities.

[0140] In some embodiments, the retrieval module 620 further includes: Determine whether the number of vulnerabilities whose relevance scores reach the first preset threshold among the top N vulnerabilities reaches the third preset threshold. If the number of vulnerabilities reaches a third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities. If the number of vulnerabilities does not reach the third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities, and at least some of the remaining vulnerabilities are selected as candidate vulnerabilities to make up the difference.

[0141] In some embodiments, the rule adjudicator module 630 further includes: Obtain the candidate version number and platform of the asset to be matched, as well as the scope of impact of the candidate vulnerability; the scope of impact includes the version range and platform range of the affected assets; In response to the fact that the candidate version number of the asset to be matched falls within the version range and the platform of the asset to be matched falls within the platform range, the first ruling result is determined to be applicable, the application indicating that the asset to be matched is affected by the candidate vulnerability; In response to the fact that the candidate version number of the asset to be matched does not fall within the version range, and / or the platform of the asset to be matched does not fall within the platform range, the first ruling result is determined to be inapplicable, and the inapplicability indicates that the asset to be matched is not affected by the candidate vulnerability; In response to the inability to obtain any of the following information, the first ruling result is determined to be unknown, wherein the unknown indicates that the rule arbiter cannot output an accurate ruling result: the candidate version number of the asset to be matched; the platform of the asset to be matched; the version range; and the platform range.

[0142] In some embodiments, the large model arbitrator module 640 further includes: Based on the asset information of the asset to be matched, and the vulnerability description of the target candidate vulnerability whose first adjudication result is unknown and whose correlation score with the asset to be matched reaches the second preset threshold, a first prompt word template is input to generate a first prompt word; the first prompt word is used to organize the asset information and the vulnerability description into a standard question and request the large model adjudicator to output the second adjudication result and reasoning. The first prompt word is sent to the large model arbitrator to obtain the second arbitration result and reason.

[0143] In some embodiments, the first prompt word template includes fixed content that does not need to be filled in and non-fixed content that needs to be filled in; the fixed content includes the decision result and reason for whether the asset to be matched is applicable to the candidate vulnerability, based on the asset information and the vulnerability description, and output in a preset format; the non-fixed content includes the asset information and the vulnerability description that need to be filled in. The large model adjudicator module 640 further includes: Write the asset information into the asset information location in the non-fixed content; Write the vulnerability description at the vulnerability description location in the non-fixed content.

[0144] In some embodiments, the system 600 further includes a verification module: After determining that the first ruling is inapplicable, in response to the asset level of the asset to be matched being important, or the candidate vulnerability being high-risk, based on the asset information of the asset to be matched, the vulnerability description of the candidate vulnerability, the scope of impact of the candidate vulnerability, and the first ruling, a second prompt word template is input to generate a second prompt word; the second prompt word is used to verify whether the first ruling result is correct, and in the case of an incorrect result, to obtain a third ruling result, and to identify the missing description in the vulnerability description that causes the first ruling result to be incorrect, and to generate supplementary rules that the rule adjudicator can recognize based on the missing description; The second prompt word is sent to the large model to obtain the verification result, and in the case that the verification result is incorrect, a third decision result and supplementary rules are obtained.

[0145] In some embodiments, the system 600 further includes an output module: If the verification result is correct, the asset to be matched is determined to be a healthy asset. In response to the verification result being incorrect, a third ruling result is output, and the scope of influence for the candidate vulnerability in the rule arbiter is updated based on the supplementary rule.

[0146] Those skilled in the art will understand that one or more embodiments of this application can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] In this application, "and / or" indicates that at least one of the two is present. The various embodiments in this application are described in a progressive manner, and similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the data processing device embodiments are basically similar to the method embodiments, so the description is relatively simple, and relevant parts can be referred to the description of the method embodiments.

[0148] While this application contains numerous specific implementation details, these should not be construed as limiting the scope of any disclosure or the scope of the claims, but rather are primarily used to describe the features of specific embodiments of a particular disclosure. Certain features described in the multiple embodiments of this application may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0149] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the described embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0150] The above are merely preferred embodiments of one or more embodiments of this application and are not intended to limit the scope of one or more embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the scope of protection of one or more embodiments of this application.

Claims

1. A dual-judgment-based asset vulnerability matching method, characterized in that, The method includes: Obtain a list of assets to be matched and a list of vulnerabilities; the list of vulnerabilities includes multiple vulnerabilities, and each vulnerability includes the affected assets it impacts and the scope of its impact on the affected assets; Candidate vulnerabilities related to the asset to be matched are retrieved from the vulnerability list; the candidate vulnerabilities are those whose relevance score to the asset to be matched reaches a first preset threshold; the relevance score indicates the probability that the asset to be matched is the affected asset. If at least one candidate vulnerability is identified, a first decision result is obtained based on the rule adjudicator to determine whether the asset to be matched is subject to the scope of influence of the candidate vulnerability; the first decision result includes one of the following three: applicable, not applicable, unknown; If the first ruling result is unknown and the relevance score reaches the second preset threshold, a second ruling result and reasoning are obtained based on the large model adjudicator to determine whether the asset to be matched is subject to the influence of the candidate vulnerability; the second ruling result includes one of the following three: applicable, not applicable, unknown; The first ruling result and the second ruling result are combined.

2. The asset vulnerability matching method based on dual adjudication according to claim 1, characterized in that, The method further includes standardizing the assets to be matched; The standardization process for the assets to be matched includes: The component names of the assets to be matched are normalized to obtain normalized names; The version number of the asset to be matched is processed by at least one of the following methods to generate at least one candidate version number: retaining the original string; removing irrelevant characters; and extracting the core numerical version.

3. The asset vulnerability matching method based on dual adjudication according to claim 2, characterized in that, The step of retrieving candidate vulnerabilities related to the asset to be matched from the vulnerability list includes: Obtain the search key that matches the preset type of the asset to be matched; Based on the search key, using a preset search strategy, the first vulnerability ranked among the top N in the vulnerability list by relevance score is selected; where N is greater than or equal to 0. If the highest relevance score among the top N first vulnerabilities is lower than the first preset threshold, it is determined that no candidate vulnerability was hit. If the highest relevance score among the top N first vulnerabilities reaches the first preset threshold, the vulnerabilities among the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities.

4. The asset vulnerability matching method based on dual adjudication according to claim 3, characterized in that, The step of identifying vulnerabilities among the top N first vulnerabilities whose relevance scores reach the first preset threshold as candidate vulnerabilities includes: Determine whether the number of vulnerabilities whose relevance scores reach the first preset threshold among the top N vulnerabilities reaches the third preset threshold. If the number of vulnerabilities reaches a third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities. If the number of vulnerabilities does not reach the third preset threshold, the vulnerabilities in the top N first vulnerabilities whose relevance scores reach the first preset threshold are identified as candidate vulnerabilities, and at least some of the remaining vulnerabilities are selected as candidate vulnerabilities to make up the difference.

5. The asset vulnerability matching method based on dual adjudication according to claim 2, characterized in that, The rule-based adjudicator obtains a first adjudication result regarding whether the asset to be matched is subject to the scope of influence of the candidate vulnerability, including: Obtain the candidate version number and platform of the asset to be matched, as well as the scope of impact of the candidate vulnerability; the scope of impact includes the version range and platform range of the affected assets; In response to the fact that the candidate version number of the asset to be matched falls within the version range and the platform of the asset to be matched falls within the platform range, the first ruling result is determined to be applicable, the application indicating that the asset to be matched is affected by the candidate vulnerability; In response to the fact that the candidate version number of the asset to be matched does not fall within the version range, and / or the platform of the asset to be matched does not fall within the platform range, the first ruling result is determined to be inapplicable, and the inapplicability indicates that the asset to be matched is not affected by the candidate vulnerability; In response to the inability to obtain any of the following information, the first ruling result is determined to be unknown, wherein the unknown indicates that the rule arbiter cannot output an accurate ruling result: the candidate version number of the asset to be matched; the platform of the asset to be matched; the version range; and the platform range.

6. The asset vulnerability matching method based on dual adjudication according to claim 1, characterized in that, The large model-based adjudicator obtains a second adjudication result and reasoning regarding whether the asset to be matched is subject to the influence scope of the candidate vulnerability, including: Based on the asset information of the asset to be matched, and the vulnerability description of the target candidate vulnerability whose first adjudication result is unknown and whose correlation score with the asset to be matched reaches the second preset threshold, a first prompt word template is input to generate a first prompt word; the first prompt word is used to organize the asset information and the vulnerability description into a standard question and request the large model adjudicator to output the second adjudication result and reasoning. The first prompt word is sent to the large model arbitrator to obtain the second arbitration result and reason.

7. The asset vulnerability matching method based on dual adjudication according to claim 6, characterized in that, The first prompt word template includes fixed content that does not need to be filled in, and non-fixed content that needs to be filled in; the fixed content includes the decision result and reason for whether the asset to be matched is applicable to the candidate vulnerability, based on the asset information and the vulnerability description, and output in a preset format; the non-fixed content includes the asset information and the vulnerability description that need to be filled in. Based on the asset information of the asset to be matched, and the vulnerability description of the target candidate vulnerability whose first ruling result is unknown and whose correlation score with the asset to be matched reaches a second preset threshold, a first prompt word template is input to generate a first prompt word, including: Write the asset information into the asset information location in the non-fixed content; Write the vulnerability description at the vulnerability description location in the non-fixed content.

8. The asset vulnerability matching method based on dual adjudication according to claim 5, characterized in that, After determining that the first ruling is inapplicable, the method further includes: In response to the asset level of the asset to be matched being important, or the candidate vulnerability being high-risk, based on the asset information of the asset to be matched, the vulnerability description of the candidate vulnerability, the scope of impact of the candidate vulnerability, and the first adjudication result, a second prompt word template is input to generate a second prompt word; the second prompt word is used to verify whether the first adjudication result is correct, and in the case of an incorrect result, to obtain a third adjudication result, and to identify the missing description in the vulnerability description that causes the first adjudication result to be incorrect, and to generate supplementary rules that the rule adjudicator can recognize based on the missing description; The second prompt word is sent to the large model to obtain the verification result, and in the case that the verification result is incorrect, a third decision result and supplementary rules are obtained.

9. The asset vulnerability matching method based on dual adjudication according to claim 8, characterized in that, The method further includes: If the verification result is correct, the asset to be matched is determined to be a healthy asset. In response to the verification result being incorrect, a third ruling result is output, and the scope of influence for the candidate vulnerability in the rule arbiter is updated based on the supplementary rule.

10. An asset vulnerability matching system based on dual adjudication, characterized in that, The system includes: The acquisition module acquires a list of assets to be matched and a list of vulnerabilities; the list of vulnerabilities includes multiple vulnerabilities, and each vulnerability includes the affected assets it impacts and the scope of its impact on the affected assets; The retrieval module retrieves candidate vulnerabilities related to the asset to be matched from the vulnerability list; the candidate vulnerabilities are vulnerabilities whose relevance score to the asset to be matched reaches a first preset threshold; the relevance score indicates the probability that the asset to be matched is the affected asset. The rule adjudicator module, upon retrieving at least one candidate vulnerability, obtains a first adjudication result based on the rule adjudicator to determine whether the asset to be matched is subject to the scope of influence of the candidate vulnerability; the first adjudication result includes one of the following three: applicable, not applicable, unknown; The large model adjudicator module, when the first adjudication result is unknown and the relevance score reaches a second preset threshold, obtains a second adjudication result and reasoning as to whether the asset to be matched is subject to the influence scope of the candidate vulnerability based on the large model adjudicator; the second adjudication result includes one of the following three: applicable, not applicable, unknown; The merging module merges the first ruling result with the second ruling result.

Images