Vulnerability analysis method based on large model, program product, equipment and medium

Abstract

The embodiment of the invention provides a vulnerability analysis method based on a large model, a program product, equipment and a medium. The method comprises the following steps: acquiring a code change record for any known vulnerability from a vulnerability information base; identifying a sensitive function of a known vulnerability introduced into a code change record by adopting a first large model; for each version of the code change record, comparing the code of the current version with the code of the known vulnerability and the code of the patch of the known vulnerability, and determining that the current version is a security version, a risk version or a repair version according to a comparison result; according to the determined repair version, searching an influence version of the known vulnerability in the version relation graph, and combining the determined risk version and the influence version to obtain an influenced version range; and determining that the analysis information of the known vulnerability comprises a sensitive function, a determined repair version and an affected version range. According to the embodiment of the invention, the vulnerability information of various vulnerabilities in the open source software can be accurately analyzed.

Description

Technical Field

[0001] This application relates to the field of software security technology, and more specifically, to a vulnerability analysis method, program product, device, and medium based on a large model. Background Technology

[0002] In recent years, an increasing number of enterprise development teams have adopted various open-source components to develop software. While this can reduce a lot of basic work and improve development efficiency, the widespread use of open-source software also exposes systems that use it to risks if vulnerabilities are disclosed in open-source components. These vulnerabilities may not be promptly patched or may exist in private branches. Summary of the Invention

[0003] The purpose of this application is to provide a vulnerability analysis method, program product, device, and medium based on a large model, so as to achieve the technical effect of accurately analyzing vulnerability information of various vulnerabilities in open source software.

[0004] In a first aspect, embodiments of this application provide a vulnerability analysis method based on a large model, including: Retrieve code change records for any known vulnerability from the vulnerability database; The first major model is used to identify sensitive functions in the code change log that introduce the known vulnerability; For each version of the code change record, the current version's code is compared with the code of the known vulnerability and the code of the patch for the known vulnerability, and the category of the current version is determined based on the comparison result; wherein, the category is a secure version, a risky version, or a patched version; Based on the identified patch version, the affected versions of the known vulnerability are located in the version relationship graph. The range of affected versions is obtained by combining the identified risk version and the affected version. The version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository. The analytical information for identifying the known vulnerability includes the sensitive function, the identified patch version, and the range of affected versions.

[0005] In the above implementation process, code change records for any known vulnerability are obtained from the vulnerability information database. The first major model is used to identify the sensitive functions that introduce the known vulnerability in the code change records. For each version of the code change record, the current version's code is compared with the code of the known vulnerability and the code of the patch for the known vulnerability. Based on the comparison results, the current version is determined to be a secure version, a risky version, or a patched version. Based on the determined patched version, the affected versions of the known vulnerability are found in the version relationship graph. Combining the determined risky version and the affected version, the range of affected versions is obtained. The analysis information of the known vulnerability includes the sensitive function, the determined patched version, and the range of affected versions. The first major model can be used to accurately analyze the introduction location of the known vulnerability. Based on the code of the known vulnerability and its patch, the risky version and patched version affected by the known vulnerability in the code change record are analyzed in depth. The affected versions of the known vulnerability on other code branches in the version relationship graph besides the code change record are also considered to fully analyze the range of affected versions of the known vulnerability, thereby achieving accurate analysis of vulnerability information of various vulnerabilities in open source software.

[0006] Furthermore, the method also includes: Extract raw vulnerability information for each known vulnerability from multiple vulnerability intelligence sources; The original vulnerability information of each known vulnerability is preprocessed to obtain the target vulnerability information of each known vulnerability; The target vulnerability information of each known vulnerability is stored in a database to obtain the vulnerability information database.

[0007] In the above implementation process, the original vulnerability information of each known vulnerability is captured from multiple vulnerability intelligence sources, the original vulnerability information of each known vulnerability is preprocessed to obtain the target vulnerability information of each known vulnerability, and the target vulnerability information of each known vulnerability is stored in the database to obtain the vulnerability information database. This can gather vulnerability information of multiple known vulnerabilities from multiple vulnerability intelligence sources, which is beneficial to increasing the data volume of the vulnerability information database.

[0008] Further, the preprocessing of the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability includes: By combining the real-time data stream processing component and the second major model, the original vulnerability information of each known vulnerability is aggregated to obtain the first vulnerability information of each known vulnerability; The third model is used to infer missing information based on the first vulnerability information of each known vulnerability, and to generate the second vulnerability information of each known vulnerability. The target vulnerability information for each known vulnerability is determined to include the first vulnerability information and the second vulnerability information for each known vulnerability.

[0009] In the above implementation process, by combining the real-time data stream processing component and the second major model to aggregate the original vulnerability information of each known vulnerability, the first vulnerability information of each known vulnerability is obtained. The third major model is used to infer the missing information based on the first vulnerability information of each known vulnerability to generate the second vulnerability information of each known vulnerability. The target vulnerability information of each known vulnerability is determined to include the first vulnerability information and the second vulnerability information of each known vulnerability. The second major model can accurately aggregate the vulnerability information of the same known vulnerability from multiple data sources, and the third major model can accurately fill in the missing vulnerability information of known vulnerabilities, which is conducive to improving the data quality of the vulnerability information database.

[0010] Furthermore, before comparing the current version of the code with the code of the patch for the known vulnerability for each version of the code change record, and determining whether the current version is a patched version based on the comparison result, the method further includes: Based on the version relationship diagram, determine the baseline version of the code change record; Starting from the baseline version, traverse the version range of the code change record, compare the code structure of two adjacent versions of the code change record, and determine the patch.

[0011] In the above implementation process, by determining the baseline version of the code change record based on the version relationship graph, traversing the version range of the code change record starting from the baseline version, comparing the code structure of two adjacent versions of the code change record, and determining the patch, it is possible to comprehensively detect the code differences between each version of the code change record and ensure accurate identification of patches for known vulnerabilities.

[0012] Further, the step of comparing the current version of the code with the code containing the known vulnerability and the code patched for the known vulnerability, and determining the category of the current version based on the comparison result, includes: The code text of the current version is compared with the code text of the known vulnerability to obtain the code text similarity. If the code text similarity is less than the code text similarity threshold, then the current version is determined to be a secure version; If the code text similarity is greater than or equal to the code text similarity threshold, then the code structure of the current version and the code structure of the patch are compared to obtain a first code structure similarity. If the first code structure similarity is greater than or equal to the code structure similarity threshold, then the fourth model is used to compare the code semantics of the current version and the code semantics of the patch to obtain the code semantic similarity. If the first code structure similarity is less than the code structure similarity threshold or the code semantic similarity is less than the code semantic similarity threshold, then the current version is determined to be a risky version; If the code semantic similarity is greater than or equal to the code semantic similarity threshold, then the current version is determined to be a fixed version.

[0013] In the above implementation process, by adopting a multi-level comparison method based on code text similarity threshold, code structure similarity threshold, and code semantic similarity threshold, the category of each version of the code change record is determined by comparing the code of each version with the code of known vulnerabilities and their patches. This can determine the category of each version of the code change record more quickly and accurately.

[0014] Furthermore, the step of searching for the affected versions of the known vulnerability in the version relationship graph based on the determined patch version includes: Extract the code fingerprint of the patch from the identified fix version; A pre-selected version is determined from the version relationship graph; wherein the code fingerprint of the pre-selected version matches the code fingerprint of the patch; The code of the pre-selected version and the code of the patch are compared, and the pre-selected version is determined to be the affected version based on the comparison results.

[0015] In the above implementation process, by extracting the code fingerprint of the patch from the determined repair version, filtering the version whose code fingerprint matches the code fingerprint of the patch from the version relationship graph as a pre-selected version, comparing the code of the pre-selected version with the code of the patch, and determining whether the pre-selected version is an affected version based on the comparison results, it is possible to first pre-select the pre-selected version that may be affected by known vulnerabilities from the version relationship graph based on the code fingerprint of the patch, and then further analyze whether the pre-selected version is affected by known vulnerabilities and whether it is an affected version based on the code of the patch. This allows for a faster and more accurate search for affected versions on other code branches in the version relationship graph besides the code change record.

[0016] Furthermore, the step of searching for the affected versions of the known vulnerability in the version relationship graph based on the determined patch version includes: Find the successor version of the repaired version in the version relationship graph; By comparing the code structure of the subsequent version with the code structure of the patch, a second code structure similarity is obtained; If the second code structure similarity is greater than or equal to the code structure similarity threshold, then the subsequent version is determined to be the affected version.

[0017] In the above implementation process, by finding the successor version of the patch version in the version relationship graph, comparing the code structure of the successor version with the code structure of the patch, a second code structure similarity is obtained. If the second code structure similarity is greater than or equal to the code structure similarity threshold, the successor version is determined to be the affected version. This can take into account the special case of regression vulnerabilities and ensure a complete analysis of the affected version range of known vulnerabilities.

[0018] Furthermore, the method also includes: In the event of an unknown vulnerability being detected, the fifth model is used to search for a target patch version that matches the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability; Based on the pull request associated with the target patch version or multiple predecessor versions of the target patch version in the version relationship diagram, construct the patching chain for the unknown vulnerability.

[0019] In the above implementation process, when an unknown vulnerability is detected, the fifth model is used to search for a target patch version that matches the unknown vulnerability in the vulnerability information database based on the vulnerability description information of the unknown vulnerability. Based on the pull request associated with the target patch version or multiple predecessor versions of the target patch version in the version relationship graph, a patching link for the unknown vulnerability is constructed. The fifth model can be used to infer the complete patching link for the unknown vulnerability based on the information in the vulnerability information database, thereby achieving accurate analysis of vulnerability information of unknown vulnerabilities in open source software.

[0020] Furthermore, the step of using the fifth major model to search for a target patch version matching the unknown vulnerability from the vulnerability information database based on the vulnerability description information includes: The fifth major model is used to search for target code change records that match the unknown vulnerability in the vulnerability information database; Determine the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information; The version with the highest semantic similarity is determined as the target repair version.

[0021] In the above implementation process, by using the fifth model to search for target code change records that match unknown vulnerabilities in the vulnerability information database, the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information is determined, and the version corresponding to the highest semantic similarity is determined as the target patch version, which can more accurately determine the target patch version.

[0022] Secondly, embodiments of this application provide a vulnerability analysis device based on a large model, comprising: The code change record acquisition module is used to retrieve code change records for any known vulnerability from the vulnerability information database; The sensitive function identification module is used to identify the sensitive functions in the code change record that introduce the known vulnerability using the first major model; The version category determination module is used to compare the current version's code with the code of the known vulnerability and the code of the patch for the known vulnerability for each version in the code change record, and determine the category of the current version based on the comparison result; wherein, the category is a secure version, a risky version, or a patched version; The affected version merging module is used to find the affected versions of the known vulnerability in the version relationship graph based on the determined patched version, and to obtain the range of affected versions by combining the determined risk version and the affected version; wherein, the version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository; The vulnerability information processing module is used to determine the analysis information of the known vulnerability, including the sensitive function, the determined patch version, and the range of affected versions.

[0023] Thirdly, embodiments of this application provide a computer program product, the computer program product including instructions, which, when executed by a computer, cause the computer to perform the method described above.

[0024] Fourthly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method described above.

[0025] Fifthly, embodiments of this application provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program; wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method described above. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application 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.

[0027] Figure 1 A flowchart illustrating a vulnerability analysis method based on a large model, provided for the first embodiment of this application; Figure 2This is a schematic diagram illustrating a process for establishing a vulnerability information database, as exemplified by the first embodiment of this application. Figure 3 A schematic diagram of a vulnerability analysis device based on a large model provided for the second embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0029] It should be noted that similar reference numerals 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. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] In recent years, an increasing number of enterprise development teams have adopted various open-source components to develop software. While this can reduce a lot of basic work and improve development efficiency, the widespread use of open-source software also exposes systems that use it to risks if vulnerabilities are disclosed in open-source components. These vulnerabilities may not be promptly patched or may exist in private branches.

[0031] Although multiple vulnerability intelligence sources have announced numerous known vulnerabilities, the vulnerability information for many of these vulnerabilities is only a rough description, and there may be contradictions in the vulnerability information for the same known vulnerability from different vulnerability intelligence sources. This makes it difficult to accurately analyze the vulnerability information such as the location of each known vulnerability in the open-source software, the patching nodes, and the range of affected versions.

[0032] To address this, this application proposes a vulnerability analysis method based on a large model. This method retrieves code change records for any known vulnerability from a vulnerability database and uses a first large model to identify sensitive functions that introduce the known vulnerability into the code change records. For each version of the code change record, the current version's code is compared with the code containing the known vulnerability and the code of the patch for that vulnerability. Based on the comparison results, the current version is determined to be a secure version, a risky version, or a patched version. Based on the identified patched version, the affected versions of the known vulnerability are located in the version relationship graph. Combining the identified risky and affected versions, the range of affected versions is obtained. The analysis information for the known vulnerability includes sensitive functions, identified patched versions, and the range of affected versions. This method utilizes the first large model to accurately analyze the location where the known vulnerability was introduced. It also deeply analyzes the risky and patched versions affected by the known vulnerability in the code change records based on the known vulnerability and its patch code, and considers the affected versions of the known vulnerability on other code branches in the version relationship graph besides the code change records, thus comprehensively analyzing the range of affected versions of the known vulnerability. This allows for precise analysis of vulnerability information for various vulnerabilities in open-source software.

[0033] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0034] The following is combined Figure 1 This application describes a vulnerability analysis method based on a large model. The method provided in this application can be executed by relevant terminal devices; the following description uses a user terminal as the execution subject.

[0035] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a vulnerability analysis method based on a large model, provided in the first embodiment of this application. The first embodiment of this application provides a vulnerability analysis method based on a large model, including steps S101-S103: S101. Obtain the code change records for any known vulnerability from the vulnerability information database.

[0036] As an example, based on actual application needs, vulnerability information of multiple known vulnerabilities is collected in advance to establish a vulnerability information database.

[0037] In practical applications, the vulnerability database stores vulnerability information for multiple known vulnerabilities, and the vulnerability information for each known vulnerability includes links to code change records, etc.

[0038] Retrieve code change records for any known vulnerability from the vulnerability database.

[0039] It should be noted that the code change log, or commit, refers to a snapshot that contains the code changes.

[0040] S102. Use the first major model to identify sensitive functions with known vulnerabilities introduced in the code change record.

[0041] As an example, after obtaining the code change log of the known vulnerability, a pre-established first large model is used to identify the sensitive functions in the code change log that introduce the known vulnerability.

[0042] Large models refer to large-scale artificial intelligence models. In practical applications, a Large Language Model (LLM) can be chosen as the primary large model. A large language model is a deep learning model trained on a large amount of text data, enabling it to generate natural language text or understand the meaning of language text. These models can perform various language tasks by being trained on massive datasets.

[0043] By employing the first major model to identify the sensitive functions in the code change log that introduced the known vulnerability, accurate identification of sensitive functions can be guaranteed.

[0044] S103. For each version in the code change log, compare the current version of the code with the code containing known vulnerabilities and the code containing patches for known vulnerabilities, and determine the category of the current version based on the comparison results; wherein, the category is a secure version, a risky version, or a patched version.

[0045] As an example, in real-world scenarios, there may be multiple code changes made to address new requirements or features, or multiple code changes made to address a single known vulnerability, and the code change log may have multiple versions.

[0046] For this reason, a patch for the known vulnerability is determined. For each version of the code change record, the current version's code is compared with the code of the known vulnerability and the code of the patch. The comparison results are used to determine the category of the current version, that is, whether the current version is a secure version, a risky version, or a patched version.

[0047] By comparing the code of each version of the code change record with the code of the known vulnerability and its patch, we can conduct in-depth analysis based on the code of the known vulnerability and its patch to determine whether each version of the code change record contains the known vulnerability, whether it contains a patch that can fix the known vulnerability, and so on, so as to accurately determine the category of each version of the code change record.

[0048] S104. Based on the identified patch version, find the affected versions of known vulnerabilities in the version relationship graph, and combine the identified risk version and affected version to obtain the range of affected versions; wherein, the version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository.

[0049] As an example, a version relationship diagram is pre-built based on the inheritance relationship between multiple version tags in the code repository of the open source software.

[0050] It's important to note that version tags, or tags, point to a single commit. In practice, however, multiple tags may point to the same commit.

[0051] After determining the categories of each version in the code change log, any of the following scenarios exist: a secure version is identified; a secure and risky version is identified; a secure and patched version is identified; a secure, risky, and patched version is identified; a risky version is identified; a risky and patched version is identified; a patched version is identified.

[0052] In practical applications, multiple code changes may be made to fix a single known vulnerability. Therefore, in this scenario, the multiple versions of the code change record usually include the risky version and the fixed version.

[0053] Once the risky and patched versions are identified, the affected versions of the known vulnerability are located in the version relationship graph based on the identified patched version. By combining the identified risky version and the found affected version, the range of affected versions is obtained.

[0054] By identifying the affected versions in the version relationship graph (excluding the code change record) based on the identified patch version, we can ensure a complete and accurate determination of the range of versions affected by the known vulnerability.

[0055] S105. Identify known vulnerability analysis information, including sensitive functions, identified patch versions, and the range of affected versions.

[0056] As an example, after obtaining the sensitive function, the identified patch version, and the affected version range, the analysis information for the known vulnerability is determined to include the sensitive function, the identified patch version, and the affected version range. This allows users to conduct subsequent application research based on the analysis information of the known vulnerability, such as analyzing the root cause of the known vulnerability, detecting the taint propagation chain, evaluating the effectiveness of the patch, and assessing software supply chain risks.

[0057] This application embodiment obtains code change records for any known vulnerability from a vulnerability information database, uses a first major model to identify sensitive functions that introduce known vulnerabilities into the code change records, and compares the current version's code with the code of the known vulnerability and the code of the patch for the known vulnerability for each version of the code change record. Based on the comparison results, the current version is determined to be a secure version, a risky version, or a patched version. Based on the determined patched version, the affected versions of the known vulnerability are found in the version relationship graph. Combining the determined risky version and the affected version, the range of affected versions is obtained. The analysis information of the known vulnerability includes sensitive functions, determined patched versions, and the range of affected versions. It can use the first major model to accurately analyze the introduction location of the known vulnerability, and deeply analyze the risky versions and patched versions affected by the known vulnerability in the code change records based on the code of the known vulnerability and its patch. It also considers the affected versions of the known vulnerability on other code branches in the version relationship graph besides the code change records to completely analyze the range of affected versions of the known vulnerability, thereby achieving accurate analysis of vulnerability information of various vulnerabilities in open source software.

[0058] In an optional embodiment, the method further includes steps S106-S108: S106. Extract the original vulnerability information of each known vulnerability from multiple vulnerability intelligence sources.

[0059] As an example, multiple vulnerability intelligence sources can be selected based on actual application requirements, such as... Figure 2 As shown, the following options are selected: CNNVD (China National Vulnerability Database of Information Security, a national information security vulnerability database built and maintained by the China Information Security Evaluation Center), NVD (National Vulnerability Database, a comprehensive vulnerability database maintained by the National Institute of Standards and Technology in the United States), CVE.org (the official website of the Common Vulnerabilities and Exposures (CVE) project, used to publicly disclose vulnerabilities and provide a unique number (CVE number) for all publicly disclosed vulnerabilities), GitHub Advisory (a security bulletin service platform provided by GitHub), and Snyk (a service platform specifically for security assessment of open source components).

[0060] Web crawling tools were used to extract raw vulnerability information for each known vulnerability from multiple vulnerability intelligence sources.

[0061] For example, an Airflow-based timed crawler scheduler can be built to perform 24-hour incremental synchronization of vulnerability intelligence sources such as CNNVD, NVD, CVE.org, GitHubAdvisory, and Snyk. The original vulnerability information of each known vulnerability captured is stored in databases in JSON, XML, and RSS formats, stored as objects, and timestamped to achieve a traceable snapshot version. The crawler can use ETag / Last-Modified headers to avoid duplicate crawling and a Bloom filter for fast deduplication to prevent the crawling of duplicate information.

[0062] S107. Preprocess the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability.

[0063] After obtaining the original vulnerability information of each known vulnerability, the original vulnerability information of each known vulnerability is preprocessed such as deduplication and normalization to obtain the target vulnerability information of each known vulnerability.

[0064] S108. Store the target vulnerability information of each known vulnerability in the database to obtain the vulnerability information database.

[0065] As an example, after obtaining the target vulnerability information of each known vulnerability, the target vulnerability information of each known vulnerability is stored in a database to obtain a vulnerability information database.

[0066] If new raw vulnerability information of known vulnerabilities is subsequently captured from multiple vulnerability intelligence sources, and the raw vulnerability information of the new known vulnerabilities is preprocessed to obtain the target vulnerability information of the new known vulnerabilities, then the target vulnerability information of the new known vulnerabilities can be directly stored in the vulnerability information database to update the vulnerability information database.

[0067] In practical applications, the target vulnerability information of each known vulnerability can be transformed into structured data and stored in a database.

[0068] This application embodiment captures the original vulnerability information of each known vulnerability from multiple vulnerability intelligence sources, preprocesses the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability, and stores the target vulnerability information of each known vulnerability in a database to obtain a vulnerability information database. This can gather vulnerability information of multiple known vulnerabilities from multiple vulnerability intelligence sources, which is beneficial to increasing the data volume of the vulnerability information database.

[0069] In an optional embodiment, the preprocessing of the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability includes: combining the real-time data stream processing component and the second major model to aggregate the original vulnerability information of each known vulnerability to obtain the first vulnerability information of each known vulnerability; using the third major model to infer missing information based on the first vulnerability information of each known vulnerability to generate the second vulnerability information of each known vulnerability; and determining that the target vulnerability information of each known vulnerability includes the first vulnerability information and the second vulnerability information of each known vulnerability.

[0070] As an example, after obtaining the original vulnerability information of each known vulnerability, the original vulnerability information of each known vulnerability is aggregated by combining the real-time data stream processing component and the pre-established second large model to obtain the first vulnerability information of each known vulnerability.

[0071] In practical applications, real-time data stream processing components, such as Spark Streaming, can be used within the data lake where the original vulnerability information of each known vulnerability resides to fuse the original vulnerability information in real time. A pre-established second-largest model is then used to perform contextual understanding and reasoning on the original vulnerability information of each known vulnerability, taking into account factors such as data source, semantic overlap, and timestamp consistency. Original vulnerability information with similar semantics is then fused to obtain the first vulnerability information for each known vulnerability. The specific process of information aggregation can be as follows: 1. Spark Streaming uses a pre-configured YAML mapping template (a YAML mapping template is a configuration template based on YAML format used to define data structures), such as "cwe_id" ↔ "weaknesses", to transform the different source fields into a unified schema (a schema is a definition of data structure and organization, used to describe the format, type, fields and relationships of data). 2. The second major model is used to vectorize the vulnerability description information of each known vulnerability. By calculating the semantic similarity of the text and the consistency of the vulnerability context, the automatic fusion of entries with highly similar vulnerability description information (e.g., similarity ≥ 90%) under the software identifier triple "{vendor, product, version}" is achieved. 3. Generate a vulnerability identifier ID = SHA-256(vendor|product|baseline_cve), which will serve as the primary key for subsequent indexing; 4. Use the component library to uniformly abstract component metadata, parse and compare package information and version dependencies of mainstream ecosystems such as Maven / NPM / PyPI, and establish a reverse index of "known vulnerability → affected package → address of the code repository"; 5. Compile the first vulnerability information for each known vulnerability.

[0072] After obtaining the first vulnerability information for each known vulnerability, a pre-established third model is used to infer the missing information based on the first vulnerability information for each known vulnerability, and generate the second vulnerability information for each known vulnerability.

[0073] In practical applications, the Llama-3-70B dedicated fine-tuning model can be selected as the third major model. The specific process of information reasoning can be as follows: 1. Entity Extraction: Automatically labels known vulnerabilities with key information such as vulnerability type (e.g., CWE), function name, and protocol; 2. Relationship Reasoning: Determine the "known vulnerability-patch" reference relationship and complete the missing patch links; 3. Risk Scoring: For events without CVSS (Common Vulnerability Scoring System) vectors, supplement them with eight basic indicators according to CVSS 3.1 rules: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I), and Availability (A). In this context, AV represents the access path required for an attacker to exploit a vulnerability. The values ​​of AV can be described in the following ways: Network (N): The attack can be carried out remotely through a network, such as the Internet, which poses the highest risk; Adjacent (A): The attack needs to be in an adjacent network, such as the same subnet or within Bluetooth range; Local (L): The attack requires local access to the target system, such as a local account or physical access; Physical (P): The attacker needs to physically touch or directly access the device, which poses the lowest risk.

[0074] AC represents the additional conditions required by an attacker to exploit a vulnerability. The values ​​of AC can be described in several ways: Low (L): The attack does not depend on special conditions and is easy to implement; High (H): Exploiting the vulnerability requires complex conditions or environmental dependencies, such as specific configurations, race conditions, etc.

[0075] PR indicates the level of privileges an attacker needs before launching an attack. The main PR values ​​are as follows: None (N): No privileges are required, such as anonymous users; Low (L): Low-privilege users are required, such as ordinary user privileges; High (H): High-privilege accounts are required, such as administrators, root, etc.

[0076] The UI indicates whether user intervention is required, such as clicking a link or opening a file. The UI values ​​are mainly described as follows: None (N): The attack does not require any user interaction; Required (R): User action is required to trigger the vulnerability.

[0077] S indicates whether the vulnerability affects different privilege boundaries, such as from the user layer to the kernel layer. The values ​​of S are mainly described as follows: Unchanged (U): The scope of the vulnerability is limited to the same security boundary; Changed (C): The vulnerability causes the privilege boundary to change, such as affecting components with higher privileges.

[0078] It should be noted that the value of PR will be affected by the value of S (the weight will be adjusted during the scoring).

[0079] C represents the degree of impact of the vulnerability on information confidentiality. The values ​​of S are mainly described as follows: None (N): No information is leaked; Low (L): Limited information is leaked, with a small impact; High (H): Sensitive information is completely leaked, with a serious impact.

[0080] I represents the degree of impact of the vulnerability on data integrity. The values ​​of I are mainly described as follows: None (N): No data tampering; Low (L): Limited tampering of some data is possible; High (H): Critical data can be completely tampered with, seriously affecting trustworthiness.

[0081] A represents the impact of the vulnerability on system availability. The values ​​of A are mainly described as follows: None (N): No impact; Low (L): May cause some functions to degrade or services to slow down; High (H): May cause the system service to be completely interrupted.

[0082] For example, suppose the basic metrics score of a remote code execution vulnerability is as shown in Table 1. Based on the basic metrics score of the vulnerability, the CVSS score of the vulnerability is calculated to be 10.0. Usually, the CVSS score of a critical vulnerability will reach 9.8 or 10.0, which indicates that this is a very critical vulnerability.

[0083] Table 1

[0084] 4. The processing results are stored in the Faiss vector library and written to two databases, MySQL and Elasticsearch, respectively, to create structured indexes and full-text indexes to support vulnerability queries and fast matching.

[0085] After obtaining the first and second vulnerability information for each known vulnerability, the target vulnerability information for each known vulnerability is determined, including the first and second vulnerability information for each known vulnerability.

[0086] For example, the final vulnerability information database includes the vulnerability name, vulnerability type, exploitation method, attack time, vulnerability identifier, corresponding affected package, code repository address, commit link, patch link, and risk score for each known vulnerability.

[0087] This application embodiment combines a real-time data stream processing component and a second major model to aggregate the original vulnerability information of each known vulnerability, obtaining the first vulnerability information of each known vulnerability. The third major model then uses the first vulnerability information of each known vulnerability to infer missing information and generate the second vulnerability information of each known vulnerability. The target vulnerability information of each known vulnerability is determined to include both the first vulnerability information and the second vulnerability information of each known vulnerability. This approach can accurately aggregate vulnerability information of the same known vulnerability from multiple data sources using the second major model and accurately complete the missing vulnerability information of known vulnerabilities using the third major model, which is beneficial to improving the data quality of the vulnerability information database.

[0088] In an optional embodiment, before comparing the current version of the code with the code of the known vulnerability and the code of the patch for the known vulnerability for each version of the code change record, and determining the category of the current version based on the comparison result, the method further includes: determining the baseline version of the code change record based on the version relationship diagram; traversing the version range of the code change record starting from the baseline version, comparing the code structure of two adjacent versions of the code change record, and determining the patch.

[0089] As an example, a version relationship diagram is pre-built based on the inheritance relationship between multiple version tags in the code repository of the open source software.

[0090] In practical applications, nodes in the version relationship graph are used to indicate versions that conform to the version number management specification, such as the version tag of SemVer. Directed edges in the version relationship graph are used to indicate the inheritance relationship between two connected version tags. For example, if there is "node P1→node P2" in the version relationship graph, it means that the version tag tag1 indicated by node P1, which is version V1, is the version tag tag2 indicated by node P2, which is the predecessor of version V2. Version V2 is the successor of version V1. Nodes carry version status attributes to indicate unknown status, risky status, or fix status. Edges carry commit span attributes to implement performance pruning.

[0091] Based on the version relationship diagram, determine the version range of the code change record, and then determine the baseline version of the code change record based on the version range of the code change record.

[0092] In practical applications, the FindCommitInterval algorithm can be called to locate the version range (tag_prev, tag_next) of the code change record in the version relationship graph. If tag_prev == ∅, the first version tag in the version range is taken as the upper bound of the risk; tag_prev is recorded as T_base, which is the baseline version of the code change record.

[0093] Starting from the baseline version, iterate through the version range of the code change record, compare the code structure of the baseline version with the code structure of the subsequent versions of the baseline version, compare the code structure of the subsequent versions with the code structure of the subsequent versions of the subsequent versions, and so on, until the code structure of the second to last version in the version range is compared with the code structure of the last version, to find the actual vulnerability modification, thereby determining the patch for the known vulnerability.

[0094] In practical applications, the code structure of each version of this code change record can be transformed into a code structure tree. For example, for each version of this code change record, the smallest code modification block of the current version, i.e., hunk, is determined. According to the pre-configured code line number-abstract syntax tree (AST) node mapping table, the AST node corresponding to the code line number of each hunk is determined. The AST of the current version, i.e., the code structure tree, is then built based on the determined AST nodes.

[0095] This application embodiment determines the baseline version of the code change record based on the version relationship diagram, traverses the version range of the code change record starting from the baseline version, compares the code structure of two adjacent versions of the code change record, and determines the patch. This can comprehensively detect the code differences between the various versions of the code change record and ensure accurate identification of patches for known vulnerabilities.

[0096] In an optional embodiment, comparing the current version's code with the code of known vulnerabilities and the code of patches for known vulnerabilities, and determining the category of the current version based on the comparison results, includes: comparing the code text of the current version with the code text of known vulnerabilities to obtain code text similarity; if the code text similarity is less than a code text similarity threshold, then the current version is determined to be a secure version; if the code text similarity is greater than or equal to the code text similarity threshold, then comparing the code structure of the current version with the code structure of the patches to obtain a first code structure similarity; if the first code structure similarity is greater than or equal to the code structure similarity threshold, then using a fourth model to compare the code semantics of the current version with the code semantics of the patches to obtain code semantic similarity; if the first code structure similarity is less than the code structure similarity threshold or the code semantic similarity is less than the code semantic similarity threshold, then the current version is determined to be a risky version; if the code semantic similarity is greater than or equal to the code semantic similarity threshold, then the current version is determined to be a patched version.

[0097] As an example, after obtaining each version of the code change record, for each version i of the code change record, firstly, the code text of the current version i is compared with the code text of the known vulnerability to obtain the code text similarity S_CODE(i) between the code text of the current version i and the code text of the known vulnerability. This code text similarity S_CODE(i) is then compared with a pre-set code text similarity threshold θ1. If the code text similarity S_CODE(i) is less than the code text similarity threshold θ1, then the current version i is considered not to contain the known vulnerability and is considered a secure version. If the code text similarity S_CODE(i) is greater than or equal to the code text similarity threshold θ1, then the current version i is considered to contain the known vulnerability. Next, the code structure of the current version i is compared with the code structure of the patch P_core of the known vulnerability to obtain the first code structure similarity S_AST(i) between the code structure of the current version i and the code structure of the patch P_core. This first code structure similarity S_AST(i) is then compared with a pre-set code structure similarity threshold θ2. If the first code structure similarity S_AST(i) is less than the code structure similarity threshold θ2, then the current version i is considered to contain the known vulnerability but not the patch P_core, and the current version i is a risky version. If the first code structure similarity S_AST(i) is greater than or equal to the code structure similarity threshold θ2, then the pre-established fourth model is used to compare the code semantics of the current version i with the code semantics of the patch P_core to obtain the code semantic similarity S_LLM(i) between the code semantics of the current version i and the code semantics of the patch P_core. The code semantic similarity S_LLM(i) is compared with the pre-set code semantic similarity threshold θ3. If the code semantic similarity S_LLM(i) is less than the code semantic similarity threshold θ3, then the current version i is considered to contain the known vulnerability but not the patch P_core, and the current version i is a risky version. If the code semantic similarity S_LLM(i) is greater than or equal to the code semantic similarity threshold θ3, then the current version i is considered to contain both the known vulnerability and the patch P_core, and the current version i is a patched version.

[0098] At this point, we can determine the category of each version in the code change log, that is, whether it is a secure version, a risky version, or a patch version.

[0099] In practical applications, regular expressions can be used to match the code text of the current version i with the code text of the known vulnerability to determine whether the code text of the current version i and the code text of the known vulnerability are the same.

[0100] This application's embodiments employ a multi-level comparison method based on code text similarity thresholds, code structure similarity thresholds, and code semantic similarity thresholds. By comparing the code of each version in the code change record with the code of known vulnerabilities and their patches, the category of each version can be determined more quickly and accurately.

[0101] In an optional embodiment, the step of searching for the affected version of a known vulnerability in the version relationship graph based on the determined patch version includes: extracting the code fingerprint of the patch from the determined patch version; determining a pre-selected version from the version relationship graph; wherein the code fingerprint of the pre-selected version matches the code fingerprint of the patch; comparing the code of the pre-selected version with the code of the patch, and determining whether the pre-selected version is an affected version based on the comparison result.

[0102] As an example, after the patch version is determined, the code fingerprint H_patch of the patch P_core is extracted from the determined patch version.

[0103] In practical applications, the code fingerprint H_patch of patch P_core can be obtained by calculating the hash value of patch P_core.

[0104] Versions whose code fingerprints match the code fingerprint of patch P_core are selected from the version relationship graph as pre-selected versions.

[0105] In practical applications, a Bloom filter can be used to select versions from the version relationship graph whose code fingerprints match the code fingerprint of the patch P_core as pre-selected versions.

[0106] Compare the code of the pre-selected version with the code of the patch P_core to obtain the comparison results, and determine whether the pre-selected version is an affected version based on the comparison results.

[0107] In practical applications, the process described above for comparing the code of each version in the code change record with the code of the patch P_core can be referenced. A comparison method based on code structure similarity threshold and code semantic similarity threshold can be used to compare the code of the pre-selected version with the code of the patch P_core to obtain the comparison results.

[0108] Specifically, the code structure of the pre-selected version is first compared with the code structure of the patch P_core to obtain the third code structure similarity between the two. This third code structure similarity is then compared with a pre-set code structure similarity threshold θ2. If the third code structure similarity is less than the threshold θ2, the pre-selected version is considered to contain the known vulnerability but not the patch P_core; therefore, it is considered a risky version affected by the known vulnerability. If the third code structure similarity is greater than or equal to the threshold θ2, then a pre-established fourth model is used to compare the code semantics of the pre-selected version with those of the patch P_core. The code semantics of the core are used to obtain the code semantic similarity between the code semantics of the pre-selected version and the code semantics of the patch P_core. This code semantic similarity is compared with a pre-set code semantic similarity threshold θ3. If the code semantic similarity is less than the code semantic similarity threshold θ3, the pre-selected version is considered to contain the known vulnerability but not the patch P_core. The pre-selected version is considered a risky version, affected by the known vulnerability, and is thus determined to be an affected version. If the code semantic similarity is greater than or equal to the code semantic similarity threshold θ3, the pre-selected version is considered to contain both the known vulnerability and the patch P_core. The pre-selected version is considered a patched version, no longer affected by the known vulnerability, and is thus determined to be an unaffected version.

[0109] This application embodiment extracts the code fingerprint of the patch from the determined repair version, selects versions whose code fingerprints match the code fingerprints of the patch from the version relationship graph as pre-selected versions, compares the code of the pre-selected version with the code of the patch, and determines whether the pre-selected version is an affected version based on the comparison results. It can first pre-select pre-selected versions that may be affected by known vulnerabilities from the version relationship graph based on the code fingerprint of the patch, and then further analyze whether the pre-selected version is affected by known vulnerabilities and whether it is an affected version based on the code of the patch. This allows for a faster and more accurate search for affected versions on other code branches in the version relationship graph besides code change records.

[0110] In an optional embodiment, the step of searching for the affected version of a known vulnerability in the version relationship graph based on the determined patch version includes: searching for the successor version of the patch version in the version relationship graph; comparing the code structure of the successor version with the code structure of the patch to obtain a second code structure similarity; if the second code structure similarity is greater than or equal to the code structure similarity threshold, then the successor version is determined to be the affected version.

[0111] As an example, after determining the patch version, the successor version j of the patch version is found in the version relationship graph. The code structure of the successor version j is compared with the code structure of the patch P_core to obtain the second code structure similarity S_AST(j) between the code structure of the successor version j and the code structure of the patch P_core. The second code structure similarity S_AST(j) is compared with the pre-set code structure similarity threshold θ2. If the second code structure similarity S_AST(j) is greater than or equal to the code structure similarity threshold θ2, it is considered that the patch in the successor version introduced a new vulnerability when patching the known vulnerability, and there is a regression vulnerability. The successor version j is also affected by the known vulnerability. At this time, the successor version j is determined to be an affected version. If the second code structure similarity S_AST(j) is less than the code structure similarity threshold θ2, it is considered that the patch in the successor version did not introduce a new vulnerability when patching the known vulnerability, and there is no regression vulnerability. The successor version j is not affected by the known vulnerability. At this time, the successor version j is determined not to be an affected version.

[0112] In practical applications, if it is determined that the subsequent version j is the affected version, the fields such as regressed_from and regressed_to in the subsequent version j can also be recorded to generate a vulnerability remediation report.

[0113] This application embodiment finds the successor version of the patched version in the version relationship graph, compares the code structure of the successor version with the code structure of the patch, and obtains a second code structure similarity. If the second code structure similarity is greater than or equal to the code structure similarity threshold, the successor version is determined to be the affected version. This can take into account the special case of regression vulnerabilities and ensure a complete analysis of the affected version range of known vulnerabilities.

[0114] In an optional embodiment, the method further includes steps S109-S110: S109. In the event of an unknown vulnerability being detected, the fifth model is used to search for a target patch version that matches the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability.

[0115] As an example, when an unknown vulnerability is detected, the vulnerability description information of the unknown vulnerability is obtained, and a pre-established fifth model is used to search for a target patch version that matches the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability.

[0116] In practical applications, the vulnerability description information of unknown vulnerabilities can be matched with the vulnerability description information of various known vulnerabilities in the vulnerability database. The patch version of the code change record of the matched known vulnerability is determined as the target patch version. The specific matching process is as follows: 1. LLM Vulnerability Description Analysis: The LLM, a lightweight instruction fine-tuning model, is selected as the fifth major model. This model is used to analyze the vulnerability information of each known vulnerability in the vulnerability information database. For example, semantic analysis is performed on vulnerability announcement texts (CVE, GHSA, CNNVD, etc.), extracting the coordinates of affected packets and version range expressions. For example, "before2.15.1" is automatically translated into a standardized constraint object VersionConstraint that is "<2.15.1 or <=1.9.0", and potential branches and label naming rules are inferred. 2. Version Compare Difference Acquisition and Commit Sampling: Based on VersionConstraint, the GitHub Compare API is called to automatically infer the upper and lower bounds of the affected interval tags and commits, and pull all commit metadata (hash value, author, commit description message, code / file changes after commit, patch link patchUrl) and file-level addition and deletion information within the interval; if the project does not use semantic tags, it is crawled by time window; 3. LLM Semantic Matching Commit: Perform Cross-Encoder similarity calculation on the diff vector and vulnerability description vector of each commit within the compare range, and combine code change features (deleting high-risk APIs, adding input validation logic) to weight and rank them. Output the top k candidate commits with the highest scores and confidence levels exceeding the confidence threshold as the target fix version Fix-Commit; otherwise, proceed to manual review.

[0117] S110. Based on the pull requests associated with the target patch version or multiple predecessor versions of the target patch version in the version relationship graph, construct the patching chain for the unknown vulnerability.

[0118] As an example, after obtaining the target patch version, if the target patch version is associated with a pull request (PR), then the patching chain for the unknown vulnerability is constructed based on the pull request associated with the target patch version.

[0119] It should be noted that when a developer finishes developing a new feature or fixing a problem, they will create a request to merge their changes into the project's main branch or other specified branches. This request is called a pull request.

[0120] If the target patch version has no associated fetch request, then trace back multiple predecessor versions of the target patch version from the version relationship graph. For example, if the number of multiple predecessor versions is less than or equal to a preset number, such as 30, then construct the patching chain for the unknown vulnerability based on these multiple predecessor versions.

[0121] In practical applications, after obtaining the target fix version Fix-Commit, the specific process of constructing the fix chain for this unknown vulnerability can be as follows: 1. Difference Summary Generation: After fixing the Fix-Commit, the ASTDiff and LLM interpreter are used to generate a user-readable repair summary (including deleted points, added points, and risk reasons, etc.), and the difference vector is cached for subsequent taint analysis. 2. Vulnerability context construction: Using Fix-Commit as the anchor, collect author information, commit information, and a list of affected files to form an -InitContext object; 3. Path branch determination: PR branch: If the commit is associated with a PR, then fetch the PR comments, review discussions, and CI logs, and analyze the motivation for the fix and the key points of the discussion; Commit branch: If there is no PR, GitRev-Walk is used to trace back multiple predecessor commits of Fix-Commit in the version relationship graph to build a linear fix chain; 4. Issue tracing and linkage: Using GraphQL query and LLM keyword matching, issues related to PR or multiple previous commits and synonymous with vulnerability keywords are found to complete the discussion chain and context information. 5. Context fusion and graph storage: Entities such as Commit, PR, and Issue and their relationships are fused into a unified FixContextJSON, forming a visualized "vulnerability ↔ fix" relationship subgraph for subsequent taint analysis.

[0122] This application embodiment, upon detecting an unknown vulnerability, employs the fifth major model to search for a target patch version matching the unknown vulnerability in a vulnerability information database based on the vulnerability description information. It then constructs a patching chain for the unknown vulnerability based on pull requests associated with the target patch version or multiple predecessor versions in a version relationship graph. This allows the fifth major model to infer the complete patching chain of an unknown vulnerability based on information in the vulnerability information database, thereby achieving accurate analysis of vulnerability information of unknown vulnerabilities in open-source software.

[0123] In an optional embodiment, the step of using the fifth major model to search for a target patch version matching the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability includes: using the fifth major model to search for target code change records matching the unknown vulnerability from the vulnerability information database; determining the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information; and determining the version corresponding to the highest semantic similarity as the target patch version.

[0124] As an example, when an unknown vulnerability is detected, the vulnerability description information of the unknown vulnerability is obtained, and a pre-established fifth model is used to search for target code change records that match the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability.

[0125] The semantics of the code and the semantics of the vulnerability description information for each version of the target code change record are compared to obtain the semantic similarity between the semantics of the code and the semantics of the vulnerability description information for each version. The version with the highest semantic similarity is then determined as the target patch version.

[0126] This application embodiment uses the fifth major model to search for target code change records that match unknown vulnerabilities in the vulnerability information database, determines the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information, and determines the version corresponding to the highest semantic similarity as the target repair version, which can more accurately determine the target repair version.

[0127] Please refer to Figure 3 , Figure 3This is a schematic diagram of a vulnerability analysis device based on a large model, provided in the second embodiment of this application. The second embodiment of this application provides a vulnerability analysis device based on a large model, comprising: a code change record acquisition module 201, used to acquire code change records for any known vulnerability from a vulnerability information database; a sensitive function identification module 202, used to identify sensitive functions that introduce known vulnerabilities into the code change records using a first large model; a version category determination module 203, used to compare the current version's code with the code of the known vulnerability and the code of the patch for each version in the code change record, and determine the category of the current version based on the comparison results; wherein the category is a secure version, a risky version, or a patched version; an affected version merging module 204, used to find the affected versions of the known vulnerability in the version relationship graph based on the determined patched version, and combine the determined risky version and the affected version to obtain the affected version range; wherein the version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository; and a vulnerability information processing module 205, used to determine that the analysis information of the known vulnerability includes sensitive functions, determined patched versions, and the affected version range.

[0128] In an optional embodiment, the device further includes: a vulnerability information database establishment module, used to: capture the original vulnerability information of each known vulnerability from multiple vulnerability intelligence sources; preprocess the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability; and store the target vulnerability information of each known vulnerability in a database to obtain a vulnerability information database.

[0129] In an optional embodiment, the preprocessing of the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability includes: combining the real-time data stream processing component and the second major model to aggregate the original vulnerability information of each known vulnerability to obtain the first vulnerability information of each known vulnerability; using the third major model to infer missing information based on the first vulnerability information of each known vulnerability to generate the second vulnerability information of each known vulnerability; and determining that the target vulnerability information of each known vulnerability includes the first vulnerability information and the second vulnerability information of each known vulnerability.

[0130] In an optional embodiment, the version category determination module 203 is further configured to, before comparing the current version of the code with the code of the known vulnerability and the code of the patch for the known vulnerability for each version of the code change record, and determining the category of the current version based on the comparison result, determine the baseline version of the code change record based on the version relationship diagram; and traverse the version range of the code change record starting from the baseline version, compare the code structure of two adjacent versions of the code change record, and determine the patch.

[0131] In an optional embodiment, comparing the current version's code with the code of known vulnerabilities and the code of patches for known vulnerabilities, and determining the category of the current version based on the comparison results, includes: comparing the code text of the current version with the code text of known vulnerabilities to obtain code text similarity; if the code text similarity is less than a code text similarity threshold, then the current version is determined to be a secure version; if the code text similarity is greater than or equal to the code text similarity threshold, then comparing the code structure of the current version with the code structure of the patches to obtain a first code structure similarity; if the first code structure similarity is greater than or equal to the code structure similarity threshold, then using a fourth model to compare the code semantics of the current version with the code semantics of the patches to obtain code semantic similarity; if the first code structure similarity is less than the code structure similarity threshold or the code semantic similarity is less than the code semantic similarity threshold, then the current version is determined to be a risky version; if the code semantic similarity is greater than or equal to the code semantic similarity threshold, then the current version is determined to be a patched version.

[0132] In an optional embodiment, the step of searching for the affected version of a known vulnerability in the version relationship graph based on the determined patch version includes: extracting the code fingerprint of the patch from the determined patch version; determining a pre-selected version from the version relationship graph; wherein the code fingerprint of the pre-selected version matches the code fingerprint of the patch; comparing the code of the pre-selected version with the code of the patch, and determining whether the pre-selected version is an affected version based on the comparison result.

[0133] In an optional embodiment, the step of searching for the affected version of a known vulnerability in the version relationship graph based on the determined patch version includes: searching for the successor version of the patch version in the version relationship graph; comparing the code structure of the successor version with the code structure of the patch to obtain a second code structure similarity; if the second code structure similarity is greater than or equal to the code structure similarity threshold, then the successor version is determined to be the affected version.

[0134] In an optional embodiment, the device further includes: a target patch version lookup module, used to, when an unknown vulnerability is detected, use the fifth model to look up a target patch version that matches the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability; and a vulnerability patching link construction module, used to construct a patching link for the unknown vulnerability based on the pull request associated with the target patch version or multiple predecessor versions of the target patch version in the version relationship diagram.

[0135] In an optional embodiment, the step of using the fifth major model to search for a target patch version matching the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability includes: using the fifth major model to search for target code change records matching the unknown vulnerability from the vulnerability information database; determining the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information; and determining the version corresponding to the highest semantic similarity as the target patch version.

[0136] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0137] The third embodiment of this application provides a computer program product, which includes instructions that, when executed by a computer, cause the computer to perform the method described in the first embodiment of this application and achieve the same beneficial effects.

[0138] The methods described in the first embodiment of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the various embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM (Open Application Model), or other programmable devices.

[0139] Computer programs or instructions can be stored in or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another via wired or wireless means. A computer-readable storage medium can be any usable medium that a computer can access, or a data storage device such as a server or data center that integrates one or more usable media. Usable media can be magnetic media, such as floppy disks, hard disks, and magnetic tapes; optical media, such as digital video discs; or semiconductor media, such as solid-state drives. The computer-readable storage medium can be volatile or non-volatile, or may include both types.

[0140] Please refer to Figure 4 , Figure 4This is a schematic diagram of the structure of an electronic device provided in the fourth embodiment of this application. The fourth embodiment of this application provides an electronic device 30, including a processor 301, a memory 302, and a computer program stored in the memory 302 and configured to be executed by the processor 301; when the processor 301 executes the computer program, it implements the method described in the first embodiment of this application and can achieve the same beneficial effects.

[0141] When the processor 301 reads a computer program from the memory 302 via the bus 303 and executes the computer program, it can implement the method described in the first embodiment of this application.

[0142] Processor 301 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 301 may be a microprocessor.

[0143] The memory 302 can be used to store instructions executed by the processor 301 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 301 of this embodiment can be used to execute the instructions in the memory 302 to implement the method described in the first embodiment of this application. The memory 302 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0144] The fifth embodiment of this application provides a computer-readable storage medium, which includes a stored computer program; wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to perform the method described in the first embodiment of this application, and can achieve the same beneficial effects.

[0145] In summary, this application provides a vulnerability analysis method, program product, device, and medium based on a large model. The vulnerability analysis method based on the large model includes: obtaining code change records for any known vulnerability from a vulnerability information database; identifying sensitive functions that introduce known vulnerabilities into the code change records using a first large model; for each version of the code change record, comparing the current version's code with the code of the known vulnerability and the code of the patch for the known vulnerability, and determining the category of the current version based on the comparison results; wherein the category is a secure version, a risky version, or a patched version; finding the affected versions of the known vulnerability in the version relationship graph based on the determined patched version, and obtaining the affected version range by combining the determined risky version and the affected version; wherein the version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository; the analysis information for the known vulnerability includes sensitive functions, determined patched versions, and the affected version range. This application embodiment obtains code change records for any known vulnerability from a vulnerability information database, uses a first major model to identify sensitive functions that introduce known vulnerabilities into the code change records, and compares the current version's code with the code of the known vulnerability and the code of the patch for the known vulnerability for each version of the code change record. Based on the comparison results, the current version is determined to be a secure version, a risky version, or a patched version. Based on the determined patched version, the affected versions of the known vulnerability are found in the version relationship graph. Combining the determined risky version and the affected version, the range of affected versions is obtained. The analysis information of the known vulnerability includes sensitive functions, determined patched versions, and the range of affected versions. It can use the first major model to accurately analyze the introduction location of the known vulnerability, and deeply analyze the risky versions and patched versions affected by the known vulnerability in the code change records based on the code of the known vulnerability and its patch. It also considers the affected versions of the known vulnerability on other code branches in the version relationship graph besides the code change records to completely analyze the range of affected versions of the known vulnerability, thereby achieving accurate analysis of vulnerability information of various vulnerabilities in open source software.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0147] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0148] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of 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 scope of protection of this application. It should be noted that similar reference numerals 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.

[0150] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0151] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A vulnerability analysis method based on a large model, characterized in that, include: Retrieve code change records for any known vulnerability from the vulnerability database; The first major model is used to identify sensitive functions in the code change log that introduce the known vulnerability; For each version of the code change record, the current version's code is compared with the code of the known vulnerability and the code of the patch for the known vulnerability, and the category of the current version is determined based on the comparison result; wherein, the category is a secure version, a risky version, or a patched version; Based on the identified patch version, the affected versions of the known vulnerability are located in the version relationship graph. The range of affected versions is obtained by combining the identified risk version and the affected version. The version relationship graph is established based on the inheritance relationship between multiple version tags in the code repository. The analytical information for identifying the known vulnerability includes the sensitive function, the identified patch version, and the range of affected versions.

2. The method according to claim 1, characterized in that, The method further includes: Extract raw vulnerability information for each known vulnerability from multiple vulnerability intelligence sources; The original vulnerability information of each known vulnerability is preprocessed to obtain the target vulnerability information of each known vulnerability; The target vulnerability information of each known vulnerability is stored in a database to obtain the vulnerability information database.

3. The method according to claim 2, characterized in that, The preprocessing of the original vulnerability information of each known vulnerability to obtain the target vulnerability information of each known vulnerability includes: By combining the real-time data stream processing component and the second major model, the original vulnerability information of each known vulnerability is aggregated to obtain the first vulnerability information of each known vulnerability; The third model is used to infer missing information based on the first vulnerability information of each known vulnerability, and to generate the second vulnerability information of each known vulnerability. The target vulnerability information for each known vulnerability is determined to include the first vulnerability information and the second vulnerability information for each known vulnerability.

4. The method according to claim 1, characterized in that, Before comparing the current version's code with the code containing the known vulnerability and the code patched for the known vulnerability for each version of the code change record, and determining the category of the current version based on the comparison results, the method further includes: Based on the version relationship diagram, determine the baseline version of the code change record; Starting from the baseline version, traverse the version range of the code change record, compare the code structure of two adjacent versions of the code change record, and determine the patch.

5. The method according to claim 1, characterized in that, The step of comparing the current version of the code with the code containing the known vulnerability and the code containing the patch for the known vulnerability, and determining the category of the current version based on the comparison results, includes: The code text of the current version is compared with the code text of the known vulnerability to obtain the code text similarity. If the code text similarity is less than the code text similarity threshold, then the current version is determined to be a secure version; If the code text similarity is greater than or equal to the code text similarity threshold, then the code structure of the current version and the code structure of the patch are compared to obtain a first code structure similarity. If the first code structure similarity is greater than or equal to the code structure similarity threshold, then the fourth model is used to compare the code semantics of the current version and the code semantics of the patch to obtain the code semantic similarity. If the first code structure similarity is less than the code structure similarity threshold or the code semantic similarity is less than the code semantic similarity threshold, then the current version is determined to be a risky version; If the code semantic similarity is greater than or equal to the code semantic similarity threshold, then the current version is determined to be a fixed version.

6. The method according to claim 1, characterized in that, The step of finding the affected versions of the known vulnerability in the version relationship graph based on the determined patch version includes: Extract the code fingerprint of the patch from the identified fix version; A pre-selected version is determined from the version relationship graph; wherein the code fingerprint of the pre-selected version matches the code fingerprint of the patch; The code of the pre-selected version and the code of the patch are compared, and the pre-selected version is determined to be the affected version based on the comparison results.

7. The method according to claim 1, characterized in that, The step of finding the affected versions of the known vulnerability in the version relationship graph based on the determined patch version includes: Find the successor version of the repaired version in the version relationship graph; By comparing the code structure of the subsequent version with the code structure of the patch, a second code structure similarity is obtained; If the second code structure similarity is greater than or equal to the code structure similarity threshold, then the subsequent version is determined to be the affected version.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: In the event of an unknown vulnerability being detected, the fifth model is used to search for a target patch version that matches the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability; Based on the pull request associated with the target patch version or multiple predecessor versions of the target patch version in the version relationship diagram, construct the patching chain for the unknown vulnerability.

9. The method according to claim 8, characterized in that, The fifth model is used to search for a target patch version matching the unknown vulnerability from the vulnerability information database based on the vulnerability description information of the unknown vulnerability, including: The fifth major model is used to search for target code change records that match the unknown vulnerability in the vulnerability information database; Determine the semantic similarity between the code semantics of each version of the target code change record and the information semantics of the vulnerability description information; The version with the highest semantic similarity is determined as the target repair version.

10. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 9.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program; wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 9.

Images