Software entity-based automated vulnerability and code repository mapping framework and vulnerability code snapshot acquisition method and system and storage medium

Abstract

The application relates to an automatic vulnerability and code warehouse mapping framework based on a software entity, a vulnerability code snapshot acquisition method and system and a storage medium, and the method comprises the following steps: S101, collecting vulnerability related information, carrying out link filtering and verification, and obtaining an initial CVE to code warehouse mapping set; S102, grouping CVEs based on software entities associated with the CVEs, obtaining CVE groups corresponding to the software entities, constructing a mapping relationship between the software entities and the code warehouses, and applying the mapping relationship to other CVEs in the groups; S103, locating accurate code states containing the vulnerabilities; S104, integrating the results of the step S103, and outputting final structured data; S105, based on continuous input of new CVE records, updating and verifying a mapping knowledge base of the software entities and the code warehouses, and realizing continuous evolution of the system. The application breaks through various bottlenecks in the prior art.

Description

Technical Field

[0001] This invention relates to the field of computer software processing technology, and in particular to an automated vulnerability and code repository mapping framework based on software entities, as well as a method, system, and storage medium for obtaining vulnerability code snapshots. Background Technology

[0002] In existing technologies, the mapping from CVEs to code repositories primarily follows a "patch-driven" paradigm. Its core idea is to handle individual CVE records in isolation through explicit reference links in vulnerability databases (such as GitHub commit hashes). Representative works include:

[0003] CVEfixes: As an early representative, this method simply extracts direct GitHub repository links from the NVD's "references" field and builds a mapping from CVEs to code repositories based on these pre-existing links. Due to its complete reliance on the limited explicit links in the NVD, its coverage is low.

[0004] MoreFixes extends CVEfixes by integrating multi-source data (such as adding GitHub security bulletins GHSA as a supplementary source) and simulating vendor-product name-based GitHub searches, attempting to improve coverage. This approach represents a more advanced tool currently available, but its coverage remains limited, and it is essentially still an aggregation of explicit links.

[0005] What these methods have in common is that they heavily rely on existing direct reference links in authoritative vulnerability databases (such as NVD and GHSA). Their core limitation is that they passively wait for the database to provide ready-made link information, rather than actively building mapping relationships.

[0006] The aforementioned existing technologies suffer from the following key problems and defects, which severely limit the scale and efficiency of vulnerability analysis:

[0007] 1. Extremely low coverage and a ceiling effect: The paradigm relying on explicit links has reached its limit because most CVE records lack direct referencing links. The root cause is that existing methods passively rely on readily available information in the database and cannot handle sparse CVE records.

[0008] 2. Isolated processing leads to poor scalability: Existing tools process each CVE atomically and independently, failing to leverage the relationships between CVEs within the same software entity (such as vendor-product pairs). For example, if multiple CVEs for a software (such as Apache Tomcat) have already been successfully mapped, but a new CVE cannot be mapped due to its brief description or lack of direct links, existing techniques cannot utilize known mappings within the group for inference. This results in an inefficient mapping process.

[0009] 3. Insufficient mapping granularity and lack of a code snapshot layer mean that downstream tasks (such as vulnerability reproduction and patch verification) require precise version snapshots. However, existing datasets (such as CVEfixes) rarely provide mappings from CVEs to specific versions (such as Git tags), forcing researchers to manually locate versions, which is time-consuming and error-prone, limiting the feasibility of large-scale security research. Summary of the Invention

[0010] This invention provides an automated vulnerability and code repository mapping framework based on software entities, as well as a method, system, and storage medium for obtaining vulnerability code snapshots, aiming to solve the deficiencies in the prior art.

[0011] This invention provides an automated vulnerability and code repository mapping framework based on software entities and a method for obtaining vulnerability code snapshots, including:

[0012] Step S101: Multi-source data fusion and direct mapping; collect vulnerability-related information from multiple data sources, and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set;

[0013] Step S102: Software entity grouping and heuristic mapping; Based on the software entities associated with CVEs, group CVEs to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, construct the mapping relationship between software entities and code repositories, and apply the mapping relationship to other CVEs within the group.

[0014] Step S103: Precise version location; Associate the affected version information disclosed in the CVE record with the specific release version in the code repository to locate the specific version code snapshot containing the vulnerability;

[0015] Step S104: Vulnerability mapping relationship generation; Integrate the results of step S103 and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots;

[0016] Step S105: Knowledge base iteration and system evolution; Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and the enhanced traceability of historical mappings, so as to realize the continuous evolution of the system.

[0017] As a further improvement of the present invention, step S101 includes:

[0018] Step S101-1: Multi-source data acquisition; Collect CVE records, reference links and affected version information from multiple data sources, including general vulnerability disclosure databases, GitHub security announcements, open source vulnerability database OSV, vulnerability exploitation databases and GitHub repositories;

[0019] Step S101-2: Link filtering and verification; Use a keyword mechanism to filter non-code repository links, verify the availability of the filtered links, and handle redirects to ensure link persistence;

[0020] Step S101-3: Proactive discovery; For CVEs that do not have explicit link mappings after filtering, initiate targeted GitHub searches using vendor-product portfolios derived from CPEs to compensate for the lack of explicit link mappings.

[0021] As a further improvement of the present invention, step S102 further includes:

[0022] Step S102-1: Entity grouping; normalize tuples from the CPE data of CVEs and group CVEs of the same entity into one group;

[0023] Step S102-2: Traverse each entity group generated in step S102-1, check each CVE entry in the group to see if a mapping relationship with the GitHub repository has been established in step S101. If a mapping exists, proceed to step S102-3. If no mapping relationship exists for any CVE in the group, skip the entity group and continue processing the next group until all entity groups have been traversed.

[0024] Step S102-3: Intra-group reasoning; If any CVE in the group has established a repository link through the verification rules, then based on the rule that vulnerabilities of the same software entity are concentrated in its main code repository, all other CVEs in the group will automatically inherit the mapping relationship.

[0025] As a further improvement of the present invention, step S103 further includes:

[0026] Step S103-1: Version Collection; Automatically obtain all historical tags and branches of the target code repository through the GitHub API, and build a complete list of repository versions to match the target library;

[0027] Step S103-2: Two-layer matching algorithm; The first layer is exact matching, which directly matches the affected version number explicitly indicated in the CVE record with the version identifier of the repository; If the exact matching fails, the second layer of multi-mode fault-tolerant matching is automatically triggered. The system automatically generates common naming variant patterns based on the initial version number and searches the repository again accordingly; For successfully matched repository versions, the system automatically generates and outputs the corresponding snapshot link of the vulnerable version provided directly by GitHub.

[0028] This invention also discloses an automated vulnerability and code repository mapping framework based on software entities and a vulnerability code snapshot acquisition system, including:

[0029] Multi-source data fusion and direct mapping unit: used to collect vulnerability-related information from multiple data sources and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set;

[0030] Software Entity Grouping and Heuristic Mapping Unit: Based on the software entities associated with CVEs, CVEs are grouped to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, a mapping relationship between software entities and code repositories is constructed, and the mapping relationship is applied to other CVEs within the group.

[0031] Precise Version Location Unit: Used to associate the affected version information disclosed in the CVE record with the specific release version in the code repository in order to locate the specific version code snapshot containing the vulnerability;

[0032] Vulnerability mapping relationship generation unit: used to integrate the results of the precise version location unit and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots;

[0033] Knowledge Base Iteration and System Evolution Unit: Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and enhance the traceability of historical mappings, thereby achieving continuous system evolution.

[0034] As a further improvement of the present invention, the multi-source data fusion and direct mapping unit includes:

[0035] Multi-source data acquisition module: used to collect CVE records, reference links and affected version information from multiple data sources, including general vulnerability disclosure databases, GitHub security announcements, open source vulnerability database OSV, vulnerability exploitation databases and GitHub repositories;

[0036] Link filtering and verification module: Used to filter non-code repository links using a keyword mechanism, verify the availability of filtered links, and handle redirects to ensure link persistence;

[0037] Proactive discovery module: For CVEs that do not have explicit link mappings after filtering, a targeted GitHub search is initiated using vendor-product portfolios derived from CPEs to compensate for the lack of explicit link mappings.

[0038] As a further improvement of the present invention, the software entity grouping and heuristic mapping unit includes:

[0039] Software Entity Grouping Module: Used to normalize tuples from the CPE data of CVEs, grouping CVEs of the same entity into one group;

[0040] Intra-group mapping judgment module: responsible for traversing each entity group generated in the software entity grouping module, checking whether each CVE entry in the group has established a mapping relationship with the GitHub repository in the multi-source data fusion and direct mapping unit. If a mapping exists, the intra-group inference module is called. If no mapping relationship exists for any CVE in the group, the entity group is skipped and the next group is judged until all entity groups have been traversed.

[0041] Intra-group inference module: If any CVE in the group has established a repository link through the verification rules, then based on the rule that vulnerabilities of the same software entity are concentrated in its main code repository, all other CVEs in the group will automatically inherit the mapping relationship.

[0042] As a further improvement of the present invention, the precise version positioning unit further includes:

[0043] Version collection module: Automatically retrieves all historical tags and branches of the target code repository through the GitHub API, and builds a complete list of repository versions to match the target repository;

[0044] The two-layer matching algorithm module consists of two layers: the first layer is exact matching, which directly matches the affected version number explicitly indicated in the CVE record with the repository's version identifier; if an exact match fails, the second layer of multi-mode fault-tolerant matching is automatically triggered, where the system automatically generates common naming variant patterns based on the initial version number and searches the repository again accordingly; for successfully matched repository versions, the system automatically generates and outputs a snapshot link of the vulnerable version provided directly by GitHub.

[0045] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the method described in the present invention when invoked by a processor.

[0046] The beneficial effects of this invention are as follows: This invention aims to break through the coverage ceiling by shifting the paradigm from "isolated CVE analysis" to "software entity-level reasoning"—systematically constructing a two-layer mapping: CVE to code repository (solving the coverage problem) and CVE to vulnerability version snapshot (solving the granularity problem), ultimately providing a large-scale, representative, and operable dataset to support next-generation vulnerability analysis. The core innovation of this invention lies in introducing software entities as an intermediate abstraction layer, realizing the propagation and expansion of mapping relationships through an intra-group reasoning mechanism, thereby overcoming the various bottlenecks faced by existing technologies. Attached Figure Description

[0047] Figure 1 This is a flowchart illustrating the overall workflow of the method of this invention;

[0048] Figure 2 This is a flowchart of the multi-source data fusion and direct mapping stage of the present invention;

[0049] Figure 3 This is a flowchart of the software entity grouping and heuristic mapping phase of the present invention;

[0050] Figure 4 This is a flowchart of the precise version positioning stage of the present invention. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0052] Parameter explanation:

[0053] CVE (Common Vulnerabilities and Exposures) is an internationally recognized standard naming system for vulnerabilities, providing a unique identifier (CVE-ID) for each security vulnerability. The general vulnerability disclosure database built based on CVE entries is one of the main data sources for this study.

[0054] GitHub Security Announcements (GHSA): This is a simpler vulnerability disclosure path provided by GitHub for maintainers, which can effectively link vulnerabilities existing in GitHub projects;

[0055] A GitHub repository is a repository created on the GitHub platform using the Git version control system, used to host project source code, documentation, and collaboration files.

[0056] CPE (Common Platform Enumeration): CPE assigns unique and resolvable identifiers to different versions, update levels, and variants of IT assets through standardized naming structures and field subdivisions, ensuring that automated tools can accurately identify asset versions and associate them with corresponding vulnerabilities.

[0057] Application areas of this invention:

[0058] 1. Automated Vulnerability Reproduction: Provides snapshots of the vulnerable code corresponding to the vulnerability disclosure, allowing researchers to download the complete code containing the vulnerability with one click, thus supporting the reproduction environment. Application: The input is the common vulnerability and exposure number (CVE number), and this framework outputs the corresponding snapshot Uniform Resource Locator (URL) for integration into reproduction tools.

[0059] 2. Patch Discovery and Security Analysis: Provides a repository mapping foundation for the patch ranking algorithm, ensuring the search scope covers the correct code base. Application: The framework outputs a CVE-repository mapping table, which is directly used as input for the patch discovery tool.

[0060] 3. Data-driven vulnerability detection model training: Constructing a large-scale vulnerability dataset for training deep learning models. Application method: The framework provides the corresponding code repositories and snapshot data for CVEs as a labeled dataset.

[0061] 4. Cyber ​​Range and Red Team / Blue Team Exercises: The precise vulnerability snapshots provided by this framework can be used to build cyber range environments, supporting security training, red team / blue team exercises, and vulnerability exploitation testing. Application: The code snapshots corresponding to CVEs are integrated into the cyber range management platform via API and automatically deployed to virtual machines or containers, providing support for one-click creation of vulnerability instances.

[0062] This invention discloses an automated vulnerability and code repository mapping framework based on software entities and a method for obtaining vulnerability code snapshots. The core of this method lies in constructing a systematic, multi-layered mapping framework. Its working mechanism is implemented through sequential steps, with the output of each step serving as the input for the next, forming a closed-loop optimization logic for data flow. The workflow diagram of this invention is shown below. Figure 1 As shown, proceed with the following steps:

[0063] Step S101: Multi-source data fusion and direct mapping; collect vulnerability-related information from multiple data sources, and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set;

[0064] Step S102: Software entity grouping and heuristic mapping; Based on the software entities associated with CVEs, group CVEs to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, construct the mapping relationship between software entities and code repositories, and apply the mapping relationship to other CVEs within the group.

[0065] Step S103: Precise version location; Associate the affected version information disclosed in the CVE record with the specific release version in the code repository to locate the specific version code snapshot containing the vulnerability;

[0066] Step S104: Vulnerability mapping relationship generation; Integrate the results of step S103 and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots;

[0067] Step S105: Knowledge base iteration and system evolution; Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and the enhanced traceability of historical mappings, so as to realize the continuous evolution of the system.

[0068] Step S101: Multi-source data fusion and direct mapping stage

[0069] This phase aims to fully utilize explicit links to existing authoritative data sources to establish high-quality initial mappings, overcoming the shortcomings of insufficient coverage from a single data source. The specific process is as follows: Figure 2 As shown.

[0070] Step S101-1: Multi-source data acquisition. This step integrates five heterogeneous data sources: the Common Vulnerability Disclosure Database, GitHub Security Announcements (GHSA), the Open Source Vulnerability Database (OSV), the Exploitation Database (EDB), and GitHub repositories, collecting CVE records, reference links, and affected version information from each source.

[0071] Step S101-2: Link Filtering and Verification. A keyword mechanism is used to filter non-code repository links (e.g., excluding URLs containing "poc" or "exploit"), and the availability of the links is verified. This involves verifying the availability of the filtered links and handling redirects to ensure link persistence.

[0072] Step S101-3: Proactive Discovery. For CVEs that do not have explicit link mappings after filtering, a targeted GitHub search is initiated using vendor-product portfolios derived from CPEs to compensate for the lack of explicit link mappings.

[0073] This phase outputs a high-quality initial set of CVE-to-code repository mappings, laying a reliable foundation for subsequent extended mappings.

[0074] Step S102: Software Entity Grouping and Heuristic Mapping Stage (Core Innovation of this Invention)

[0075] This phase introduces "software entities" as an intermediate layer to address the coverage bottleneck faced by traditional methods due to their reliance on explicit linking. For example... Figure 3 As shown.

[0076] Step S102-1: Entity Grouping. Normalize the (vendor, product) tuples from the CVE's CPE data, grouping CVEs of the same entity into one group (e.g., all CVEs belonging to (Apache, Tomcat) form one group).

[0077] Step S102-2: Traverse entity groups. Traverse each entity group generated in step S102-1, and check whether each CVE entry in the group has been mapped to the GitHub repository in step S101. If a mapping exists, proceed to step S102-3. If no mapping exists for any CVE in the group, skip the entity group and continue processing the next group until all entity groups have been traversed.

[0078] Step S102-3: Intra-group reasoning. If any CVE within the group has established a reliable repository link through verification rules (including: product name matching repository name, or vendor name matching owner and repository name appearing in the CVE description), then based on the objective fact that "vulnerabilities of the same software entity are usually concentrated in its main code repository," this step causes all other CVEs within the group to automatically inherit this mapping relationship. This action, by constructing and utilizing the stable mapping relationship of "software entity-code repository," achieves the effective dissemination and reuse of mapping knowledge within the group, expands the overall mapping coverage, and updates the mapping relationship to the mapping records of other CVEs within the group.

[0079] Step S103: Precise Version Identification Stage

[0080] After successfully establishing the mapping relationship between CVEs and source code repositories, to meet the rigid requirements of downstream tasks such as accurate vulnerability reproduction and impact scope analysis for specific vulnerability code contexts, this framework enters the precise version location phase. The core task of this phase is to precisely associate the "affected version" information disclosed in the CVE records with the specific release version in the code repository, thereby pinpointing the exact code state containing the vulnerability. To achieve this goal, this phase involves... Figure 4 As shown, the following standardized process shall be performed:

[0081] Step S103-1: First, the system automatically obtains all historical tags and branches of the target code repository through the GitHub API and builds a complete list of repository versions to match the target library.

[0082] Step S103-2: Subsequently, the system initiates a crucial two-layer matching algorithm: The first layer is exact matching, which directly matches the affected version number (e.g., 1.0) explicitly indicated in the CVE record with the repository's version identifier. If an exact match fails, the second layer of multi-mode fault-tolerant matching is automatically triggered. The system automatically generates a series of common naming variant patterns based on the initial version number (e.g., for 1.0, v1.0, V1.0, release-1.0, 1.0.0, etc.), and searches the repository again accordingly to effectively address the issues of inconsistent version naming and prefix / suffix usage in the open-source community. For each successfully matched repository version, the system automatically generates and outputs a snapshot link (zipball or tarball format) of the vulnerable version, which can be directly downloaded from GitHub. Thus, this stage successfully completes the upgrade from the macro-macro mapping of "CVE-repository" to the micro-macro mapping of "CVE-affected exact code snapshot".

[0083] Step S104: Vulnerability Mapping Relationship Generation Phase

[0084] This stage integrates the results of previous steps and outputs the final structured data, including: a mapping table from CVEs to repositories, and a set of URLs from CVEs to specific version code snapshots.

[0085] Step S105: Knowledge Base Iteration and System Evolution Stage

[0086] The continuous input of new CVE records enriches and validates the knowledge base of mappings between software entities and repositories. This process not only serves the mapping of new CVEs but also retrospectively verifies and enhances historical mapping relationships, enabling the system to continuously evolve and respond to dynamic changes in the software ecosystem.

[0087] Overall workflow integration.

[0088] The above steps are connected in series through data flow to form an end-to-end pipeline. From inputting CVE records to outputting actionable snapshots, the entire process is automated and requires no manual intervention.

[0089] This invention also discloses an automated vulnerability and code repository mapping framework based on software entities and a vulnerability code snapshot acquisition system, including:

[0090] Multi-source data fusion and direct mapping unit: used to collect vulnerability-related information from multiple data sources and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set;

[0091] Software Entity Grouping and Heuristic Mapping Unit: Based on the software entities associated with CVEs, CVEs are grouped to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, a mapping relationship between software entities and code repositories is constructed, and the mapping relationship is applied to other CVEs within the group.

[0092] Precise Version Location Unit: Used to associate the affected version information disclosed in the CVE record with the specific release version in the code repository in order to locate the exact code status containing the vulnerability;

[0093] Vulnerability mapping relationship generation unit: used to integrate the results of the precise version location unit and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots;

[0094] Knowledge Base Iteration and System Evolution Unit: Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and enhance the traceability of historical mappings, thereby achieving continuous system evolution.

[0095] The multi-source data fusion and direct mapping unit includes:

[0096] Multi-source data acquisition module: used to collect CVE records, reference links and affected version information from multiple data sources, including general vulnerability disclosure databases, GitHub security announcements, open source vulnerability databases (OSV), vulnerability exploitation databases and GitHub repositories;

[0097] Link filtering and verification module: Used to filter non-code repository links using a keyword mechanism, verify the availability of filtered links, and handle redirects to ensure link persistence;

[0098] Proactive discovery module: For CVEs that do not have explicit link mappings after filtering, a targeted GitHub search is initiated using vendor-product portfolios derived from CPEs to compensate for the lack of explicit link mappings.

[0099] The software entity grouping and heuristic mapping unit includes:

[0100] Software Entity Grouping Module: Used to normalize tuples from the CPE data of CVEs, grouping CVEs of the same entity into one group;

[0101] Intra-group mapping judgment module: responsible for traversing each entity group generated in the software entity grouping module, checking whether each CVE entry in the group has established a mapping relationship with the GitHub repository in the multi-source data fusion and direct mapping unit. If a mapping exists, the intra-group inference module is called. If no mapping relationship exists for any CVE in the group, the entity group is skipped and the next group is judged until the intra-group inference module is called.

[0102] Intra-group inference module: If any CVE in the group has established a repository link through the verification rules, then based on the rule that vulnerabilities of the same software entity are concentrated in its main code repository, all other CVEs in the group will automatically inherit the mapping relationship.

[0103] The precise version positioning unit also includes:

[0104] Version collection module: Automatically retrieves all historical tags and branches of the target code repository through the GitHub API, and builds a complete list of repository versions to match the target library;

[0105] The two-layer matching algorithm module consists of two layers: the first layer is exact matching, which directly matches the affected version number explicitly indicated in the CVE record with the repository's version identifier; if an exact match fails, the second layer of multi-mode fault-tolerant matching is automatically triggered, where the system automatically generates common naming variant patterns based on the initial version number and searches the repository again accordingly; for successfully matched repository versions, the system automatically generates and outputs a snapshot link of the vulnerable version provided directly by GitHub.

[0106] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the method described in the present invention when invoked by a processor.

[0107] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for obtaining vulnerability code snapshots based on automated vulnerability-code repository mapping of software entities, characterized in that, include: Step S101, Multi-source data fusion and direct mapping: Collect vulnerability-related information from multiple data sources, and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set; Step S102, Software Entity Grouping and Heuristic Mapping: Based on the software entities associated with CVEs, CVEs are grouped to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, a mapping relationship between software entities and code repositories is constructed, and the mapping relationship is applied to other CVEs within the group. Step S103, Precise Version Location: Associate the affected version information disclosed in the CVE record with the specific release version in the code repository to locate the specific version code snapshot containing the vulnerability; Step S104, vulnerability mapping relationship generation: integrate the results of step S103, and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots; Step S105, Knowledge Base Iteration and System Evolution: Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and the enhanced traceability of historical mappings, so as to realize the continuous evolution of the system; Step S101 includes: Step S101-1, Multi-source data acquisition: Collect CVE records, reference links and affected version information from multiple data sources, including the general vulnerability disclosure database, GitHub security announcements, the open source vulnerability database OSV, vulnerability exploitation database and GitHub repositories; Step S101-2, Link Filtering and Verification: Use a keyword mechanism to filter non-code repository links, verify the availability of the filtered links, and handle redirection to ensure link persistence; Step S101-3, Proactive Discovery: For CVEs that do not have explicit link mappings after filtering, initiate targeted GitHub searches using vendor-product combinations derived from CPEs to compensate for the lack of explicit link mappings. Step S102 further includes: Step S102-1, Entity Grouping: Normalize tuples from the CPE data of CVEs and group CVEs of the same entity into one group; Step S102-2: Traverse each entity group generated in step S102-1, check each CVE entry in the entity group to see if a mapping relationship with the GitHub repository has been established in step S101. If a mapping exists, proceed to step S102-3. If no mapping relationship exists for any CVE in the entity group, skip the entity group and continue processing the next group until all entity groups have been traversed. Step S102-3, Intra-group reasoning: If any CVE in the group has established a repository link through the verification rules, then based on the rule that vulnerabilities of the same software entity are concentrated in its main code repository, all other CVEs in the group will automatically inherit the mapping relationship.

2. The method for obtaining vulnerability code snapshots by automatically mapping vulnerabilities to code repositories according to claim 1, characterized in that, Step S103 further includes: Step S103-1, Version Collection: Automatically obtain all historical tags and branches of the target code repository through the GitHub API, and build a complete list of repository versions to match the target library; Step S103-2, two-layer matching algorithm: The first layer is exact matching, which directly matches the affected version number explicitly indicated in the CVE record with the version identifier of the repository; if the exact matching fails, the second layer of multi-mode fault-tolerant matching is automatically triggered. The system automatically generates common naming variant patterns based on the initial version number and searches the repository again accordingly; for the successfully matched repository version, the system automatically generates and outputs the corresponding snapshot link of the vulnerable version that can be directly downloaded from GitHub.

3. A vulnerability code snapshot acquisition system based on automated vulnerability-code repository mapping of software entities, characterized in that, include: Multi-source data fusion and direct mapping unit: used to collect vulnerability-related information from multiple data sources and perform link filtering and verification on the collected data to obtain an initial CVE to code repository mapping set; Software Entity Grouping and Heuristic Mapping Unit: Based on the software entities associated with CVEs, CVEs are grouped to obtain CVE groups corresponding to the same software entity. Using the CVEs with established mappings within the group, a mapping relationship between software entities and code repositories is constructed, and the mapping relationship is applied to other CVEs within the group. Precise Version Location Unit: Used to associate the affected version information disclosed in the CVE record with the specific release version in the code repository in order to locate the specific version code snapshot containing the vulnerability; Vulnerability mapping relationship generation unit: used to integrate the results of the precise version location unit and output the final structured data, including: a mapping relationship table from CVE to repository, and a set of URLs from CVE to specific version code snapshots; Knowledge Base Iteration and System Evolution Unit: Based on the continuous input of new CVE records, update and verify the mapping knowledge base between software entities and code repositories to support the mapping of new CVEs and enhance the traceability of historical mappings, thereby achieving continuous system evolution; The multi-source data fusion and direct mapping unit includes: Multi-source data acquisition module: used to collect CVE records, reference links and affected version information from multiple data sources, including general vulnerability disclosure databases, GitHub security announcements, open source vulnerability database OSV, vulnerability exploitation databases and GitHub repositories; Link filtering and verification module: Used to filter non-code repository links using a keyword mechanism, verify the availability of filtered links, and handle redirects to ensure link persistence; Proactive discovery module: For CVEs that do not have explicit link mappings after filtering, a targeted GitHub search is initiated using vendor-product portfolios derived from CPEs to compensate for the lack of explicit link mappings; The software entity grouping and heuristic mapping unit includes: Software Entity Grouping Module: Used to normalize tuples from the CPE data of CVEs, grouping CVEs of the same entity into one group; The intra-group mapping judgment module is responsible for traversing each entity group generated in the software entity grouping module, checking whether each CVE entry in the entity group has established a mapping relationship with the GitHub repository in the multi-source data fusion and direct mapping unit. If a mapping exists, the intra-group inference module is called. If no mapping relationship exists for any CVE in the entity group, the entity group is skipped and the next group is judged until all entity groups have been traversed. Intra-group inference module: If any CVE in the group has established a repository link through the verification rules, then based on the rule that vulnerabilities of the same software entity are concentrated in its main code repository, all other CVEs in the group will automatically inherit the mapping relationship.

4. The automated vulnerability and code repository mapping vulnerability code snapshot acquisition system according to claim 3, characterized in that, The precise version positioning unit also includes: Version collection module: Automatically retrieves all historical tags and branches of the target code repository through the GitHub API, and builds a complete list of repository versions to match the target library; The two-layer matching algorithm module consists of two layers: the first layer is exact matching, which directly matches the affected version number explicitly indicated in the CVE record with the repository's version identifier; if an exact match fails, the second layer of multi-mode fault-tolerant matching is automatically triggered, where the system automatically generates common naming variant patterns based on the initial version number and searches the repository again accordingly; for successfully matched repository versions, the system automatically generates and outputs a snapshot link of the vulnerable version provided directly by GitHub.

5. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program configured to implement the steps of the method according to any one of claims 1-2 when invoked by a processor.

Images