Vulnerability version verification method, system and equipment based on multi-source heterogeneous information

Abstract

The invention discloses a vulnerability version verification method, system and equipment based on multi-source heterogeneous information, and the method comprises the steps: obtaining vulnerability information from a plurality of heterogeneous sources, extracting core elements, and carrying out formatting processing and verification to obtain structured vulnerability entries; collecting or generating a concept verification code, and positioning and generating through a vulnerability code if the concept verification code cannot be collected; performing automatic verification on the concept verification code, and recording a function call chain and a system behavior; and migrating the successfully verified concept verification code to other versions of the software, and determining the vulnerability influence range. The method further comprises the steps of selecting the core elements according to a preset priority rule, and processing the core elements by adopting a conflict resolution rule; vulnerability code positioning comprises similarity calculation, call graph analysis, symbolic execution and large language model generation; the automatic verification is executed and monitored in an isolated environment; code migration is realized by executing path tree representation, binary code comparison and path alignment. According to the method, the influence range of the vulnerability in different software versions can be accurately verified, and the vulnerability repairing efficiency is improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of network security and software vulnerability analysis, and relates to a vulnerability version verification method, system and device based on multi-source heterogeneous information. BACKGROUND

[0002] With the increasing complexity of software systems and the widespread use of open source components, the number of network security vulnerabilities continues to rise, and efficient management and analysis of vulnerabilities have become the core of network security. The Common Vulnerabilities and Exposures (CVE) database, as a widely used public vulnerability information library in the industry, provides basic information about vulnerabilities for security personnel.

[0003] Currently, vulnerability information mainly comes from various vulnerability databases and intelligence platforms. For example, CN109960937B discloses a method and system for constructing a vulnerability exercise environment, which can obtain vulnerability intelligence in a computer security system, extract vulnerability information from the vulnerability intelligence, including software manufacturer, software name, software version, etc., to establish a vulnerability exercise environment. This method improves the accuracy of vulnerability information and the efficiency of establishing a vulnerability exercise environment.

[0004] In terms of vulnerability analysis, existing technologies mainly use a combination of static analysis and dynamic analysis. CN116170186A discloses an attack code online detection method based on network traffic analysis, which uses vulnerability data sets to analyze vulnerability execution paths, combines semantic analysis of known vulnerability information, extracts various information elements during vulnerability reproduction, and constructs vulnerability execution features. CN107273751B proposes a security vulnerability online discovery method based on multi-mode matching, which discovers known vulnerabilities through software version feature matching and vulnerability matching, and discovers unknown vulnerabilities through vulnerability pattern matching.

[0005] For vulnerability verification, CN109325351B discloses a security vulnerability automatic verification system based on a crowd testing platform, which realizes automatic verification of vulnerabilities through steps such as verification information collection, verification information packaging, seeking verification strategies, and automatic vulnerability verification. In terms of source code vulnerability detection, CN115563617B proposes a source code vulnerability detection method and device, which analyzes the source code of software through a pre-set source code vulnerability analysis engine and based on a pre-set vulnerability rule library, improving the accuracy and efficiency of source code vulnerability detection.

[0006] However, in the face of massive vulnerability information and constantly changing attack methods, traditional vulnerability management and analysis techniques gradually expose many shortcomings and are difficult to meet the efficient and accurate security protection needs. Mainly reflected in: (1) Single information dimension: the information provided by the CVE database often lacks key information such as vulnerability type and root cause, making it difficult for security personnel to quickly and accurately understand the nature of the vulnerability; (2) Difficulty in obtaining and generating concept verification code: the ways to obtain the concept verification code required for vulnerability verification are scattered and the quality is uneven, and the verification process consumes a lot of manpower. When there is no public concept verification code, its generation process is heavily dependent on manual analysis by experts, which is time-consuming and has an uncertain success rate; (3) Insufficient precision of automated analysis: existing automated analysis methods (such as symbolic execution and AI generation) fail to effectively utilize deep information such as code path constraints to guide the generation of concept verification codes that can accurately trigger vulnerabilities, and lack the ability to automatically analyze the same vulnerability across different software versions; (4) Fragmented knowledge management: various types of vulnerability-related information (descriptions, codes, concept verification codes, etc.) are stored in scattered locations, and there is a lack of a unified organizational framework, which is not conducive to the accumulation, sharing, and reuse of knowledge. SUMMARY

[0007] The purpose of the present application is to solve the problems in the prior art and provide a vulnerability version verification method, system and device based on multi-source heterogeneous information In order to achieve the above purpose, the following technical solutions are adopted in the present application: In a first aspect, the present application provides a vulnerability version verification method, comprising the following steps: A plurality of heterogeneous sources are used to obtain vulnerability information, and the core elements of the vulnerability are extracted from the vulnerability information, and then the core elements are formatted and verified to obtain structured vulnerability entries; Concept verification codes are collected from known information, and if they cannot be collected, the following steps are performed after generating concept verification codes through vulnerability code positioning, and if they can be collected, the following steps are directly continued: The collected or generated concept verification codes are automatically verified, and the complete function call chain and system behavior in the automatic verification are recorded; The concept verification codes that are successfully verified are migrated to other versions of the software to determine the impact range of the vulnerability in different software versions.

[0008] In a second aspect, the present application provides a vulnerability version verification system, comprising: A multi-source heterogeneous information fusion module is used to obtain vulnerability information from a plurality of heterogeneous sources, extract the core elements of the vulnerability from the vulnerability information, and then perform formatting and verification on the core elements to obtain structured vulnerability entries; The automatic proof-of-concept code generation module is used to collect proof-of-concept code from known information. If it cannot collect the code, it performs vulnerability code location to generate the proof-of-concept code before proceeding to the next steps. If the code can be collected, it directly continues to the next steps. Automated verification of collected or generated proof-of-concept code, and recording of complete function call chains and system behavior during automated verification; Migrate the proof-of-concept code that was successfully automated to other versions of the software to determine the scope of the vulnerability's impact across different software versions.

[0009] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0010] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described above.

[0011] Fifthly, this application provides a computer program product, the computer program product including computer instructions, wherein a processor of a computer device reads the computer instructions, and the processor of the computer device executes the computer instructions to implement the steps of the method described above.

[0012] Compared with the prior art, this application has the following beneficial effects: This application effectively solves the problem of the single-dimensional information in traditional CVE databases by using multi-source heterogeneous information fusion technology. It integrates information from multiple channels and automatically extracts core elements using a large language model, significantly improving the completeness and richness of vulnerability information. Simultaneously, it resolves conflicts through predefined hierarchical priority rules, ensuring the authority and accuracy of the information. This application improves the success rate and quality of proof-of-concept code generation by combining formal constraints and large language models. By using path constraints extracted from symbolic execution as guiding information for generation, it reduces reliance on purely manual PoC writing. Combined with code semantic understanding and call graph analysis, it further improves the accuracy of vulnerability function location. Secondly, this application's multi-dimensional proof-of-concept code verification mechanism overcomes the shortcomings of insufficient accuracy in existing verification methods. By integrating multi-layered technologies such as function-level instrumentation, system call tracing, and memory access monitoring, it can more comprehensively capture various types of execution evidence, such as program crashes, memory corruption, and privilege escalation, improving the accuracy of vulnerability confirmation. Finally, this application solves the technical challenge of accurately defining the scope of cross-version vulnerability impact by using cross-version vulnerability automated analysis based on proof-of-concept code. Through path-aware fuzzing and cross-version path alignment technology, it can automatically discover affected versions that may be missed in official disclosures, significantly improving the completeness of version coverage. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of the method described in this application.

[0015] Figure 2 This is a schematic diagram of the system in this application.

[0016] Figure 3 This is an overall architecture diagram of an embodiment of this application.

[0017] Figure 4 This is a schematic diagram of multi-source information fusion and priority rules in an embodiment of this application.

[0018] Figure 5 This is a flowchart illustrating the proof-of-concept code generation and verification process for an embodiment of this application.

[0019] Figure 6 This is a schematic diagram of cross-version fuzz test path alignment in an embodiment of this application.

[0020] Figure 7This is a database architecture diagram of an embodiment of this application.

[0021] Figure 8 A flowchart illustrating the information disclosure of a general vulnerability in an embodiment of this application.

[0022] Figure 9 This is a flowchart illustrating the continuous monitoring and incremental update process in this application embodiment. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0024] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0026] In the description of the embodiments of this application, it should be noted that if terms such as "upper," "lower," "horizontal," or "inner" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of the invention is in use, they are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, terms such as "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] Furthermore, the use of the term "horizontal" does not imply that the component must be absolutely horizontal, but rather that it can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0028] In the description of the embodiments of this application, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0029] See Figure 1 This embodiment discloses a vulnerability version verification method, including the following steps: S1 obtains vulnerability information from multiple heterogeneous sources, extracts the core elements of the vulnerability from the vulnerability information, and then formats and verifies the core elements to obtain structured vulnerability entries. It should be noted that after extracting the core elements of a vulnerability from vulnerability information, the following are also included: S1-1 selects core elements according to preset priority rules; S1-2 processes the selected core elements using preset conflict resolution rules.

[0030] In practical applications, the preset conflict resolution rules include: 1) For factual and definitional core elements: use the core elements corresponding to the highest priority vulnerability information currently available; 2) For descriptive and analytical elements: Use the core elements corresponding to the vulnerability information that provides the most detailed technical information from the highest priority currently available; 3) For the core elements of the version range affected by the vulnerability: obtain the core elements corresponding to all vulnerability information, calculate the union, and use the union as the corresponding core element; 4) For the core elements of proof-of-concept code: obtain the link to the proof-of-concept code or the core elements corresponding to the code from all vulnerability information.

[0031] S2 collects proof-of-concept code from known information. If it cannot collect the code, it locates the vulnerability code, generates the proof-of-concept code, and then executes the following steps. If the code can be collected, it directly continues to execute the following steps: S2-1 automates the verification of collected or generated proof-of-concept code and records the complete function call chain and system behavior during the automated verification. In practical applications, methods for automated verification include: 1) Execute proof-of-concept code in an isolated environment and set up multi-dimensional monitoring; 2) Execute proof-of-concept code within the container and collect execution evidence; 3) Based on the multi-dimensional monitoring results and the collected execution evidence, determine whether the vulnerability exploitation was successful and store the execution trace information.

[0032] S2-2 migrates the successfully automated proof-of-concept code to other versions of the software to determine the scope of the vulnerability's impact across different software versions.

[0033] In practical applications, methods for locating vulnerable code include: 1) Encode the vulnerability information and the functions in the code library, calculate the cosine similarity, and obtain the candidate functions with the highest similarity as the vulnerability functions to be located; 2) Employ call graph analysis to construct the program's function call graph, which is used to find all simple paths from the user input entry point to the located vulnerability function; 3) Perform symbolic execution on the identified vulnerable functions to extract the path constraints that triggered the vulnerability; 4) Input path constraints as contextual information into the large language model to generate proof-of-concept code; 5) Perform syntax and semantic checks on the generated proof-of-concept code.

[0034] In practical applications, methods for verifying code migration to other versions of the software include: 1) Execute the validated proof-of-concept code on the reference version to establish a tree representation structure of the reference execution path; 2) Compare the binary code of the reference version and the target version to detect function-level code changes and identify corresponding function pairs between the two versions; 3) Represent the execution paths of the reference version and the target version as a tree structure, and match the execution path tree of the reference version with the potential execution path of the target version to obtain the cross-version path alignment result; 4) Based on the cross-version path alignment results, identify the key variables accessed in the target execution path of the target version; 5) Based on the identified key variables, use fuzz testing to iteratively mutate the original proof-of-concept code.

[0035] like Figure 2 As shown, this embodiment provides a vulnerability version verification system, including a multi-source heterogeneous information fusion module and a proof-of-concept code automatic generation module.

[0036] The multi-source heterogeneous information fusion module acquires vulnerability information from multiple heterogeneous sources, extracts the core elements of the vulnerabilities from this information, and then formats and verifies these core elements to obtain structured vulnerability entries. In its implementation, the module connects to multiple heterogeneous data sources, such as the National Vulnerability Database, vendor security bulletins, security research reports, and open-source intelligence platforms, via API interfaces to obtain the latest vulnerability information in real time. The acquired vulnerability information typically includes vulnerability ID, affected software version, vulnerability type, vulnerability description, and CVSS score. The module uses natural language processing technology to extract the core elements of the vulnerabilities from this unstructured text, including key information such as vulnerability triggering conditions, affected components, and vulnerability causes. The extracted core elements are then formatted and uniformly converted to standard formats such as JSON or XML, and data integrity and consistency checks are performed to ultimately form structured vulnerability entries for subsequent analysis and processing.

[0037] The automatic proof-of-concept code generation module collects proof-of-concept code from known information. If it cannot collect such code, it performs vulnerability code localization to generate proof-of-concept code before proceeding to the next steps. If code can be collected, it directly continues with the following steps: automating the verification of the collected or generated proof-of-concept code and recording the complete function call chain and system behavior during the automated verification; migrating the successfully verified proof-of-concept code to other versions of the software to determine the impact scope of the vulnerability in different software versions. In actual operation, the automatic proof-of-concept code generation module first searches public platforms such as GitHub and ExploitDB, as well as technical blogs published by security researchers, attempting to collect existing proof-of-concept code. If relevant code is successfully collected, the module standardizes the code to ensure it can run normally in the test environment.

[0038] In a preferred embodiment, when proof-of-concept code cannot be collected from known information, the automatic proof-of-concept code generation module locates the vulnerability code through a combination of static and dynamic analysis. The static analysis uses program slicing technology, starting from the vulnerability point and tracing back the data and control flows to determine the necessary conditions for vulnerability triggering. The dynamic analysis uses fuzzing and symbolic execution techniques to explore possible input spaces and generate input samples that can trigger the vulnerability. Based on the analysis results, the module automatically constructs the proof-of-concept code framework, fills in the necessary vulnerability triggering logic, and finally generates complete proof-of-concept code.

[0039] Whether the proof-of-concept code is collected or generated, the system performs automated verification in an isolated virtual environment. The verification process uses dynamic instrumentation to monitor the function call chain during program execution in real time, recording system behaviors such as memory allocation, file operations, and network communication. The system compares the verification results with expected vulnerability behavior characteristics, such as out-of-bounds memory access, null pointer dereferences, and privilege escalation, to confirm whether the proof-of-concept code successfully triggered the target vulnerability.

[0040] After successful verification, the system automatically migrates the proof-of-concept code to other versions of the software. During the migration process, the system analyzes the binary differences or source code changes of the target software versions and automatically adjusts offsets, function names, or API calling methods in the proof-of-concept code to ensure that the code can run correctly on different versions. By executing the adjusted proof-of-concept code on multiple versions, the system can accurately determine the scope of the vulnerability and generate a detailed version compatibility report.

[0041] In a preferred embodiment, the system further includes a vulnerability information visualization module. This module visually displays the core elements, scope of impact, and verification results of the vulnerability in chart form, helping security analysts quickly understand the characteristics and impact of the vulnerability. The visualization module supports multi-dimensional data display, including heatmaps distributed by software version, vulnerability exploitation difficulty assessment charts, and dependency graphs of affected components.

[0042] In another preferred embodiment, the system further includes a vulnerability remediation suggestion generation module, which automatically generates targeted remediation suggestions based on the core elements of the vulnerability and verification results. The remediation suggestions include both temporary mitigation measures and permanent remediation solutions, and provide customized remediation guidance according to the characteristics of different software versions.

[0043] The system's workflow is as follows: First, the multi-source heterogeneous information fusion module collects vulnerability information from multiple data sources, extracts core elements, and forms structured vulnerability entries. Then, the automatic proof-of-concept code generation module attempts to collect or generate proof-of-concept code and verifies it in an isolated environment. Finally, the system migrates the successfully verified proof-of-concept code to different software versions, determines the scope of the vulnerability's impact, and generates a detailed analysis report. Through these steps, the system can efficiently and accurately verify the existence of vulnerabilities in different software versions, providing security teams with a reliable basis for vulnerability management.

[0044] like Figure 3 As shown, this embodiment provides a method for constructing an automated Common Vulnerabilities and Exposures (CVE) vulnerability knowledge base, including the following steps: S1: Vulnerability information enhancement based on multi-source heterogeneous information fusion; raw information is obtained from multiple fixed data sources through automated programs, deep analysis and information extraction are performed using a large language model, and the extraction results are compared and fused to finally form a structured description of the six core elements of the vulnerability.

[0045] It should be noted that this application obtains vulnerability information from multiple heterogeneous sources and extracts the core elements of the vulnerabilities from this information. These core elements are then formatted and validated to obtain structured vulnerability entries. After extracting the core elements, this application further selects the core elements according to a preset priority rule, and then processes the selected core elements using a preset conflict resolution rule.

[0046] S2: Proof-of-Concept Code Collection and Formal Constraint-Guided Proof-of-Concept Code Generation. Proof-of-concept code is collected and validated. If no publicly available proof-of-concept code is found or the validation fails, proof-of-concept code is generated based on a large language model guided by formal constraints.

[0047] It should be noted that these conflict resolution rules include four case handling methods: For factual and definitional core elements, the core element corresponding to the highest priority vulnerability information currently available is used; for descriptive and analytical elements, the core element corresponding to the vulnerability information providing the most detailed technical information among the highest priority currently available is used; for core elements of version range affected by the vulnerability, the core elements corresponding to all vulnerability information are obtained, the union is calculated, and the union is used as the corresponding core element; for core elements of proof-of-concept code, the core element corresponding to the link to the proof-of-concept code or the code itself is obtained from all vulnerability information.

[0048] S3: Proof-of-Concept Code Validation and Dynamic Call Chain Recording. Automated validation of collected or generated proof-of-concept code, recording complete function call chains and system behavior.

[0049] It should be noted that this application collects proof-of-concept code from known information. If proof-of-concept code cannot be collected, vulnerability code localization and generation are required. The vulnerability code localization method includes the following steps: encoding the vulnerability information and the functions in the code library, calculating the cosine similarity to obtain several candidate functions with the highest similarity, which are used as the localized vulnerability functions; using a call graph analysis method to construct the program's function call graph to find all simple paths from the user input entry point to the localized vulnerability function; performing symbolic execution on the localized vulnerability function to extract the path constraints that trigger the vulnerability; inputting the path constraints as context information into a large language model to generate proof-of-concept code; and performing syntax and semantic checks on the generated proof-of-concept code.

[0050] S4: Cross-version fuzzing based on proof-of-concept code. By migrating successfully validated proof-of-concept code to other versions of the software, path-aware fuzzing methods are used to determine the scope of the vulnerability's impact across different versions.

[0051] It should be noted that after collecting or generating proof-of-concept code, this application performs automated verification of this code and records the complete function call chain and system behavior during the automated verification. The automated verification methods include: executing the proof-of-concept code in an isolated environment and setting up multi-dimensional monitoring; executing the proof-of-concept code in a container and collecting execution evidence; and based on the results of multi-dimensional monitoring and the collected execution evidence, determining whether the vulnerability exploitation was successful and storing the execution trace information.

[0052] S5: Knowledge Base Construction and Updates. The extracted six elements, proof-of-concept code, call chains, constraints, and cross-version test results are stored in a graph database, and relationships between entities are established to achieve structured management and continuous updates of knowledge.

[0053] It should be noted that this application migrates successfully verified proof-of-concept code to other versions of the software to determine the scope of the vulnerability's impact across different software versions. The method for migrating the verification code to other versions of the software includes: executing the verified proof-of-concept code on a reference version to establish a tree representation of the reference execution path; comparing the binary code of the reference and target versions to detect function-level code changes and identify corresponding function pairs between the two versions; representing the execution paths of the reference and target versions as tree structures, matching the execution path tree of the reference version with the potential execution paths of the target version to obtain cross-version path alignment results; based on the cross-version path alignment results, identifying the key variables accessed in the target execution path of the target version; and using fuzz testing to iteratively mutate the original proof-of-concept code based on the identified key variables.

[0054] This method allows for comprehensive verification of the existence of software vulnerabilities in different versions, providing a reliable basis for software security assessment and vulnerability remediation.

[0055] like Figure 4 The diagram shown illustrates the second flowchart of the vulnerability version verification method in this application, which may include: S201, vulnerability information enhancement based on multi-source heterogeneous information fusion.

[0056] This is a flowchart illustrating a vulnerability information enhancement method based on multi-source heterogeneous information fusion. An automated program acquires raw information from multiple fixed data sources, performs deep analysis and information extraction using a large language model, and compares and fuses the extracted results to ultimately form a structured description of the six core elements of the vulnerability. Specifically, the following method can be used in this embodiment: S201-1, Obtain vulnerability-related information from multiple heterogeneous data sources.

[0057] Information can be obtained from the following data sources using web crawling technology: official sources, which may include the National Vulnerability Database (NVD), official databases of general vulnerability disclosures, vendor security bulletins, and patch management systems; community sources, which may include issue discussions on code hosting platforms, technical blogs, security conference papers, and security discussions on social media; exploit databases, which may include publicly available exploit code repositories and penetration testing frameworks; and threat intelligence platforms, which may include virus detection platforms and open threat intelligence exchange platforms.

[0058] S201-2, extracting the six core elements of the vulnerability.

[0059] In practical applications, the number and specific content of the core elements extracted from the vulnerability can be adjusted according to the needs of use. The following is a set of six core elements given in this embodiment: (1) Vulnerability type: Identify the specific technical category to which the vulnerability belongs. For example: SQL injection, buffer overflow, cross-site scripting (XSS), server-side request forgery (SSRF), etc.

[0060] (2) Root cause: Analyze the specific code defects, design logic errors or improper configurations that led to the vulnerability.

[0061] (3) Affected products: Accurately identify the software, hardware or components with the vulnerability and determine the specific range of affected versions.

[0062] (4) Impact: Describe the specific consequences that the system’s confidentiality, integrity and availability may be caused if the vulnerability is successfully exploited.

[0063] (5) Attacker type: Define the attacker's privileges and location required to exploit the vulnerability. For example: unauthenticated remote attackers, local users with specific privileges, etc.

[0064] (6) Attack Vector: Describes the specific technical path and method used by the attacker to trigger and exploit this vulnerability.

[0065] S201-3, Multi-source result comparison and conflict resolution based on predefined priority rules.

[0066] The six elements of the same vulnerability extracted from different information sources through a large language model are compared horizontally, and selection and conflict resolution are carried out according to a predefined priority rule set based on the authority of the information source.

[0067] In practical applications, information sources can be categorized into different levels using priority rule sets: First priority (highest): Official sources. This includes NVDs, CVEs, and vendor security bulletins directly related to the vulnerabilities. Information from these sources is considered the baseline fact.

[0068] Second priority: Managed technical databases. This includes vulnerability and exploit code repositories such as Exploit-DB and Metasploit, which are reviewed and managed by designated personnel.

[0069] Third priority: reputable communities and personal sources. This includes blogs of trustworthy security research teams and well-known security projects on GitHub.

[0070] When information about the same element from different sources conflicts, the following conflict resolution rules can be adopted: (1) For factual and definitional elements (such as vulnerability type, impact, attacker type): directly use the information provided by the highest priority information source currently available. For example, if NVD (first priority) provides a CVSS vector, then the "impact" and "attacker type" elements are based on this, ignoring contradictory descriptions from other sources.

[0071] (2) For descriptive and analytical elements (e.g., root cause, attack vector): prioritize information from the highest priority source that provides the most detailed technical information. If the description from the highest priority source (e.g., NVD) is too brief, then search down to the next lower priority source (e.g., technical blog) and select the description that provides code-level analysis or detailed steps.

[0072] (3) For the range of versions affected by the vulnerability: special rules are adopted, namely, obtaining version information from all sources and calculating their union to ensure the integrity of the coverage and prevent any affected versions from being missed.

[0073] (4) For proof-of-concept code: Collect links or codes of proof-of-concept code from all sources, but prioritize displaying and tagging proof-of-concept code from the second priority (managed technology database) because it is usually verified and more available.

[0074] S201-4, Structured Data Storage and Validation.

[0075] The final six-element result, obtained after priority rule filtering and fusion (conflict resolution), is formatted and then subjected to final integrity and logical consistency verification. Once the verification passes, the structured vulnerability entry is stored in the target knowledge base.

[0076] S202, Proof-of-Concept Code Collection and Formal Constraint-Guided Proof-of-Concept Code Generation.

[0077] This application collects and verifies proof-of-concept code. If no publicly available proof-of-concept code is found or the proof-of-concept code fails to be verified, the application uses formal constraints to guide the generation of proof-of-concept code from a large language model.

[0078] like Figure 5 The diagram shown illustrates the proof-of-concept code generation and verification process in this embodiment. Specifically, it may include: (1) Collect existing proof-of-concept code from multiple vulnerability exploit databases.

[0079] Proof-of-concept code was collected by web scraping from publicly available exploit code repositories, penetration testing framework module libraries, code hosting platforms, and security researcher blogs.

[0080] (2) If the proof-of-concept code is successfully collected, proceed directly to step S203. If the verification fails, continue to the following step (3).

[0081] (3) If the verification fails or no public code is found, locate the vulnerability code.

[0082] The code semantic understanding localization method is adopted. The vulnerability information extracted in step S201 is encoded using a pre-trained code understanding model, the functions in the code library are encoded, the cosine similarity is calculated, and the 5 to 10 candidate functions with the highest similarity are returned.

[0083] By employing a call graph analysis method, a function call graph of the program is constructed to find all simple paths from the user input entry point to the identified vulnerable function.

[0084] (4) Perform symbolic execution on the located vulnerable functions to extract the path constraints that trigger the vulnerabilities; The taint analysis method is used to mark user-controllable input parameters as taint sources, track the propagation of taints in assignment statements, and detect the situation where tainted variables are passed to dangerous functions.

[0085] The symbolic execution method is adopted. The symbolic execution engine is used to analyze the vulnerable function, create symbolic states and symbolic inputs, set initial constraints, and execute symbolic execution until a path to the vulnerability point is found. The path constraints and input samples that satisfy the constraints are then extracted.

[0086] By employing constraint simplification and normalization methods, the SMT solver (Satisfiability Modulus Theory Solver) is used to convert the constraints extracted by symbolic execution into a standard format, check the satisfiability of constraints, simplify constraints and remove redundant conditions, and convert formal constraints into natural language descriptions.

[0087] (5) Input path constraints as contextual information into the large language model to generate proof-of-concept code; Construct structured prompts, including task description, the six elements of vulnerability information, vulnerability code context, path constraints that must be met, generation requirements, and output format.

[0088] Successful proof-of-concept code for similar vulnerability types is retrieved from the knowledge base as small sample learning examples. Each example includes a common vulnerability disclosure number, code, and key point descriptions. Two to five examples are selected.

[0089] A multi-round iterative optimization generation method is adopted. The first round calls the large language model to generate proof-of-concept code. The satisfiability model theory solver is used to verify whether the generated code satisfies the constraints. If all constraints are satisfied, a success result is returned. Otherwise, feedback prompts are constructed to explain the unsatisfied constraints, the current value, the expected value, and the correction suggestions. The feedback is added to the dialogue history and generation continues, with a maximum of 3 to 5 iterations.

[0090] (6) Perform syntax and semantic checks on the generated proof-of-concept code.

[0091] Perform syntax checks by parsing the code into an abstract syntax tree; if parsing fails, a syntax error is reported. Perform semantic checks by checking for issues such as undefined variables, type mismatches, and logical errors. Perform security checks by using regular expressions to match dangerous operation patterns, including deleting system files, overwriting disks, and process bombs; if a dangerous operation is detected, execution is refused.

[0092] S203, Proof of Concept Code Verification and Dynamic Call Chain Recording.

[0093] This step automates the validation of the collected or generated proof-of-concept code and records the complete function call chain and system behavior.

[0094] S203-1, Execute proof-of-concept code in an isolated environment and set up multi-dimensional monitoring.

[0095] Employing function-level instrumentation, a dynamic binary instrumentation framework is used to hook the target process at runtime, tracking calls to 5 to 20 target functions, recording the depth, name, module, timestamp, parameter values ​​and parameter types of each function call, and recording the return value and timestamp when the function returns.

[0096] The system call tracing technology is used to start a system call tracing tool in the container to track all system calls and record the timestamp, system call name, parameters, return value and execution duration. The execution duration is in seconds.

[0097] Memory access monitoring technology is used, and an environment variable is set to enable address sterilizer when the container starts. Address sterilizer detects and reports memory errors, including heap buffer overflow, stack buffer overflow, global variable overflow, use after free, double free, etc.

[0098] S203-2, Execute proof-of-concept code and collect execution evidence; Copy the proof-of-concept code into a container, execute the code inside the container, set the execution timeout to 3 to 10 seconds, and capture standard output, standard error, and exit code.

[0099] If the program crashes, and the exit code is less than 0, the signal number is extracted to determine the crash type, which may include segmentation fault, illegal instruction, floating-point exception, bus error, etc.

[0100] Detect memory corruption, extract address sanitizer reports from container logs, and parse error type, access size, access address, and backtrace stack.

[0101] To detect privilege escalation, compare the user ID and group ID before and after execution. If the current ID is less than the original ID, it is determined to be privilege escalation.

[0102] To detect information leaks, search for sensitive data patterns in the output of proof-of-concept code, including passwords, keys, configuration file content, database connection strings, etc.

[0103] The system detects code execution by searching the function call chain for unexpected and dangerous functions, including system command execution functions, dynamically loaded functions, and memory protection modification functions; it also searches the system call log for system calls that created or replaced processes.

[0104] To detect a denial of service, attempt to connect to the target service. If the service does not respond or returns an error, it is determined to be a denial of service.

[0105] S203-3, comprehensively determine whether the vulnerability exploitation was successful.

[0106] The expected impact is determined based on the type of impact disclosed in the general vulnerability disclosure, including remote code execution, denial of service, information disclosure, privilege escalation, memory corruption, etc.

[0107] Establish a mapping relationship for success determination criteria: remote code execution or code execution affects corresponding code execution evidence; denial of service affects corresponding program crash or denial of service evidence; information leakage affects corresponding information leakage evidence; privilege escalation affects corresponding privilege escalation evidence; memory corruption affects corresponding memory corruption or program crash evidence.

[0108] If any of the expected effects corresponds to a non-empty type of evidence, the exploitation is deemed successful, and the success result and all evidence are returned.

[0109] S203-4, Structured storage of complete execution trace information; The critical path from the entry point to the vulnerability trigger point is extracted by finding the vulnerable function calls in the call chain, tracing upwards to the entry point, and extracting the critical functions, modules, and parameters in ascending order of call depth.

[0110] The vulnerability signature is generated by extracting the function call sequence of the critical path as the call sequence feature, extracting the memory access pattern as the memory access feature, serializing the feature and calculating a 256-bit hash value using a secure hash algorithm.

[0111] The execution tracking information will be stored, including the general vulnerability disclosure number, timestamp, complete call chain (total number of calls, maximum depth, function list, critical path), system call records (total number of calls, grouped by type, timeline), collected evidence, and generated vulnerability signatures.

[0112] S204, Cross-version fuzzing based on proof-of-concept code.

[0113] By migrating the successfully validated proof-of-concept code to other versions of the software, and employing path-aware fuzzing methods, the scope of the vulnerability's impact across different versions can be determined. For example... Figure 6 The image shows a schematic diagram of the path alignment process for cross-version fuzz testing. Specifically: S204-1, Reference Version: Proof-of-Concept Code Execution and Path Recording.

[0114] Execute validated proof-of-concept code on the reference version (i.e., the version where the vulnerability was initially discovered), and use dynamic binary instrumentation to record the complete function call chain, execution branches, and key variable information. Establish a tree representation of the reference execution path, recording all function call sequences, branch decisions, and variable access patterns from the entry point to the vulnerability trigger point.

[0115] S204-2, Analysis of cross-version function-level code changes.

[0116] The binary code of the reference version and the target version is compared to detect function-level code changes, including function renaming, merging, and splitting. A code similarity calculation method is used to establish a version mapping relationship for each function, identifying corresponding function pairs between two versions.

[0117] S204-3, Cross-version path alignment A tree-based data structure is used to represent the execution paths of the reference version and the target version as a tree structure. A context-sensitive tree alignment algorithm is employed to match the execution path tree of the reference version with the potential execution paths of the target version, establish corresponding function mapping relationships, and determine the target execution path that should be executed in the target version.

[0118] S204-4, Identification of key variables in the target version.

[0119] Based on the cross-version path alignment results, key variables accessed in the target execution path of the target version are identified. The values ​​of these key variables directly affect whether the same vulnerability can be triggered. The dependencies between these key variables and the input of the original proof-of-concept code are extracted.

[0120] S204-5, Path-Aware Fuzz Testing and Proof-of-Concept Code Variation.

[0121] Based on the identified key variables, fuzz testing is used to iteratively mutate the original proof-of-concept code, focusing on adjusting input bytes related to the key variables. Each mutated proof-of-concept code is executed on the target version, and its execution path is recorded. The similarity between the execution path of the mutated code and the target path of the reference version is calculated, and the mutated sample with the highest similarity is selected for the next round of mutation.

[0122] S204-6, invoke step S203 to verify the cross-version vulnerability.

[0123] Once the modified proof-of-concept code is generated, the modified code and its target version are submitted to the verification process in step S203. The established multi-dimensional monitoring and comprehensive judgment mechanism is used to verify whether the vulnerability exploitation is successful. S3 will return the verification results of the vulnerability exploitation, execution trace information, and vulnerability signature. If the verification is successful, it is confirmed that the modified proof-of-concept code can reproduce the vulnerability in the target version.

[0124] S204-7 summarizes all target versions tested.

[0125] Integrate the verification results from step S203 to determine the precise range of affected versions. Update the affected version field of the general vulnerability disclosure entry in the central vulnerability knowledge base, supplementing any affected versions omitted from the official vulnerability disclosure. Link the variant proof-of-concept code form corresponding to each version with the vulnerability signature generated in step S203 for reference in subsequent vulnerability assessments.

[0126] S205, Knowledge Base Construction and Update The extracted six elements, proof-of-concept code, call chain, constraints, and cross-version test results are stored in a graph database, and relationships between entities are established to achieve structured management and continuous updating of knowledge.

[0127] S501: Create a graph database like Figure 7 As shown, Figure 7 This is a data architecture diagram. Entity types are defined as follows: General Vulnerability Disclosure Entity, with attributes including ID, vulnerability type, root cause, impact, attacker type, attack vector, general vulnerability scoring system score, disclosure date, and last update time; Product Entity, with attributes including name, vendor, and type; Version Entity, with attributes including version number, product, status, and release date; Function Entity, with attributes including name, file, start line number, end line number, and code content; File Entity, with attributes including path and code repository; Proof-of-Concept Code Entity, with attributes including ID, code, programming language, source, whether verified, success rate, and creation time; Call Chain Entity, with attributes including ID, entry point, trigger point, and maximum depth; Constraint Entity, with attributes including ID, type, expression, description, and whether it can be satisfied. The defined relationship types include: Impact relationship (from general vulnerability disclosure to version); Fix-in relationship (from general vulnerability disclosure to version); Located relationship (from general vulnerability disclosure to function); Belonging relationship (from version to product); Define-in relationship (from function to file); Call relationship (from function to function, carrying attributes including call chain number, order, and parameters); Possessing proof-of-concept code relationship (from general vulnerability disclosure to proof-of-concept code); Possessing call chain relationship (from general vulnerability disclosure to call chain); Containing relationship (from call chain to function); Need relationship (from general vulnerability disclosure to constraint); Similar to relationship (from general vulnerability disclosure to general vulnerability disclosure, carrying attributes including similarity score and common features). Create uniqueness constraints to ensure that the common vulnerability disclosure number and product name are unique; create indexes on the vulnerability type field and version number field of the common vulnerability disclosure. S502: Procedure for storing complete information on common vulnerability disclosures The process of storing information about common vulnerability disclosures is as follows: Figure 8 As shown, the specific process is as follows: Create or merge common vulnerability disclosure nodes, and set the six-element attributes and metadata attributes; Create product and version nodes, parse affected product information, create or merge product nodes, traverse affected versions, create or merge version nodes, create relationships between versions affected by general vulnerability disclosure, and create relationships between versions and products; if there is remediation version information, create or merge remediation version nodes, and create relationships between general vulnerability disclosure remediation and versions. Store code location information, traverse the code location list, create or merge file nodes and function nodes, set function attributes, create relationships between general vulnerability disclosures and functions, and create relationships between function definitions and files; Store proof-of-concept code information, traverse the list of proof-of-concept codes, create proof-of-concept code nodes, set attributes, and create a general vulnerability disclosure of the relationships between the proof-of-concept codes; Store call chain information, traverse the call chain list, create call chain nodes, set attributes, and create relationships between call chains that disclose general vulnerabilities; traverse the function sequence in the call chain, create or merge function nodes, create call relationships between functions, and set the attributes of the call relationships; Store constraint information, traverse the constraint list, create constraint nodes, set attributes, and create the relationships that need to be constrained for general vulnerability disclosure. S503: Enable continuous monitoring and incremental updates Continuous monitoring and incremental update process as follows Figure 9 As shown: The monitoring threads include: the National Vulnerability Database monitoring thread, which retrieves the latest updated general vulnerability disclosures every 30 to 60 minutes, adds the updated information to the queue, and marks it as high priority; the code hosting platform monitoring thread, which searches for new code repositories containing general vulnerability disclosure keywords every 15 to 30 minutes, extracts the general vulnerability disclosure number, adds the proof-of-concept code information to the queue, and marks it as medium priority; and the vulnerability exploit database monitoring thread, which checks for newly added vulnerability exploit entries every 1 to 2 hours. Start the update processing thread, retrieve update tasks from the queue, query whether the general vulnerability disclosure already exists in the knowledge base, if it exists, perform incremental update, if it does not exist, execute the complete analysis process from steps S1 to S4, and finally store the results in the knowledge base. Incremental update process: If the update source is a code hosting platform and contains new proof-of-concept code, download and verify the proof-of-concept code. If the verification is successful, add the proof-of-concept code information to the knowledge base; if the update source is the national vulnerability database, update the metadata attributes of the general vulnerability disclosure. S504: Provides a knowledge base query interface; Table 1 Overview of Graph Database Query Interfaces

[0128] It provides an interface for querying complete information on common vulnerability disclosures. By entering the common vulnerability disclosure number, it returns six elements, affected versions, patched versions, code location, proof-of-concept code, call chain, and constraints. Provides an interface for querying by vulnerability type. Input the vulnerability type and return all common vulnerability disclosures of that type, along with their ratings, impacts, and the number of verified proof-of-concept codes. Provides an interface for querying by product. Enter the product name and an optional version number, and it will return a list of all common vulnerability disclosures affecting that product and a list of affected versions. Provides an interface for querying similar vulnerabilities. Input a common vulnerability disclosure number, and it will return other common vulnerability disclosures with the same vulnerability type, the same root cause, or the same vulnerability function. Provides an interface for querying call chains. Input a generic vulnerability disclosure number, and it returns the complete function call sequence and the parameters of each call. Provides an interface for querying exploit paths. Input a generic vulnerability disclosure number, and it returns the complete path from the entry point to the vulnerability trigger point and the constraints that must be met. Provides an interface for querying the vulnerability status of a version. Input the product name and version number, and it will return a list of all vulnerabilities and fixed vulnerabilities for that version. Provides an interface for analyzing the attack surface. Input the product name and version number, and it returns the number of vulnerabilities grouped by attacker type, a list of vulnerability types, and a list of affected functions. Provides an interface for keyword search; input keywords and search fields, and it returns matching general vulnerability disclosures and their basic information. Provides an interface to obtain statistical information, returning the total number of general vulnerability disclosures, statistics by vulnerability type, the number of verified proof-of-concept codes, the number of products covered, and the latest update time; This application provides a computer device according to an embodiment. The computer device of this embodiment includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the various method embodiments described above. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the various device embodiments described above.

[0129] A computer program can be divided into one or more modules / units, one or more modules / units are stored in memory and executed by a processor to complete this application.

[0130] Computer equipment can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. Computer equipment may include, but is not limited to, processors and memory.

[0131] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0132] Memory can be used to store computer programs and / or modules. The processor performs various functions of the computer device by running or executing the computer programs and / or modules stored in the memory, and by calling the data stored in the memory.

[0133] When modules / units integrated into a computer device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0134] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform... Figure 1 The methods provided are among the various optional methods available in the code, so they will not be elaborated upon here.

[0135] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0136] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0137] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0138] The methods and related apparatus provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The computer program instructions may be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, causing the instructions stored in the computer-readable storage medium to produce an article of manufacture including the instruction means, or to be transmitted via a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The instruction means is implemented in the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0139] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0140] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0141] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

[0142] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for verifying vulnerability versions, characterized in that, Includes the following steps: Vulnerability information is obtained from multiple heterogeneous sources, and the core elements of the vulnerability are extracted from the vulnerability information. The core elements are then formatted and verified to obtain structured vulnerability entries. Collect proof-of-concept code from known information. If it cannot be collected, locate the vulnerability code, generate proof-of-concept code, and then proceed with the following steps. If it can be collected, continue directly to the following steps: Automated verification of collected or generated proof-of-concept code, and recording of complete function call chains and system behavior during automated verification; Migrate the proof-of-concept code that was successfully automated to other versions of the software to determine the scope of the vulnerability's impact across different software versions.

2. The vulnerability version verification method according to claim 1, characterized in that, After extracting the core elements of the vulnerability from the vulnerability information, the process also includes: The core elements are selected according to a preset priority rule; The selected core elements are processed using preset conflict resolution rules.

3. The vulnerability version verification method according to claim 2, characterized in that, The preset conflict resolution rules include: For factual and definitional core elements: use the core elements corresponding to the highest priority vulnerability information currently available; For descriptive and analytical elements: the core elements corresponding to the vulnerability information that provides the most detailed technical information among the highest priority currently available; For the core elements of the version range affected by the vulnerability: obtain the core elements corresponding to all vulnerability information, calculate the union, and use the union as the corresponding core element; The core elements of proof-of-concept code: obtain the link to the proof-of-concept code or the core elements corresponding to the code from all vulnerability information.

4. The vulnerability version verification method according to claim 1, characterized in that, The method for locating vulnerable code includes: The vulnerability information is encoded, and the functions in the code library are encoded. The cosine similarity is calculated to obtain several candidate functions with the highest similarity, which are used as the vulnerability functions to be located. The function call graph of the program is constructed using the call graph analysis method to find all simple paths from the user input entry point to the located vulnerability function; Symbolic execution was performed on the identified vulnerable functions to extract the path constraints that triggered the vulnerabilities; Inputting path constraints as contextual information into a large language model generates proof-of-concept code. Perform syntax and semantic checks on the generated proof-of-concept code.

5. The vulnerability version verification method according to claim 1, characterized in that, The method for performing automated verification includes: Execute proof-of-concept code in an isolated environment and set up multi-dimensional monitoring; Execute proof-of-concept code within the container and collect execution evidence; Based on the multi-dimensional monitoring results and the collected execution evidence, determine whether the vulnerability exploitation was successful and store the execution trace information.

6. The vulnerability version verification method according to claim 1, characterized in that, The method for migrating the verification code to other versions of the software includes: Execute the validated proof-of-concept code on the reference version to build a tree representation of the reference execution path; By comparing the binary code of the reference version and the target version, function-level code changes are detected, and corresponding function pairs between the two versions are identified. The execution paths of the reference version and the target version are represented as a tree structure. The execution path tree of the reference version is matched with the potential execution path of the target version to obtain the cross-version path alignment result. Based on the cross-version path alignment results, the key variables accessed in the target execution path of the target version are identified. Based on the identified key variables, fuzz testing is used to iteratively mutate the original proof-of-concept code.

7. A vulnerability version verification system, characterized in that, include: A multi-source heterogeneous information fusion module is used to obtain vulnerability information from multiple heterogeneous sources, extract the core elements of the vulnerability from the vulnerability information, and then perform formatting and verification on the core elements to obtain structured vulnerability entries. The automatic proof-of-concept code generation module is used to collect proof-of-concept code from known information. If it cannot collect the code, it performs vulnerability code location to generate the proof-of-concept code before proceeding to the next steps. If the code can be collected, it directly continues to the next steps. Automated verification of collected or generated proof-of-concept code, and recording of complete function call chains and system behavior during automated verification; Migrate the proof-of-concept code that was successfully automated to other versions of the software to determine the scope of the vulnerability's impact across different software versions.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes computer instructions, a processor of a computer device reads the computer instructions, and the processor of the computer device executes the computer instructions to implement the steps of the method as described in any one of claims 1 to 6.

Images