A method for verifying penetration test results by comparing them with vulnerability databases

Abstract

This invention relates to the field of network testing technology and discloses a method for comparing and verifying penetration test results with a vulnerability database. The method includes the following steps: performing attack chain topology analysis on the original penetration test results, extracting each attack node and the path dependencies between nodes, and constructing a directed acyclic graph (DAG) of the attack chain; for each attack node in the DAG, retrieving a set of hit candidates from the vulnerability database using a three-layer progressive comparison method. The purpose of this method is to address the problem that existing comparison and verification methods forcibly decompose penetration test results into discrete vulnerability entries, severing the real node path dependencies and attack chain topology. This results in an inability to accurately quantify the actual threat of vulnerabilities in the actual attack path by combining real-world environmental conditions and topological locations, leading to the underestimation of high-risk vulnerabilities on critical paths and inaccurate remediation priorities.

Description

Technical Field

[0001] This invention relates to the field of network testing technology, specifically a method for comparing and verifying penetration test results with a vulnerability database. Background Technology

[0002] With the increasingly severe cybersecurity situation, penetration testing has become an important means of proactively discovering system vulnerabilities. After penetration testing, testers typically need to compare the obtained test results with a standard known vulnerability database to qualitatively identify and categorize the discovered security issues. Existing comparison methods generally rely on extracting single vulnerability signatures or identifiers from the test results, directly mapping and matching them one by one with entries in the vulnerability database, and then directly applying the static theoretical scores of a general vulnerability scoring system (such as CVSS) to assess the severity of the vulnerability. This static score is then used as a routine basis for guiding the priority of network system vulnerability remediation.

[0003] However, existing methods forcibly break down penetration test results into discrete vulnerability entries during the comparison process, completely severing and discarding the actual node path dependencies and attack chain topology that exist during the test. This comparison method, which is based solely on the isolated characteristics of vulnerabilities, assigns a fixed risk score to the same vulnerability regardless of whether it is located at the core or periphery of the attack chain. It fails to accurately quantify the real threat of a vulnerability in the actual attack path based on the preconditions and attack context of the real environment. Ultimately, this results in high-threat vulnerabilities on critical paths being underestimated, while isolated vulnerabilities that are unreachable in the environment are remediated, resulting in a significant waste of resources. Summary of the Invention

[0004] The purpose of this invention is to address the problem that existing comparison and verification methods forcibly decompose penetration test results into discrete vulnerability entries, severing the real node path dependencies and attack chain topology. This results in the inability to accurately quantify the real threat of vulnerabilities in the actual attack path by combining real-world preconditions and topological locations, leading to the underestimation of high-risk vulnerabilities on critical paths and inaccurate remediation priorities. Therefore, this invention proposes a method for comparing and verifying penetration test results with vulnerability databases.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: A method for verifying penetration test results by comparing them with a vulnerability database includes the following steps: S1. Perform attack chain topology analysis on the original penetration test results, extract each attack node and the path dependency relationship between nodes, and construct a directed acyclic graph of the attack chain. S2. For each attack node in the directed acyclic graph of the attack chain, a set of hit candidates is retrieved in the vulnerability database through a three-layer progressive comparison method. The three-layer progressive comparison is, in order, precise identifier matching, semantic feature vector similarity matching, and attack mode pre- and post-condition matching. S3. For the attack node in the hit candidate set, calculate its topological position weight in the directed acyclic graph of the attack chain, and verify the preconditions of the hit vulnerability entry in the target environment. Calculate the scenario-based vulnerability risk score of the node based on the topological position weight and the precondition satisfaction status. S4. For attack nodes that fail to match all three layers of progressive comparison, classify and mark them as unreachable nodes or candidate new vulnerability nodes based on the preconditions, and implement differentiated handling procedures accordingly. S5. Aggregate the scenario-based vulnerability risk scores of all scored nodes at the attack chain level to generate the overall attack chain risk value and a priority list of key nodes for remediation. Write the empirical data generated by the comparison back to the vulnerability database to update the actual exploitability confidence of the corresponding entries.

[0006] Based on the above technical solution, the present invention can be further improved as follows.

[0007] Furthermore, the attack chain topology parsing in S1 includes: Each attack node is identified from the raw penetration test results. The information carried by each attack node includes the node type, the set of preconditions on which the node's successful execution depends, and the attack result obtained after the node's successful execution. The node type can be one of the following: initial breakthrough node, lateral movement node, privilege escalation node, or target achievement node. The set of preconditions records the complete set of target environment state parameters required, including service running status, network port open status, and access permission level. The attack result records the control capabilities and permission scope obtained after the node's successful execution. Using attack nodes as vertices and the dependency relationship in the attack path where the attack result of the previous attack node satisfies the precondition of the next attack node as directed edges, a directed acyclic graph of the attack chain is constructed; the directed edges are labeled with the specific capabilities passed from the previous node to the next node.

[0008] Furthermore, S1 also includes extracting a multi-dimensional feature vector for each attack node, the multi-dimensional feature vector containing the following dimensions: In terms of vulnerability semantic features, a dense semantic vector is obtained by encoding the vulnerability description text of the node using a pre-trained word vector model in the security domain. The attack vector attribute dimension encodes three attributes of the node: network reachability, required permission level, and user interaction requirements, into discrete feature values. The node topology position dimension identifies whether the node belongs to the root node, intermediate node, or leaf node in the directed acyclic graph of the attack chain.

[0009] Furthermore, the prerequisite for executing the three-layer progressive comparison in S2 is to pre-construct a three-layer hierarchical index structure for the vulnerability database, which includes: A first-level exact hash index, using CVE number and CNVD number as keys to establish a hash mapping; The secondary semantic vector index extracts semantic feature vectors from the description text and affected component information of each vulnerability record in the vulnerability database, and establishes a vectorized inverted index based on approximate nearest neighbor retrieval. The three-level attack pattern clustering index divides vulnerability database entries into corresponding clusters based on MITREATT&CK attack tactic categories. Each cluster maintains two sets: a typical set of preconditions and a typical set of post-capabilities. The typical set of preconditions is formed by taking the union of the preconditions of each vulnerability entry in the cluster and arranging them in descending order of frequency of occurrence. The typical set of post-capabilities is formed by aggregating the maximum capability boundary of the permissions obtained after successful exploitation of each vulnerability entry in the cluster.

[0010] Furthermore, the specific execution rules for the three-layer progressive comparison in S2 are as follows: The first layer queries the first-level exact hash index using the CVE number or CNVD number carried by the attacking node. If a match is found, the exact match result is recorded and the process proceeds directly to step S3. If no match is found, the process proceeds to the second layer. The second layer submits the dense semantic vector of the attacking node to the secondary semantic vector index, retrieves the top K candidate entries with the highest cosine similarity, where K ranges from 5 to 10, and records the candidate entries with cosine similarity exceeding the first similarity threshold as the semantic hit candidate set. If the candidate set is not empty, proceed to step S3; if the candidate set is empty, proceed to the third layer. The third layer calculates the Jaccard similarity between the set of preconditions of the attack node and the standard preconditions of each vulnerability entry in the corresponding attack tactic cluster. At the same time, it compares the attack result of the attack node with the standard post-capability set of each entry for semantic similarity. Entries whose weighted combined score of the two scores exceeds the second similarity threshold are recorded as pattern hit candidates and enter step S3. If none of the three layers hit, the attack node is sent to step S4.

[0011] Furthermore, the calculation method for the topological location weights in S3 is as follows: The attack chain contribution is defined as the ratio of the number of leaf nodes reachable from the node via directed edges to the total number of leaf nodes in the directed acyclic graph of the attack chain; the substitutability is defined as the ratio of the number of bypass paths that can still reach the same set of leaf nodes by bypassing the node to the total number of paths in the attack chain; the topological position weight is obtained by multiplying the complement of the attack chain contribution and the substitutability. The verification method for the precondition satisfaction status is as follows: take the intersection of the standard triggering precondition set of the hit vulnerability entry and the target environment actual state parameter set recorded during the penetration test, and calculate the ratio of the number of intersection elements to the total number of elements in the standard triggering precondition set as the precondition satisfaction rate; when the precondition satisfaction rate is not lower than the preset reachability threshold, the node is marked as an environment reachable node and participates in the calculation of the scenario-based vulnerability risk score; when it is lower than the preset reachability threshold, the node is marked as an environment unreachable node and sent to step S4.

[0012] Furthermore, the scenario-based vulnerability risk score in S3 is composed of a weighted sum of three components: The first component is the value of the basic CVSS score of the hit vulnerability entry after normalization to the range of zero to one; the second component is the topological position weight of the node; the third component is the contribution value of the preconditions, which is obtained by taking the attack difficulty coefficient marked by the penetration tester based on the time required to meet the preconditions and the technical complexity during the actual attack process. The sum of the weighting coefficients of the three components is constant at one. The weighting coefficient of the first component is dynamically adjusted according to the actual availability confidence of the vulnerability entry: when the actual availability confidence is higher than the preset high confidence threshold, the weighting coefficient of the first component takes the preset upper limit value; when the actual availability confidence is lower than the preset low confidence threshold, the weighting coefficient of the second component is increased accordingly.

[0013] Furthermore, the differentiated processing procedure for classification in S4 includes: For nodes that are unreachable in the environment, extract the corresponding vulnerability database entry identifier, record the unmet preconditions and actual parameter values ​​in the target environment, and generate an unreachable record of the environment containing the direction of security hardening configuration. These nodes do not participate in the attack chain aggregation in step S5. For candidate new vulnerability nodes, extract node feature descriptions, attack payload types, response characteristics, and vulnerability triggering condition records, generate a draft of candidate new vulnerabilities to be reviewed according to the standard field format of the vulnerability database, and push the attached penetration testing evidence collection data summary to the manual review queue. After the candidate new vulnerability draft is approved, it is written into the vulnerability database according to the empirical data write-back process.

[0014] Furthermore, the execution methods for attack chain-level aggregation and empirical data write-back in S5 include: The overall risk value of the attack chain is calculated using a chain-like product aggregation method. The overall risk value is 1 minus the product of the scenario-based vulnerability risk score of all environmentally reachable nodes in the directed acyclic graph and their topological position weights. Key nodes are extracted in descending order of their topological location weights to generate a priority repair list. Cross-chain reuse weights are added to the same attack node that exists in key positions on multiple attack chains for reordering. For entries that hit the vulnerability database, the target environment preconditions snapshot, attack payload type, and attack difficulty are extracted as empirical data and appended to the extended fields of the corresponding entries. The actual exploitability confidence of the hit entries is updated based on the empirical data from each iteration. The base value of the actual exploitability confidence is the ratio of the sum of the number of historical successful exploits, the number of times the environment is marked as unreachable, and the number of times the candidate new vulnerability is associated. The updated actual exploitability confidence is obtained by multiplying the base value by a time decay coefficient.

[0015] Furthermore, the verification report generated in S5 is organized around the attack chain and includes the following six structured parts: Attack Chain Overview: Includes a directed acyclic graph of the attack chain, the overall risk value of the attack chain, and an identifier for attack tactical combinations; Critical node vulnerability list: includes critical vulnerability entries sorted in descending order of topological location weight, scenario-based vulnerability risk score items, corresponding vulnerability database entry identifiers, and actual exploitability confidence levels; List of unreachable vulnerabilities in the environment: includes vulnerability entries sorted in ascending order of prerequisite satisfaction rate and their corresponding security hardening configuration directions; List of candidate novel vulnerabilities: includes feature vector summaries of candidate novel vulnerability nodes, forensic data indexes, and review status; Recommended repair combination: Includes a repair combination scheme based on the aforementioned cross-chain reuse weight and the expected reduction in the overall risk value of the attack chain after implementing the scheme; Vulnerability database write-back summary: Includes the total number of empirical data entries written back, details of actual exploitability confidence changes, and a list of candidate novel vulnerability entries written to the vulnerability database.

[0016] Compared with the prior art, the technical solution of this application has the following beneficial technical effects: This invention constructs a directed acyclic graph of the attack chain, fully preserving the real node path dependencies in penetration testing. This breaks the limitations of traditional isolated vulnerability dismantling. Combined with a three-layer progressive comparison for precise mapping of the vulnerability database, it introduces topological position weights and precondition fulfillment states to perform scenario-based, weighted vulnerability risk scoring on nodes. This completely solves the problem of static, unchanging scores for the same vulnerability, ensuring that vulnerabilities at the core of the attack chain receive high weights commensurate with their actual threat. Simultaneously, for nodes that fail the comparison, they are precisely classified as unreachable nodes or candidate novel vulnerability nodes based on precondition fulfillment states, effectively eliminating isolated vulnerabilities that cannot be triggered in the current environment and fundamentally avoiding the waste of ineffective remediation resources. Finally, by aggregating the risk scores at the attack chain level to generate a priority remediation list and using empirical data to feed back and update the vulnerability database confidence, it achieves precise quantification of global risk and minimal-cost blocking, significantly improving the accuracy of vulnerability threat assessment and the actual effectiveness of security hardening. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the overall process of comparing and verifying penetration test results with vulnerability databases according to the present invention. Figure 2 This is a flowchart of the attack chain topology analysis and feature extraction process of this invention; Figure 3 This is a schematic diagram of the three-layer hierarchical index structure of the vulnerability database of this invention; Figure 4 This is a flowchart of the three-layer progressive comparison execution of the present invention; Figure 5 This is a flowchart illustrating the topological location weighting and scenario-based hazard scoring process of this invention. Figure 6 This is a flowchart illustrating the classification and handling process for missed nodes in this invention. Figure 7 This is a flowchart illustrating the attack chain-level aggregation and empirical data write-back process of this invention. Detailed Implementation

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

[0019] This embodiment provides a method for comparing and verifying penetration test results with a vulnerability database, such as... Figure 1As shown, this method revolves around the raw result data generated after penetration testing. It achieves systematic verification of penetration test results and dynamic calibration of the vulnerability database through six stages: attack chain topology modeling, hierarchical index construction, progressive vulnerability database comparison, scenario-based risk quantification, classification and handling of missed nodes, and attack chain-level aggregation and write-back. The entire method includes steps S1 to S5. like Figure 2 As shown, step S1: Attack chain topology analysis and directed acyclic graph construction The attack chain topology is analyzed on the original penetration test results to extract each attack node and the path dependency relationship between nodes, and a directed acyclic graph of the attack chain is constructed.

[0020] Raw penetration test results typically exist in the form of test report documents, JSON / XML logs exported by automated tools, or structured data packets from the penetration testing platform. In this step, the raw data sources are first preprocessed for format normalization, converting test records from different sources and formats into a standardized sequence of attack events. Each attack event corresponds to an independent attack operation during the penetration test, including the exploited vulnerability information, target host and service identifiers, attack timestamp, and execution result.

[0021] Each attack node is identified from the raw penetration test results. Each attack node carries information including its type, the set of preconditions required for its successful execution, and the attack result obtained after successful execution. Specifically, an aggregation operation is performed on the normalized attack event sequence, merging multiple attempts targeting the same vulnerability into a single attack node, and retaining the record of the final successful execution as the node's payload.

[0022] The node type can be one of the following: initial breach node, lateral movement node, privilege escalation node, or goal achievement node. In actual judgment, if an attack node is the starting point of the entire attack chain and its prerequisites only involve external network reachability, it is marked as an initial breach node; if the node's prerequisites depend on internal network credentials or session tokens obtained by preceding nodes, and its attack results in a new host in a different network segment, it is marked as a lateral movement node; if the node escalates low privileges to high privileges within the same host (e.g., from ordinary user privileges to administrator privileges or from container privileges to host privileges), it is marked as a privilege escalation node; if the node's attack results directly achieve the preset goals in the penetration testing task (e.g., obtaining specified sensitive data or controlling core business servers), it is marked as a goal achievement node. In some complex scenarios, the same node may possess both lateral movement and privilege escalation characteristics. In this case, priority is assigned based on its primary attack intent, with lateral movement taking precedence over privilege escalation.

[0023] The precondition set records the complete set of target environment state parameters required, including service running status, network port open status, and access permission levels. For example, an attack node exploiting a deserialization vulnerability in a web application has preconditions including three parameters: the target host's port 8080 is open, the target web application's version number falls within the affected range, and the attacker possesses ordinary user login credentials for the application. In addition to these three types of parameters, the precondition set can be further expanded to include environmental parameters such as operating system version, security software running status, and network isolation policy configuration.

[0024] The attack results record the control capabilities and permission scope gained after the node is successfully executed. The attack results are recorded using a unified capability description syntax, including the level of permission gained (e.g., ordinary user, administrator, system kernel), the network range that can be accessed (e.g., specified subnet segment, global network), and the types of system resources that can be manipulated (e.g., file system read / write, process control, network traffic forwarding).

[0025] Using attacking nodes as vertices and the dependency relationship where the attack result of the preceding attacking node satisfies the precondition of the following attacking node as directed edges, a directed acyclic graph (DAG) is constructed. The directed edges are labeled with the specific capabilities passed from the preceding node to the following node. The rule for establishing directed edges is as follows: traverse all binary combinations of attacking nodes. If the attack result set of node A and the precondition set of node B have a non-empty intersection, and node A's attack execution time is earlier than node B's, then a directed edge is established from node A to node B. The capability items labeled on this edge are the specific parameters in their intersection. For example, if node A obtains SSH login credentials for a certain sub-segment of the internal network, and node B's preconditions require these SSH credentials, then the directed edge is labeled "SSH credentials@192.168.1.0 / 24". After construction, a loop detection algorithm (such as topological sorting based on depth-first search) is executed. If a loop is detected, the edge with the latest timestamp in the loop is disconnected to ensure that the final graph structure is a DAG.

[0026] After the graph is constructed, if there are multiple nodes without incoming edges, it indicates that there are multiple independent initial breakthrough paths in the penetration test; if there are multiple leaf nodes without outgoing edges, it indicates that there are multiple final attack targets. The entire directed acyclic graph is stored in the form of an adjacency list. Each node entry contains a node identifier, node type, a set of preconditions, a set of attack results, and lists of incoming and outgoing edges.

[0027] Step S1 also includes extracting a multi-dimensional feature vector for each attack node. The multi-dimensional feature vector contains the following dimensions. This feature vector is used for semantic similarity comparison in the subsequent step S2, and its extraction process is carried out simultaneously with the construction of the directed acyclic graph.

[0028] For the vulnerability semantic feature dimension, a pre-trained word vector model in the security domain is used to encode the vulnerability description text of the node to obtain a dense semantic vector. In this embodiment, the training corpus of the pre-trained word vector model comes from vulnerability description texts and security bulletin texts in publicly available vulnerability databases (such as NVD and CNVD), and the model output dimension is a 256-dimensional dense vector. During encoding, the vulnerability description information, attack payload feature description, and target component name recorded in the attack node are concatenated into a complete text input, which is then encoded by the model to obtain the semantic feature vector of the node. If the attack node lacks structured vulnerability description text, the attack steps description filled in by the penetration tester is used as a substitute input.

[0029] The attack vector attribute dimension encodes three attributes of the node: network reachability, required permission level, and user interaction requirements, into discrete feature values. The encoding method for these three attributes follows the definition standard of attack vectors in the CVSS scoring system: network reachability is rated at four levels: network layer reachability, neighboring network reachability, local reachability, or physical contact, encoded as 3, 2, 1, and 0 respectively; required permission level is rated at three levels: no permission required, low permission, and high permission, encoded as 2, 1, and 0 respectively; and user interaction requirements are rated at two levels: no interaction required or interaction required, encoded as 1 and 0 respectively.

[0030] The node topological position dimension identifies whether the node belongs to the root node, intermediate node, or leaf node in the directed acyclic graph of the attack chain. The root node is a node with an in-degree of zero, the leaf node is a node with an out-degree of zero, and the rest are intermediate nodes. This dimension is encoded as a ternary one-hot vector for easy concatenation with other dimension vectors in subsequent operations.

[0031] Ultimately, the multidimensional feature vector of each attack node is formed by concatenating the aforementioned dimensional vectors in sequence, serving as a unified numerical representation for the node to participate in retrieval and comparison operations in subsequent steps.

[0032] Step S2: Three-layer progressive comparison and candidate set retrieval For each attack node in the directed acyclic graph of the attack chain, a set of hit candidates is retrieved from the vulnerability database through a three-layer progressive comparison method. The three-layer progressive comparison method consists of precise identifier matching, semantic feature vector similarity matching, and attack mode pre- and post-condition matching.

[0033] Before performing the three-level progressive comparison, preprocessing work such as index building of the vulnerability database is required. For example... Figure 3 As shown, the prerequisite for executing the three-layer progressive comparison is to pre-build a three-layer hierarchical index structure for the vulnerability database.

[0034] A first-level exact hash index is used to establish a hash mapping with CVE and CNVD numbers as keys. In the specific implementation, each vulnerability record in the vulnerability database may have both a CVE number and a CNVD number. In this case, both numbers serve as independent keys pointing to the same record, enabling mutual lookup using two keys. The hash function uses a consistent hashing algorithm, eliminating the need for a full index rebuild when vulnerabilities are dynamically added or deleted from the vulnerability database.

[0035] The secondary semantic vector index extracts semantic feature vectors from the descriptive text and impact component information of each vulnerability record in the vulnerability database, establishing a vectorized inverted index based on approximate nearest neighbor retrieval. The extraction method of semantic feature vectors is consistent with the encoding method for attack nodes in step S1, employing the same security domain pre-trained word vector model to ensure that attack node vectors and vulnerability database entry vectors are in the same semantic space. Approximate nearest neighbor retrieval uses a hierarchical navigable small-world graph (HNSW) algorithm to construct the index. This algorithm, while ensuring retrieval accuracy, can control the retrieval time complexity of a large-scale vector database to the logarithmic level. After the index is built, incremental updates are performed periodically. When a new entry is added to the vulnerability database, the semantic vector of the new entry is inserted into the corresponding level of the HNSW graph.

[0036] The three-tier attack pattern clustering index categorizes vulnerability database entries into corresponding clusters based on MITREATT&CK attack tactical categories. Each cluster maintains two sets: a set of typical preconditions and a set of typical post-capabilities. The MITREATT&CK framework defines 12 tactical categories: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, data theft, and impact. Each tactical category corresponds to an independent cluster. For vulnerability entries that may span multiple tactical categories, these entries are included in all relevant clusters simultaneously.

[0037] The typical set of preconditions is formed by taking the union of the preconditions of each vulnerability entry within a cluster and then sorting them in descending order of frequency. For example, if the "Lateral Movement" tactical cluster contains 100 vulnerability records, of which 75 preconditions include "internal network credentials", 60 include "target port reachable", and 30 include "specific service version", then the typical set of preconditions for this cluster is a list of ordered triples.

[0038] The typical set of post-exploitation capabilities is aggregated with the maximum capability boundary of the privileges gained after successful exploitation of each vulnerability entry within a cluster as its upper limit. That is, the attack results of each entry within the cluster are taken as the union of the upper bounds of the capabilities. For example, if one entry in a cluster grants ordinary user privileges and another grants administrator privileges, then the upper limit of the typical post-exploitation capabilities for that cluster is administrator privileges.

[0039] like Figure 4As shown, the construction of the three-layer hierarchical index is completed offline during the system initialization phase, and subsequent updates are only performed locally when there are incremental changes to the vulnerability database.

[0040] After the index is built, a progressive comparison is performed on each attack node in the directed acyclic graph. The specific execution rules for the three-layer progressive comparison are as follows: The first layer queries the first-level exact hash index using the CVE number or CNVD number carried by the attacking node. If a match is found, the exact match result is recorded and the process proceeds directly to step S3. If no match is found, the process proceeds to the second layer. In actual penetration testing, the results generated by automated scanning tools (such as Nessus and OpenVAS) usually carry explicit CVE numbers, while vulnerabilities discovered by manual penetration testing may lack standard numbers. In this case, the first layer cannot be hit, and the process naturally degrades to the second layer.

[0041] The second layer submits the dense semantic vector of the attack node to the secondary semantic vector index, retrieving the top K candidate entries with the highest cosine similarity. The value of K ranges from 5 to 10. Candidate entries with a cosine similarity exceeding the first similarity threshold are recorded as a semantic hit candidate set. If the candidate set is not empty, proceed to step S3; otherwise, proceed to the third layer. In this embodiment, the default value of K is 7, and the default value of the first similarity threshold is 0.82. This threshold can be adjusted according to the size and domain coverage of the vulnerability database: when the vulnerability database is small, the threshold should be appropriately lowered to improve the recall rate; when the vulnerability database is large, the threshold should be appropriately increased to control false matches. When calculating cosine similarity, L2 norm normalization is performed on both the attack node vector and the candidate entry vector to ensure that the similarity calculation result is within the standard range of -1 to 1.

[0042] The third layer calculates the Jaccard similarity between the set of preconditions for the attack node and the standard preconditions for each vulnerability entry in the corresponding attack tactic cluster. Simultaneously, it compares the attack result of the attack node with the standard post-capability set of each entry for semantic similarity. Entries whose weighted combined score exceeds the second similarity threshold are recorded as pattern hit candidates and proceed to step S3. The retrieval scope of the third layer comparison is limited to the attack tactic cluster corresponding to the attack node type, rather than the entire vulnerability database, thus significantly reducing the computational load. In this embodiment, the weighting coefficients for Jaccard similarity and semantic similarity are set to 0.4 and 0.6, respectively, and the default value for the second similarity threshold is 0.70. The weighting coefficients are set based on the fact that the set of preconditions for attack patterns is mostly a set comparison of discrete parameter items, while the description of post-capability involves semantic understanding at the natural language level. The latter usually has higher discriminative power than the former, therefore, semantic similarity is given higher weight.

[0043] If no match is found in all three layers, the attacking node is sent to step S4. In practice, to improve the traceability of the overall comparison, each attacking node generates a comparison log after completing the three-layer progressive comparison, recording the comparison result (hit / miss) of the node in each layer, the list of matched candidate entries, and the corresponding similarity score, which is convenient for subsequent verification and auditing.

[0044] Step S3: Topology location weight calculation and scenario-based vulnerability risk scoring like Figure 5 As shown, for attack nodes that hit the candidate set, the topological position weight in the directed acyclic graph of the attack chain is calculated, and the preconditions of the hit vulnerability entries are verified in the target environment. Based on the topological position weight and the precondition satisfaction status, the scenario-based vulnerability risk score of the node is calculated.

[0045] The attack chain contribution is defined as the ratio of the number of leaf nodes reachable from a given node via directed edges to the total number of leaf nodes in the directed acyclic graph (DAG). This calculation is performed by performing a depth-first or breadth-first traversal of the DAG starting from the current node, and the size of the set of reachable leaf nodes is determined. For example, if there are 4 leaf nodes in the DAG (corresponding to 4 final attack targets), and an attacking node can reach 3 of these leaf nodes, then its attack chain contribution is 0.75.

[0046] Substitutability is defined as the ratio of the number of bypass paths that still reach the same set of leaf nodes while bypassing a given node to the total number of paths in the attack chain. The substitutability is calculated as follows: temporarily remove the node and all its incoming and outgoing edges from the directed acyclic graph. Count the number of reachable paths from all root nodes to the original set of leaf nodes after removal, and divide this count by the total number of paths from all root nodes to all leaf nodes in the original graph. If the node becomes completely unreachable after removal, the substitutability is zero, indicating that the node is a critical bottleneck in the attack chain.

[0047] The topological position weight is obtained by multiplying the attack chain contribution by the complement of the substitutability. That is, the topological position weight equals the attack chain contribution multiplied by (1 minus the substitutability). When a node has a high attack chain contribution and a low substitutability, its topological position weight approaches the attack chain contribution itself, indicating that the node occupies an unavoidable core hub position in the attack chain.

[0048] The verification method for the precondition satisfaction status is as follows: The intersection of the standard trigger precondition set for a vulnerability entry and the set of actual target environment state parameters recorded during the penetration test is taken. The ratio of the number of elements in the intersection to the total number of elements in the standard trigger precondition set is used as the precondition satisfaction rate. The set of actual target environment state parameters originates from the environment information collection phase during the penetration test execution and typically includes port scan results, service fingerprinting results, operating system version detection results, and a list of obtained credentials for the target host. This set is continuously updated during the penetration test execution to reflect the dynamic changes in the environment state as the attack progresses.

[0049] If the precondition satisfaction rate is not lower than the preset reachability threshold, the node is marked as an environment reachable node and participates in the calculation of scenario-based vulnerability risk score. If it is lower than the preset reachability threshold, the node is marked as an environment unreachable node and sent to step S4. In this embodiment, the default value of the preset reachability threshold is 0.80, which means that at least 80% of the preconditions for hitting a vulnerability entry must be met in the target environment to be considered as an environment reachable node. This threshold can be adjusted according to the strictness of the penetration testing task: in high-security scenarios, it can be set to 0.90 or higher to reduce false positives, and in rapid investigation scenarios, it can be set to 0.70 to expand the coverage.

[0050] For attack nodes that pass the environmental reachability verification, the scenario-based vulnerability risk score is calculated. The scenario-based vulnerability risk score is composed of a weighted sum of three components.

[0051] The first component is the value of the base CVSS score of the hit vulnerability entry, normalized to the range of zero to one. The normalization method is to divide the base CVSS score (original range 0 to 10) by 10. If the same attack node hits multiple vulnerability database candidate entries, the one with the highest base CVSS score is taken as the first component value of that node.

[0052] The second component is the topological position weight of the node, which is the product of the attack chain contribution calculated above and the substitutability complement.

[0053] The third component is the contribution value for achieving the preconditions. It is obtained by subtracting the attack difficulty coefficient, which is marked by penetration testers based on the time and technical complexity required to meet the preconditions during the actual attack. The attack difficulty coefficient is marked by penetration testers based on practical experience during the penetration process, and its value ranges from zero to one. The higher the value, the higher the time investment and technical ability required to meet the preconditions of the vulnerability. The third component equals 1 minus the attack difficulty coefficient. When the attack difficulty coefficient is zero (i.e., the preconditions are very easy to meet), the third component takes the maximum value of 1; when the attack difficulty coefficient is 1 (i.e., the preconditions are very difficult to meet), the third component takes the minimum value of 0. If the penetration tester does not provide a mark, the system automatically calculates the default value of the attack difficulty coefficient based on the precondition satisfaction rate. The calculation rule is: attack difficulty coefficient equals 1 minus the precondition satisfaction rate.

[0054] The sum of the weighting coefficients of the three components is constant at one. The weighting coefficient of the first component is dynamically adjusted based on the current actual exploitability confidence level of the vulnerability entry: when the actual exploitability confidence level is higher than a preset high confidence threshold, the weighting coefficient of the first component takes a preset upper limit value; when the actual exploitability confidence level is lower than a preset low confidence threshold, the weighting coefficient of the second component increases accordingly. In this embodiment, the weighting coefficients of the three components are denoted as α, β, and δ, with default initial values ​​of 0.4, 0.35, and 0.25, respectively. The preset high confidence threshold is 0.80, corresponding to an upper limit of α of 0.50; the preset low confidence threshold is 0.30. When the actual exploitability confidence level is lower than this threshold, α decreases to 0.25, β increases to 0.50, and δ remains unchanged at 0.25. This dynamic adjustment mechanism ensures that: for vulnerabilities confirmed to be exploitable through multiple actual penetration tests, their CVSS base score weight is increased; for vulnerabilities lacking actual exploitation verification, their topological position in the attack chain is given a more decisive role. The calculation and updating method of actual availability confidence is explained in detail in step S5.

[0055] Step S4: Classification, labeling, and differentiated handling of missing nodes like Figure 6 As shown, attack nodes that fail to match all three layers of progressive comparison are classified and marked as unreachable nodes or candidate new vulnerability nodes based on the fulfillment of preconditions, and differentiated handling procedures are implemented accordingly.

[0056] Step S4 receives two types of input nodes: one type is nodes that did not match any of the three-layer comparisons in step S2, and the other type is nodes that, although they matched the candidate set in step S3, were marked as environmentally unreachable because their precondition satisfaction rate was lower than the reachability threshold. Different processing logic is executed for these two types of nodes.

[0057] For nodes that are unreachable in the environment, the corresponding vulnerability database entry identifier is extracted, and the unmet preconditions and actual parameter values ​​in the target environment are recorded. This generates an unreachable environment record containing security hardening configuration directions. These nodes do not participate in the attack chain aggregation in step S5. The data structure of the unreachable environment record includes: vulnerability database entry identifier, precondition fulfillment rate value, a list of unmet conditions (each containing condition name, standard requirement value, and actual value in the target environment), and hardening configuration direction suggestions. The hardening configuration direction is automatically generated by the system based on the mapping relationship between unmet conditions and the standard security baseline configuration library. For example, if a condition is "target port 3389 is open" and the actual value in the target environment is "port 3389 is closed," then the hardening configuration direction is "maintain port 3389 in a closed state or continuously block access to this port at the network boundary level." These records are stored independently and do not participate in subsequent chain aggregation and risk value calculation, but are included in the final verification report as part of the security hardening recommendations.

[0058] For candidate novel vulnerability nodes, the system extracts node feature descriptions, attack payload types, response characteristics, and vulnerability triggering conditions. A draft candidate vulnerability is generated according to the standard field format of the vulnerability database, and the accompanying penetration testing forensics data summary is pushed to the manual review queue. A candidate novel vulnerability node refers to an attack node that has been successfully exploited in penetration testing but cannot be matched with any entry in the vulnerability database. For such nodes, the system reconstructs a complete description of the node from the multi-dimensional feature vector extracted in step S1, and extracts the attack payload types recorded during the penetration testing process (such as remote code execution, SQL injection, buffer overflow, etc.), the abnormal response characteristics of the target system during the attack process (such as specific error codes, abnormal return data packet characteristics, service crash log fragments), and the specific conditions for vulnerability triggering (such as specific request parameter formats, specific protocol interaction sequences). The above information is structured and populated according to the field definitions of standard vulnerability database entries (including vulnerability title, affected components, vulnerability type, severity level, triggering conditions, remediation suggestions, etc.) to generate a draft candidate vulnerability. The draft is marked "Pending Review" and includes a summary of forensic data from the penetration test (including network traffic summaries of the attack process, hash indexes of key operation screenshots, and snapshots of the test environment configuration), which is then pushed to the manual review queue. After reviewers perform technical verification and information supplementation on the draft, those that pass the review proceed to step S5, the empirical data write-back process, to be formally written into the vulnerability database. Upon the first write, the entry's source field is marked with a "First Discovery by Penetration Test" source tag to distinguish it from vulnerability entries discovered through security bulletins or automated scans. Drafts that fail the review are marked with the reason for rejection and archived, but are not written into the vulnerability database.

[0059] In real-world penetration testing scenarios, the probability of a candidate novel vulnerability node appearing is usually low, but once it does appear, it often has high security value because it means that there are security risks in the target system that have not yet been publicly recorded.

[0060] Step S5: Attack chain-level aggregation, repair list generation, and empirical data closed-loop write-back like Figure 7 As shown, the scenario-based vulnerability risk scores of all scored nodes are aggregated at the attack chain level to generate the overall attack chain risk value and a priority list of key nodes for remediation. The empirical data generated by the comparison is written back to the vulnerability database to update the actual exploitability confidence of the corresponding entries.

[0061] This process is executed in three phases: calculating the overall risk value of the attack chain, generating a priority list of key nodes for repair, and writing back empirical data in a closed loop.

[0062] Overall risk value calculation of the attack chain The overall risk value of the attack chain is calculated using a chain-like product aggregation method. The overall risk value is 1 minus the product of the scenario-based vulnerability risk score and the topological position weight of all environmentally reachable nodes in the directed acyclic graph. Specifically, let V be a set of all environmentally reachable attack nodes in the directed acyclic graph. For the i-th node in set V, its scenario-based vulnerability risk score is denoted as Ri, and its topological position weight is denoted as Wi. Then, the overall risk value of the attack chain is equal to 1 minus the product of (1 minus Ri multiplied by Wi) of all nodes in set V. This aggregation method uses the complementary calculation logic of at least one occurrence of independent events in probability: each attack node is considered an independent attack attempt event, and its success probability is approximately represented by the product of Ri and Wi. The overall risk value of the attack chain represents the combined probability that at least one node has successfully attacked. When there are multiple nodes with high scores and high topological weights in the attack chain, the overall risk value approaches 1; when the scores or topological weights of all nodes are low, the overall risk value approaches 0.

[0063] If there are multiple independent attack chains in a directed acyclic graph (i.e., disjoint subgraphs that start from different root nodes and reach different leaf nodes), then calculate the overall risk value of each independent attack chain separately, and finally take the maximum value among all the overall risk values ​​of the attack chains as the upper bound of the comprehensive risk of the target system.

[0064] Critical Node Priority Repair List Generation The system extracts key nodes in descending order of their topological position weights to generate a priority repair list. For the same attack node present in key positions across multiple attack chains, a cross-chain reuse weight is added for reordering. The specific execution process is as follows: First, all reachable nodes in the directed acyclic graph are sorted from highest to lowest topological position weight. The top N nodes are extracted to form the initial repair list. The default value for N is 3, which can be adjusted by the user based on the actual constraints of the repair resources. Then, each node in the initial list is traversed, checking if it simultaneously appears in key positions on two or more independent attack chains (i.e., positions ranked in the top N by topological position weight). If the condition is met, a cross-chain reuse weight is added to the node. The cross-chain reuse weight is equal to the number of attack chains the node traverses divided by the total number of attack chains, and is added to the node's original topological position weight. After adding the cross-chain reuse weight, the repair list is reordered, and the final priority repair list of key nodes is output.

[0065] Based on the repair list, a minimum-cost repair combination scheme is further generated. The goal of this scheme is to select the fewest number of attack nodes for repair, so as to maximize the reduction in the overall risk value of the attack chain after repair. Specifically, the scheme involves sequentially simulating the removal of the top-ranked attack nodes from the repair list, recalculating the overall risk value of the attack chain, selecting the node combination that maximizes the reduction in risk value as the recommended scheme, and recording the expected risk value reduction for each combination.

[0066] Empirical data closed-loop write-back For entries that hit the vulnerability database, the target environment's preconditions snapshot, attack payload type, and attack difficulty are extracted as empirical data and appended to the corresponding entry's extended fields. The extended fields' data structure includes: a penetration test execution timestamp, a target environment preconditions snapshot (recording the complete set of state parameters of the target environment during this penetration test), an identifier for the actual attack payload type used, the attack difficulty coefficient marked by the penetration tester, and a Boolean flag indicating whether the attack was successful. Empirical data written back from each penetration test is appended to the entry's extended fields, preserving historical records without overwriting previous writes.

[0067] The actual exploitability confidence of the hit entries is updated based on empirical data from previous iterations. The base value of the actual exploitability confidence is the ratio of the sum of the number of successful exploits in history, the number of times the environment is unreachable, and the number of times the candidate new vulnerability is associated. The updated actual exploitability confidence is obtained by multiplying the base value by a time decay factor. Specifically, for a specific entry in the vulnerability database, all historical penetration test write-back records in its extended fields are counted, and the following are calculated: number of successful exploits (the number of records where the attack was successful and the environment is reachable), number of times the environment is unreachable (the number of records that were hit but the environment is unreachable), and number of times the candidate new vulnerability is associated (the number of records where there is a high correlation between this entry and the candidate new vulnerability draft, and the correlation is determined by semantic similarity). The base value is equal to the number of successful exploits divided by the sum of the three items. A time decay factor is introduced above the base value to reflect the timeliness of the vulnerability. The time decay factor is a constant less than 1 and greater than 0 (0.95 in this embodiment), and is exponentially calculated using the time interval since the last update (in months). That is, the time decay factor is equal to 0.95 raised to the power of the difference in months. The updated actual exploitability confidence level is equal to the base value multiplied by the time decay factor. When a vulnerability entry has not been hit in a penetration test for a long time, its confidence level will gradually decay over time and approach zero, reflecting that the actual exploitability of the vulnerability in the current environment is decreasing.

[0068] The updated actual exploitability confidence level is written back to the corresponding field of the vulnerability database entry, for use in the dynamic adjustment of the weighting coefficient in step S3 during subsequent penetration testing comparison and verification, thus forming a complete closed loop of "penetration testing verification → vulnerability database confidence level update → comparison score weight adjustment → reference for the next penetration test".

[0069] After completing the above three stages, the generated verification report is organized by the attack chain and includes the following six structured parts.

[0070] Attack Chain Overview: Includes the directed acyclic graph of the attack chain, the overall risk value of the attack chain, and the attack tactic combination identifier. The directed acyclic graph of the attack chain is presented simultaneously in two forms: a visual topology graph and an adjacency list. The attack tactic combination identifier is an ordered combination of the MITREATT&CK tactic categories corresponding to all attack nodes in the attack chain.

[0071] Critical Node Vulnerability List: Includes critical vulnerability entries sorted in descending order of topological location weight, scenario-based vulnerability risk score components, corresponding vulnerability database entry identifiers, and actual exploitability confidence levels. Each record displays the independent values ​​of the three scoring components and the weighted overall score.

[0072] Unreachable Environment Vulnerability List: This list includes vulnerability entries sorted in ascending order of prerequisite fulfillment rate, along with their corresponding security hardening configuration directions. Entries with lower fulfillment rates appear earlier in the list, indicating they are further from being exploitable. However, this also means that if environmental conditions change (such as opening new ports or adding new services), the threat of the vulnerability may rapidly increase, requiring continuous monitoring.

[0073] Candidate Novel Vulnerability List: Includes feature vector summaries of candidate novel vulnerability nodes, forensic data indexes, and review status. Review status includes three values: "Pending Review," "Approved and Added to Database," and "Rejected and Archived."

[0074] Recommended Repair Combinations: This includes repair combination schemes that prioritize cross-chain reuse weights and the expected reduction in the overall risk value of the attack chain after implementing the scheme. The repair combination schemes are presented in tabular form, with each row corresponding to one repair combination, listing the set of nodes to be repaired, the expected overall risk value after repair, and the percentage reduction in risk value.

[0075] Vulnerability Database Write-back Summary: This includes the total number of empirical data entries written back, details of changes in actual exploitability confidence levels, and a list of candidate novel vulnerability entries written to the vulnerability database. The confidence level change details are listed item by item, comparing the confidence level values ​​before and after the update.

Claims

1. A method for comparing and verifying penetration test results with a vulnerability database, characterized in that, Includes the following steps: S1. Perform attack chain topology analysis on the original penetration test results, extract each attack node and the path dependency relationship between nodes, and construct a directed acyclic graph of the attack chain. S2. For each attack node in the directed acyclic graph of the attack chain, a set of hit candidates is retrieved in the vulnerability database through a three-layer progressive comparison method. The three-layer progressive comparison is, in order, precise identifier matching, semantic feature vector similarity matching, and attack mode pre- and post-condition matching. S3. For the attack node in the hit candidate set, calculate its topological position weight in the directed acyclic graph of the attack chain, and verify the preconditions of the hit vulnerability entry in the target environment. Calculate the scenario-based vulnerability risk score of the node based on the topological position weight and the precondition satisfaction status. S4. For attack nodes that fail to match all three layers of progressive comparison, classify and mark them as unreachable nodes or candidate new vulnerability nodes based on the preconditions, and implement differentiated handling procedures accordingly. S5. Aggregate the scenario-based vulnerability risk scores of all scored nodes at the attack chain level to generate the overall attack chain risk value and a priority list of key nodes for remediation. Write the empirical data generated by the comparison back to the vulnerability database to update the actual exploitability confidence of the corresponding entries.

2. The method for comparing and verifying penetration test results with a vulnerability database according to claim 1, characterized in that, The attack chain topology analysis in S1 includes: Each attack node is identified from the raw penetration test results. The information carried by each attack node includes the node type, the set of preconditions on which the node's successful execution depends, and the attack result obtained after the node's successful execution. The node type can be one of the following: initial breakthrough node, lateral movement node, privilege escalation node, or target achievement node. The set of preconditions records the complete set of target environment state parameters required, including service running status, network port open status, and access permission level. The attack result records the control capabilities and permission scope obtained after the node's successful execution. Using attack nodes as vertices and the dependency relationship in the attack path where the attack result of the previous attack node satisfies the precondition of the next attack node as directed edges, a directed acyclic graph of the attack chain is constructed; the directed edges are labeled with the specific capabilities passed from the previous node to the next node.

3. The method for comparing and verifying penetration testing results with a vulnerability database according to claim 2, characterized in that, S1 further includes extracting a multi-dimensional feature vector for each attack node, the multi-dimensional feature vector containing the following dimensions: In terms of vulnerability semantic features, a dense semantic vector is obtained by encoding the vulnerability description text of the node using a pre-trained word vector model in the security domain. The attack vector attribute dimension encodes three attributes of the node: network reachability, required permission level, and user interaction requirements, into discrete feature values. The node topology position dimension identifies whether the node belongs to the root node, intermediate node, or leaf node in the directed acyclic graph of the attack chain.

4. The method for comparing and verifying penetration test results with a vulnerability database according to claim 3, characterized in that, The prerequisite for executing the three-layer progressive comparison in S2 is to pre-construct a three-layer hierarchical index structure for the vulnerability database. The three-layer hierarchical index structure includes: A first-level exact hash index, using CVE number and CNVD number as keys to establish a hash mapping; The secondary semantic vector index extracts semantic feature vectors from the description text and affected component information of each vulnerability record in the vulnerability database, and establishes a vectorized inverted index based on approximate nearest neighbor retrieval. The three-level attack pattern clustering index divides vulnerability database entries into corresponding clusters based on MITREATT&CK attack tactic categories. Each cluster maintains two sets: a typical set of preconditions and a typical set of post-capabilities. The typical set of preconditions is formed by taking the union of the preconditions of each vulnerability entry in the cluster and arranging them in descending order of frequency of occurrence. The typical set of post-capabilities is formed by aggregating the maximum capability boundary of the permissions obtained after successful exploitation of each vulnerability entry in the cluster.

5. The method for comparing and verifying penetration test results with a vulnerability database according to claim 4, characterized in that, The specific execution rules for the three-layer progressive comparison in S2 are as follows: The first layer queries the first-level exact hash index using the CVE number or CNVD number carried by the attacking node. If a match is found, the exact match result is recorded and the process proceeds directly to step S3. If no match is found, the process proceeds to the second layer. The second layer submits the dense semantic vector of the attacking node to the secondary semantic vector index, retrieves the top K candidate entries with the highest cosine similarity, where K ranges from 5 to 10, and records the candidate entries with cosine similarity exceeding the first similarity threshold as the semantic hit candidate set. If the candidate set is not empty, proceed to step S3; if the candidate set is empty, proceed to the third layer. The third layer calculates the Jaccard similarity between the set of preconditions of the attack node and the standard preconditions of each vulnerability entry in the corresponding attack tactic cluster. At the same time, it compares the attack result of the attack node with the standard post-capability set of each entry for semantic similarity. Entries whose weighted combined score of the two scores exceeds the second similarity threshold are recorded as pattern hit candidates and enter step S3. If none of the three layers hit, the attack node is sent to step S4.

6. The method for comparing and verifying penetration test results with a vulnerability database according to claim 1, characterized in that, The calculation method for the topological location weights in S3 is as follows: The attack chain contribution is defined as the ratio of the number of leaf nodes reachable from the node via directed edges to the total number of leaf nodes in the directed acyclic graph of the attack chain; the substitutability is defined as the ratio of the number of bypass paths that can still reach the same set of leaf nodes by bypassing the node to the total number of paths in the attack chain; the topological position weight is obtained by multiplying the complement of the attack chain contribution and the substitutability. The verification method for the precondition satisfaction status is as follows: take the intersection of the standard triggering precondition set of the hit vulnerability entry and the target environment actual state parameter set recorded during the penetration test, and calculate the ratio of the number of intersection elements to the total number of elements in the standard triggering precondition set as the precondition satisfaction rate; when the precondition satisfaction rate is not lower than the preset reachability threshold, the node is marked as an environment reachable node and participates in the calculation of the scenario-based vulnerability risk score; when it is lower than the preset reachability threshold, the node is marked as an environment unreachable node and sent to step S4.

7. The method for comparing and verifying penetration test results with a vulnerability database according to claim 6, characterized in that, The scenario-based vulnerability risk score in S3 is composed of a weighted sum of three components: The first component is the value of the basic CVSS score of the hit vulnerability entry after normalization to the range of zero to one; the second component is the topological position weight of the node; the third component is the contribution value of the preconditions, which is obtained by taking the attack difficulty coefficient marked by the penetration tester based on the time required to meet the preconditions and the technical complexity during the actual attack process. The sum of the weighting coefficients of the three components is constant at one. The weighting coefficient of the first component is dynamically adjusted according to the actual availability confidence of the vulnerability entry: when the actual availability confidence is higher than the preset high confidence threshold, the weighting coefficient of the first component takes the preset upper limit value; when the actual availability confidence is lower than the preset low confidence threshold, the weighting coefficient of the second component is increased accordingly.

8. The method for comparing and verifying penetration test results with a vulnerability database according to claim 7, characterized in that, The differentiated processing procedure for classification in S4 includes: For nodes that are unreachable in the environment, extract the corresponding vulnerability database entry identifier, record the unmet preconditions and actual parameter values ​​in the target environment, and generate an unreachable record of the environment containing the direction of security hardening configuration. These nodes do not participate in the attack chain aggregation in step S5. For candidate new vulnerability nodes, extract node feature descriptions, attack payload types, response characteristics, and vulnerability triggering condition records, generate a draft of candidate new vulnerabilities to be reviewed according to the standard field format of the vulnerability database, and push the attached penetration testing evidence collection data summary to the manual review queue. After the candidate new vulnerability draft is approved, it is written into the vulnerability database according to the empirical data write-back process.

9. The method for comparing and verifying penetration test results with a vulnerability database according to claim 8, characterized in that, The execution methods for attack chain-level aggregation and empirical data write-back in S5 include: The overall risk value of the attack chain is calculated using a chain-like product aggregation method. The overall risk value is 1 minus the product of the scenario-based vulnerability risk score of all environmentally reachable nodes in the directed acyclic graph and their topological position weights. Key nodes are extracted in descending order of their topological location weights to generate a priority repair list. Cross-chain reuse weights are added to the same attack node that exists in key positions on multiple attack chains for reordering. For entries that hit the vulnerability database, the target environment preconditions snapshot, attack payload type, and attack difficulty are extracted as empirical data and appended to the extended fields of the corresponding entries. The actual exploitability confidence of the hit entries is updated based on the empirical data from each iteration. The base value of the actual exploitability confidence is the ratio of the sum of the number of historical successful exploits, the number of times the environment is marked as unreachable, and the number of times the candidate new vulnerability is associated. The updated actual exploitability confidence is obtained by multiplying the base value by a time decay coefficient.

10. A method for comparing and verifying penetration testing results with a vulnerability database according to claim 9, characterized in that, The verification report generated in S5 is organized by attack chain and includes the following six structured parts: Attack Chain Overview: Includes a directed acyclic graph of the attack chain, the overall risk value of the attack chain, and an identifier for attack tactical combinations; Critical node vulnerability list: includes critical vulnerability entries sorted in descending order of topological location weight, scenario-based vulnerability risk score items, corresponding vulnerability database entry identifiers, and actual exploitability confidence levels; List of unreachable vulnerabilities in the environment: includes vulnerability entries sorted in ascending order of prerequisite satisfaction rate and their corresponding security hardening configuration directions; List of candidate novel vulnerabilities: includes feature vector summaries of candidate novel vulnerability nodes, forensic data indexes, and review status; Recommended repair combination: Includes a repair combination scheme based on the aforementioned cross-chain reuse weight and the expected reduction in the overall risk value of the attack chain after implementing the scheme; Vulnerability database write-back summary: Includes the total number of empirical data entries written back, details of actual exploitability confidence changes, and a list of candidate novel vulnerability entries written to the vulnerability database.

Images