Historical enhanced version-based prediction and double-group hybrid recall vulnerability patch retrieval method, system and device
By combining historical enhanced version prediction with a dual-group hybrid recall method, and utilizing historical CVE records from the same repository and a large language model, the high recall rate, low cost, and adaptability issues of existing vulnerability patch retrieval technologies are solved, achieving efficient and accurate vulnerability patch retrieval.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HARBIN INSTITUTE OF TECHNOLOGY (SHENZHEN) (INSTITUTE OF SCIENCE AND TECHNOLOGY INNOVATION HARBIN INSTITUTE OF TECHNOLOGY SHENZHEN)
- Filing Date
- 2026-06-08
- Publication Date
- 2026-07-03
AI Technical Summary
Existing vulnerability patch retrieval methods cannot simultaneously achieve high recall, high accuracy, and low computational cost. Version prediction relies on a single CVE description, resulting in poor adaptability. Hard version filtering is prone to missing patch submissions, and semantic models have excessive computational overhead.
By constructing a historical enhanced version prediction and dual-group hybrid recall method, enhancing version range prediction is achieved using historical CVE records in the same repository. A soft constraint strategy and dual-group independent sorting are adopted, and submissions are filtered by combining a large language model and a lightweight model.
It significantly improves the accuracy and adaptability of version range prediction, ensures the integrity of recall, and greatly reduces computational overhead while maintaining retrieval accuracy, achieving the best balance between accuracy and efficiency.
Smart Images
Figure CN122333489A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of open-source software security technology, and in particular to a method, system, and apparatus for retrieving vulnerability patches based on historical enhanced version prediction and dual-group hybrid recall. Background Technology
[0002] In the field of open-source software security, the core task of vulnerability patch retrieval is to quickly sift through the massive historical commits of code repositories to identify a small number of candidate commits that may fix specific vulnerabilities (CVEs), allowing security analysts to further confirm them. Existing technologies are mainly divided into two categories:
[0003] The first category is retrieval methods based on semantic similarity. This method calculates the similarity between the CVE description text and the text of each commit message, code change, etc., and extracts the top-ranked commits based on relevance. Depending on the model strength, lightweight methods such as TF-IDF and BM25 are computationally efficient but have weak semantic understanding; deep semantic methods utilize pre-trained models to capture code semantics better, improving retrieval accuracy, but require reasoning for each candidate commit in the repository one by one, resulting in extremely high computational overhead in large-scale repositories, making full deployment difficult.
[0004] The second type is the version-based retrieval method. This method extracts the affected version range from the CVE description, maps it to repository Git tags, and retains only commits within that version range as candidates. This method is highly efficient, but its retrieval performance depends entirely on the accuracy of the version extraction, and existing methods only extract based on a single CVE description, without utilizing historical vulnerability information from the same repository.
[0005] In summary, existing technologies generally face the challenge of balancing recall, accuracy, and computational cost. On one hand, semantic methods suffer from a fundamental contradiction between cost and accuracy: deep semantic models offer high retrieval quality, but the computational and time overhead of encoding each entry in the entire database is insufficient to handle the massive number of submissions from large-scale repositories; lightweight vocabulary matching models offer acceptable efficiency, but their semantic understanding capabilities are weak. Neither model can simultaneously achieve high recall and low cost. On the other hand, version-based methods lack fault tolerance and historical experience reuse mechanisms: existing version filtering treats the prediction interval as a hard constraint, permanently removing submissions outside the interval. If version information is missing or the format is inconsistent with the repository tags, the actual fix submission will be lost. Furthermore, version prediction relies solely on a single CVE description, failing to reuse version mapping patterns from historical CVEs within the same repository and thus unable to learn the repository's unique version naming conventions, resulting in insufficient accuracy and adaptability. These two types of methods have long developed independently, failing to complement the efficient pruning capabilities of version information with the generalized recognition capabilities of semantic matching. Summary of the Invention
[0006] To address the above technical problems, this invention discloses a vulnerability patch retrieval method, system, and apparatus based on historical enhanced version prediction and dual-group hybrid recall. This solves the technical problems of existing vulnerability patch retrieval methods, which cannot simultaneously achieve high recall rate, high accuracy, and low computational cost; version prediction relies on a single CVE description, resulting in poor adaptability; hard version filtering easily leads to missed patch submissions; and semantic model computational overhead is too high.
[0007] The technical solution adopted by this invention is as follows:
[0008] The vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall includes the following steps:
[0009] Step S1, Historical Enhanced Context Construction: Collect historical CVE records publicly available in the target code repository before the current target CVE disclosure date. Construct a structured set of historical example entries containing CVE description text, the latest affected version tag, and the earliest patched version tag. Select several historical CVE example entries closest to the target CVE disclosure date from this set as minority sample examples. Combine this with the task description, the target CVE description text, and the target repository's Git tag list to generate a structured hint text rich in contextual information. This step overcomes the limitation of existing technologies that rely solely on a single CVE description for version inference. By utilizing historical vulnerability records from the same repository to build a knowledge base, it provides a context rich in repository-specific conventions for subsequent version range prediction.
[0010] Step S2, Historical Enhanced Version Range Prediction: The structured hint text is input into the large language model for inference, and the predicted patch version range is output. This range includes two endpoints: the latest affected version and the earliest patched version. Then, the patch version range is mapped to a time window for submission filtering. The time window starts at the submission time corresponding to the latest affected version or the earliest submission time of the repository, and ends at the submission time corresponding to the earliest patched version or the latest submission time of the repository. This step utilizes the contextual hints constructed in Step S1 to guide the large language model in version range prediction, solving the accuracy and adaptability problems caused by traditional methods neglecting repository naming conventions.
[0011] Step S3, Version Soft Constraint Dual-Group Hybrid Recall: Based on the time window, all repository commits are divided into a priority group within the interval and a non-priority group outside the interval; semantic similarity with the target CVE description is calculated using semantic models of different precision for the priority and non-priority groups and sorted in descending order; the priority group sorted list is concatenated before the non-priority group sorted list, and the top K commits are truncated to generate a vulnerability patch candidate commit list. This step, by introducing a "soft priority" signal and a dual-group independent sorting strategy, controls computational costs while ensuring the completeness of the recall.
[0012] This technical solution enhances version range prediction by utilizing historical CVE examples from the same repository and learns version naming conventions to improve accuracy. It uses the prediction range as a soft priority signal, semantically sorts the priority group and non-priority group separately, and then concatenates them. This improves efficiency while fully preserving the recall potential. Furthermore, the partitioning strategy allows for flexible allocation of semantic model strength, balancing recall and cost.
[0013] As a further improvement of the present invention, in step S1, at most 5 historical CVE example entries closest to the disclosure date of the target CVE are selected as a small sample example; if there are fewer than 5, all of them are used.
[0014] As a further improvement of the present invention, in step S1, the structured prompt text is a task description, the aforementioned historical examples, the description text of the target CVE, and a list of Git tags for the target repository, organized according to a structured template. This template aims to enable the large language model to learn the repository's unique version naming conventions (such as whether it includes a "v" prefix, separator styles, etc.) and repair interval patterns through historical examples.
[0015] As a further improvement of the present invention, in step S2, if the latest affected version is a specific version tag name, the submission time corresponding to the tag is taken as the starting point; if it is marked as "starting version", the earliest submission time of the repository is taken as the starting point; if the earliest repaired version is a specific version tag name, the submission time corresponding to the tag is taken as the ending point; if it is marked as "not yet released" or "no corresponding version", the latest submission time of the repository is taken as the ending point.
[0016] As a further improvement of the present invention, in step S3, semantic ranking models of different complexities are used for the priority group and the non-priority group respectively. A high-precision semantic ranking model is deployed for the priority group, and a lightweight semantic ranking model is deployed for the non-priority group.
[0017] This invention discloses a vulnerability patch retrieval system based on historical enhanced version prediction and dual-group hybrid recall, comprising:
[0018] The history-enhanced context building module is used to collect historical CVE records that have been made public in the target code repository before the current target CVE disclosure date. It builds a set of structured historical example entries containing CVE description text, the latest affected version tag, and the earliest patch version tag. From this set, it selects several historical CVE example entries that are closest to the target CVE disclosure date as a few sample examples. Combined with the task description, the target CVE description text, and the target repository's Git tag list, it generates a structured hint text rich in context information.
[0019] The historical enhanced version interval prediction module inputs the structured prompt text into a large language model for inference and outputs the predicted patch version interval. This interval contains two endpoints: the latest affected version and the earliest patch version. Then, the patch version interval is mapped to a time window for submission filtering. The time window starts with the submission time corresponding to the latest affected version or the earliest submission time of the repository, and ends with the submission time corresponding to the earliest patch version or the latest submission time of the repository.
[0020] The version soft constraint dual-group hybrid recall module divides all repository commits into a priority group within the time window and a non-priority group outside the time window. It calculates the semantic similarity between the priority group and the target CVE description using semantic models of different precision and sorts them in descending order. The priority group sorted list is placed before the non-priority group sorted list and concatenated. The top K commits are then used to generate a vulnerability patch candidate commit list.
[0021] As a further improvement of the present invention, the historical enhanced context construction module selects up to 5 historical CVE example entries that are closest to the disclosure date of the target CVE as a few sample examples; if there are fewer than 5, all of them are used.
[0022] As a further improvement of the present invention, if the latest affected version is a specific version tag name, the start time is the submission time corresponding to that tag; if it is marked as "starting version", the start time is the earliest submission time of the repository; if the earliest repaired version is a specific version tag name, the end time is the submission time corresponding to that tag; if it is marked as "not yet released" or "no corresponding version", the end time is the latest submission time of the repository.
[0023] As a further improvement of the present invention, the version soft-constraint dual-group hybrid recall module adopts semantic ranking models of different complexities for priority groups and non-priority groups respectively, deploying a high-precision semantic ranking model for priority groups and a lightweight semantic ranking model for non-priority groups.
[0024] The present invention also discloses a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall as described above.
[0025] The present invention also discloses a vulnerability patch retrieval device based on historical enhanced version prediction and dual-group hybrid recall, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall as described above.
[0026] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0027] The technical solution of this invention introduces historical CVEs from the same repository as few-sample examples to guide a large language model in learning the repository's unique version naming conventions and repair interval patterns. This significantly improves the accuracy and adaptability of version interval prediction, overcoming the problems of existing methods that rely solely on a single CVE description and cannot handle inconsistent or missing version formats. By using the predicted version interval as a "soft priority" signal rather than hard filtering, all commits within the priority group are retained and prioritized, while commits outside the interval are also included in the ranking as a backup group. This achieves soft priority partitioning recall, completely avoiding the risk of genuine repair commits being incorrectly removed due to version prediction errors, thus ensuring the integrity of the recall. Through a dual-group independent ranking strategy, a high-precision deep semantic model is allowed for priority groups with fewer commits, while a lightweight model is used for non-priority groups with more commits. This significantly reduces overall computational overhead while maintaining retrieval accuracy, achieving the best balance between accuracy and efficiency. The technical solution of this invention can be directly embedded into existing vulnerability database patch link automation completion processes, rapid vulnerability version location in network testing ranges, and other scenarios. The output results are simple in format, easy to integrate with downstream systems, and have wide applicability. Attached Figure Description
[0028] Figure 1 This is a schematic diagram of the overall process of the method of the present invention.
[0029] Figure 2 This is a schematic diagram of the sub-process for constructing the history enhancement context in step S1 of an embodiment of the present invention.
[0030] Figure 3 This is a schematic diagram of the historical enhanced version interval prediction process in step S2 of this embodiment of the invention.
[0031] Figure 4 This is a schematic diagram of the soft-constraint dual-group hybrid recall process in step S3 of this embodiment of the invention. Detailed Implementation
[0032] The preferred embodiments of the present invention will be described in further detail below.
[0033] Example 1
[0034] A vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall utilizes historical CVE records from the target code repository as a few-sample example to guide a large language model to predict the patch version range of the current vulnerability. This range is then used as a "soft priority" signal to partition and sort all commits, rather than through hard filtering. The overall process is as follows: Figure 1 As shown, it includes the following steps:
[0035] Step S1, History Enhancement Context Construction.
[0036] This step aims to overcome the limitations of existing technologies that rely solely on a single CVE description for version inference. By leveraging historical vulnerability records from the same repository to build a knowledge base, it provides a context rich in repository-specific conventions for subsequent version range predictions. The specific process is as follows: Figure 2 As shown, it includes the following sub-steps:
[0037] Sub-step S101: Knowledge Base Construction. Pre-collect all publicly available CVE records from the target code repository prior to the current target CVE disclosure date. For each record, extract its CVE description text, the corresponding latest affected version tag, and the earliest patched version tag to form a structured set of historical example entries.
[0038] Sub-step S102: Example retrieval and organization. From the knowledge base, select up to 5 historical CVE example entries that are closest to the disclosure date of the target CVE as a small sample example, based on the principle of temporal proximity; if there are fewer than 5, use all of them.
[0039] Sub-step S103: Hint Template Generation. The task description, the aforementioned historical examples, the description text of the target CVE, and the list of Git tags for the target repository are organized into a complete hint text using a structured template. This template aims to enable the large language model to learn the repository's unique version naming conventions (such as whether it includes a "v" prefix, separator styles, etc.) and repair interval patterns through historical examples.
[0040] This step outputs a structured hint rich in contextual information for use in the next step of version prediction.
[0041] Step S2: Historical Enhanced Version Range Prediction.
[0042] The contextual hints constructed in step S1 guide the large language model in version range prediction, addressing the accuracy and adaptability limitations of traditional methods that neglect repository naming conventions. The specific process is as follows: Figure 3 As shown, it includes the following sub-steps:
[0043] Sub-step S201: Large Language Model Inference. The structured hints generated in step S1 are input into the large language model for inference. The large language model, combined with the version mapping prior knowledge provided in historical examples, outputs the predicted patch version range, containing two endpoints: the latest affected version and the earliest patched version. These two endpoints are usually specific version tag names in the repository; if the vulnerability has existed since the beginning of the project, the latest affected version is marked as the "starting version"; if it is believed that there is no version tag after the patch, the earliest patched version is marked as "not yet released".
[0044] Sub-step S202: Version Range Mapping. The predicted patch version range from sub-step S201 is mapped to a time window for commit filtering. The time window is defined by a start and an end point. The start point is determined by the latest affected version: if it's a specific tag name, the start point is the commit time corresponding to that tag; if it's marked as "starting version," the start point is the earliest commit time in the repository. The end point is determined by the earliest patch version: if it's a specific tag name, the end point is the commit time corresponding to that tag; if it's marked as "not yet released" or "no corresponding version," the end point is the latest commit time in the repository.
[0045] This step outputs a time window, which serves as a constraint signal for the next step.
[0046] Step S3: Version-based soft-constraint dual-group hybrid recall. This step introduces a "soft priority" signal and a dual-group independent sorting strategy to control computational costs while ensuring recall completeness. The specific process is as follows: Figure 4 As shown, it includes the following sub-steps:
[0047] Sub-step S301: Commit set partitioning. Let C be the total set of commits in the repository, with each commit having a specific timestamp. Based on the time window obtained in S2, divide C into two disjoint subsets: the priority group C_A contains all commits whose commit times fall within this interval, and is the set most likely to contain a patch based on version prediction; the non-priority group C_B contains all remaining commits outside the interval as a backup.
[0048] Sub-step S302: Independent semantic ranking for both groups. For groups C_A and C_B, calculate the semantic similarity score between each submission and the target CVE description. This step allows for flexible allocation of computational resources as needed: a high-precision semantic ranking model can be deployed for the priority group, which typically has fewer submissions; a lightweight model can be deployed for the non-priority group, which has a large number of submissions, to ensure efficiency. The two groups are then sorted in descending order of their similarity scores, resulting in ordered lists L_A and L_B.
[0049] Sub-step S303: Candidate list concatenation and truncation. The two ordered lists are merged according to priority, with all commits from priority group L_A placed before those from non-priority group L_B, forming the final candidate list L. This sorting achieves a "version priority" soft constraint effect, ensuring that all commits falling within the prediction interval are placed before all commits outside the interval. Finally, the top K commits are truncated based on downstream requirements as the retrieval recall output.
[0050] Finally, a list of Top K candidate submissions is output for security analysts to verify.
[0051] The following examples illustrate this point.
[0052] This example uses a real CVE (denoted as CVE-2024-45310) from the open-source code repository opencontainers / runc to illustrate the specific execution process of this invention.
[0053] Step S1, History Enhancement Context Construction.
[0054] First, collect all publicly available CVE records from the repository prior to the disclosure date of CVE-2024-45310. For each record, obtain its description text from OSV and the corresponding latest affected version tag and earliest patch version tag from the repository maintenance information to form a structured entry.
[0055] Then, based on the principle of temporal proximity, select up to five historical records closest to the disclosure date of the target CVE. This example selects the following historical records: CVE-2019-5736, CVE-2021-30465, CVE-2021-43784, CVE-2022-29162, CVE-2023-25809. Next, organize the content according to the predefined prompt template:
[0056] Task: Based on the following historical examples and list of repository tags, predict the current CVE fix version range.
[0057] Warehouse tag list (excerpt):
[0058] v0.0.9, ..., v1.0.0-rc6, v1.0.0-rc7, v1.0.0-rc93, v1.0.0-rc94,
[0059] v1.0.2, v1.0.3, v1.1.2, v1.1.3, v1.1.4, v1.1.5,
[0060] v1.1.13, v1.1.14, v1.2.0-rc.2, v1.2.0-rc.3, ....
[0061] Historical examples:
[0062] CVE-2019-5736: Description: "A vulnerability exists in runC up to 1.0-rc6 (used in Docker versions prior to 18.09.2). An attacker could exploit improper handling of the file descriptor / proc / self / exe by executing commands with root privileges inside the container, thereby overwriting the host machine's runC binary and gaining root access to the host machine." Latest affected version: v1.0.0-rc6, earliest patched version: v1.0.0-rc7;
[0063] CVE-2021-30465: Description: "RunC before 1.0.0-rc95 contains a container file system escape vulnerability, which is achieved through directory traversal. An attacker needs to create multiple containers and configure specific mounts, and use symbolic link swapping to trigger a race condition." Latest affected version: v1.0.0-rc93, earliest patched version: v1.0.0-rc94;
[0064] CVE-2021-43784: Description: "In all versions of runC prior to 1.0.3, the internal netlink encoder has an integer overflow when processing 16-bit length fields of byte array attribute types. A sufficiently large malicious byte array attribute can cause the length to overflow and result in the attribute content being parsed as a netlink message configured by the container, thereby bypassing namespace restrictions." Latest affected version: v1.0.2, earliest patched version: v1.0.3;
[0065] CVE-2022-29162: Description: "In versions of runC prior to 1.1.2, runc exec --cap created a non-empty set of inherited Linux process capabilities, allowing programs with inherited file capabilities to elevate their capabilities to the license set during execve(2)." Latest affected version: v1.1.2, earliest patched version: v1.1.3;
[0066] CVE-2023-25809: Description: "In versions of runC prior to 1.1.5, runC made / sys / fs / cgroup writable in rootless mode, potentially allowing containers to gain write permissions to all cgroup levels of the host user." Latest affected version: v1.1.4, earliest patched version: v1.1.5. Target CVE: CVE-2024-45310, Description: "A path or directory creation vulnerability exists in runc versions 1.1.13 and earlier, and 1.2.0-rc2 and earlier. An attacker could influence the host file system through shared volumes and race conditions. This issue was patched in runc v1.1.14 and v1.2.0-rc3."
[0067] Please output the latest affected version and the earliest fixed version, in the format "Version A -> Version B".
[0068] This prompt text is the output of step S1.
[0069] Step S2, historical enhanced version range prediction.
[0070] The above prompt text is input into a large language model (e.g., Deepseek-V3), with the temperature parameter set to 0 to obtain deterministic output. The model outputs a prediction based on the repository version naming conventions learned from historical examples (e.g., using a "v" prefix, dot separators, and an incrementing patch version number pattern), for example: "v 1.1.13 -> v 1.1.14". Then, the repository's Git metadata is queried: the commit time corresponding to the "v1.1.13" tag is June 10, 2024, and the commit time corresponding to the "v1.1.14" tag is September 3, 2024. Therefore, the time window starts on June 10, 2024, and ends on September 3, 2024.
[0071] Step S3: Version soft constraint dual-group mixed recall.
[0072] Retrieve a complete list of commits for the repository, each with a timestamp. Assign all commits with timestamps between 2024-06-10 and 2024-09-03 (inclusive) to priority group C_A, and the remaining commits to non-priority group C_B. C_A contains 81 commits, and C_B contains 7854 commits.
[0073] For C_A, a high-precision semantic ranking model (e.g., a deep model fine-tuned from CodeBERT) is used to calculate the similarity score between each submission and the CVE description, and L_A is obtained by sorting the scores in descending order. For C_B, a lightweight model (e.g., BM25) is used to calculate the similarity score, and L_B is obtained by sorting the scores in descending order. Then, all L_A submissions are ranked before L_B to form the final candidate list L. Finally, based on downstream recall requirements (e.g., needing the top 100 candidates), the top 100 submissions of L are truncated as output.
[0074] Security analysts can quickly verify these 100 submissions, and the actual patches usually fall in the top few of priority group C_A, thus greatly reducing the workload of manual review.
[0075] Example 2
[0076] A system based on the method of Embodiment 1 described above. The system includes:
[0077] Historical Enhancement Context Building Module: Used to execute step S1 of Embodiment 1, including a historical data acquisition unit, an example retrieval unit, and a prompt generation unit. This module outputs structured prompt text.
[0078] Historical Enhanced Version Interval Prediction Module: Used to execute step S2 of Example 1, including a large language model call interface, a parsing unit, and a time window mapping unit. This module outputs a time window.
[0079] Version soft constraint dual-group hybrid recall module: used to execute step S3 of embodiment 1, including a submission partitioning unit, a dual-group semantic sorting unit, and a candidate list concatenation and truncation unit. This module outputs the top K candidate submission lists.
[0080] The modules described above can be deployed on a single server or run as a distributed service. The large language model can be deployed locally using open-source models (such as CodeLLaMA) or can be accessed via API calls to commercial models.
[0081] 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 predicting and retrieving patches for vulnerabilities based on historical enhanced versions with double set hybrid recall, characterized in that: Includes the following steps: Step S1: Collect historical CVE records that have been published in the target code repository before the current target CVE disclosure date, and construct a set of structured historical example entries containing CVE description text, latest affected version tag, and earliest patch version tag. Select several historical CVE example entries that are closest to the target CVE disclosure date from this set as a few sample examples. Combine the task description, the target CVE description text, and the target repository's Git tag list to generate a structured hint text rich in context information. Step S2: Input the structured prompt text into the large language model for inference and output the predicted patch version range. The range includes two endpoints: the latest affected version and the earliest patch version. Then, the patch version range is mapped to a time window for submission filtering. The time window starts with the submission time corresponding to the latest affected version or the earliest submission time of the repository, and ends with the submission time corresponding to the earliest patch version or the latest submission time of the repository. Step S3: Divide all repository submissions into priority groups within the time window and non-priority groups outside the time window; calculate the semantic similarity with the target CVE description using semantic models of different precision for priority groups and non-priority groups respectively, and sort them in descending order; concatenate the priority group sorting list before the non-priority group sorting list, and extract the top K submissions to generate a vulnerability patch candidate submission list.
2. The method of claim 1, wherein the method is based on historical enhanced version prediction with dual group hybrid recall vulnerability patch retrieval. In step S1, select up to 5 historical CVE example entries that are closest to the disclosure date of the target CVE as a small sample example; if there are fewer than 5, all of them will be used.
3. The method of claim 1, wherein: In step S2, if the latest affected version is a specific version tag name, the start time is the submission time corresponding to that tag; if it is marked as "starting version", the start time is the earliest submission time of the repository; if the earliest repaired version is a specific version tag name, the end time is the submission time corresponding to that tag; if it is marked as "not yet released" or "no corresponding version", the end time is the latest submission time of the repository.
4. The method of claim 1, wherein: In step S3, semantic ranking models of different complexities are used for priority groups and non-priority groups respectively. A high-precision semantic ranking model is deployed for priority groups, and a lightweight semantic ranking model is deployed for non-priority groups.
5. A system for predicting and dual ensemble recall vulnerability patch retrieval based on historical enhanced versions, comprising: include: The history-enhanced context building module is used to collect historical CVE records that have been made public in the target code repository before the current target CVE disclosure date. It builds a set of structured historical example entries containing CVE description text, the latest affected version tag, and the earliest patch version tag. From this set, it selects several historical CVE example entries that are closest to the target CVE disclosure date as a few sample examples. Combined with the task description, the target CVE description text, and the target repository's Git tag list, it generates a structured hint text rich in context information. The historical enhanced version interval prediction module inputs the structured prompt text into a large language model for inference and outputs the predicted patch version interval. This interval contains two endpoints: the latest affected version and the earliest patch version. Then, the patch version interval is mapped to a time window for submission filtering. The time window starts with the submission time corresponding to the latest affected version or the earliest submission time of the repository, and ends with the submission time corresponding to the earliest patch version or the latest submission time of the repository. The version soft constraint dual-group hybrid recall module divides all repository commits into a priority group within the time window and a non-priority group outside the time window. It calculates the semantic similarity between the priority group and the target CVE description using semantic models of different precision and sorts them in descending order. The priority group sorted list is placed before the non-priority group sorted list and concatenated. The top K commits are then used to generate a vulnerability patch candidate commit list.
6. The system of claim 5, wherein: The historical enhanced context building module selects up to 5 historical CVE example entries that are closest to the disclosure date of the target CVE as a small sample example; if there are fewer than 5, all of them are used.
7. The system of claim 5, wherein: If the latest affected version is a specific version tag name, the start time is the commit time corresponding to that tag; if it is marked as "starting version", the start time is the earliest commit time of the repository; if the earliest fixed version is a specific version tag name, the end time is the commit time corresponding to that tag; if it is marked as "not yet released" or "no corresponding version", the end time is the latest commit time of the repository.
8. The system of claim 5, wherein: The aforementioned soft-constraint dual-group hybrid recall module employs semantic ranking models of different complexities for priority groups and non-priority groups respectively. A high-precision semantic ranking model is deployed for priority groups, while a lightweight semantic ranking model is deployed for non-priority groups.
9. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the program is executed by the processor, it implements the vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall as described in any one of claims 1 to 4.
10. A device for predicting and retrieving patches for vulnerabilities based on historical enhanced version of a dual group mixed recall, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that: When the processor executes the computer program, it implements the vulnerability patch retrieval method based on historical enhanced version prediction and dual-group hybrid recall as described in any one of claims 1 to 4.