Cross-source vulnerability association method based on identifier pattern recognition and bidirectional atomic link
By employing identifier pattern recognition and bidirectional atomic linking, the problems of insufficient consistency and coverage in cross-source vulnerability association are solved, enabling efficient, reliable association and continuous optimization of cross-source vulnerability information.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- THE FIRST RES INST OF MIN OF PUBLIC SECURITY
- Filing Date
- 2026-02-03
- Publication Date
- 2026-05-12
AI Technical Summary
Existing technologies for cross-source vulnerability association suffer from issues such as one-way association, lost updates during concurrent writes, difficulty in automatically discovering hidden aliases, and lack of quality assessment, resulting in inconsistent association relationships and insufficient coverage.
By employing a method based on identifier pattern recognition and bidirectional atomic linking, and through normalization processing, identifier type recognition, candidate discovery, and bidirectional atomic association writing, combined with regular symmetry auditing, a bidirectional association and self-healing mechanism for vulnerability information is achieved, ensuring the symmetry and coverage of the association relationship.
It significantly improves the coverage and consistency of cross-source vulnerability associations, reduces the probability of one-way edges and lost updates, has engineering feasibility in large-scale production environments, and provides a continuously optimized quality assessment mechanism.
Smart Images
Figure CN122020666A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network security technology, specifically to a cross-source vulnerability association method based on identifier pattern recognition and bidirectional atomic linking. Background Technology
[0002] Cross-origin vulnerability correlation is a technique that integrates and analyzes security vulnerability information from different sources and dimensions to discover a broader attack surface or advanced threats. It reveals cross-system, cross-application, or cross-organizational attack paths that attackers may exploit by connecting seemingly isolated vulnerability data.
[0003] Currently, one of the following methods is commonly used to achieve "alignment" or "reference" of cross-source vulnerabilities: 1. Centralized mapping table scheme: Record the mapping of `ID_A -> ID_B` in an independent relation table.
[0004] 2. One-way reference field solution: Set fields such as `references / aliases` in the vulnerability record to store the URL or external ID, but do not force reverse write-back.
[0005] 3. Knowledge Graph Construction Scheme: Construct a security knowledge graph, using vulnerabilities, assets, attack events, etc. as nodes and reasoning about their relationships. However, vulnerability ID alignment often relies on existing data or manual rules.
[0006] The existing technology has at least the following drawbacks: 1. One-way association leads to unreachability: If a record is referenced only on one side, it cannot be guaranteed that the corresponding record can be retrieved from the other side.
[0007] 2. Concurrent writes lead to lost updates: In distributed data collection and parallel tasks, the traditional "read-modify-write" process is prone to overwriting, resulting in the loss of correlation relationships.
[0008] 3. Hidden aliases are difficult to discover automatically: External IDs often appear in description text, tags, or announcement body text, and the coverage is insufficient when there is a lack of systematic extraction and noise reduction strategies.
[0009] 4. Lack of operational quality assessment: It is impossible to continuously quantify quality indicators such as "related proportion", "distribution by source" and "whether symmetry is broken", making it difficult to achieve closed-loop optimization. Summary of the Invention
[0010] To address the shortcomings of existing technologies, this invention aims to provide a cross-source vulnerability association method based on identifier pattern recognition and bidirectional atomic linking.
[0011] To achieve the above objectives, the present invention adopts the following technical solution: The method for cross-source vulnerability association based on identifier pattern recognition and bidirectional atomic links includes the following steps: S1. Vulnerability Information Collection: After collecting vulnerability information from external data sources, a corresponding vulnerability record document is generated for each vulnerability in the vulnerability document library of the storage layer. The fields of the vulnerability record document include vulnerability main identifier, source identifier, tag array, alias array, description text, set of associated identifiers, and last modification time. The source and description text of each vulnerability are filled into the corresponding fields of the vulnerability record document. If the upstream data source provides an alias list, the identifiers in the alias list are filled into the alias array field. S2. Standardization Processing: Standardize the original vulnerability primary identifier contained in the vulnerability information and perform format validity verification. If the verification fails, the current processing ends and the reason for the failure is recorded; if the verification passes, proceed to step S3. S3. Identifier type identification: The normalized original vulnerability master identifier is matched and identified in the identifier type pattern library to obtain the identifier type. Then, the normalized original vulnerability master identifier is written as the standard ID v of the unified key space into the vulnerability master identifier field of the vulnerability document. If the vulnerability information of a data source contains both the original vulnerability master identifier and the CVE identifier that the data source originally possesses, and the CVE identifier is ultimately selected as the standard ID in the unified key space, then the original vulnerability master identifier is written into the tag array of the vulnerability record document. S4. Candidate Discovery: S4.1 Read the tag array field of the vulnerability log document, parse the external identifier tags, and obtain the candidate set C1; S4.2 If the alias array field in the vulnerability log document is not empty, read the identifier of the alias array field, normalize it, and add it to the candidate set C2; S4.3 Perform substring-level pattern scanning on the description text field in the vulnerability log document, extract substrings that conform to the identifier format, and add them to the candidate set C3 after normalization. S5. Merge to obtain candidate set C = C1 ∪ C2 ∪ C3, and perform deduplication and noise reduction on candidate set C. Remove the identifiers in candidate set C that are the same as v in the vulnerability master identifier field of the vulnerability record document, and remove the identifiers that do not meet the format legality check. S6, Bidirectional Atomic Association Write: Perform the following sequentially for each candidate c ∈ C in the candidate set: (1) Write A→B: In the storage layer, update the vulnerability record document corresponding to v. If the field of the associated identifier set is empty, initialize it first and add candidate c to the associated identifier set. If the associated identifier set already exists, but c does not exist in it, append candidate c to the associated identifier set. After updating the fields of the associated identifier set, update the last modified time field last_modified synchronously. (2) Write B→A: Perform the same update on the vulnerability record document corresponding to candidate c in the storage layer, write v into the associated identifier set of the vulnerability record document corresponding to candidate c, and update the last modified time field last_modified; S7. Output and Record: Output the processing results, including the number of newly added associations, the list of failed candidates and the reasons for failure, and write them to the audit log and the statistics counter. The statistics counter is used to count the number of successful writes, the number of failed writes, the number of retries, the distribution of failure reasons, and the number of tasks to be compensated.
[0012] Furthermore, in step S2, the normalization process includes case normalization and removal of invisible characters and whitespace.
[0013] Furthermore, in steps (1) and (2) of S6, when updating the vulnerability document, field-level scripted atomic updates are used. When writing, the full vulnerability record document is not read, and only the fields of the associated identifier set are updated conditionally.
[0014] Furthermore, in step S6, if the write operation fails in either direction of (1) and (2), the retry logic is triggered to retry the incomplete write operation. If the write operation still fails after a limited number of retries, the incomplete write operation is recorded as a "task to be compensated" and will be rewritten by the subsequent symmetry audit.
[0015] Furthermore, in step S7, the processing results include the number of newly added associations, the list of failed candidates, and the reasons for failure, and are written into the audit log and the statistics counter.
[0016] Furthermore, the above method also includes step S8: periodically performing symmetry audit tasks. S8.1 Scan all vulnerability record documents that satisfy the condition that the set of associated identifiers is not empty; S8.2 For each vulnerability record document in the vulnerability record document set obtained in step S8.1, perform the following checks: For a certain vulnerability record document A, check whether the associated identifier set of the vulnerability record document corresponding to each element in its associated identifier set contains the vulnerability master identifier of vulnerability record document A. If the associated identifier set of vulnerability record document B does not contain the vulnerability master identifier of vulnerability record document A, then write the vulnerability master identifier of vulnerability record document A into the associated identifier set of vulnerability record document B, and record the number of audit repairs. S8.3 Output audit metrics, including the number of asymmetric association edges detected, the success rate of repair, and the distribution of sources; an asymmetric association edge refers to a relationship that exists only in one direction, that is, A's set of association identifiers contains B, but B's set of association identifiers does not contain A.
[0017] Furthermore, when no vulnerability list is specified, the latest collected vulnerability information is retrieved according to the time window, and each vulnerability information is automatically associated according to steps S2-S7.
[0018] Furthermore, the above method also includes the following steps: outputting and continuously tracking the following evaluation metrics: (1) Association coverage rate, which is calculated as follows: coverage = count(exists(linked_ids)) / count(total) Among them, exists(linked_ids) represents the number of vulnerability records that have established cross-source associations, and total represents the total number of vulnerability records; (2) Symmetry disruption rate, which is calculated as follows: Asymmetry Rate=count({(A,B)|B∈linked_ids(A) and A∉linked_ids(B)}) / count(all_links) Used to measure the proportion of asymmetric associated edges to all associated edges; (3) Self-healing repair rate, which is calculated as follows: Healing Rate=repaired_asym_links / detected_asym_links Where, detected_asym_links represents the total number of asymmetric links detected in the symmetry audit; repaired_asym_links represents the number of asymmetric links successfully repaired in this symmetry audit; (4) The success rate of concurrent conflict retry is calculated as follows: retry_ok=retries_succeeded / retries_total Here, retries_total represents the total number of retries triggered by concurrent write conflicts, and retries_succeeded represents the number of times the write was eventually successfully completed among these retries.
[0019] The present invention also provides a system for implementing the above method, comprising an access layer, a processing layer, a core service layer, and a storage layer; The access layer is used to provide an interface to input the vulnerability records to be processed into the processing layer; The processing layer is used to perform normalization, type identification, candidate discovery, and deduplication and noise reduction on vulnerability records; The core service layer is used to perform bidirectional atomic association writing to the candidate set output by the processing layer and to periodically perform symmetry auditing; The storage layer is used to store vulnerability log documents and audit logs.
[0020] The beneficial effects of this invention are as follows: (1) Improved cross-source association coverage: The present invention adopts a three-channel candidate discovery mechanism, which can significantly supplement hidden aliases and delayed references, thereby improving the alignment ratio of the same vulnerability between different sources and effectively solving the problem of association omission caused by missing identifiers or heterogeneous naming in the prior art; (2) Improved consistency and symmetry: This invention ensures that the symmetry invariant is still satisfied in the concurrent write scenario through the synergistic effect of bidirectional atomic linking, concurrent retry and symmetry audit self-healing mechanism, significantly reducing the probability of unidirectional edge and lost update, and ensuring bidirectional reachability and logical consistency of the association relationship. (3) High-concurrency engineering is feasible: This invention adopts a field-level atomic idempotent update strategy to avoid the use of global locks, which can well adapt to the parallel execution requirements of distributed collection and batch processing tasks and has engineering feasibility for actual deployment in large-scale production environments. (4) Operability and sustainable optimization: This invention forms a quality closed loop through the statistics of indicators such as coverage and source distribution, supports continuous iterative optimization of matching rules and candidate source strategies, and realizes the long-term operability of the system and continuous improvement of its performance. Attached Figure Description
[0021] Figure 1 This is a flowchart illustrating the overall process of the method in Embodiment 1 of the present invention. Figure 2 This is a schematic diagram of the overall architecture of the system in Embodiment 2 of the present invention. Detailed Implementation
[0022] The present invention will be further described below with reference to the accompanying drawings. It should be noted that this embodiment is based on the present technical solution and provides detailed implementation methods and specific operation processes, but the protection scope of the present invention is not limited to this embodiment.
[0023] Example 1
[0024] This embodiment provides a cross-source vulnerability association method based on identifier pattern recognition and bidirectional atomic linking, such as... Figure 1 As shown, it includes the following steps: S1. Vulnerability Information Collection: After collecting vulnerability information from external data sources, a corresponding vulnerability record document is generated for each vulnerability information in the vulnerability document library of the storage layer. The fields of the vulnerability record document include vulnerability master identifier (vuln_id, a standard ID in the unified key space), source identifier (source), tag array (tags, which may contain external ID tags), alias array (aliases, a set of external IDs provided by the upstream), description text (description), linked identifier set (linked_ids, an array field with set semantics), and last modified time (last_modified). The source and description text of each vulnerability information are filled into the corresponding fields of the vulnerability record document; if the upstream data source provides a list of aliases, the identifiers in the alias list are filled into the alias array field.
[0025] S2. Standardization Processing: Standardize the original vulnerability primary identifier (such as CVE-2024-1234 / GHSA-xxxx-xxxx-xxxx / CNVD-2024-xxxx, etc.) contained in the vulnerability information by normalizing its case, removing invisible characters and whitespace, and performing format validity verification. If the verification fails, the current processing ends and the reason for the failure is recorded; if the verification passes, proceed to step S3. S3. Identifier Type Recognition: The normalized original vulnerability primary identifier is matched against an identifier type pattern library to identify the identifier type (e.g., CVE, GHSA, CNVD, CNNVD, etc.). Then, the normalized original vulnerability primary identifier is written as the standard ID v in the unified key space into the vulnerability primary identifier field of the vulnerability document. For example, if the form `GHSA-xxxx-xxxx-xxxx` is matched in the identifier type pattern library, the identifier type is identified as GHSA.
[0026] If the vulnerability information of a data source contains both the original vulnerability master identifier (such as GHSA / CNVD / CNNVD) and the CVE identifier, and the CVE identifier is ultimately selected as the standard ID in the unified key space, then the original vulnerability master identifier is written into the tag array of the vulnerability record document.
[0027] S4. Candidate Findings (in order of confidence): S4.1 Read the tag array field of the vulnerability log document, parse the external identifier tags, and obtain the candidate set C1.
[0028] S4.2 If the alias array field in the vulnerability log document is not empty, read the identifier of the alias array field, normalize it, and add it to the candidate set C2.
[0029] S4.3 Perform substring-level pattern scanning on the description text field in the vulnerability log document, extract substrings that conform to the identifier format, such as `CVE-YYYY-NNNN...`, `CNVD-...`, etc., and add them to the candidate set C3 after normalization. C3 is mainly used to complete historical data or to complete vulnerability records with missing tag arrays and aliases arrays.
[0030] S5. Merge the candidate set C = C1 ∪ C2 ∪ C3, and perform deduplication and noise reduction on the candidate set C. Remove identifiers in the candidate set C that are identical to the v in the vulnerability master identifier field of the vulnerability record document (without self-loops), and remove identifiers that do not meet the format validity check. Optionally, set the priority according to the candidate source channel, i.e., tag array > alias array > description text field scanning and extraction.
[0031] S6, Bidirectional Atomic Association Write: Perform the following sequentially for each candidate c ∈ C in the candidate set: (1) Write A→B: In the storage layer, perform field-level scripted atomic update on the vulnerability record document corresponding to v. If the field of the associated identifier set is empty, initialize it first and add candidate c to the associated identifier set. If the associated identifier set already exists, but c does not exist in it, append candidate c to the associated identifier set. After updating the fields of the associated identifier set, update the last modified time field last_modified synchronously. (2) Write B→A: Perform the same field-level scripted atomic update on the vulnerability record document corresponding to candidate c in the storage layer, write v into the associated identifier set of the vulnerability record document corresponding to candidate c, and update the last modified time field last_modified; If the write operation fails in either direction of (1) or (2), such as when the vulnerability document library is updated, a `version_conflict_engine_exception` (or a similar "version conflict" error) is returned. This usually occurs when the same vulnerability record document is updated concurrently, and it is manifested as one of the write operations A→B or B→A failing to be successfully written to the database. Then the retry logic is triggered to retry the incomplete write operation. If it still fails after a limited number of retries, the incomplete write operation is recorded as a "task to be compensated" and will be rewritten by the subsequent symmetric audit.
[0032] Through the processing in steps S5 and S6 above, the elements in the associated identifier set are unique, and the vulnerability master identifier does not appear in its associated identifier set. Furthermore, if vulnerability B appears in the associated identifier set of vulnerability A, i.e., B ∈ linked_ids(A), then vulnerability A must also appear in the associated identifier set of vulnerability B, i.e., A ∈ linked_ids(B).
[0033] In this embodiment, the storage layer provides scripted update capabilities. When writing, it does not read the full vulnerability record document, but only performs conditional updates on the target field associated identifier set to avoid concurrent read, modify and write overwriting.
[0034] In this embodiment, the storage layer employs optimistic concurrency control. If concurrent updates lead to version conflicts, a limited number of retries are performed on the same write operation. If the retries still fail or a network anomaly occurs, the incomplete reverse write is recorded as a "task to be compensated" and handed over to the symmetry audit task to complete the write in a subsequent cycle, thereby ensuring eventual consistency.
[0035] S7. Output and Recording: Output the processing results, including the number of newly added associations, the list of failed candidates and the reasons for failure (including concurrency conflicts / document non-existence, etc.), and write them to the audit log and statistical counter. The statistical counter is used to count the number of successful writes, the number of failed writes, the number of retries, the distribution of failure reasons, and the number of tasks to be compensated. The statistical counter can be used to continuously monitor the quality and stability of associated tasks, providing indicators for alarm thresholds and capacity assessment.
[0036] In this embodiment, step S8 is also included: periodically performing a symmetry audit task. S8.1 Scan all vulnerability record documents that satisfy the condition that the set of associated identifiers is not empty.
[0037] S8.2 For each vulnerability record document in the vulnerability record document set obtained in step S8.1, perform the following checks: For a certain vulnerability record document A, check whether the associated identifier set of the vulnerability record document corresponding to each element in its associated identifier set contains the vulnerability master identifier of vulnerability record document A. If the associated identifier set of vulnerability record document B does not contain the vulnerability master identifier of vulnerability record document A, then write the vulnerability master identifier of vulnerability record document A into the associated identifier set of vulnerability record document B, and record the number of audit fixes.
[0038] S8.3 Output audit metrics, including the number of asymmetric association edges detected, the success rate of repair, and the distribution of sources; an asymmetric association edge refers to a relationship that exists only in one direction, that is, A's set of association identifiers contains B, but B's set of association identifiers does not contain A.
[0039] Thus, even in the event of network jitter, partial write failures, or concurrent conflicts, eventual consistency can be achieved through compensation in step S8.
[0040] In this embodiment, when no vulnerability list is specified, the latest collected vulnerability information (e.g., up to 500 entries) is retrieved by time window (e.g., the most recent 24 hours). For each vulnerability information, automatic association is performed according to steps S2-S7, and the results such as the number of processed entries, the number of vulnerability entries with at least one association, the number of newly added association edges, the proportion of associated vulnerabilities, and the statistics by source distribution are output.
[0041] In this embodiment, the method further includes the following steps: outputting and continuously tracking the following evaluation metrics: (1) Coverage, which is calculated as coverage = count(exists(linked_ids)) / count(total), where exists(linked_ids) represents the number of vulnerability records that have established cross-source associations, and total represents the total number of vulnerability records. It is used to measure the proportion of vulnerability records that have established cross-source associations to the total number of vulnerability records. (2) Asymmetry rate, which is calculated as follows: Asymmetry Rate=count({(A,B)|B∈linked_ids(A) and A∉linked_ids(B)}) / count(all_links) Used to measure the proportion of asymmetric associated edges out of all associated edges.
[0042] (3) Healing Rate, which is calculated as follows: Healing Rate=repaired_asym_links / detected_asym_links Here, `detected_asym_links` represents the total number of asymmetric edges detected in the symmetry audit (the number of unidirectional associations that need to be repaired); `repaired_asym_links` represents the number of asymmetric edges successfully repaired in this symmetry audit. This is used to measure the ability of the symmetry audit's self-healing mechanism to successfully repair asymmetric edges.
[0043] (4) Concurrency conflict retry success rate (retry_ok), which is calculated as follows: retry_ok=retries_succeeded / retries_total Here, retries_total represents the total number of retries triggered by concurrent write conflicts (the sum of the attempts), and retries_succeeded represents the number of times the write was successfully completed among these retries. It is used to measure the effectiveness of the retry mechanism in concurrent write conflict scenarios.
[0044] The above indicator system can meet the requirements for providing specific effect data or comparative data.
[0045] Example 2
[0046] This embodiment provides a system for implementing the method of Embodiment 1, such as... Figure 2 As shown, it includes an access layer, a processing layer, a core service layer, and a storage layer; The access layer is used to provide an interface to input the vulnerability information to be processed into the processing layer; The processing layer is used to perform normalization, type identification, candidate discovery, and deduplication and noise reduction on vulnerability records; The core service layer is used to perform bidirectional atomic association writing to the candidate set output by the processing layer and to periodically perform symmetry auditing; The storage layer is used to store vulnerability log documents and audit logs.
[0047] Example 3
[0048] In this embodiment, the upstream can directly provide a list of aliases. The specific steps are basically the same as in Embodiment 1, with the main difference being: In step S1, while inputting the identifier string GHSA-xxxx-xxxx-xxxx, the alias array aliases = ["CVE-2021-44228", "CNVD-2021-xxxx"].
[0049] In steps S2 and S3, in addition to normalizing and identifying the type of the input identifier string, it is also necessary to perform normalization and type identification on the alias array.
[0050] In step S4, bidirectional atomic links are directly performed on each alias in the alias array, and the number of newly added associations and failed entries are output. The difference from Example 1 is that Example 1 uses the alias array as one of the candidate sources, going through a complete candidate merging, deduplication, and noise reduction process before finally writing the associations. This example, however, treats the upstream-provided alias list as a high-confidence candidate set, directly performing bidirectional atomic links on each alias and outputting the results. However, minimum verification is still required, including normalizing the aliases, validating their format, and removing self-loops identical to the vulnerability's primary identifier v.
[0051] For those skilled in the art, various corresponding changes and modifications can be made based on the above technical solutions and concepts, and all such changes and modifications should be included within the protection scope of the claims of this invention.
Claims
1. A method for cross-source vulnerability association based on identifier pattern recognition and bidirectional atomic linking, characterized in that, Includes the following steps: S1. Vulnerability Information Collection: After collecting vulnerability information from external data sources, a corresponding vulnerability record document is generated for each vulnerability in the vulnerability document library of the storage layer. The fields of the vulnerability record document include vulnerability main identifier, source identifier, tag array, alias array, description text, set of associated identifiers, and last modification time. The source and description text of each vulnerability are filled into the corresponding fields of the vulnerability record document. If the upstream data source provides an alias list, the identifiers in the alias list are filled into the alias array field. S2. Standardization Processing: Standardize the original vulnerability primary identifier contained in the vulnerability information and perform format validity verification. If the verification fails, the current processing ends and the reason for the failure is recorded; if the verification passes, proceed to step S3. S3. Identifier type identification: The normalized original vulnerability master identifier is matched and identified in the identifier type pattern library to obtain the identifier type. Then, the normalized original vulnerability master identifier is written as the standard ID v of the unified key space into the vulnerability master identifier field of the vulnerability document. If the vulnerability information of a data source contains both the original vulnerability master identifier and the CVE identifier that the data source originally possesses, and the CVE identifier is ultimately selected as the standard ID in the unified key space, then the original vulnerability master identifier is written into the tag array of the vulnerability record document. S4. Candidate Discovery: S4.1 Read the tag array field of the vulnerability log document, parse the external identifier tags, and obtain the candidate set C1; S4.2 If the alias array field in the vulnerability log document is not empty, read the identifier of the alias array field, normalize it, and add it to the candidate set C2; S4.3 Perform substring-level pattern scanning on the description text field in the vulnerability log document, extract substrings that conform to the identifier format, and add them to the candidate set C3 after normalization. S5. Merge to obtain candidate set C = C1 ∪ C2 ∪ C3, and perform deduplication and noise reduction on candidate set C. Remove the identifiers in candidate set C that are the same as v in the vulnerability master identifier field of the vulnerability record document, and remove the identifiers that do not meet the format legality check. S6, Bidirectional Atomic Association Write: Perform the following sequentially for each candidate c ∈ C in the candidate set: (1) Write A→B: In the storage layer, update the vulnerability record document corresponding to v. If the field of the associated identifier set is empty, initialize it first and add candidate c to the associated identifier set. If the associated identifier set already exists, but c does not exist in it, append candidate c to the associated identifier set. After updating the fields of the associated identifier set, update the last modified time field last_modified synchronously. (2) Write B→A: Perform the same update on the vulnerability record document corresponding to candidate c in the storage layer, write v into the associated identifier set of the vulnerability record document corresponding to candidate c, and update the last modified time field last_modified; S7. Output and Record: Output the processing results, including the number of newly added associations, the list of failed candidates and the reasons for failure, and write them to the audit log and the statistics counter. The statistics counter is used to count the number of successful writes, the number of failed writes, the number of retries, the distribution of failure reasons, and the number of tasks to be compensated.
2. The method according to claim 1, characterized in that, In step S2, the normalization process includes case normalization and removal of invisible characters and whitespace.
3. The method according to claim 1, characterized in that, In steps (1) and (2) of S6, when updating the vulnerability document, field-level scripted atomic updates are used. When writing, the full vulnerability record document is not read, and only the fields of the associated identifier set are updated conditionally.
4. The method according to claim 1, characterized in that, In step S6, if the write operation fails in either direction of (1) and (2), the retry logic is triggered to retry the incomplete write operation. If the write operation still fails after a limited number of retries, the incomplete write operation is recorded as a "task to be compensated" and will be rewritten by the subsequent symmetry audit.
5. The method according to claim 1, characterized in that, In step S7, the processing results include the number of newly added associations, the list of failed candidates, and the reasons for failure, and are written into the audit log and the statistics counter.
6. The method according to claim 4, characterized in that, It also includes step S8, periodically performing symmetry audit tasks: S8.1 Scan all vulnerability record documents that satisfy the condition that the set of associated identifiers is not empty; S8.2 For each vulnerability record document in the vulnerability record document set obtained in step S8.1, perform the following checks: For a certain vulnerability record document A, check whether the associated identifier set of the vulnerability record document corresponding to each element in its associated identifier set contains the vulnerability master identifier of vulnerability record document A. If the associated identifier set of vulnerability record document B does not contain the vulnerability master identifier of vulnerability record document A, then write the vulnerability master identifier of vulnerability record document A into the associated identifier set of vulnerability record document B, and record the number of audit repairs. S8.3 Output audit metrics, including the number of asymmetric association edges detected, the success rate of repair, and the distribution of sources; an asymmetric association edge refers to a relationship that exists only in one direction, that is, A's set of association identifiers contains B, but B's set of association identifiers does not contain A.
7. The method according to claim 1, characterized in that, If no vulnerability list is specified, the latest collected vulnerability information is retrieved by time window, and each vulnerability information is automatically associated according to steps S2-S7.
8. The method according to claim 1, characterized in that, It also includes the following steps: outputting and continuously tracking the following evaluation metrics: (1) Association coverage rate, which is calculated as follows: coverage = count(exists(linked_ids)) / count(total) Among them, exists(linked_ids) represents the number of vulnerability records that have established cross-source associations, and total represents the total number of vulnerability records; (2) Symmetry disruption rate, which is calculated as follows: Asymmetry Rate=count({(A,B)|B∈linked_ids(A) and A∉linked_ids(B)}) / count(all_links) Used to measure the proportion of asymmetric associated edges to all associated edges; (3) Self-healing repair rate, which is calculated as follows: Healing Rate=repaired_asym_links / detected_asym_links Where, detected_asym_links represents the total number of asymmetric links detected in the symmetry audit; repaired_asym_links represents the number of asymmetric links successfully repaired in this symmetry audit; (4) The success rate of concurrent conflict retry is calculated as follows: retry_ok=retries_succeeded / retries_total Here, retries_total represents the total number of retries triggered by concurrent write conflicts, and retries_succeeded represents the number of times the write was eventually successfully completed among these retries.
9. A system for implementing the method of any one of claims 1-8, characterized in that, It includes the access layer, processing layer, core service layer, and storage layer; The access layer is used to provide an interface to input the vulnerability records to be processed into the processing layer; The processing layer is used to perform normalization, type identification, candidate discovery, and deduplication and noise reduction on vulnerability records; The core service layer is used to perform bidirectional atomic association writing to the candidate set output by the processing layer and to periodically perform symmetry auditing; The storage layer is used to store vulnerability log documents and audit logs.