Knowledge-enhanced false positive judgment method and system for vulnerabilities

Abstract

The application discloses a kind of knowledge enhancement-based vulnerability false alarm determination method and system, it is related to computer network security technical field.The method includes: constructing the vulnerability exploitation condition constraint graph including condition node and the logic relationship between nodes;Correlate operating environment information and responsible person feedback to generate structured evidence information;Build vulnerability context information and input large language model, obtain the state determination result of each condition node and multi-source evidence conflict identification result;Based on the pessimistic evaluation criterion and constraint propagation calculation, perform credibility evaluation;According to the comparison result of credibility and threshold value, execute closed loop disposal, and store the case determined as no vulnerability in false alarm knowledge base.The application realizes the explainable vulnerability false alarm automation determination, reduces vulnerability false alarm rate, meets the traceability and auditability requirements of vulnerability disposal.

Description

Technical Field

[0001] This invention relates to the field of computer network security technology, specifically to a method and system for determining false vulnerability reports based on knowledge enhancement. Background Technology

[0002] As banking information systems gradually evolve towards cloud-native, microservice, and software supply chain models, business systems heavily rely on open-source components, middleware, third-party SDKs, and container images to build business capabilities. To mitigate vulnerability risks, enterprises typically employ methods such as software composition analysis, container image scanning, host vulnerability scanning, and SBOM analysis to identify component vulnerabilities. The main principle of existing vulnerability scanning systems is to match component names with version numbers using rules. When the system detects a specific version of a component in the target environment, if a corresponding CVE vulnerability exists in the vulnerability database, the system is directly deemed to have a vulnerability risk.

[0003] However, this approach has significant drawbacks. Whether a vulnerability actually exists depends not only on the component version, but also on the exploitation conditions, operating environment, component configuration, protocol enabled status, system architecture, call chain path, and runtime behavior. In real-world scenarios, many vulnerabilities, while theoretically meeting the version requirements, cannot be exploited by attackers because the exploitation prerequisites are not met. This leads to a large number of false positives in vulnerability scanning systems, requiring security operations personnel to invest significant manpower in manual review.

[0004] To address the aforementioned issues, existing technologies have attempted to incorporate artificial intelligence to enhance the automation level of vulnerability analysis. For example, Chinese invention patent publication CN121561915A proposes a technical solution that utilizes historical vulnerability cases to construct a structured vulnerability knowledge graph. This graph serves as prior knowledge to guide a large language model in identifying pollution sources and risk pools, driving a static analysis engine to generate suspected paths. A two-level hierarchical review mechanism then filters these suspected paths to output high-confidence vulnerabilities. This solution guides a large model in code auditing through historical vulnerability patterns accumulated in the knowledge graph, thereby improving the credibility of vulnerability analysis to some extent.

[0005] However, the aforementioned existing technologies still have the following shortcomings: First, this approach focuses on static analysis of the source code itself. Its knowledge graph construction is based on comparative analysis of vulnerable code samples and patched code samples, resulting in knowledge that represents code-level pollution sources and risk pool patterns, rather than modeling the exploitation conditions of component vulnerabilities. Since the exploitability of component vulnerabilities is not solely determined by code characteristics but also depends on multi-dimensional factors such as configuration conditions, network conditions, permission conditions, and dependency conditions in the runtime environment, this approach is difficult to transfer to a comprehensive determination of whether the exploitation prerequisites are met in a component vulnerability scenario.

[0006] Secondly, although the scheme improves analysis efficiency through a two-level hierarchical review mechanism, it lacks a mechanism to quantitatively assess the credibility of the vulnerability false alarm judgment results. Its final output is only a vulnerability ruling result in the form of "yes / no", which cannot provide a structured vulnerability exclusion evidence chain and is difficult to meet the interpretability requirements of the financial industry in the compliance audit of vulnerability handling.

[0007] Third, the solution does not establish a mechanism for the accumulation and reuse of historical false alarm cases. For vulnerability cases that have been judged as false alarms, the basis for their exclusion cannot be systematically recorded and reused in similar scenarios in the future. As a result, the knowledge of false alarm judgment cannot be transferred to experience, making it difficult to continuously reduce the false alarm rate as the system runs. Summary of the Invention

[0008] Based on the technical problems mentioned in the background section above, this invention provides a method and system for determining false positives of vulnerabilities based on knowledge enhancement.

[0009] To address the aforementioned technical problems, this invention provides a method for determining false positives of vulnerabilities based on knowledge enhancement, comprising the following steps: Step S1, Constructing a Vulnerability Exploitation Condition Constraint Graph: In response to receiving component vulnerability detection results from a security scanning device, the vulnerability detection results are standardized and normalized to generate basic vulnerability information. This basic vulnerability information includes at least the vulnerability name, CVE number, vulnerability type, affected version, vulnerability path, discovery time, and component name. The basic vulnerability information is parsed, and text preprocessing is performed. Entity recognition is conducted using a network security-specific dictionary, identifying at least the CVE number and component name. Information extraction is performed using a predefined relationship template, and the extraction results are converted into a structured format and stored in the component vulnerability knowledge base. Exploitation condition information for the corresponding vulnerability is extracted from the component vulnerability knowledge base. This exploitation condition information includes at least the vulnerable version, operating environment, configuration conditions, permission conditions, network conditions, and dependency conditions. The exploitation condition information is converted into a structured vulnerability exploitation condition constraint graph. This graph contains multiple condition nodes and logical relationships between nodes, including AND, OR, pre-dependency, and blocking relationships.

[0010] Step S2, associating runtime environment information with feedback from the responsible party: Obtain runtime information of the business system affected by the component vulnerability through the vulnerability scanning device probe. The runtime information includes at least the business system identifier, host IP, host name, container ID, Pod name, and path information. Associate and map the runtime information with the condition nodes in the vulnerability exploitation condition constraint diagram to determine the initial state of each condition node. Dispatch a vulnerability remediation process work order to the responsible party, receive the explanation that the vulnerability does not exist submitted by the responsible party, call the large language model to perform semantic structuring processing on the explanation that the vulnerability does not exist, extract factual assertions for the reason for vulnerability exclusion, and generate structured evidence information. The structured evidence information includes at least evidence number, evidence source, evidence attribute name, and attribute value.

[0011] Step S3, Generate Enhanced Vulnerability Context Information: Construct vulnerability context information around the component vulnerability, the vulnerability context information including the vulnerability basic information, the vulnerability exploitation condition constraint graph, the runtime information, and the structured evidence information.

[0012] Step S4: Invoke the large model for knowledge-enhanced reasoning: Convert the vulnerability context information into a JSON structured representation according to a preset structured format, and input it into the large language model deployed in the local intranet environment; The large language model performs fact extraction and condition verification based on a preset prompt word template, and outputs the state judgment result and corresponding evidence information for each condition node in the vulnerability exploitation condition constraint graph. The state judgment result includes condition valid, condition invalid, and state unknown; The large language model also performs multi-source evidence conflict identification based on the structured evidence information, the runtime information, and historical false alarm cases, and determines whether there is a semantic contradiction in the evidence values ​​under the same evidence attribute from different data sources. The different data sources include at least runtime environment information, vulnerability exploitation condition verification results, responsible person feedback information, and vulnerability scanning results.

[0013] Step S5: Perform constraint propagation calculation and credibility assessment: According to the pessimistic assessment criterion, condition nodes with an unknown state are considered to be conditional. Based on the state determination result, constraint propagation calculation is performed on the vulnerability exploitation condition constraint graph to determine whether the vulnerability exploitation path is blocked. If a key condition node is determined to be conditional or blocked after constraint propagation, the vulnerability does not exist. Otherwise, the vulnerability existence credibility is calculated. The vulnerability existence credibility is determined based on the vulnerability exploitation condition matching degree, multi-source evidence conflict degree, and historical false alarm case similarity. The vulnerability exploitation condition matching degree reflects the proportion of the number of satisfied vulnerability exploitation conditions to the total number of vulnerability exploitation conditions. The multi-source evidence conflict degree reflects the proportion of conflicting evidence identified by the large language model to the total number of evidence, and the existence of conflicting evidence negatively adjusts the vulnerability existence credibility. The historical false alarm case similarity reflects the matching degree between the current vulnerability and historical false alarm cases in the false alarm knowledge base, and the matching of historical false alarm cases reduces the vulnerability existence credibility.

[0014] Step S6, Closed-loop processing and false alarm knowledge learning: Closed-loop processing is performed based on the comparison result between the vulnerability's credibility and a preset threshold: when the vulnerability's credibility is higher than the first preset threshold, a vulnerability existence determination result is output and the vulnerability remediation process is initiated; when the vulnerability's credibility is lower than the second preset threshold, a vulnerability non-existence determination result is output and the vulnerability processing process is closed; when the vulnerability's credibility is between the first and second preset thresholds, a determination result requiring manual review is output; a determination report containing a structured evidence chain is generated; for cases determined to be non-existent, the vulnerability type, vulnerability name, and proof information of the vulnerability's non-existence are extracted and stored in the vulnerability false alarm knowledge base for future vulnerability determination using historical false alarm case similarity matching.

[0015] To implement the above method, the present invention also provides a knowledge-enhanced vulnerability false alarm judgment system, including a large model support module, a vulnerability exploitation condition constraint graph construction module, an operating environment awareness module, a vulnerability context parsing module, an intelligent reasoning decision module, a closed-loop handling module, and a false alarm knowledge learning module.

[0016] The large model support module is deployed in the local intranet environment and is used to provide large model computing power support for the statistics of vulnerability context information and the inference of vulnerability existence.

[0017] The vulnerability exploitation condition constraint graph construction module includes a vulnerability detection submodule and a vulnerability exploitation condition parsing submodule. The vulnerability detection submodule, in response to receiving component vulnerability detection results from a security scanning device, standardizes and normalizes the detection results to generate basic vulnerability information. This basic vulnerability information includes at least the vulnerability name, CVE number, vulnerability type, affected version, vulnerability path, discovery time, and component name. The vulnerability exploitation condition parsing submodule parses the basic vulnerability information, performs text preprocessing, and performs entity recognition using a network security domain-specific dictionary. Entity recognition identifies at least the CVE number and component name. Information is extracted using a predefined relationship template, and the extracted results are converted into a structured format and stored in a component vulnerability knowledge base. Exploitation condition information for the corresponding vulnerability is extracted from the component vulnerability knowledge base. This exploitation condition information includes at least the vulnerable version, operating environment, configuration conditions, permission conditions, network conditions, and dependency conditions. The exploitation condition information is then converted into a structured vulnerability exploitation condition constraint graph. This graph contains multiple condition nodes and logical relationships between nodes, including AND, OR, pre-dependency, and blocking relationships.

[0018] The runtime environment awareness module is used to obtain runtime information of the business system affected by the component vulnerability through the vulnerability scanning device probe. The runtime information includes at least the business system identifier, host IP, host name, container ID, Pod name and path information. The runtime information is then associated and mapped with the condition nodes in the vulnerability exploitation condition constraint graph to determine the initial state of each condition node.

[0019] The intelligent reasoning and decision-making module includes a responsible person feedback parsing submodule, a knowledge-enhanced reasoning submodule, and a credibility measurement submodule. The responsible person feedback parsing submodule is used to dispatch vulnerability remediation process work orders to the responsible person, receive a vulnerability non-existence statement submitted by the responsible person, call the large language model to perform semantic structuring processing on the vulnerability non-existence statement, extract factual assertions for vulnerability exclusion reasons, and generate structured evidence information. The structured evidence information includes at least evidence number, evidence source, evidence attribute name, and attribute value. The knowledge-enhanced reasoning submodule is used to convert the vulnerability context information into a JSON structured representation according to a preset structured format and input it into the large language model. The large language model performs fact extraction and condition verification based on a preset prompt word template, outputting a state judgment result and corresponding evidence information for each condition node in the vulnerability exploitation condition constraint graph. The state judgment result includes condition valid, condition invalid, and state unknown. The large language model also performs multi-source evidence conflict identification based on the structured evidence information, the runtime information, and historical false alarm cases, determining the source of the conflict. The module checks whether there are semantic contradictions in the evidence values ​​of the same evidence attribute from different data sources. It then uses a credibility measurement submodule to treat condition nodes with unknown states as valid based on a pessimistic assessment criterion. Based on the state determination result, it performs constraint propagation calculations on the vulnerability exploitation condition constraint graph to determine whether the vulnerability exploitation path is blocked. When a key condition node is determined to be invalid or blocked after constraint propagation, it outputs a vulnerability non-existent result; otherwise, it calculates the vulnerability existence credibility. The vulnerability existence credibility is determined comprehensively based on the vulnerability exploitation condition fulfillment matching degree, multi-source evidence conflict degree, and historical false alarm case similarity. The vulnerability exploitation condition fulfillment matching degree reflects the proportion of satisfied vulnerability exploitation conditions to the total number of vulnerability exploitation conditions. The multi-source evidence conflict degree reflects the proportion of conflicting evidence identified by the large language model to the total number of evidence, and the existence of conflicting evidence negatively adjusts the vulnerability existence credibility. The historical false alarm case similarity reflects the degree of matching between the current vulnerability and historical false alarm cases in the false alarm knowledge base, and the matching of historical false alarm cases reduces the vulnerability existence credibility.

[0020] The vulnerability context parsing module is used to construct vulnerability context information around the component vulnerability and provide it to the intelligent reasoning and decision-making module. The vulnerability context information includes the vulnerability basic information, the vulnerability exploitation condition constraint graph, the runtime information, and the structured evidence information.

[0021] The closed-loop processing module is used to perform closed-loop processing based on the comparison result of the vulnerability's credibility with a preset threshold: when the vulnerability's credibility is higher than the first preset threshold, a vulnerability existence determination result is output and the vulnerability remediation process is initiated; when the vulnerability's credibility is lower than the second preset threshold, a vulnerability non-existence determination result is output and the vulnerability processing process is closed; when the vulnerability's credibility is between the first preset threshold and the second preset threshold, a determination result requiring manual review is output; and a determination report containing a structured evidence chain is generated.

[0022] The false alarm knowledge learning module is used to extract the vulnerability type, vulnerability name, and proof information that the vulnerability does not exist for cases that are determined to be non-existent, and store them in the vulnerability false alarm knowledge base, so that the knowledge enhancement reasoning submodule can perform similarity matching of historical false alarm cases in subsequent vulnerability determinations.

[0023] Compared with the prior art, this application has the following advantages: 1. Vulnerability knowledge representation methods Existing technologies use pollution sources and risk pool APIs in the source code as the core nodes of the knowledge graph, representing vulnerability knowledge as a "Source-Sink" pattern at the code level. Its knowledge scope is limited to the static structural features of the code.

[0024] This application constructs a vulnerability exploitation condition constraint graph, using multiple dimensions of exploitation conditions such as vulnerable version, runtime environment, configuration conditions, permission conditions, network conditions, and dependency conditions as nodes. The logical structure between these conditions is characterized by AND, OR, prerequisite dependencies, and blocking relationships. This representation method elevates vulnerability knowledge from the code level to the exploitation condition level, enabling the system to understand the core logic of "under what conditions the vulnerability is established and under what conditions it is blocked," providing a structured basis for subsequent runtime environment correlation verification.

[0025] 2. Methods for associating and verifying runtime information Existing technologies only perform static analysis on the target source code, identifying pollution sources and risk pools by parsing code text. Their information sources are singular and cannot obtain the actual operating status of the system where the vulnerability is located.

[0026] This application proactively acquires runtime information of the business system through vulnerability scanning device probes, including container IDs, Pod names, and path information, and maps this runtime information to various condition nodes in the vulnerability exploitation constraint graph. This mechanism allows vulnerability determination to no longer rely on static code feature inference, but rather on direct verification based on the actual runtime state of the target system, fundamentally solving the problem that traditional version-matching-based scanning methods cannot confirm whether the premises for vulnerability exploitation are met.

[0027] 3. Interpretability of false alarm determination results While existing technologies generate argument records through a multi-model debate involving "attacker-defender-referee," their explanations revolve around code execution paths, focusing on technical arguments regarding "whether the code segment can be exploited," rather than a structured chain of evidence geared towards compliance audits for vulnerability handling.

[0028] This application uses a large model to output a status determination result and corresponding evidence information for each vulnerability exploitation condition node, and generates a structured evidence chain containing evidence number, evidence source, evidence attribute name, and attribute value. Each determination result can be traced back to a specific evidence source (such as runtime environment probe data, responsible person feedback, vulnerability scan results, etc.), ensuring that the conclusion that the vulnerability does not exist has complete and auditable compliance evidence support, meeting the financial industry's regulatory requirements for traceable and verifiable vulnerability handling.

[0029] 4. Mechanism for the accumulation and reuse of historical experience While existing technologies have built and accumulated API patterns of historical vulnerabilities through offline knowledge graphs, the objects of their experience reuse are the identification of "vulnerable code patterns" rather than the accumulation and migration of "reasons for false vulnerability reports".

[0030] This application includes a dedicated false positive knowledge learning module. For cases where a vulnerability is determined to be nonexistent, the vulnerability type, name, and supporting evidence of its nonexistence are extracted and stored in the vulnerability false positive knowledge base. When encountering similar vulnerability alerts later, the system can directly retrieve historical false positive cases as a basis for judgment, reducing the credibility of vulnerability existence. This mechanism forms a continuous optimization loop of "false positive judgment - experience accumulation - experience reuse," enabling the system to continuously improve judgment efficiency and reduce the false positive rate during long-term operation.

[0031] 5. Human-machine collaboration and trustworthy measurement mechanism While existing hierarchical verification mechanisms adjudicate suspected paths through Level 1 rapid screening and Level 2 in-depth debate, their final output is a binary "yes / no" vulnerability judgment result, lacking a quantitative expression of the credibility of the judgment result.

[0032] This application introduces a quantified vulnerability credibility assessment mechanism, which calculates vulnerability credibility based on three factors: the matching degree of vulnerability exploitation conditions, the conflict degree of multi-source evidence, and the similarity of historical false alarm cases. Specifically, the matching degree of vulnerability exploitation conditions positively contributes to credibility, while the conflict degree of multi-source evidence and the similarity of historical false alarm cases negatively adjust credibility. The comprehensive calculation of these three factors ensures that the credibility assessment reflects both the sufficiency and reliability of the evidence. A three-tiered threshold handling mechanism is also implemented: high credibility automatically initiates the remediation process, low credibility automatically closes the handling process, and values ​​between these two levels are subject to manual review. This quantification mechanism allows the system to dynamically allocate decision-making authority (automatic system handling or manual intervention) based on the completeness of the evidence, avoiding the inaccurate decision-making problems of binary judgment in scenarios with insufficient evidence.

[0033] The aforementioned technical features are not simply superimposed, but rather form an organic whole around the core judgment logic of "whether the conditions for exploitation are met": The vulnerability exploitation condition constraint graph construction module collaborates with the runtime environment awareness module to associate and map abstract exploitation conditions with specific runtime information, giving a verifiable technical basis for whether the "conditions are valid". The intelligent reasoning and decision-making module enhances reasoning capabilities by introducing knowledge from a large model, performs state determination on condition nodes, and identifies conflicts in multi-source evidence. The credibility measurement submodule further integrates condition matching degree, evidence conflict degree, and historical false alarm similarity to achieve credibility measurement of the determination results. The closed-loop handling module and the false alarm knowledge learning module form a complete closed loop from "determination" to "handling" and then to "experience accumulation".

[0034] Overall, this application features seamless information flow and complementary functions among its modules, from "constructing verifiable judgment criteria" to "performing intelligent condition verification" and "generating a compliant chain of evidence." The system can automate the entire process from receiving vulnerability alerts to determining interpretable false positives, freeing component vulnerability verification from the multiple limitations of traditional solutions, such as static rule matching, single data sources, uninterpretable black-box reasoning, and the inability to accumulate knowledge. Attached Figure Description

[0035] Figure 1 This is an overall flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a sub-flowchart of calling a large model for knowledge-enhanced reasoning in Embodiment 1 of the present invention; Figure 3 This is an overall architecture diagram of the system according to Embodiment 2 of the present invention; Figure 4 This is a schematic diagram of the internal composition and data interaction of the intelligent reasoning and decision-making module in Embodiment 2 of the present invention. Detailed Implementation

[0036] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to specific embodiments. The following embodiments are merely illustrative and do not constitute a limitation on the scope of protection of the present invention.

[0037] To facilitate understanding of the technical solution of this invention, the following terms are first defined and explained: A vulnerability exploitation constraint graph is a graph structure data model constructed with the various conditions required for vulnerability exploitation as nodes and the logical relationships between the conditions as edges. The nodes include at least vulnerable version condition nodes, runtime environment condition nodes, configuration condition nodes, permission condition nodes, network condition nodes, and dependency condition nodes. The logical relationships include at least AND relationships, OR relationships, prerequisite dependencies, and blocking relationships.

[0038] The condition node status refers to the determination result of whether each condition node in the vulnerability exploitation condition constraint diagram meets the current vulnerability exploitation requirements, including three types: condition met, condition not met, and status unknown.

[0039] The credibility of vulnerability existence refers to a comprehensive quantitative assessment of whether a vulnerability in a target component actually exists. This value is calculated based on at least one of the following factors: the degree of matching of vulnerability exploitation conditions, the degree of conflict of multi-source evidence, and the similarity of historical false alarm cases.

[0040] The pessimistic assessment criterion refers to a rule that considers the exploit condition node as valid if its validity cannot be clearly determined from currently available evidence, based on the principle of security conservatism. This criterion applies only to exploit condition nodes and not to blocking condition nodes in blocking relationships. For blocking condition nodes with unknown status, they are considered invalid according to the conservatism principle to avoid incorrectly blocking the exploit path due to missing information.

[0041] Structured evidence information refers to evidence data units obtained by formatting and organizing the factual evidence involved in the vulnerability determination process according to a preset data model. The evidence data unit includes at least evidence number, evidence source, evidence attribute name, and evidence attribute value.

[0042] Example 1 like Figure 1 As shown, this embodiment provides a method for determining false positives of vulnerabilities based on knowledge enhancement.

[0043] The method includes the following steps: Step S1: Construct a vulnerability exploitation constraint graph.

[0044] In response to receiving component vulnerability detection results from security scanning devices, the system standardizes and normalizes these results to generate basic vulnerability information. This basic vulnerability information includes at least the vulnerability name, CVE number, vulnerability type, affected version, vulnerability path, discovery time, and component name. The raw alert data received by the system may originate from different security devices, and the data formats output by these devices differ. For example, alerts from host vulnerability scanning systems may include host IP and port information, alerts from software composition analysis systems may include component dependency paths and version information, and alerts from container image scanning systems may include image layer information and container identification information. Through standardization and normalization, the system converts these alert data from different sources and in different formats into a standardized format of basic vulnerability information, enabling subsequent modules to process the data based on a unified data structure.

[0045] The vulnerability information is parsed and preprocessed, including at least HTML tag cleaning and word / sentence segmentation. For example, the original vulnerability announcement may contain a large number of HTML tags that are irrelevant to the vulnerability's semantics and need to be cleaned and removed. Word / sentence segmentation involves dividing the continuous text into independent word and sentence units according to language conventions to facilitate subsequent entity recognition and information extraction.

[0046] Entity recognition is performed on preprocessed text using a specialized dictionary in the cybersecurity field. This entity recognition identifies at least the CVE number and component name. The specialized dictionary includes standard terminology and common expressions in the cybersecurity field, including naming patterns for various CVE numbers, standard names for various open-source components and middleware, and standard classification names for various vulnerability types. With the assistance of this specialized dictionary, entity recognition can accurately distinguish between ordinary text and cybersecurity terminology. For example, in the text "Apache Avro 1.11.3 and earlier versions have a remote code execution vulnerability under certain conditions, numbered CVE-2024-47561," entity recognition can accurately identify "Apache Avro" as the component name entity, "CVE-2024-47561" as the CVE number entity, "remote code execution vulnerability" as the vulnerability type entity, "1.11.3 and earlier versions" as the version condition entity, and "specific conditions" as the exploit condition entity.

[0047] Information extraction is performed using predefined relationship templates, which represent the semantic associations between components, versions, conditions, and vulnerabilities. For example, a relationship template can be defined as the semantic pattern "component plus version has a vulnerability under the condition". By filling slots in the entity identification results according to this template, the natural language description is converted into structured information units. The extraction results are then converted into a structured format and stored in a component vulnerability knowledge base.

[0048] The exploitation condition information for corresponding vulnerabilities is extracted from the component vulnerability knowledge base. This exploitation condition information includes at least vulnerable version conditions, runtime environment conditions, configuration conditions, permission conditions, network conditions, and dependency conditions. For example, for a remote code execution vulnerability in a web application framework, the exploitation condition information might include: vulnerable version condition being a specific version series; runtime environment condition being that the target application is deployed in a Java runtime environment; configuration condition being that a specific functional module is enabled; permission condition being that the attacker can access the attacked interface without authentication; network condition being that the target interface is open to the public internet; and dependency condition being that the target application has introduced a specific version of a dependency library. This exploitation condition information is converted into a structured vulnerability exploitation condition constraint graph. The vulnerability exploitation condition constraint graph contains multiple condition nodes and logical relationships between nodes, including AND relationships, OR relationships, prerequisite dependencies, and blocking relationships. Each condition node is represented using a unified JSON data format, which includes at least a node identifier field, a condition type field, a condition value field, an evidence source field, and a status field.

[0049] The following is an example of a vulnerability exploitation condition constraint diagram in one implementation method: Example of a condition node: The node identifier is N0, the condition type is CVE number, the condition value is CVE-2024-47561, the source of evidence is the vulnerability announcement, and the status is condition met.

[0050] Example 2 of a condition node: The node identifier is N1, the condition type is version condition, the condition value is a specific version or lower, the source of evidence is a vulnerability announcement, and the status is unknown.

[0051] Example 3 of a condition node: The node identifier is N2, the condition type is exploitation condition, the condition value is processing untrusted data files, the source of evidence is vulnerability announcement, and the status is unknown.

[0052] Example 4 of a condition node: The node identifier is N3, the condition type is exploitation condition, the condition value is the existence of an exploitable class, the source of evidence is a vulnerability announcement, and the status is unknown.

[0053] Example 5 of a condition node: The node identifier is N4, the condition type is exploitation condition, the condition value is data verification not enabled, the source of evidence is vulnerability announcement, and the status is unknown.

[0054] Example of logical relationships: Node N1 and Node N2 are in an AND relationship, Node N2 and Node N3 are in an AND relationship, and Node N3 and Node N4 are in an AND relationship. This logical relationship means that all four conditions must be met simultaneously for the exploit path to be valid.

[0055] Step S2: Link the operating environment information and feedback from the responsible person.

[0056] The vulnerability scanning device probes acquire runtime information of the business system affected by the component vulnerability. This runtime information includes at least the business system identifier, host IP address, hostname, container identifier, Pod name, and path information. For example, in a containerized deployment environment, the runtime information acquired by the probe includes: the business system name is "Internet Financial Transaction System," the host IP address is a specified internal network IP address, the hostname is a specified hostname, the container identifier is the container ID assigned at runtime, the Pod name is the Pod name in the Kubernetes cluster, and the path information is the component's deployment path within the container. This runtime information is then mapped to the condition nodes in the vulnerability exploitation constraint graph to determine the initial state of each condition node. For example, the component deployment path information is associated with the path dependency conditions in the vulnerability exploitation conditions, the container runtime environment information is associated with the runtime environment conditions in the vulnerability exploitation conditions, and the network port open information is associated with the network conditions in the vulnerability exploitation conditions.

[0057] The system dispatches vulnerability remediation work orders to the responsible party and receives their submissions stating that the vulnerability does not exist. For example, the system sends a vulnerability remediation task to the responsible party through the work order system. After receiving the work order, the responsible party confirms that the vulnerability does not exist in the business system they are responsible for and submits a statement that the vulnerability does not exist through the work order system. This statement should include at least the reasons why the vulnerability does not exist and relevant supporting information. A large language model deployed in the local intranet environment is invoked to perform semantic structuring processing on the statement that the vulnerability does not exist, extracting factual assertions that explain the reasons for excluding the vulnerability, and generating structured evidence information. The structured evidence information should include at least the evidence number, evidence source, evidence attribute name, and evidence attribute value.

[0058] The following is an example of the responsible person's feedback parsing process in one implementation method: The prompt word template defines the model role as a financial network security and component vulnerability analysis expert. The task is to extract the reasons for excluding the non-existence of the vulnerability from the input basic vulnerability information and the feedback from the responsible party, and convert them into standard JSON format evidence information. It also sets rules to identify all factual evidence related to vulnerability exploitation conditions in the feedback from the responsible party, generate a unique evidence number for each extracted fact, fix the evidence source as the feedback from the responsible party, and extract the corresponding evidence attribute names and attribute values.

[0059] The original explanation submitted by the person in charge that the vulnerability did not exist was: "Although the business system used the affected version of the component, the data verification mechanism was enabled in the system configuration, and the exploitable class was not loaded in the runtime environment." The large language model extracts two factual assertions from the above description and generates the following structured evidence information: Evidence 1: Evidence number is E001, the source of the evidence is feedback from the responsible person, the evidence attribute name is data verification status, and the evidence attribute value is enabled.

[0060] Evidence 2: Evidence number E002, source of evidence is feedback from the responsible person, evidence attribute name is available class loading status, evidence attribute value is not loaded.

[0061] Step S3: Generate enhanced vulnerability context information.

[0062] A vulnerability context information is constructed around the aforementioned component vulnerability. This vulnerability context information includes the basic vulnerability information, the vulnerability exploitation constraint graph, the runtime information, and the structured evidence information. The vulnerability context information is organized in a JSON structured format to facilitate understanding and processing by the subsequent large language model. For example, in one implementation, the vulnerability context information includes the following: the basic vulnerability information section includes the vulnerability name, CVE number, vulnerability type, affected version, and component name; the vulnerability exploitation constraint graph section includes the identifier, type, value, source, and status of each condition node, as well as the logical relationships between nodes; the runtime information section includes the business system identifier, host IP, container identifier, and path information; and the structured evidence information section includes the evidence number, source, attribute name, and attribute value extracted from the feedback of the responsible party.

[0063] Step S4: Call the large model to perform knowledge-enhanced reasoning.

[0064] like Figure 2As shown, this step specifically includes: converting the vulnerability context information into a JSON structured representation and inputting it into the large language model; the large language model performs a status determination (valid / invalid / unknown) for each condition node based on a preset prompt word template; at the same time, the large language model performs conflict identification on multi-source evidence from different data sources such as vulnerability scan results, operating environment, and feedback from responsible persons, and outputs a structured determination result.

[0065] The detailed technical details are as follows: The vulnerability context information is converted into a JSON structured representation according to a preset structured format and then input into the large language model. The large language model is deployed in a local intranet environment to prevent sensitive vulnerability information from being uploaded to external networks.

[0066] The large language model performs fact extraction and condition verification based on a preset prompt word template. The preset prompt word template includes at least a role definition section, a condition matching rule section, a state determination rule section, and an output format constraint section. Specifically, the role definition section positions the large language model as a network security vulnerability analysis expert; the condition matching rule section defines the matching logic between various types of exploitation conditions and runtime information; the state determination rule section defines the criteria for determining three states: condition valid, condition invalid, and unknown state; and the output format constraint section requires the model to output structured data containing the state determination result and corresponding evidence for each condition node.

[0067] The large language model outputs a state determination result and corresponding evidence information for each condition node in the vulnerability exploitation constraint graph. The state determination result includes condition met, condition not met, and state unknown. For example, for the version condition node, the large language model compares the component version recorded in the vulnerability scan results with the affected version range in the vulnerability exploitation conditions. If the versions match, the condition is determined to be met, and the evidence source is the vulnerability scan results. For the configuration condition node, the large language model compares the configuration item values ​​in the runtime information with the configuration requirements in the vulnerability exploitation conditions. If the configuration meets the exploitation requirements, the condition is determined to be met; if the configuration does not meet the exploitation requirements, the condition is determined to be not met; if the configuration item value cannot be determined from the runtime information, the state is determined to be unknown.

[0068] The following is an example of how a large model performs state determination on condition nodes in one implementation: The vulnerability context information input to the large language model includes the following condition node information: the condition value of the version condition node is a specific version or lower, and the version of this component in the runtime information is a specific version; the condition value of the untrusted data file processing condition node is processing untrusted data files, and the vulnerability description information indicates that this component has a security risk when processing external input data; the condition value of the exploitable class existence condition node is the existence of an exploitable class, and the responsible person's feedback states that the exploitable class has not been loaded; the condition value of data validation not enabled condition node is data validation not enabled, and the responsible person's feedback states that data validation has been enabled.

[0069] After the large language model determines the status of each of the above condition nodes, it outputs the following: the version condition node is in a conditional state, with evidence from vulnerability scan results; the condition node for handling untrusted data files is in a conditional state, with evidence from vulnerability scan results; the condition node for the existence of exploitable classes is in a conditional state, with evidence from feedback from the responsible party; and the condition node for not enabling data verification is in a conditional state, with evidence from feedback from the responsible party.

[0070] The large language model also performs multi-source evidence conflict identification based on the structured evidence information, the runtime information, and historical false alarm cases. Multi-source evidence conflict identification refers to determining whether there are semantic contradictions in evidence values ​​under the same evidence attribute from different data sources. These different data sources include at least runtime environment information, vulnerability exploitation condition verification results, responsible party feedback information, and vulnerability scanning results.

[0071] The following is an example of multi-source evidence conflict identification in one implementation: The system received a vulnerability alert for a component. The runtime environment awareness module obtained version A for this component. However, the vulnerability scan results recorded version B for the same component. The responsible party's feedback stated that the component version was version A. The large language model identified a semantic contradiction between version A provided by the runtime environment awareness module and version B recorded in the vulnerability scan results, recording this as a conflict of evidence from multiple sources.

[0072] The following is an example of multi-source evidence conflict identification in another implementation: The responsible party claimed in their feedback that a certain security configuration was enabled, but the runtime environment awareness module found that the configuration was actually disabled by reading the configuration file. After the large language model identified this contradiction, the system prioritized the direct probe data from the runtime environment awareness module.

[0073] Specifically, when calling the large language model to identify conflicts in multi-source evidence, the following prompt word template is used to guide the model to output the conflict identification results: The prompt word template defines the model role as a financial-grade cybersecurity compliance and evidence auditing expert, whose task is to identify semantic contradictions in the input JSON structured evidence list, determine whether there are logical conflicts in the key values ​​of different data sources on the same or related evidence attributes, and set rules to traverse all input evidence objects, compare evidence objects with the same evidence attributes, determine whether the evidence values ​​provided by different sources have semantic contradictions or obvious inconsistencies, and count the total number of input evidence and the number of identified conflicting evidence.

[0074] Step S5: Perform constraint propagation calculation and credibility assessment.

[0075] According to the pessimistic assessment criterion, exploit condition nodes with an unknown state are considered valid; blocking condition nodes with an unknown state are considered invalid according to the conservative principle, to avoid missed detections due to missing information triggering blocking. The pessimistic assessment criterion is based on the security priority principle; when it is impossible to confirm whether a condition is valid, it is assumed to be valid to trigger further verification, avoiding the omission of real vulnerabilities due to lack of evidence.

[0076] Based on the state determination result, constraint propagation calculations are performed on the vulnerability exploitation constraint graph to determine whether the vulnerability exploitation path is blocked. The constraint propagation calculation is performed according to the logical relationships between the condition nodes in the vulnerability exploitation constraint graph, specifically including: for multiple condition nodes connected by an AND relationship, if any condition node is determined to be false, the entire AND relationship is false, resulting in blocking; for multiple condition nodes connected by an OR relationship, if all condition nodes are determined to be false, the entire OR relationship is false, resulting in blocking; for prerequisite dependencies, if a prerequisite condition node is determined to be false, subsequent condition nodes depending on that prerequisite condition node cannot be true, resulting in blocking; for blocking relationships, when a blocking condition node is determined to be true, the target condition node constrained by that blocking relationship is false, resulting in blocking.

[0077] If a critical condition node is determined to be invalid or blocked after constraint propagation, the system outputs a result indicating that the vulnerability does not exist, and generates a structured chain of evidence containing the blocking path. For example, in the aforementioned example, an exploitable condition node is determined to be invalid, a data validation not enabled condition node is determined to be invalid, and the above condition nodes, version condition nodes, and untrusted data file processing condition nodes are all ANDed. If any condition node fails, the entire AND relationship will be invalid, the vulnerability exploitation path will be blocked, and the system will output a result indicating that the vulnerability does not exist.

[0078] Otherwise, the credibility of the vulnerability is calculated. The credibility of the vulnerability is determined based on a combination of the vulnerability exploitation condition matching degree, multi-source evidence conflict degree, and historical false positive case similarity. The vulnerability exploitation condition matching degree reflects the proportion of the number of satisfied vulnerability exploitation conditions to the total number of vulnerability exploitation conditions. For example, if there are five vulnerability exploitation conditions, and four of them are determined to be satisfied, then the vulnerability exploitation condition matching degree is four-fifths. The multi-source evidence conflict degree reflects the proportion of conflicting evidence identified by the large language model to the total number of evidence. The existence of conflicting evidence indicates inconsistencies between information from different data sources, weakening the reliability of the judgment basis. Therefore, the existence of conflicting evidence negatively adjusts the credibility of the vulnerability. For example, if there are four total pieces of evidence, and one piece of evidence is conflicting, then the multi-source evidence conflict degree is one-quarter. The historical false positive case similarity reflects the degree of matching between the current vulnerability and historical false positive cases in the false positive knowledge base. When the current vulnerability and historical false positive cases in the false positive knowledge base are consistent in terms of component name, vulnerability type, exploitation conditions, and network architecture, it is determined that there are similar historical false positives. The matching of historical false positive cases reduces the credibility of the vulnerability.

[0079] For condition nodes whose status is determined to be unknown, they are not included in the numerator calculation of the vulnerability exploitation condition matching degree. That is, only condition nodes with a clear determination result are counted in the matching degree calculation. Simultaneously, the system introduces an evidence completeness factor, reflecting the proportion of unknown state nodes to the total number of condition nodes. The higher the proportion of unknown state nodes, the less sufficient the evidence available for judgment. This factor negatively adjusts the credibility of the vulnerability's existence. Through this mechanism, the system will neither falsely report vulnerabilities due to pessimistic assessments nor easily overlook vulnerabilities due to missing information when evidence is insufficient. Instead, it objectively reflects the incompleteness of the evidence in the credibility metric.

[0080] Step S6: Closed-loop handling and false alarm knowledge learning.

[0081] A closed-loop process is executed based on the comparison between the vulnerability's credibility and a preset threshold. When the vulnerability's credibility is higher than the first preset threshold, a vulnerability existence determination result is output, and the process proceeds to vulnerability remediation. When the vulnerability's credibility is lower than the second preset threshold, a vulnerability non-existence determination result is output, and the vulnerability handling process is closed. When the vulnerability's credibility is between the first and second preset thresholds, a determination result requiring manual review is output, and the vulnerability administrator conducts manual review and confirmation. A determination report containing a structured evidence chain is generated, whereby the structured evidence chain includes at least the status determination result of each condition node, the corresponding evidence source, and the evidence content.

[0082] For cases where a vulnerability is determined to be non-existent, the vulnerability type, vulnerability name, and proof of its non-existence are extracted and stored in a false positive knowledge base. This information is used for historical false positive case similarity matching during subsequent vulnerability assessments. For example, if a vulnerability with a certain CVE number is determined to be non-existent in a specific business system environment, the system stores the CVE number, vulnerability type, proof of its non-existence, and corresponding operating environment characteristics in the false positive knowledge base. When the system subsequently receives a vulnerability alert with the same CVE number, it queries the false positive knowledge base and finds historical false positive records for that vulnerability. The system then incorporates the similarity of these historical false positive cases into the credibility calculation to reduce the credibility of the vulnerability and avoid redundant manual review.

[0083] Example 2 like Figure 3 As shown, this embodiment provides a vulnerability false alarm determination system based on knowledge enhancement.

[0084] The system includes a large model support module, a vulnerability exploitation constraint graph construction module, a runtime environment awareness module, a vulnerability context parsing module, an intelligent reasoning and decision-making module, a closed-loop handling module, and a false alarm knowledge learning module. Data interaction between these modules uses JSON structured data format, and the modules communicate through pre-defined data interfaces to achieve loosely coupled integration.

[0085] The large model support module is deployed in a local intranet environment to provide large model computing power support for vulnerability context information statistics and vulnerability existence inference. The large model support module is equipped with graphics processing unit (GPU) computing resources to load and run multimodal large language models. All vulnerability-related data is processed within the local intranet environment without needing to be uploaded to an external network.

[0086] The vulnerability exploitation condition constraint graph construction module includes a vulnerability detection submodule and a vulnerability exploitation condition parsing submodule.

[0087] The vulnerability detection submodule is used to respond to the component vulnerability detection results received from the security scanning device, and to standardize and normalize the vulnerability detection results to generate basic vulnerability information. The basic vulnerability information includes at least the vulnerability name, CVE number, vulnerability type, affected version, vulnerability path, discovery time, and component name.

[0088] The vulnerability exploitation condition parsing submodule is used to parse the basic vulnerability information and perform text preprocessing on the basic vulnerability information. This text preprocessing includes at least HTML tag cleaning and word / sentence segmentation. Entity recognition is performed on the preprocessed text using a cybersecurity-specific dictionary. Entity recognition identifies at least the CVE number and component name. Information extraction is performed using a predefined relationship template, which represents the semantic association between components, versions, conditions, and vulnerabilities. The extraction results are converted into a structured format and stored in the component vulnerability knowledge base. Exploitation condition information for the corresponding vulnerability is extracted from the component vulnerability knowledge base. This exploitation condition information includes at least vulnerable version conditions, runtime environment conditions, configuration conditions, permission conditions, network conditions, and dependency conditions. The exploitation condition information is converted into a structured vulnerability exploitation condition constraint graph. The vulnerability exploitation condition constraint graph contains multiple condition nodes and logical relationships between nodes. These logical relationships include AND relationships, OR relationships, prerequisite dependencies, and blocking relationships. Each condition node is represented using a unified JSON data format, which includes at least a node identifier field, a condition type field, a condition value field, an evidence source field, and a status field.

[0089] The runtime environment awareness module is used to obtain runtime information of business systems affected by the component vulnerability through vulnerability scanning device probes. The runtime information includes at least the business system identifier, host IP address, host name, container identifier, Pod name, and path information. The runtime environment awareness module also associates and maps the runtime information with the condition nodes in the vulnerability exploitation condition constraint graph to determine the initial state of each condition node.

[0090] Figure 4 This diagram illustrates the internal structure and data interaction of the intelligent reasoning and decision-making module. The core of this module is the knowledge-enhanced reasoning submodule, which receives inputs including vulnerability context information from the vulnerability context parsing module, structured evidence information from the responsible party feedback parsing submodule, and historical false alarm cases from the false alarm knowledge learning module. The knowledge-enhanced reasoning submodule invokes a large model for reasoning, outputting the results to the credibility measurement submodule for constraint propagation calculation and credibility quantification, ultimately generating a judgment result containing a credibility score.

[0091] Specifically, the intelligent reasoning decision-making module includes a responsible person feedback analysis submodule, a knowledge-enhanced reasoning submodule, and a credibility measurement submodule.

[0092] The responsible party feedback parsing submodule is used to dispatch vulnerability remediation process work orders to the responsible party, receive the vulnerability non-existence statement submitted by the responsible party, call the large language model to perform semantic structuring processing on the vulnerability non-existence statement, extract factual assertions for vulnerability exclusion, and generate structured evidence information. The structured evidence information includes at least evidence number, evidence source, evidence attribute name, and evidence attribute value. The responsible party feedback parsing submodule uses the prompt word template described in Embodiment 1 to guide the large language model to output structured evidence information.

[0093] The knowledge-enhanced reasoning submodule converts the vulnerability context information into a JSON structured representation according to a preset structured format and inputs it into the large language model. The large language model performs fact extraction and condition verification based on a preset prompt word template. The preset prompt word template includes at least a role definition section, a condition matching rule section, a state determination rule section, and an output format constraint section. The large language model outputs a state determination result and corresponding evidence information for each condition node in the vulnerability exploitation condition constraint graph. The state determination result includes condition true, condition false, and state unknown. The large language model also performs multi-source evidence conflict identification based on the structured evidence information, the runtime information, and historical false alarm cases to determine whether there are semantic contradictions in the evidence values ​​under the same evidence attribute from different data sources. The knowledge-enhanced reasoning submodule uses the multi-source evidence conflict identification prompt word template described in Embodiment 1 to guide the large language model to output conflict identification results.

[0094] The credibility measurement submodule is used to treat condition nodes whose state determination result is unknown as condition valid according to the pessimistic evaluation criterion. Based on the state determination result, constraint propagation calculation is performed on the vulnerability exploitation condition constraint graph to determine whether the vulnerability exploitation path is blocked. The constraint propagation calculation is performed according to the logical relationship between each condition node in the vulnerability exploitation condition constraint graph, specifically including: for multiple condition nodes connected by an AND relationship, if any condition node is determined to be invalid, the entire AND relationship is invalid, resulting in blocking; for multiple condition nodes connected by an OR relationship, if all condition nodes are determined to be invalid, the entire OR relationship is invalid, resulting in blocking; for pre-dependency relationships, if a pre-condition node is determined to be invalid, subsequent condition nodes depending on that pre-condition node cannot be valid, resulting in blocking; for blocking relationships, when a blocking condition node is determined to be valid, the target condition node constrained by that blocking relationship is invalid, resulting in blocking. When a critical condition node is determined to be invalid or blocked after constraint propagation, a determination result indicating that the vulnerability does not exist is output; otherwise, the credibility of the vulnerability is calculated. The credibility of a vulnerability is determined based on a comprehensive assessment of the matching degree of vulnerability exploitation conditions, the conflict degree of multi-source evidence, and the similarity of historical false positive cases. The matching degree of vulnerability exploitation conditions reflects the proportion of satisfied vulnerability exploitation conditions to the total number of exploitation conditions. The conflict degree of multi-source evidence reflects the proportion of conflicting evidence identified by the large language model to the total number of evidence; the presence of conflicting evidence negatively adjusts the credibility of the vulnerability's existence. The similarity of historical false positive cases reflects the degree of matching between the current vulnerability and historical false positive cases in the false positive knowledge base. When the current vulnerability and historical false positive cases in the false positive knowledge base are consistent in terms of component name, vulnerability type, exploitation conditions, and network architecture, it is determined that there are similar historical false positives, and the matching of historical false positive cases reduces the credibility of the vulnerability's existence.

[0095] The vulnerability context parsing module is used to construct vulnerability context information around the component vulnerability and provide it to the intelligent reasoning and decision-making module. The vulnerability context information includes the basic vulnerability information, the vulnerability exploitation condition constraint graph, the runtime information, and the structured evidence information. The vulnerability context information is organized in a JSON structured format.

[0096] The closed-loop handling module is used to perform closed-loop handling based on the comparison result of the vulnerability's credibility with a preset threshold. When the vulnerability's credibility is higher than the first preset threshold, a vulnerability existence determination result is output and the process is transferred to the vulnerability remediation process. When the vulnerability's credibility is lower than the second preset threshold, a vulnerability non-existence determination result is output and the vulnerability handling process is closed. When the vulnerability's credibility is between the first and second preset thresholds, a determination result requiring manual review is output. The closed-loop handling module is also used to generate a determination report containing a structured evidence chain, which includes at least the status determination result of each condition node, the corresponding evidence source, and the evidence content.

[0097] The false alarm knowledge learning module is used to extract the vulnerability type, vulnerability name, and proof information that the vulnerability does not exist for cases that are determined to be non-existent, and store them in the vulnerability false alarm knowledge base, so that the knowledge enhancement reasoning submodule can perform similarity matching of historical false alarm cases in subsequent vulnerability determinations.

[0098] Example 3 This embodiment uses an internet finance business system in a bank's production environment as an application scenario to provide a detailed explanation of the specific implementation process of the technical solution of the present invention.

[0099] The bank's internet finance business system runs on a Kubernetes container cluster, with an application runtime environment including Tomcat, Nginx, Redis, the Spring Boot framework, and multiple open-source components. The bank's security operations center conducts periodic vulnerability checks on the production environment using a host intrusion detection system and a host vulnerability scanning system.

[0100] The vulnerability administrator regularly imports internet vulnerability information, regulatory agency announcements, and security operations center reports. The system obtains basic vulnerability information through semantic analysis, including vulnerability name, vulnerability type, vulnerability exploitation conditions, vulnerability principle, affected versions, risk indicators, attack process, vulnerability verification code, and remediation plan, forming a built-in component vulnerability knowledge base.

[0101] Let's take a vulnerability in an open-source serialization component, CVE-2024-47561, as an example. The original vulnerability announcement received by the system states: This component has a remote code execution vulnerability in certain versions and earlier. Exploiting this vulnerability requires the following conditions to be met: First, the application processes untrusted data files from external sources; second, an exploitable class exists in the runtime environment; and third, the system does not have a data verification mechanism enabled.

[0102] The system performs text preprocessing on the aforementioned vulnerability announcement information, including HTML tag cleaning and word / sentence segmentation. It then uses a cybersecurity-specific dictionary for entity recognition, identifying CVE number entities, component name entities, version condition entities, vulnerability type entities, and multiple exploitation condition entities. Information extraction is performed using predefined relationship templates, and the extracted results are converted into a JSON structured format and stored in the component vulnerability knowledge base.

[0103] The system generates a vulnerability exploitation constraint graph. This constraint graph contains the following condition nodes: CVE ID node, condition value is CVE-2024-47561, source is vulnerability announcement, initial state is condition met; Version condition node, condition value is the range of affected versions, source is vulnerability announcement, initial state is unknown; First exploit condition node, condition value is processing untrusted data files, source is vulnerability announcement, initial state is unknown; Second exploit condition node, condition value is the existence of an exploitable class, source is vulnerability announcement, initial state is unknown; Third exploit condition node, condition value is data verification not enabled, source is vulnerability announcement, initial state is unknown. The above version condition node, first exploit condition node, second exploit condition node, and third exploit condition node are connected by an AND relationship.

[0104] The system also constructs a historical vulnerability false alarm knowledge base. This knowledge base stores information on component vulnerabilities that were historically determined to be non-existent, along with their corresponding chains of evidence, and is linked to the component vulnerability knowledge base, providing historical experience for current vulnerability analysis.

[0105] The system receives an alert from a host vulnerability scanning system, indicating the presence of the aforementioned component vulnerability in the target business system. The system standardizes and normalizes the alert information using the vulnerability detection submodule, generating basic vulnerability information. The system then obtains the runtime information of the affected business system through the runtime environment awareness module. This runtime information includes the business system name, host IP address, host name, container identifier, Pod name, and deployment path.

[0106] The system extracts the exploitation condition information of the vulnerability from the component vulnerability knowledge base and associates it with runtime information. The system uses the vulnerability exploitation condition parsing submodule to extract the exploitation condition information of the vulnerability from the component vulnerability knowledge base and supplements the state information of each node in the vulnerability exploitation condition constraint diagram.

[0107] The vulnerability administrator confirms and sends a vulnerability remediation work order to the person responsible for vulnerability remediation in the corresponding business system. The person responsible confirms that the vulnerability does not exist and submits a statement explaining that the vulnerability does not exist. This statement indicates that although the business system uses the affected version of the component, the system configuration has enabled a data verification mechanism, and there are no exploitable classes in the runtime environment.

[0108] The system calls the responsible party feedback parsing submodule, which in turn calls the large language model to perform semantic structuring on the responsible party feedback. The large language model extracts the following factual assertions from the responsible party feedback: First, the data verification mechanism is enabled; the source of evidence is the responsible party feedback, the evidence attribute name is "data verification status," and the evidence attribute value is "enabled." Second, there are no usable classes in the runtime environment; the source of evidence is the responsible party feedback, the evidence attribute name is "usable class exists status," and the evidence attribute value is "does not exist."

[0109] The system calls the knowledge-enhanced reasoning submodule to convert the vulnerability context information into a JSON structured representation before inputting it into the large language model. The large language model performs status determination on each condition node: the version condition node is in a true state, with evidence from the vulnerability scan results; the condition node for handling untrusted data files is in a true state, with evidence from the vulnerability scan results; the condition node for the existence of exploitable classes is in a false state, with evidence from feedback from the responsible party; and the condition node for not enabling data validation is in a false state, with evidence from feedback from the responsible party.

[0110] The system calls the Trustworthiness Measurement submodule to perform constraint propagation calculations. Since both the exploitable class condition node and the condition node with disabled data validation are deemed invalid, and these two condition nodes are ANDed with the version condition node and the condition node for handling untrusted data files, according to the propagation rules of AND relationships, the invalidation of any condition node immediately invalidates the entire AND relationship, thus blocking the vulnerability exploitation path. The system outputs a result indicating that the vulnerability does not exist.

[0111] The system invokes the closed-loop handling module to generate a judgment report containing a structured evidence chain. This structured evidence chain includes the status judgment results of each condition node and the corresponding evidence source. The system then invokes the false alarm knowledge learning module to extract the vulnerability type and name, storing the proof that the vulnerability does not exist in the vulnerability false alarm knowledge base. Subsequently, when this business system or other business systems receive vulnerability alerts with the same CVE number, the system can retrieve this historical false alarm case from the false alarm knowledge base and use it as a basis for reducing the credibility of the vulnerability's existence.

[0112] Example 4 This embodiment provides an implementation example of the technical solution of this application in another specific application scenario.

[0113] A company's security operations center has deployed a software composition analysis system and a container image scanning system. These systems generate a large number of component vulnerability alerts daily, and security operations personnel need to manually review each alert to confirm whether the vulnerability actually exists.

[0114] After the security operations center deploys the system described in this application, it will connect the alarm outputs of the host vulnerability scanning system, software composition analysis system, and container image scanning system to the vulnerability detection submodule of the system described in this application.

[0115] The system received a vulnerability alert for a component. The alert information included the component name, component version, CVE number, and discovery path. The system extracted the exploitation conditions corresponding to the CVE number from the component vulnerability knowledge base.

[0116] The system obtains the actual deployment information of the component through the runtime environment awareness module, including the container environment identifier, Pod identifier, deployment path, and configuration file path. The system then maps the configuration file path information to the configuration conditions in the vulnerability exploitation conditions. In one implementation, the system reads the configuration file content, identifies the on / off state of a certain security configuration, compares this state with the configuration conditions in the vulnerability exploitation conditions, determines that the configuration condition node is invalid, blocks the vulnerability exploitation path, automatically outputs a result indicating that the vulnerability does not exist, and closes the handling process.

[0117] In another implementation, the system obtains information that the component is running in non-privileged mode through the runtime environment awareness module. After comparing this information with the permission conditions in the vulnerability exploitation conditions, the permission condition node is determined to be invalid, and the vulnerability exploitation path is blocked.

[0118] In another implementation, the system obtains information from the environment awareness module that the network partition where the component is located has a strict network access control policy. After comparing the policy information with the network conditions in the vulnerability exploitation conditions, the network condition node is determined to be invalid, and the vulnerability exploitation path is blocked.

[0119] The judgment results and corresponding evidence sources for each of the above-mentioned condition nodes are recorded as structured evidence information and output along with the judgment report. Security operations personnel no longer need to review each alarm individually; they only need to focus on alarm items that the system determines require manual review, significantly reducing the manual cost of vulnerability remediation.

[0120] Example 5 This embodiment provides a specific implementation example of the multi-source evidence conflict identification mechanism in the technical solution of this application.

[0121] The system received a vulnerability alert for a certain component. The runtime environment awareness module obtained the component's version information as version A. However, the vulnerability scan results recorded the component's version information as version B. The responsible person's feedback stated that the component's version was version A.

[0122] The system calls the knowledge-enhanced reasoning submodule, inputting the version information from the three data sources mentioned above as three evidence values ​​under the same evidence attribute into the large language model for multi-source evidence conflict identification.

[0123] The large language model identifies a semantic contradiction between version A provided by the runtime environment awareness module and version B recorded in the vulnerability scan results. The system records this conflict as a multi-source evidence conflict, with a total of three pieces of evidence, one of which is conflicting, resulting in a multi-source evidence conflict degree of one-third. The existence of this conflicting evidence positively adjusts the vulnerability's credibility during calculation.

[0124] The system further obtains more detailed component version information through the runtime environment awareness module to confirm the accurate version. After confirming that the version is version A, the system marks the version information in the vulnerability scan results as inaccurate and performs subsequent vulnerability exploitation condition verification based on version A.

[0125] In another implementation, the responsible party's feedback statement claims that a certain security configuration is enabled, but the runtime environment awareness module discovers that the configuration is actually disabled by reading the configuration file. After the large language model identifies this contradiction, the system prioritizes the direct probe data from the runtime environment awareness module and determines that the configuration condition node is valid. The existence of conflicting evidence from multiple sources positively adjusts the credibility of the vulnerability's existence, thereby ensuring that the system will not miss a vulnerability due to a single unreliable data source.

[0126] In another implementation, the historical false alarm knowledge base records historical false alarm cases with the same CVE number under the same business system. In these historical false alarm cases, the vulnerability was determined to be non-existent because the responsible party reported that a certain configuration condition was not met. In the current vulnerability determination, the runtime environment awareness module confirms that the configuration condition is actually met. The large language model identifies an inconsistency between the current evidence and historical false alarm cases, and the system determines that it is not a similar historical false alarm. The similarity of historical false alarm cases does not contribute to reducing the credibility of the vulnerability's existence. The system makes independent determinations based on the current runtime information, ensuring that historical false alarm experience does not incorrectly overwrite the current actual runtime state.

[0127] Example 6 This embodiment provides a specific implementation example of the reliability quantification assessment mechanism for the vulnerability existence in the technical solution of this application.

[0128] The vulnerability exploitation constraint diagram for a certain component contains five exploitation condition nodes. After the system correlates runtime information and analyzes the feedback from the responsible party, the status judgment results of each condition node are as follows: the first condition node is judged as condition true, the second condition node is judged as condition true, the third condition node is judged as condition true, the fourth condition node is judged as condition false, and the fifth condition node is judged as condition true.

[0129] The system uses a pessimistic evaluation criterion for constraint propagation calculations. Since the fourth condition node is false and there is a blocking relationship between this node and the other condition nodes, the exploit path is blocked. The system directly outputs a result indicating that the vulnerability does not exist, without requiring confidence level calculations.

[0130] In another scenario, the exploit constraint graph for a component vulnerability contains five exploit condition nodes, all of which are ANDed with each other. The status determination results for each condition node are as follows: the first condition node is determined to be true, the second condition node is determined to be true, the third condition node is determined to be true, the fourth condition node is determined to be unknown, and the fifth condition node is determined to be true.

[0131] According to the pessimistic evaluation criterion, the system considers the unknown state of the fourth condition node as a valid condition. No condition nodes are determined to be invalid, and constraint propagation is not blocked. The system then proceeds to the credibility calculation process.

[0132] The vulnerability exploitation conditions were found to be met out of all five conditions, representing 100% of the total five conditions. Four pieces of evidence were provided: runtime environment information, vulnerability exploitation condition verification results, and feedback from responsible parties. The large language model identified one instance of conflicting evidence from multiple sources, with a conflict rate of one-quarter, indicating an inconsistency among the four pieces of evidence and reducing the overall reliability of the judgment. The existence of this conflicting evidence negatively adjusted the credibility, resulting in a moderate calculated credibility for the vulnerability. No similar historical false positive cases were found in the historical false positive knowledge base, resulting in a zero similarity between historical false positive cases and the actual false positive cases.

[0133] The credibility of the vulnerability is calculated based on the above factors. The final calculated credibility is high, exceeding the first preset threshold. The system then outputs the vulnerability assessment result and initiates the vulnerability remediation process.

[0134] In another scenario, the vulnerability exploitation constraint graph for a component vulnerability contains six exploitation condition nodes, all of which are ANDed with each other. The status determination results for each condition node are as follows: the first condition node is determined to be true, the second condition node is determined to be true, the third condition node is determined to be true, the fourth condition node is determined to be true, the fifth condition node is determined to be true, and the sixth condition node is determined to be in an unknown state.

[0135] According to the pessimistic evaluation criterion, the system considers the unknown state of the sixth condition node as a valid condition. No condition nodes are determined to be invalid, and constraint propagation is not blocked. The system then proceeds to the credibility calculation process.

[0136] The vulnerability exploitation conditions were met out of all six conditions, representing 100% of the total six conditions. No conflicts were found between the various pieces of evidence, resulting in a zero conflict rate. Three similar historical false alarm cases were found in the historical false alarm knowledge base. All three cases involved the same component name, vulnerability type, similar exploitation conditions, and the same network architecture, resulting in a similarity of three. Matching these historical false alarm cases negatively adjusted the confidence level, ultimately leading to a low calculated vulnerability existence confidence value, below the second preset threshold. Therefore, the system output a vulnerability non-existent determination and closed the vulnerability handling process.

[0137] In another scenario, the vulnerability exploitation constraint graph for a component vulnerability contains four exploitation condition nodes. The status determination results for each condition node are as follows: the first condition node is determined to be true, the second condition node is determined to be true, the third condition node is determined to be unknown, and the fourth condition node is determined to be unknown.

[0138] Based on the pessimistic assessment criteria, the system considers the unknown state of both the third and fourth condition nodes as valid conditions. The exploitation condition matching degree is defined as the number of conditions met out of four, representing 100% of the total four conditions. The system then proceeds to the credibility calculation process. Considering the existence of two condition nodes with unknown states, whose evidentiary support is relatively weak, the system applies a confidence discount to the exploitation condition matching degree during credibility calculation. The final calculated vulnerability existence credibility falls between the first and second preset thresholds. The system outputs a judgment result requiring manual review, whereby the vulnerability administrator conducts further investigation and confirmation of the condition nodes with unknown states.

[0139] Example 7 This embodiment provides a specific implementation case of the construction and updating of the component vulnerability knowledge base in the technical solution of this application.

[0140] During initial system deployment, the component vulnerability knowledge base is empty. Vulnerability administrators import internet vulnerability information, regulatory agency announcements, and security operations center reports through the system's provided knowledge import interface.

[0141] The system preprocesses the imported raw vulnerability announcement information. Taking a vulnerability announcement for a web application framework as an example, the original announcement text contains an HTML-formatted vulnerability description, a list of affected versions, and remediation suggestions. The system cleans the HTML tags, extracts the plain text content, and then performs word segmentation and sentence segmentation.

[0142] The system uses a proprietary dictionary in the cybersecurity field to perform entity recognition on the preprocessed text. The entity recognition results include: CVE number entity, identified as the CVE number of the vulnerability; component name entity, identified as the name of the web application framework; vulnerability type entity, identified as remote code execution; version condition entity, identified as the range of affected versions; and exploit condition entity, identified as multiple exploit prerequisites.

[0143] The system uses predefined relation templates for information extraction. These templates include a first template and a second template. The first template matches semantic patterns of component name plus version plus existence plus vulnerability, while the second template matches semantic patterns of existence plus vulnerability under a given condition. Through template matching and slot filling, the system combines component name, version condition, and vulnerability type from the entity identification results into structured data, and extracts each exploit prerequisite from the exploit condition entity into independent exploit condition entries.

[0144] The system converts the extracted results into a JSON structured format and stores them in the component vulnerability knowledge base. The data stored in the knowledge base includes at least three fields: basic vulnerability information, exploitation condition list, and relationship. The basic vulnerability information field includes at least the CVE number, component name, vulnerability type, and affected version. The exploitation condition list field includes at least the condition type and value for each exploitation condition entry. The relationship field records the logical relationships between the various condition entries.

[0145] When the system receives new vulnerability announcements, it repeats the above process, incrementally storing the new vulnerability information into the component vulnerability knowledge base. Existing vulnerability information in the knowledge base is not overwritten by updates; the system retains historical versions of the knowledge through a version management mechanism. As the number of vulnerability entries stored in the knowledge base increases, the system's input knowledge to the large language model is continuously enriched, and the inference accuracy of the large language model in subsequent vulnerability assessments gradually improves.

[0146] Example 8 This embodiment provides a specific implementation example of locally deploying a large language model in the technical solution of this application.

[0147] The system described in this application is deployed in the bank's security operations center. The system's large-scale model support module is equipped with a computing server using domestically produced artificial intelligence computing chips. This server is deployed in a secure area of ​​the bank's internal network and is physically isolated from the external Internet.

[0148] The large model supports module loading of multimodal large language models. This large language model is a domestically developed open-source large language model, and its parameter scale can meet the computational needs of vulnerability context information statistics and vulnerability existence inference. At the same time, its deployment method complies with the financial industry's regulatory requirements for sensitive data not leaving the domain.

[0149] During system operation, all data processing involving detailed vulnerability information, operating environment information, and feedback from responsible parties is completed within the local intranet environment where the large model support module resides. The input data for the large language model is vulnerability context information represented in JSON structure, and the output data consists of the status judgment results for each condition node and corresponding evidence information. Neither the input nor output data contains the original source code or production data; it only contains vulnerability metadata and judgment result information.

[0150] During system operation, the large model support module periodically retrieves incremental update packages for the large language model from the internal network security update server. These incremental update packages contain model parameter updates obtained from training based on the latest vulnerability data. All model update operations are completed within the local internal network environment, without uploading any data to the external network.

[0151] The embodiments described above are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A vulnerability false alarm determination method based on knowledge enhancement, characterized in that, include: Construct a vulnerability exploitation constraint graph: Normalize the component vulnerability detection results to generate basic vulnerability information; The basic information of the vulnerability is analyzed, and the exploitation condition information is extracted from the component vulnerability knowledge base and converted into a vulnerability exploitation condition constraint graph. The constraint graph contains condition nodes and logical relationships between nodes. Corresponding to the operating environment and feedback from responsible persons: Obtain the operating status information of the affected business systems and associate them with the condition nodes in the constraint diagram to determine the initial state; The vulnerability of the receiving party does not exist. After semantic structuring, factual assertions are extracted to generate structured evidence information. Generate vulnerability context information: Construct vulnerability context information around the component vulnerability, including basic vulnerability information, constraint diagrams, runtime information, and structured evidence information; Calling large model reasoning: Input vulnerability context information into large language model to obtain the state judgment results and corresponding evidence of each condition node, as well as the multi-source evidence conflict identification results; Constraint propagation and credibility assessment: Exploitation condition nodes with unknown states are considered valid according to the pessimistic assessment criteria; For blocking condition nodes with unknown states, they are considered invalid according to the conservative principle. Constraint propagation calculations are performed on the constraint graph to determine whether the vulnerability exploitation path is blocked. If blocked, the vulnerability is determined to not exist; otherwise, the credibility of vulnerability existence is calculated based on the matching degree of vulnerability exploitation condition validity, the conflict degree of multi-source evidence, and the similarity of historical false alarm cases. Among them, the constraint propagation calculation is performed according to the logical relationship between each condition node in the vulnerability exploitation condition constraint graph, specifically including: for multiple condition nodes connected by an AND relationship, if any condition node is determined to be invalid, the AND relationship as a whole is invalid, resulting in blocking; for multiple condition nodes connected by an OR relationship, if all condition nodes are determined to be invalid, the OR relationship as a whole is invalid, resulting in blocking; for a prerequisite dependency relationship, if a prerequisite condition node is determined to be invalid, the subsequent condition nodes that depend on the prerequisite condition node cannot be valid, resulting in blocking; for a blocking relationship, when a blocking condition node is determined to be valid, the target condition node constrained by the blocking relationship is invalid, resulting in blocking. Closed-loop processing and knowledge learning: Based on the comparison results of credibility and threshold, closed-loop processing is performed to generate a judgment report of structured evidence chain; information of cases judged as non-existent is extracted and stored in the false alarm knowledge base.

2. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, The process of parsing basic vulnerability information includes: preprocessing the basic vulnerability information into text, which includes at least HTML tag cleaning and word / sentence segmentation; performing entity recognition using a cybersecurity-specific dictionary, which includes at least CVE number and component name recognition; extracting information using predefined relation templates, which represent the semantic relationships between components, versions, conditions, and vulnerabilities; and converting the extraction results into a structured format and storing them in the component vulnerability knowledge base.

3. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, The semantic structuring of the statement that a vulnerability does not exist specifically includes: calling a large language model deployed in the local intranet environment, extracting factual assertions from the statement that a vulnerability does not exist through preset prompt word templates, and generating structured evidence information. The structured evidence information includes at least the evidence number, evidence source, evidence attribute name, and attribute value.

4. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, The large language model performs fact extraction and condition verification based on a preset prompt word template. The preset prompt word template includes at least a role definition part, a condition matching rule part, a state determination rule part, and an output format constraint part. Multi-source evidence conflict identification refers to determining whether there are semantic contradictions in the evidence values ​​of the same evidence attribute from different data sources. Different data sources include at least operating environment information, vulnerability exploitation condition verification results, feedback information from responsible persons, and vulnerability scanning results.

5. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, The matching degree of vulnerability exploitation conditions reflects the proportion of the number of vulnerability exploitation conditions that are met out of the total number of vulnerability exploitation conditions. Multi-source evidence conflict degree reflects the proportion of conflicting evidence identified by the large language model to the total number of evidence. The existence of conflicting evidence indicates inconsistencies between different data sources, weakening the reliability of the judgment basis. Therefore, multi-source evidence conflict degree negatively adjusts the credibility of vulnerability existence. Historical false alarm case similarity reflects the degree of matching between the current vulnerability and historical false alarm cases in the false alarm knowledge base. When the current vulnerability and historical false alarm cases reach a preset consistency threshold in terms of component name, vulnerability type, exploitation conditions, and network architecture, it is determined that there is a similar historical false alarm. The matching of historical false alarm cases negatively adjusts the credibility of vulnerability existence.

6. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, The closed-loop handling based on the comparison between the vulnerability's credibility and a preset threshold specifically includes: when the vulnerability's credibility is higher than the first preset threshold, outputting a vulnerability existence determination result and proceeding to the vulnerability remediation process; when the vulnerability's credibility is lower than the second preset threshold, outputting a vulnerability non-existence determination result and closing the vulnerability handling process; when the vulnerability's credibility is between the first and second preset thresholds, outputting a determination result requiring manual review.

7. The vulnerability false alarm determination method based on knowledge enhancement according to claim 1, characterized in that, Obtain runtime information of business systems affected by component vulnerabilities, specifically including: obtaining runtime information through vulnerability scanning device probes, which includes at least the business system identifier, host IP, host name, container ID, Pod name and path information.

8. A vulnerability false alarm determination system based on knowledge enhancement, characterized in that, include: The large model support module is deployed in the local intranet environment to provide large model computing power support for the inference of vulnerability context information; The vulnerability exploitation condition constraint graph construction module is used to generate basic vulnerability information in response to receiving component vulnerability detection results, extract the corresponding vulnerability exploitation condition information from the component vulnerability knowledge base, and convert the exploitation condition information into a structured vulnerability exploitation condition constraint graph. The runtime environment awareness module is used to obtain runtime information of business systems affected by component vulnerabilities, and associate and map the runtime information with the condition nodes in the vulnerability exploitation condition constraint diagram to determine the initial state of each condition node. The vulnerability context parsing module is used to construct vulnerability context information around component vulnerabilities. The vulnerability context information includes basic vulnerability information, vulnerability exploitation condition constraint graph, runtime information, and structured evidence information. The intelligent reasoning and decision-making module is used to input vulnerability context information into the large language model, obtain the state judgment results of each condition node and the corresponding evidence information, as well as the multi-source evidence conflict identification results, and perform constraint propagation calculation on the vulnerability exploitation condition constraint graph based on the state judgment results. It calculates the vulnerability existence credibility when the vulnerability exploitation path is not blocked. The constraint propagation calculation is performed according to the logical relationships between each condition node in the vulnerability exploitation condition constraint graph, specifically including: for multiple condition nodes connected by an AND relationship, if any condition node is judged to be false, the entire AND relationship is false, resulting in blocking; for multiple condition nodes connected by an OR relationship, if all condition nodes are judged to be false, the entire OR relationship is false, resulting in blocking; for pre-dependency relationships, if a pre-condition node is judged to be false, subsequent condition nodes depending on that pre-condition node cannot be true, resulting in blocking; for blocking relationships, when a blocking condition node is judged to be true, the target condition node constrained by that blocking relationship is false, resulting in blocking. The closed-loop handling module is used to perform closed-loop handling based on the comparison result of the vulnerability's credibility with a preset threshold, and generate a judgment report containing a structured chain of evidence. The false alarm knowledge learning module is used to extract the vulnerability type, vulnerability name, and proof that the vulnerability does not exist for cases that are determined to be non-existent, and store them in the vulnerability false alarm knowledge base.

9. The vulnerability false alarm determination system based on knowledge enhancement according to claim 8, characterized in that, The intelligent reasoning and decision-making module includes: The responsible person feedback parsing submodule is used to dispatch vulnerability remediation process work orders to the responsible person for vulnerability remediation, receive the vulnerability non-existence statement submitted by the responsible person, call the large language model to perform semantic structuring processing on the vulnerability non-existence statement, extract the factual assertions of the reasons for vulnerability exclusion, and generate structured evidence information; The knowledge-enhanced reasoning submodule is used to input vulnerability context information into the large language model. The large language model outputs the state judgment result and corresponding evidence information for each condition node in the vulnerability exploitation condition constraint diagram based on the preset prompt word template, and performs multi-source evidence conflict identification based on structured evidence information, runtime information and historical false alarm cases. The credibility measurement submodule is used to treat condition nodes whose state determination result is unknown as conditional based on the pessimistic evaluation criterion. Based on the state determination result, it performs constraint propagation calculation on the vulnerability exploitation condition constraint graph to determine whether the vulnerability exploitation path is blocked. When a critical condition node is determined to be invalid or blocked after constraint propagation, it outputs the determination result that the vulnerability does not exist. Otherwise, it calculates the credibility of the vulnerability existence.

Images