A security vulnerability assessment method, system, device and computer storage medium

Abstract

The application discloses a security vulnerability evaluation method, system, device and computer storage medium, relates to the technical field of network security, and applies a vulnerability analysis model to process standardized security event records, obtains initial vulnerability analysis results and takes the initial vulnerability analysis results as vulnerability analysis results to be verified; external tools matched with the vulnerability analysis results to be verified are screened as current tools; the current tools are called to process the vulnerability analysis results to be verified, and vulnerability verification information is obtained; the vulnerability analysis model is applied to process the vulnerability verification information, and updated vulnerability analysis results are obtained; if a preset termination condition is not met, the updated vulnerability analysis results are taken as the vulnerability analysis results to be verified, and the step of screening the external tools matched with the vulnerability analysis results to be verified is returned to be executed; if the preset termination condition is met, vulnerability evaluation results of target network data are generated based on the initial vulnerability analysis results, the vulnerability verification information and the updated vulnerability analysis results. Reliability and interpretability are high.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and more specifically, to a security vulnerability assessment method, system, device, and computer storage medium. Background Technology

[0002] With increasingly stringent cybersecurity requirements, the Zero Trust Protection (ZTP) architecture, adhering to the security principle of "never trust, always verify," places higher demands on the continuous security assessment of network assets. Current vulnerability assessment technologies mainly include rule-based passive traffic analysis, which discovers known attack behaviors through predefined rules or signatures.

[0003] However, in rule-based passive traffic analysis, such as Web application firewalls and intrusion detection / intrusion prevention systems, the detection capability is limited by the rule set. It lacks the ability to generalize the discovery of unknown attacks, and the detection granularity is limited to the single session level. It lacks the ability to perform correlation analysis across time, source, and protocol, resulting in poor reliability and interpretability of vulnerability assessment.

[0004] In conclusion, improving the reliability and interpretability of vulnerability assessments is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a security vulnerability assessment method that can, to some extent, address the technical problem of how to improve the reliability and interpretability of vulnerability assessments. This application also provides a security vulnerability assessment system, an electronic device, and a computer-readable storage medium.

[0006] To achieve the above objectives, firstly, a security vulnerability assessment method is provided, including: Acquire standardized security event records obtained after processing target network data; The standardized security event records are processed using a vulnerability analysis model to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified. Select external tools that match the analysis results of the vulnerabilities to be verified, and use them as the current tools; The current tool is invoked to process the vulnerability analysis results to obtain vulnerability verification information; The vulnerability analysis model is applied to process the vulnerability verification information to obtain updated vulnerability analysis results; If the preset termination condition is not met, the vulnerability analysis result will be updated as the vulnerability analysis result to be verified, and the process will return to the step of filtering external tools that match the vulnerability analysis result to be verified. In response to the satisfaction of the preset termination condition, a vulnerability assessment result of the target network data is generated based on the initial vulnerability analysis result, vulnerability verification information, and updated vulnerability analysis result. The external tools include functional execution components that are independent of the vulnerability analysis model.

[0007] Preferably, the external tool used to filter and match the vulnerability analysis results to be verified, as the current tool, includes: The preset external tools are determined, including traffic feature extraction tools, vulnerability knowledge base retrieval tools, threat intelligence query tools, vulnerability verification assistance tools, and attack surface analysis tools; If the analysis results of the vulnerability to be verified show the presence of structured vulnerability characteristics, then the traffic feature extraction tool will be used as the current tool. If the vulnerability analysis results contain information to be queried, the vulnerability knowledge base retrieval tool will be used as the current tool, and the information to be queried includes version information. If the vulnerability analysis results contain information to be verified, the threat intelligence query tool will be used as the current tool. The information to be verified includes IP address and / or domain name and / or Uniform Resource Locator. If an endpoint is found in the vulnerability analysis results to be verified, the vulnerability verification auxiliary tool will be used as the current tool. If asset information is found in the vulnerability analysis results to be verified, then the attack surface analysis tool will be used as the current tool.

[0008] Preferably, the external tool used to filter and match the vulnerability analysis results to be verified, as the current tool, includes: Obtain a dynamic context window, which is used to store the vulnerability analysis results and vulnerability verification information for a set number of rounds; Select the external tool that matches the latest vulnerability analysis result in the dynamic context window as the current tool.

[0009] Preferably, the step of generating a vulnerability assessment result for the target network data based on the initial vulnerability analysis result, vulnerability verification information, and updated vulnerability analysis result includes: According to the chronological order and logical relationship, the initial vulnerability analysis results, vulnerability verification information and updated vulnerability analysis results are linked and integrated to generate a chain of evidence. Based on the chain of evidence, a vulnerability assessment result for the target network data is generated.

[0010] Preferably, generating the vulnerability assessment result of the target network data based on the chain of evidence includes: Based on the standardized security event records and the evidence chain, version matching degree, configuration feature degree, attack surface reachability, intelligence correlation and evidence consistency are generated; A vulnerability confidence score is generated by weighted summation of the version matching degree, the configuration feature degree, the attack surface reachability, the intelligence correlation degree, and the evidence consistency. Based on the chain of evidence and the vulnerability confidence score, a vulnerability assessment result for the target network data is generated; The version matching degree represents the degree of matching between the software version information extracted from the standardized security event record and the version affected by the known vulnerability; the configuration feature degree represents the degree of fit between the insecure configuration items exposed from the standardized security event record and the preconditions for vulnerability exploitation; the attack surface reachability represents the degree of exposure of the vulnerable component from the perspective of network reachability; the intelligence correlation degree represents the degree of existence of active attack records related to the current vulnerability in the threat intelligence source; and the evidence consistency represents the degree of consistency between multiple independent pieces of evidence.

[0011] Preferably, the application vulnerability analysis model processes the standardized security event records, including: The standardized security event records are reassembled according to the communication session to generate an initial session object containing request and response pairs; The initial session object is anonymized to generate the target session object; The task of generating a security profile of the target session object; The security profiling task is processed using a vulnerability analysis model.

[0012] Preferably, the target network data includes network traffic data and audit log data passively collected by the security probe in a bypass manner, and the security probe is deployed on the network node.

[0013] Secondly, a security vulnerability assessment system is provided, including: The event acquisition module is used to acquire standardized security event records obtained after processing target network data; The initial analysis module is used to process the standardized security event records using a vulnerability analysis model to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified. The tool filtering module is used to filter external tools that match the analysis results of the vulnerability to be verified and select them as the current tools. The verification module is used to process the vulnerability analysis results of the current tool to obtain vulnerability verification information. The update module is used to process the vulnerability verification information using the vulnerability analysis model to obtain updated vulnerability analysis results. The decision module is used to, in response to the failure to meet the preset termination condition, update the vulnerability analysis result as the vulnerability analysis result to be verified and return to the step of filtering external tools that match the vulnerability analysis result to be verified; in response to the satisfaction of the preset termination condition, generate the vulnerability assessment result of the target network data based on the initial vulnerability analysis result, vulnerability verification information and updated vulnerability analysis result. The external tools include functional execution components that are independent of the vulnerability analysis model.

[0014] Thirdly, an electronic device is provided, comprising: Memory, used to store computer programs; A processor for implementing any of the security vulnerability assessment methods described above when executing the computer program.

[0015] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements any of the security vulnerability assessment methods described above.

[0016] This application provides a security vulnerability assessment method, which involves: acquiring standardized security event records obtained after processing target network data; applying a vulnerability analysis model to process the standardized security event records to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified; selecting external tools that match the vulnerability analysis results to be verified, and using them as the current tools; calling the current tools to process the vulnerability analysis results to be verified, and obtaining vulnerability verification information; applying the vulnerability analysis model to process the vulnerability verification information, and obtaining updated vulnerability analysis results; in response to the failure to meet a preset termination condition, using the updated vulnerability analysis results as the vulnerability analysis results to be verified, and returning to the step of selecting external tools that match the vulnerability analysis results to be verified; and in response to the satisfaction of the preset termination condition, generating a vulnerability assessment result for the target network data based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results; wherein, the external tools include functional execution components independent of the vulnerability analysis model. This application, by setting up multiple rounds of inference loops, continuously filters and calls external tools to obtain new vulnerability verification information based on the current vulnerability analysis results in each round. The newly acquired vulnerability verification information is then re-inputted into the vulnerability analysis model for comprehensive evaluation, thereby achieving iterative accumulation of evidence across multiple rounds and cross-round correlation analysis. This allows fragmented traffic clues to reach a reliable level of credibility after multiple rounds of aggregation. Simultaneously, since the external tools are functional execution components independent of the vulnerability analysis model, they do not generate active probe traffic when called. Furthermore, the external tools only process existing vulnerability analysis results and return vulnerability verification information without injecting any probe data packets into the target network. Therefore, the evaluation process does not have any active impact on the target network and can run securely in various production environments and zero-trust protection architectures. In addition, by comprehensively generating vulnerability evaluation results based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results accumulated over multiple rounds, the evaluation conclusions are supported by multi-dimensional evidence, improving the reliability and interpretability of the evaluation results. The security vulnerability evaluation system, electronic device, and computer-readable storage medium provided in this application also solve the corresponding technical problems. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a security vulnerability assessment method provided in this application embodiment; Figure 2This is a flowchart of a security vulnerability assessment method based on the chain of evidence. Figure 3 This is a schematic diagram of the intelligent agent's structure; Figure 4 This is an overall schematic diagram of vulnerability analysis based on intelligent agents; Figure 5 This is a schematic diagram of the structure of a security vulnerability assessment system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application. Detailed Implementation

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

[0020] With increasingly stringent cybersecurity requirements, the Zero Trust Protection (ZTP) architecture, adhering to the security principle of "never trust, always verify," places higher demands on the continuous security assessment of network assets. Current vulnerability assessment technologies mainly include rule-based passive traffic analysis, which discovers known attack behaviors through predefined rules or signatures.

[0021] However, in rule-based passive traffic analysis, devices such as Web Application Firewalls and Intrusion Detection Systems / Intrusion Prevention Systems have limited detection capabilities due to the rule set. They lack the ability to generalize and discover unknown attacks, and their detection granularity remains at the single session level. They also lack the ability to perform cross-time, cross-source, and cross-protocol correlation analysis, resulting in poor reliability and interpretability of vulnerability assessments. The security vulnerability assessment solution provided in this application can improve the reliability and interpretability of vulnerability assessments.

[0022] Please see Figure 1 , Figure 1 This is a flowchart of a security vulnerability assessment method provided in an embodiment of this application.

[0023] This application provides a security vulnerability assessment method, which may include the following steps: Step S101: Obtain standardized security event records obtained after processing the target network data.

[0024] In practical applications, standardized security event records obtained after processing the target network data can be acquired first. The target network data includes network traffic data and audit log data, specifically including PCAP (PacketCapture) packets, HTTP (Hypertext Transfer Protocol) session data, DNS (Domain Name System) query records, TLS (Transport Layer Security) / SSL (Secure Sockets Layer) handshake information, and application audit logs. Among these, HTTP session data includes HTTP / HTTPS request and response headers, status codes, and response body digests; TLS / SSL handshake information includes certificates and cipher suite lists; and application audit logs include web access logs, database audit logs, and authentication logs.

[0025] In practical applications, the process of processing target network data to obtain standardized security event records can begin with protocol parsing and field extraction. For example, PCAP data can be parsed layer by layer in the order of Ethernet / IP / TCP / HTTP / DNS / TLS to extract key fields at each layer. Audit logs can be structured to extract metadata such as timestamps, source / destination addresses, request methods, URIs, response codes, and server versions. Then, the extracted fields are standardized to convert heterogeneous data into standardized security event records. Each standardized security event record can include an event timestamp, source / destination IP and port, protocol type, application layer protocol, request digest vector, response feature vector, and TLS / certificate information. This standardization process ensures that data from different data sources and protocols has a unified semantics and format, providing a consistent data interface for vulnerability analysis models.

[0026] In practical applications, the target network data in this application can be obtained through active scanning, such as sending crafted probe packets to the target system using an active scanner. However, active probe traffic may impact production systems and even cause service interruptions. Furthermore, probe activity is easily intercepted by the target IDS / IPS, leading to distorted assessments. To avoid this, the target network data in this application can be obtained passively. Specifically, the target network data includes network traffic data and audit log data passively collected by a security probe in a bypass manner. The security probe is deployed on the network nodes to be analyzed, such as critical network nodes. It acquires PCAP packets flowing through the network through port mirroring or traffic splitting, and obtains web access logs, database audit logs, authentication logs, etc., as target network data through log forwarding. In this way, no active probe traffic is generated throughout the vulnerability assessment process, completely eliminating the operational risk to the business system. It is also undetectable or unblockable by the target system, making it truly suitable for production environments and ZTP architectures.

[0027] Step S102: Apply the vulnerability analysis model to process the standardized security event records to obtain the initial vulnerability analysis results, which are then used as the vulnerability analysis results to be verified.

[0028] In practical applications, vulnerability analysis models are used to process standardized security event records to obtain initial vulnerability analysis results, which are then used as the results to be verified. These vulnerability analysis models are built upon neural network models fine-tuned from security domain corpora. The security domain corpora used in the fine-tuning process include Common Vulnerability Exposure (CVE) data, vulnerability database data, security hardening guidelines, attack technique reports, and the Open Web Application Security Project (OWASP) knowledge system. For example, vulnerability analysis models can be built based on Large Language Models (LLMs), multimodal large models, hybrid expert models (MoEs), or by employing multi-model integration / voting strategies. A vulnerability analysis model must possess at least three key capabilities: first, semantic understanding of network protocol sessions, enabling the identification of vulnerability clues such as server version, middleware type, and insecure configurations from HTTP requests / responses; second, code security auditing, capable of analyzing the security of captured JavaScript, SQL queries, and other code fragments within traffic; and third, logical reasoning based on security knowledge, capable of deriving potential vulnerability issues from multiple discrete traffic observations.

[0029] In practical applications, vulnerability analysis models can be directly applied to process standardized security event records to obtain initial vulnerability analysis results. Alternatively, the standardized security event records can be processed before vulnerability analysis. Specifically, during the processing of standardized security event records using vulnerability analysis models, the records can be reassembled according to communication sessions to generate an initial session object containing request-response pairs. This involves first identifying assets, such as extracting all unique IP addresses, domain names, and service port combinations from the standardized security event records to form an asset list. Then, session classification is performed, such as grouping standardized security event records by target assets and reassembling multiple discrete data packets from the same TCP / HTTP session into a complete session context, constructing an initial session object containing complete request-response pairs. The initial session object is anonymized, such as by automatically identifying and anonymizing credentials, Personal Identification Information (PII), and authentication tokens, to generate the target session object. A security profile task for the target session object is then generated. A vulnerability analysis model is applied to process the security profile task. Specifically, the vulnerability analysis model performs an initial analysis on each security profile task, extracting key information. For example, it extracts fields from HTTP response headers to identify the web server type and version number, extracts fields from HTTP response headers to identify the backend technology stack, extracts the issuer, subject, and validity period from TLS certificate information, and extracts subdomain information from DNS records. Based on the extracted key information, the vulnerability analysis model generates initial vulnerability analysis results, i.e., vulnerability hypotheses. Each vulnerability analysis result can include a vulnerability description, initial confidence level, supporting evidence, etc. For example, when a web server returns a "Apache / 2.4.49" Server header in passive traffic, the vulnerability analysis model generates a vulnerability description that hypothesizes "CVE-2021-41773 path traversal vulnerability may exist." Even if the vulnerability description does not contain attack traces, it will still include the possibility of inferring the existence of known vulnerabilities related to the version based on version information.

[0030] Step S103: Select external tools that match the vulnerability analysis results to be verified as the current tools. External tools include functional execution components that are independent of the vulnerability analysis model.

[0031] Step S104: Call the current tool to process the vulnerability analysis results to obtain vulnerability verification information.

[0032] Step S105: Apply the vulnerability analysis model to process the vulnerability verification information and obtain updated vulnerability analysis results.

[0033] In practical applications, vulnerability analysis models generate vulnerability analysis results through cognitive reasoning capabilities. Their knowledge source is static security domain knowledge encoded in the model weights, possessing global vulnerability analysis capabilities. Combining this with specific vulnerability analysis capabilities, i.e., detailed vulnerability analysis capabilities, undoubtedly improves the accuracy of vulnerability analysis. To this end, external tools can be set up to run independently of the large language model. Each external tool encapsulates a type of dedicated vulnerability analysis capability not possessed by the large language model itself; essentially, it is a functional execution component. Then, external tools matching the vulnerability analysis results to be verified can be selected as the current tool. The current tool is then called to process the vulnerability analysis results to obtain vulnerability verification information. Subsequently, the vulnerability analysis model is applied to process the vulnerability verification information to obtain updated vulnerability analysis results. In this way, the specific vulnerability analysis capabilities of external tools can assist the vulnerability analysis model in performing vulnerability analysis again, achieving a combination of global and detailed analysis and ensuring the accuracy of vulnerability analysis.

[0034] In practical applications, external tools can be flexibly configured as needed. For example, external tools should include at least traffic feature extraction tools, vulnerability knowledge base retrieval tools, threat intelligence query tools, vulnerability verification assistance tools, and attack surface analysis tools. Among them, traffic feature extraction tools are used to extract structured vulnerability features such as Server headers, TLS cipher suites, and DNS records from standardized security event records or raw traffic data; vulnerability knowledge base retrieval tools are used to encode key features such as version information into vectors, perform semantic similarity retrieval in the vulnerability vector database, and match associated vulnerability entries; threat intelligence query tools are used to connect to external threat intelligence platforms through standardized application programming interfaces to perform reputation queries on IP addresses, domain names, or Uniform Resource Locators; vulnerability verification assistance tools are used to perform non-destructive information verification operations only on network endpoints that have appeared in passive traffic, such as OPTIONS requests, accessing robots.txt or public API documentation, without performing any vulnerability exploitation attempts that may cause impact; and attack surface analysis tools are used to draw attack surface maps based on discovered asset information to help identify potential exposure points. Each external tool runs independently of the large language model and can be coupled with the vulnerability analysis model through a standardized function call interface. In this way, when the vulnerability analysis model needs to call a certain external tool, it only needs to output the corresponding function call request, and then execute the corresponding tool call according to the tool name and parameter value in the function call request.

[0035] Based on this, in the process of selecting external tools that match the vulnerability analysis results to be verified as the current tool, preset external tools can be determined. These external tools include traffic feature extraction tools, vulnerability knowledge base retrieval tools, threat intelligence query tools, vulnerability verification auxiliary tools, and attack surface analysis tools. If structured vulnerability features are found in the vulnerability analysis results to be verified, the traffic feature extraction tool is selected as the current tool. If information to be queried is found in the vulnerability analysis results to be verified, the vulnerability knowledge base retrieval tool is selected as the current tool; the information to be queried includes version information. If information to be verified is found in the vulnerability analysis results to be verified, the threat intelligence query tool is selected as the current tool; the information to be verified includes IP addresses and / or domain names and / or Uniform Resource Locators. If endpoints are found in the vulnerability analysis results to be verified, the vulnerability verification auxiliary tool is selected as the current tool. If asset information is found in the vulnerability analysis results to be verified, the attack surface analysis tool is selected as the current tool. Understandably, the vulnerability verification information corresponds to the processing capabilities of the current tool. For example, if the current tool is a vulnerability knowledge base retrieval tool, it encodes the received query information into a vector, performs an approximate nearest neighbor search in the vulnerability vector database, and returns a list of matching CVE entries and their similarity scores as vulnerability verification information. If the current tool is a threat intelligence query tool, it connects to an external threat intelligence platform through a standardized API to query the reputation information of a specified IP address and returns a malicious rating, related events, etc., as vulnerability verification information.

[0036] In practical applications, during the processing of vulnerability verification information, the vulnerability analysis model can analyze the correlation, consistency, and sufficiency of the vulnerability verification information with the current vulnerability analysis results to be verified. Specifically, it determines whether the newly obtained vulnerability verification information supports the current hypothesis in the current vulnerability analysis results, whether it is consistent with existing evidence, and whether it provides new key information. Based on the evaluation results, the current vulnerability analysis results to be verified are updated to obtain updated vulnerability analysis results. For example, if the new evidence supports the hypothesis, the confidence level of the vulnerability analysis results to be verified is increased; if the new evidence contradicts the hypothesis, the confidence level of the vulnerability analysis results to be verified is decreased or the hypothesis is excluded. If the evidence is insufficient, the next round of strategies is automatically planned, such as adjusting search keywords, expanding the time window, or introducing new analysis dimensions, such as expanding from web services to related database audit logs.

[0037] In practical applications, to ensure consistent accumulation of information across rounds, avoid information forgetting, and prevent continuous information buildup, a dynamic context window can be obtained during the process of selecting external tools that match the vulnerability analysis results to be verified as the current tool. The dynamic context window is used to store the vulnerability analysis results and vulnerability verification information for a set round. That is, the dynamic context window is a key data structure in the vulnerability analysis model for accumulating information across rounds, and its content is dynamically updated as the inference rounds progress. The external tool that matches the latest vulnerability analysis result in the dynamic context window is selected as the current tool. The latest vulnerability analysis result in the dynamic context window refers to the vulnerability analysis result obtained after evaluation and update by the vulnerability analysis model in the most recent inference loop. Understandably, the content in the dynamic context window can be flexibly configured as needed. For example, it can include at least the standardized security event records of the initial input, the generated initial vulnerability analysis results and the vulnerability analysis results after each round of updates, the external tools called in each round of inference loops and their input parameters and the vulnerability verification information returned, the intermediate inference conclusions of each round of inference loops, the alternative hypotheses that have been excluded and the reasons for their exclusion, etc. The intermediate inference conclusions of each round of inference loops can include the evaluation of the results returned by the tools, the judgment of support or rejection of the hypothesis, and the planning of the next analysis strategy, etc. On this basis, the vulnerability analysis model can use the entire content of the dynamic context window as input for inference to ensure the global optimality of the decision.

[0038] Step S106: In response to the failure to meet the preset termination condition, the updated vulnerability analysis result is used as the vulnerability analysis result to be verified, and the process returns to step S103.

[0039] Step S107: In response to the satisfaction of the preset termination condition, a vulnerability assessment result for the target network data is generated based on the initial vulnerability analysis result, vulnerability verification information, and updated vulnerability analysis result.

[0040] In practical applications, vulnerability analysis updates can be performed through multiple rounds of tool calls. However, termination conditions are needed to prevent unlimited tool calls. Specifically, it's necessary to check if a preset termination condition is met. If not, tool calls can continue, with the updated vulnerability analysis results used as verification results. The process then returns to the external tools that match the verification results and proceeds with subsequent steps. Through this iterative mechanism, the vulnerability analysis model can cross-dimensionally correlate fragmented traffic from different times, sources, and protocols. In multiple iterations, evidence is continuously accumulated, gradually approaching accurate conclusions. Fragmented clues insufficient to determine vulnerability existence with a single instance are transformed through multiple rounds of iterations. After aggregation, a reliable level of trust is achieved. For example, "middleware version leaked by HTTP response," "internal domain name exposed by DNS record," "weak TLS encryption suite," and "abnormal access patterns in audit logs" can be integrated into a complete assessment conclusion of "high-risk vulnerability caused by outdated and misconfigured components." If preset termination conditions are met, a vulnerability assessment result for the target network data is generated based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results. The vulnerability assessment result may include a list of affected assets, vulnerability identifiers (CVE numbers or custom identifiers), vulnerability names and descriptions, risk levels, confidence scores, complete evidence chain details, and remediation recommendations. Furthermore, for user convenience, the vulnerability assessment results can be compiled into a vulnerability assessment report. The vulnerability assessment report may include an assessment overview, a vulnerability details list, and a remediation priority ranking. The assessment overview may include the assessment time range, total number of assets, total number of vulnerabilities, and risk distribution. The vulnerability details list may include the CVE number, description, risk level, confidence score, evidence chain shown in a timeline and correlation diagram, and details of affected assets for each vulnerability. The remediation priority ranking may include a list of remediation recommendations ranked by risk level and confidence level.

[0041] In practical applications, the preset termination conditions can be flexibly set as needed. For example, the preset termination conditions may include at least one of the following: the confidence level of all vulnerability analysis results reaches a preset high threshold, such as 85%; there is no new evidence and no change in confidence level in two consecutive inference cycles; the number of inference cycles reaches the preset maximum number of cycles, such as 10 cycles.

[0042] This application provides a security vulnerability assessment method, which involves: acquiring standardized security event records obtained after processing target network data; applying a vulnerability analysis model to process the standardized security event records to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified; selecting external tools that match the vulnerability analysis results to be verified, and using them as the current tools; calling the current tools to process the vulnerability analysis results to be verified, and obtaining vulnerability verification information; applying the vulnerability analysis model to process the vulnerability verification information, and obtaining updated vulnerability analysis results; in response to the failure to meet a preset termination condition, using the updated vulnerability analysis results as the vulnerability analysis results to be verified, and returning to the step of selecting external tools that match the vulnerability analysis results to be verified; and in response to the satisfaction of the preset termination condition, generating a vulnerability assessment result for the target network data based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results; wherein, the external tools include functional execution components independent of the vulnerability analysis model. In this application, by setting up multiple rounds of inference loops, new vulnerability verification information can be continuously filtered and invoked from external tools based on the current vulnerability analysis results in each round. The newly acquired vulnerability verification information is then re-input into the vulnerability analysis model for comprehensive evaluation, thereby achieving iterative accumulation of evidence across multiple rounds and cross-round correlation analysis. This allows fragmented traffic clues to reach a reliable level of credibility after multiple rounds of aggregation. Simultaneously, since the external tools are functional execution components independent of the vulnerability analysis model, they do not generate active probe traffic when invoked. Furthermore, the external tools only process existing vulnerability analysis results and return vulnerability verification information without injecting any probe data packets into the target network. Therefore, the evaluation process does not have any active impact on the target network and can run securely in various production environments and zero-trust protection architectures. Moreover, by comprehensively generating vulnerability evaluation results based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results accumulated over multiple rounds, the evaluation conclusions are supported by multi-dimensional evidence, improving the reliability and interpretability of the evaluation results.

[0043] Based on the above embodiments, directly using the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results as the vulnerability assessment results would be detrimental to user understanding and handling of vulnerabilities. To avoid this situation, please refer to... Figure 2 The security vulnerability assessment method provided in this application embodiment may include the following steps: Step S201: Obtain standardized security event records obtained after processing the target network data.

[0044] Step S202: Apply the vulnerability analysis model to process the standardized security event records to obtain the initial vulnerability analysis results, which are then used as the vulnerability analysis results to be verified.

[0045] Step S203: Select external tools that match the vulnerability analysis results to be verified as the current tools. External tools include functional execution components that are independent of the vulnerability analysis model.

[0046] Step S204: Call the current tool to process the vulnerability analysis results to obtain vulnerability verification information.

[0047] Step S205: Apply the vulnerability analysis model to process the vulnerability verification information and obtain updated vulnerability analysis results.

[0048] Step S206: In response to the failure to meet the preset termination condition, the updated vulnerability analysis result is used as the vulnerability analysis result to be verified, and the process returns to step S203.

[0049] Step S207: In response to the satisfaction of the preset termination condition, the initial vulnerability analysis results, vulnerability verification information and updated vulnerability analysis results are linked and integrated according to the time sequence and logical relationship to generate a chain of evidence.

[0050] In practical applications, during the process of generating vulnerability assessment results for target network data based on initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results, the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results can be linked and integrated according to time sequence and logical relationships to generate an evidence chain. For example, the evidence can be arranged in the order of evidence collection time, showing the time evolution process from vulnerability discovery to confirmation. The external tools called, the vulnerability verification information obtained, and the updated vulnerability analysis results generated in each round of reasoning can be arranged in the actual time sequence. Then, the evidence can be organized according to the logical link of traffic characteristics, vulnerability clues, known vulnerability information, multi-dimensional corroborating evidence, and assessment conclusions, clearly showing the basis and conclusion of each step of reasoning. For example, the Server header extracted from the initial traffic serves as the first step of evidence, the CVE entries matched by the vulnerability knowledge base search serve as the second step of evidence, the threat intelligence query results serve as the third step of evidence, and the comprehensive assessment conclusion serves as the final evidence. Finally, the correlation between different pieces of evidence can be shown, such as the same source IP, the same type of vulnerability, the same component dependency, etc., and the logical connection between the evidence can be presented in a visual way.

[0051] Step S208: Generate vulnerability assessment results for the target network data based on the chain of evidence.

[0052] In practical applications, during the process of generating vulnerability assessment results for target network data based on the evidence chain, version matching degree, configuration signature, attack surface reachability, intelligence relevance, and evidence consistency can be generated based on standardized security event records and the evidence chain. A weighted sum of these factors is then used to generate a vulnerability confidence score. Based on the evidence chain and the vulnerability confidence score, the vulnerability assessment result for the target network data is generated. In this way, the vulnerability assessment result includes both the evidence chain and the vulnerability confidence score, allowing users to trace the vulnerability assessment process and assess its credibility, facilitating user understanding and handling of vulnerabilities.

[0053] In practical applications, version matching degree characterizes the degree of matching between software version information extracted from standardized security event records and versions affected by known vulnerabilities. For example, it compares the version number extracted from traffic with the range of affected versions recorded in the vulnerability knowledge base. If the version number falls completely within the affected range, the version matching degree is 1; if the version number is near the boundary of the affected range (e.g., the difference between the next version number and the previous one is 1), the version matching degree is 0.7; and if the version number is clearly outside the affected range, the version matching degree is 0. Configuration characteristic degree characterizes the degree of fit between insecure configuration items exposed from standardized security event records and the preconditions for vulnerability exploitation. Attack surface reachability characterizes the degree of exposure of vulnerable components from the perspective of network reachability. For example, it judges whether vulnerable components can be accessed from external networks based on traffic data. If the vulnerable component is exposed on a public IP and the port is open to the outside world, the attack surface reachability is high; if it is only accessible on the internal network, the attack surface reachability is medium; and if it is only accessible on the local loopback interface, the attack surface reachability is low. Intelligence correlation degree characterizes the degree of existence of active attack records related to the current vulnerability in the threat intelligence source, and evidence consistency characterizes the degree of consistency between multiple independent pieces of evidence.

[0054] To facilitate understanding of the security vulnerability assessment scheme provided in this application, it is assumed that the security vulnerability assessment is implemented through an intelligent agent. The structure of the intelligent agent can be as follows: Figure 3As shown, the system includes an LLM inference kernel, a multi-round inference and planning engine, an evaluation decision and confidence calculation engine, and a tool invocation and integration engine. Specifically, the LLM inference kernel is used to acquire standardized security event records obtained after processing the target network data, apply a vulnerability analysis model to process the standardized security event records to obtain initial vulnerability analysis results as vulnerability analysis results to be verified, and apply a vulnerability analysis model to process the vulnerability verification information to obtain updated vulnerability analysis results. The multi-round inference and planning engine is used to filter external tools that match the vulnerability analysis results to be verified and use them as the current tools. The tool invocation and integration engine calls the current tools to process the vulnerability analysis results to be verified and obtain vulnerability verification information. If the preset termination condition is not met, the updated vulnerability analysis result is used as the vulnerability analysis result to be verified, and the process returns to the step of filtering external tools that match the vulnerability analysis results to be verified. If the preset termination condition is met, the evaluation decision and confidence calculation engine is called to generate vulnerability evaluation results. The evaluation decision and confidence calculation engine is used to generate vulnerability evaluation results for the target network data based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results. In specific application scenarios, intelligent agents can be leveraged to analyze unpatched known CVE vulnerabilities based on version fingerprint matching; analyze web security configuration defects based on missing security HTTP headers, improper CORS configuration, and weakened TLS; analyze information leakage vulnerabilities based on error page information leakage, sensitive file exposure, and debug endpoint exposure; analyze authentication and authorization defects based on passively observed unauthorized access patterns; and analyze logical vulnerabilities based on inferences from non-compliant business process interaction patterns. Furthermore, as time progresses, accumulated vulnerability analysis cases serve as feedback data to continuously optimize the agent's inference and tool invocation strategies. Confirmation or corrections of conclusions by operations personnel can be recorded for model fine-tuning or parameter adjustments, ensuring the agent's vulnerability assessment capabilities continuously improve over time.

[0055] Building upon the aforementioned intelligent agent, a vulnerability knowledge base and intelligence source module can be set up to provide external knowledge support for the agent's analysis. This allows external tools to quickly and accurately generate vulnerability verification information. This module can include three sub-components: a vulnerability vector database, a security knowledge graph, and a real-time threat intelligence interface. The vulnerability vector database encodes entries from publicly available vulnerability databases such as CVE / NVD / CNVD into fixed-dimensional vectors using an embedding model, supporting rapid semantic similarity retrieval and periodic incremental updates to cover newly disclosed vulnerabilities. The security knowledge graph organizes CVE vulnerabilities, affected software / versions, ATT&CK attack techniques, mitigation measures, and component dependencies in a graph structure, supporting multi-hop inference by the agent. The real-time threat intelligence interface connects to external intelligence sources via a standardized API, providing IP / domain / URL reputation queries and vulnerability exploitation activity information. In this way, the complete architecture, including the intelligent agent, can be configured as follows: Figure 4 As shown.

[0056] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a security vulnerability assessment system provided in an embodiment of this application.

[0057] This application provides a security vulnerability assessment system that may include: The event acquisition module 101 is used to acquire standardized security event records obtained after processing target network data; The initial analysis module 102 is used to process standardized security event records using a vulnerability analysis model to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified. The tool filtering module 103 is used to filter external tools that match the vulnerability analysis results to be verified, and use them as the current tools. Verification module 104 is used to call the current tool to process the vulnerability analysis results to obtain vulnerability verification information; The update module 105 is used to process vulnerability verification information using the vulnerability analysis model to obtain updated vulnerability analysis results. The decision module 106 is used to, in response to the failure to meet the preset termination conditions, update the vulnerability analysis results as the vulnerability analysis results to be verified and return to the step of filtering external tools that match the vulnerability analysis results to be verified; in response to the satisfaction of the preset termination conditions, generate vulnerability assessment results of the target network data based on the initial vulnerability analysis results, vulnerability verification information and updated vulnerability analysis results. The external tools include functional execution components that are independent of the vulnerability analysis model.

[0058] This application provides a security vulnerability assessment system. The tool selection module is specifically used to: determine preset external tools, including traffic feature extraction tools, vulnerability knowledge base retrieval tools, threat intelligence query tools, vulnerability verification auxiliary tools, and attack surface analysis tools; in response to the presence of structured vulnerability features in the vulnerability analysis results to be verified, the traffic feature extraction tool is selected as the current tool; in response to the presence of query information in the vulnerability analysis results to be verified, the vulnerability knowledge base retrieval tool is selected as the current tool, and the query information includes version information; in response to the presence of verification information in the vulnerability analysis results to be verified, the threat intelligence query tool is selected as the current tool, and the verification information includes IP addresses and / or domain names and / or Uniform Resource Locators; in response to the presence of endpoints in the vulnerability analysis results to be verified, the vulnerability verification auxiliary tool is selected as the current tool; and in response to the presence of asset information in the vulnerability analysis results to be verified, the attack surface analysis tool is selected as the current tool.

[0059] This application provides a security vulnerability assessment system, in which a tool filtering module is specifically used to: obtain a dynamic context window, which stores the vulnerability analysis results and vulnerability verification information for a set number of rounds; and filter external tools that match the latest vulnerability analysis results in the dynamic context window as the current tool.

[0060] This application provides a security vulnerability assessment system in which the decision module is specifically used to: integrate the initial vulnerability analysis results, vulnerability verification information and updated vulnerability analysis results in sequence and logical relationship to generate an evidence chain; and generate vulnerability assessment results for the target network data based on the evidence chain.

[0061] This application provides a security vulnerability assessment system. The decision module is specifically used to: generate version matching degree, configuration feature degree, attack surface reachability, intelligence correlation degree, and evidence consistency based on standardized security event records and evidence chains; perform a weighted summation of version matching degree, configuration feature degree, attack surface reachability, intelligence correlation degree, and evidence consistency to generate a vulnerability confidence score; and generate a vulnerability assessment result for the target network data based on the evidence chain and the vulnerability confidence score. Specifically, version matching degree represents the degree of matching between software version information extracted from standardized security event records and versions affected by known vulnerabilities; configuration feature degree represents the degree of fit between insecure configuration items exposed from standardized security event records and preconditions for vulnerability exploitation; attack surface reachability represents the degree of exposure of vulnerable components from a network reachability perspective; intelligence correlation degree represents the degree of existence of active attack records related to the current vulnerability in threat intelligence sources; and evidence consistency represents the degree of consistency among multiple independent pieces of evidence.

[0062] This application provides a security vulnerability assessment system, in which the initial analysis module is specifically used to: reorganize standardized security event records according to communication sessions to generate an initial session object containing request and response interaction pairs; desensitize the initial session object to generate a target session object; generate a security profile task for the target session object; and process the security profile task using a vulnerability analysis model.

[0063] This application provides a security vulnerability assessment system in which the target network data includes network traffic data and audit log data passively collected by security probes in a bypass manner, and the security probes are deployed on network nodes.

[0064] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 6 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application, as shown below. Figure 6 As shown, the electronic device includes: Communication interface 1 enables information exchange with other devices, such as network devices; Processor 2 is connected to communication interface 1 to enable information exchange with other devices and, when running a computer program, executes the security vulnerability assessment methods provided by one or more of the aforementioned technical solutions. The computer program is stored on memory 3.

[0065] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 The general will label all buses as Bus System 4.

[0066] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0067] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0068] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.

[0069] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0070] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0071] In an exemplary embodiment, this application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in any of the preceding embodiments.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed apparatus, terminal, and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0073] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0074] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0075] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0076] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0077] For descriptions of relevant parts of the security vulnerability assessment system, electronic device, and computer-readable storage medium provided in this application's embodiments, please refer to the detailed descriptions of the corresponding parts in the security vulnerability assessment method provided in this application's embodiments; they will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0078] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0079] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A security vulnerability assessment method, characterized in that, include: Acquire standardized security event records obtained after processing target network data; The standardized security event records are processed using a vulnerability analysis model to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified. Select external tools that match the analysis results of the vulnerabilities to be verified, and use them as the current tools; The current tool is invoked to process the vulnerability analysis results to obtain vulnerability verification information; The vulnerability analysis model is applied to process the vulnerability verification information to obtain updated vulnerability analysis results; If the preset termination condition is not met, the vulnerability analysis result will be updated as the vulnerability analysis result to be verified, and the process will return to the step of filtering external tools that match the vulnerability analysis result to be verified. In response to the satisfaction of the preset termination condition, a vulnerability assessment result of the target network data is generated based on the initial vulnerability analysis result, vulnerability verification information, and updated vulnerability analysis result. The external tools include functional execution components that are independent of the vulnerability analysis model.

2. The method according to claim 1, characterized in that, The external tools used for screening and matching the results of the vulnerability analysis to be verified, as the current tools, include: The preset external tools are determined, including traffic feature extraction tools, vulnerability knowledge base retrieval tools, threat intelligence query tools, vulnerability verification assistance tools, and attack surface analysis tools; If the analysis results of the vulnerability to be verified show the presence of structured vulnerability characteristics, then the traffic feature extraction tool will be used as the current tool. If the vulnerability analysis results contain information to be queried, the vulnerability knowledge base retrieval tool will be used as the current tool, and the information to be queried includes version information. If the vulnerability analysis results contain information to be verified, the threat intelligence query tool will be used as the current tool. The information to be verified includes IP address and / or domain name and / or Uniform Resource Locator. If an endpoint is found in the vulnerability analysis results to be verified, the vulnerability verification auxiliary tool will be used as the current tool. If asset information is found in the vulnerability analysis results to be verified, then the attack surface analysis tool will be used as the current tool.

3. The method according to claim 1, characterized in that, The external tools used for screening and matching the results of the vulnerability analysis to be verified, as the current tools, include: Obtain a dynamic context window, which is used to store the vulnerability analysis results and vulnerability verification information for a set number of rounds; Select the external tool that matches the latest vulnerability analysis result in the dynamic context window as the current tool.

4. The method according to claim 1, characterized in that, The generation of vulnerability assessment results for the target network data based on the initial vulnerability analysis results, vulnerability verification information, and updated vulnerability analysis results includes: According to the chronological order and logical relationship, the initial vulnerability analysis results, vulnerability verification information and updated vulnerability analysis results are linked and integrated to generate a chain of evidence. Based on the chain of evidence, a vulnerability assessment result for the target network data is generated.

5. The method according to claim 4, characterized in that, The generation of the vulnerability assessment result for the target network data based on the chain of evidence includes: Based on the standardized security event records and the evidence chain, version matching degree, configuration feature degree, attack surface reachability, intelligence correlation and evidence consistency are generated; A vulnerability confidence score is generated by weighted summation of the version matching degree, the configuration feature degree, the attack surface reachability, the intelligence correlation degree, and the evidence consistency. Based on the chain of evidence and the vulnerability confidence score, a vulnerability assessment result for the target network data is generated; The version matching degree represents the degree of matching between the software version information extracted from the standardized security event record and the version affected by the known vulnerability; the configuration feature degree represents the degree of fit between the insecure configuration items exposed from the standardized security event record and the preconditions for vulnerability exploitation; the attack surface reachability represents the degree of exposure of the vulnerable component from the perspective of network reachability; the intelligence correlation degree represents the degree of existence of active attack records related to the current vulnerability in the threat intelligence source; and the evidence consistency represents the degree of consistency between multiple independent pieces of evidence.

6. The method according to claim 1, characterized in that, The application vulnerability analysis model processes the standardized security event records, including: The standardized security event records are reassembled according to the communication session to generate an initial session object containing request and response pairs; The initial session object is anonymized to generate the target session object; The task of generating a security profile of the target session object; The security profiling task is processed using a vulnerability analysis model.

7. The method according to any one of claims 1 to 6, characterized in that, The target network data includes network traffic data and audit log data passively collected by security probes in a bypass manner, and the security probes are deployed on network nodes.

8. A security vulnerability assessment system, characterized in that, include: The event acquisition module is used to acquire standardized security event records obtained after processing target network data; The initial analysis module is used to process the standardized security event records using a vulnerability analysis model to obtain initial vulnerability analysis results, which are then used as vulnerability analysis results to be verified. The tool filtering module is used to filter external tools that match the analysis results of the vulnerability to be verified and select them as the current tools. The verification module is used to process the vulnerability analysis results of the current tool to obtain vulnerability verification information. The update module is used to process the vulnerability verification information using the vulnerability analysis model to obtain updated vulnerability analysis results. The decision module is used to respond to situations where the preset termination conditions are not met, by updating the vulnerability analysis results as the vulnerability analysis results to be verified, and returning to the step of executing the screening of external tools that match the vulnerability analysis results to be verified. In response to the satisfaction of the preset termination condition, a vulnerability assessment result of the target network data is generated based on the initial vulnerability analysis result, vulnerability verification information, and updated vulnerability analysis result. The external tools include functional execution components that are independent of the vulnerability analysis model.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the security vulnerability assessment method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the security vulnerability assessment method as described in any one of claims 1 to 7.

Images