Vulnerability software version detection method and device

Abstract

The invention discloses a vulnerability software version detection method and device, relates to the technical field of vulnerability software version detection, and solves the problems that in the prior art, due to the fact that noise cannot be effectively filtered, vulnerability lines are wrongly recognized, and vulnerability sources cannot be accurately traced. The method comprises the steps of obtaining input data, and obtaining a code change record and a first vulnerability line set; vulnerability description information is obtained according to the input data, code change records are screened to obtain code change records related to vulnerabilities, and a big language model is utilized to perform noise filtering to obtain vulnerability lines which are really easily attacked; tracing vulnerabilities corresponding to the vulnerability lines by using a context-based line mapping algorithm to obtain introduction and submission of the vulnerabilities; finding all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determining the version numbers as a vulnerability version set; according to the method, missing report and false report of vulnerability versions are reduced, potential safety hazards existing in software projects are reduced, and the safety of a software system is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability software version detection, and in particular to a vulnerability software version detection method and device. Background Art

[0002] Software vulnerabilities refer to security defects in software that threaten the confidentiality, integrity, availability, access control, etc. of the system or its application data. These vulnerabilities may be caused by programming errors, design flaws, imperfect testing, or failure to consider all usage scenarios. The existence of software vulnerabilities may lead to various serious consequences, including data leakage, system paralysis, service interruption, privacy violation, economic loss, and even personal safety. Therefore, timely detection and repair of software vulnerabilities is crucial to ensure the security and stability of the system.

[0003] In order to collect, organize and publish detailed information about known vulnerabilities in computer software and hardware and provide a centralized, publicly accessible resource, the National Institute of Standards and Technology of the United States has established the National Vulnerability Database (NVD). NVD collects and organizes vulnerability information from various sources, including vulnerability description information (name, vulnerability type, affected software or hardware, etc.) and repair information released by manufacturers, related references and links, and assigns a unique vulnerability number (CVE ID) as a vulnerability identifier. The database also provides information on the risk level and timeliness of the vulnerability to help users better assess and manage security risks.

[0004] In recent years, software supply chain security has become increasingly important for software companies, as they often use a lot of open source software (OSS) in their projects. The widespread use of open source software by software companies increases security risks. Multiple open source software increases the possibility of industrial projects containing vulnerabilities and backdoors, increasing the risk of attacks on key systems and data of enterprises. At the same time, the open source community usually does not have the same support system as commercial software, which may lead to untimely vulnerability repairs and updates.

[0005] To avoid this kind of software supply chain security issue, software companies often use software composition analysis (SCA) tools such as Snyk1 and Whitesource2 to check for vulnerabilities in their project components. These SCA tools output based on the vulnerability information provided in NVD. However, the vulnerable version information about the software in NVD is not reliable. NVD usually adopts a conservative principle: "If version X has a vulnerability, then all previous versions also have vulnerabilities." However, in actual situations, this assumption is not always true, so some early versions of the software may be mistakenly marked as vulnerable. At the same time, in some cases, NVD will also regard vulnerable versions as safe.

[0006] Incorrect vulnerability version information may cause additional work and burden to software companies. If NVD misses reporting vulnerabilities in certain versions, software companies may ignore the security issues of these versions, exposing the system to security risks. In addition, many proprietary software systems may rely on older versions of open source software. In this case, if the old version does not have vulnerabilities, then there is no need to update it. Once updated to a new version, it will destroy the original functions, resulting in a lot of additional overhead and workload.

[0007] In past studies, some methods have been proposed to automatically identify vulnerability introduction submissions and vulnerable software versions based on vulnerability repair submissions. However, there are still some problems with the existing technology:

[0008] (1) Existing technologies are unable to filter out noise lines: In existing vulnerability software version detection methods, each deleted semantic line in the vulnerability repair submission is considered to be the vulnerability line that caused the vulnerability. However, in fact, many of these lines are irrelevant to the vulnerability. Existing vulnerability software version identification methods are unable to identify these noises in vulnerability repair submissions, resulting in false positives of vulnerability versions.

[0009] (2) Existing methods are inaccurate in tracing the source of vulnerable lines: Due to algorithm defects, existing vulnerable software version detection methods will incorrectly identify the introduction submission of the vulnerability in many cases, resulting in the underreporting of the vulnerability version number. Summary of the invention

[0010] The present invention provides a method and device for detecting vulnerable software versions, thereby solving the problems in the prior art of being unable to effectively filter noise, leading to incorrect identification of vulnerable lines, and being unable to accurately trace the source of the vulnerability, thereby reducing missed reports and false positives of vulnerable versions, reducing the potential safety hazards of software projects, and improving the security of software systems.

[0011] In a first aspect, the present invention provides a method for detecting vulnerable software versions, the method comprising:

[0012] Obtain input data, pull warehouse data from the open source code warehouse according to the input data, and obtain a code change record and a first vulnerability row set;

[0013] Obtain vulnerability description information according to the input data, and filter the code change records to obtain code change records related to the vulnerability, and use a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines;

[0014] According to the vulnerability line, using a context-based line mapping algorithm, the vulnerability corresponding to the vulnerability line is traced to obtain the introduction submission of the vulnerability;

[0015] Find all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determine them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

[0016] In combination with the first aspect, in a possible implementation manner, pulling warehouse data from an open source code warehouse according to the input data and obtaining a code change record and a first vulnerability row set includes:

[0017] According to the warehouse name, obtaining warehouse data corresponding to the warehouse name in the open source platform;

[0018] According to the vulnerability repair submission, a code change record in the vulnerability repair submission is obtained from the warehouse data;

[0019] The code change record is preprocessed to obtain a first vulnerability row set.

[0020] In combination with the first aspect, in a possible implementation manner, preprocessing the code change record to obtain a first vulnerability row set includes:

[0021] Determine the deleted lines in the code change record;

[0022] Non-semantic rows in the deleted rows are removed to obtain a first vulnerability row set.

[0023] In combination with the first aspect, in a possible implementation, obtaining vulnerability description information according to the input data, screening the code change records to obtain code change records related to the vulnerability, and using a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines; including:

[0024] Construct a vulnerability database including all data in the CVE library;

[0025] According to the input CVE ID field, query the vulnerability description information corresponding to the vulnerability in the vulnerability database;

[0026] Obtaining context code change information of the vulnerability line in the first vulnerability line set from the code change record, and performing text processing at the same time to obtain a vulnerability-related code change set;

[0027] According to the vulnerability description information and the set of vulnerability-related code changes, prompt words are constructed using natural language, and the prompt words are input into a large language model to obtain the vulnerability lines that are truly vulnerable to attack.

[0028] In combination with the first aspect, in a possible implementation manner, obtaining the context code change information of the vulnerability line in the first vulnerability line set and performing text processing to obtain the vulnerability-related code change set includes:

[0029] In the vulnerability repair submission, a regular text matching method is used to find the newly added code lines in the multiple lines above and below the vulnerability line in the first vulnerability line set, and use the newly added code lines together with the vulnerability line as the context code change information;

[0030] Different annotations are performed on the added code lines and the deleted code lines in the context code change information to obtain a vulnerability-related code change set.

[0031] In combination with the first aspect, in a possible implementation, the use of a context-based row mapping algorithm to trace the vulnerability corresponding to the vulnerability row to obtain the introduction submission of the vulnerability includes:

[0032] According to the vulnerability line that is truly vulnerable to attack, determining a submission that introduces the vulnerability line;

[0033] Recursively use a line mapping algorithm based on context mapping to trace the introduction commits of all versions of the vulnerability line to obtain the commit sequence where the vulnerability was introduced;

[0034] The last item of the commit sequence, that is, the earliest version of the commit introducing the vulnerability is determined as the commit introducing the vulnerability.

[0035] In combination with the first aspect, in a possible implementation method, the use of a context mapping-based line mapping algorithm is used to trace the introduction submissions of all versions of the vulnerable line to obtain a submission sequence where the vulnerability is introduced, including: calculating the string similarity between the deleted line in the submission where the vulnerable line is introduced and the vulnerable line, as well as the string similarity of the context code near the two, comprehensively determining whether there is an earlier version of the vulnerable line based on the two string similarities, tracing the version that introduced the vulnerable line, and obtaining the submission sequence where the vulnerable line is introduced.

[0036] In a second aspect, the present invention provides a device for detecting a vulnerable software version, the device comprising:

[0037] A preprocessing module, configured to pull warehouse data from an open source code warehouse according to the input data, and obtain a code change record and a first vulnerability row set;

[0038] A vulnerability line determination module, configured to obtain vulnerability description information according to the input data, filter the code change records to obtain code change records related to the vulnerability, and use a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines;

[0039] A calculation module, configured to trace the vulnerability corresponding to the vulnerability row by using a context-based row mapping algorithm according to the vulnerability row, and obtain an introduction submission of the vulnerability;

[0040] The output module is used to find all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determine them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

[0041] In a third aspect, the present invention provides a vulnerability software version detection server, the server comprising a memory and a processor;

[0042] The memory is used to store computer executable instructions;

[0043] The processor is used to execute the computer executable instructions to implement the vulnerable software version detection method described in any one of claims 1-7.

[0044] One or more technical solutions provided in the present invention have at least the following technical effects or advantages:

[0045] The present invention adopts a vulnerability software version detection method and device, which can preliminarily obtain possible vulnerability lines according to the vulnerability repair submission and the vulnerability number, and then generate prompt words by combining the vulnerability description information with the vulnerability-related code, and submit it to a large language model to perform intelligent analysis on the repair submission, realize filtering of noise lines, and successfully identify the real vulnerability lines in the vulnerability repair submission, and then recursively use a context-based line mapping algorithm to accurately trace the vulnerability, lock the source of the vulnerability, and finally obtain the vulnerability introduction submission and the software version with the vulnerability; the present invention achieves high accuracy. Compared with the prior art, the present invention also reduces the underreporting and false positives of the vulnerability software version, can more accurately identify the vulnerability introduction submission, and more effectively determine the version range affected by the vulnerability. In actual application scenarios, the security of software systems is improved. The present invention is simple to deploy, has lower overhead, and stable performance. It can effectively reduce the maintenance costs of software companies for the system, while reducing the security risks of the system. In academic research on software vulnerabilities, the present invention is also widely used. In defect prediction research, the present invention can be used to identify the introduction of vulnerabilities to evaluate the prediction model proposed by researchers. In addition, the present invention also has important practical value in empirical research such as code review, code smell detection, and technical debt. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A schematic diagram of a flow chart of a method for detecting vulnerable software versions provided by an embodiment of the present invention;

[0047] Figure 2 A schematic diagram of a flow chart of a context-based row mapping algorithm provided in an embodiment of the present invention;

[0048] Figure 3 A schematic diagram of a specific use embodiment provided for an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] In a first aspect, the present invention provides a method for detecting a vulnerable software version. Figure 1 As shown, the method includes the following steps S101 to S104.

[0051] S101, obtaining input data, pulling warehouse data from an open source code warehouse according to the input data, and obtaining a code change record and a first vulnerability row set.

[0052] Specifically, in step S101, according to the input data, warehouse data is pulled from the open source code warehouse, and a code change record and a first vulnerability row set are obtained, including:

[0053] (1) According to the warehouse name, the warehouse data corresponding to the warehouse name is obtained in the open source platform; here, according to the warehouse name R in the input data, the corresponding software project of the GitHub open source code warehouse platform is obtained, including project code, project submission log, code change record, etc.

[0054] (2) Using the commit information of the vulnerability repair, the code change record in the commit information of the vulnerability repair is obtained from the warehouse data; here, according to the vulnerability repair commit F in the input data, the code change record of commit F is obtained from the pulled software code warehouse. Since the vulnerability repair commit completes the repair of the vulnerability, the specific method is to delete the line containing the vulnerability and add a safe and reliable line. Therefore, the vulnerability line must appear in the deleted line. In this step, the line deleted in this commit is obtained.

[0055] (3) Preprocess the code change record to obtain the first set of vulnerable lines. Specifically, preprocess the code change record to obtain the first set of vulnerable lines, including: determining the deleted lines in the code change record; removing the non-semantic lines in the deleted lines to obtain the first set of vulnerable lines. Here, there are some non-semantic lines in the deleted lines obtained. Non-semantic lines will definitely not cause vulnerabilities to occur, and they need to be filtered to preliminarily determine the lines that may have vulnerabilities. Furthermore, the deleted lines are preliminarily filtered using an annotation graph to exclude blank lines, comment lines, and lines involving format modifications in the deleted lines.

[0056] S102, obtaining vulnerability description information according to the input data, and screening the code change records to obtain the code change records related to the vulnerability, and using the large language model to perform noise filtering on the first vulnerability line set to obtain the vulnerability lines that are truly vulnerable to attack.

[0057] Specifically, in step S102, vulnerability description information is obtained according to the input data, and the code change records are screened to obtain code change records related to the vulnerability. The first vulnerability line set is noise filtered using a large language model to obtain the truly vulnerable vulnerability lines, including the following steps S1021 to S1024.

[0058] S1021, constructing a vulnerability database including all data in the CVE library;

[0059] S1022, querying vulnerability description information corresponding to the vulnerability in the vulnerability database according to the input CVE ID field;

[0060] S1023, obtaining context code change information of the vulnerability line in the first vulnerability line set in the code change record, and performing text processing at the same time to obtain a vulnerability-related code change set; Here, specifically, in step S1023, obtaining context code change information of the vulnerability line in the first vulnerability line set in the code change record, and performing text processing at the same time to obtain a vulnerability-related code change set, includes:

[0061] (1) In the vulnerability repair submission, a regular text matching method is used to find the newly added code lines in the multiple lines above and below the vulnerability line in the first vulnerability line set, and use them together with the vulnerability line as the context code change information;

[0062] (2) Differently mark the added code lines and the deleted code lines in the context code change information to obtain a vulnerability-related code change set.

[0063] S1024, construct prompt words using natural language according to the vulnerability description information set and the vulnerability-related code change set, input the prompt words into the large language model, and obtain the vulnerability row.

[0064] Exemplarily, a MongoDB vulnerability database containing all data in the CVE library is first constructed locally, and then the database is connected and a query is executed to obtain detailed description information description of the vulnerability according to the input CVE ID field name.

[0065] According to the code change record of the vulnerability fix submission F, filter out the vulnerability-related code lines that can be understood by the large language model code = {code 1 ,…,code x}, in identifying the vulnerability-related code lines, regular matching is used to obtain the vulnerability line obtained in S102 and the added content in up to three lines above and below it. In this way, on the one hand, sufficient vulnerability-related information can be provided, and on the other hand, the interference of vulnerability-irrelevant code can be minimized, thereby reducing the possibility of model misjudgment and saving overhead. In addition, a minus sign "-" is marked before the deleted line, and a plus sign "+" is marked before the newly added line to indicate the changes in each line, so that the large language model can understand the meaning of the code changes.

[0066] Combine vulnerability description information, vulnerability-related code lines, and natural language to construct prompt words, and define the rules for the large language model to identify vulnerability lines, so that it can correctly analyze and determine the code lines that actually cause the vulnerability, and control the content returned by the large language model to be a single vulnerability line for subsequent operations. Deliver the prompt words to the large language model to filter out the lines that are not related to the vulnerability from the lines collected by S101, and output the lines L where the vulnerability actually exists.

[0067] Specifically, the template for generating prompt words is "A CVE vulnerability description is as follows: {description}. In the following commits, the vulnerability is fixed. Deleted lines are marked with a minus sign "-", and newly added lines are marked with a plus sign "+": {code}. One of the lines starting with "-" is actually the code line that causes the vulnerability. Determine which line is the most likely vulnerability line, return the line of code, and remove the "-" in front of it. It is forbidden to return other contexts, and it is forbidden to add any other text descriptions. Only one line of data is returned." The return value obtained is the real vulnerability line L after filtering.

[0068] S103, according to the vulnerability line, using a context-based line mapping algorithm, trace the vulnerability corresponding to the vulnerability line to obtain the introduction submission of the vulnerability.

[0069] Specifically, in step S103, according to the vulnerability row that is truly vulnerable to attack, the vulnerability is traced using a context-based row mapping algorithm to obtain the introduction submission of the vulnerability, including steps S1031 to S1033.

[0070] S1031, according to the vulnerability line that is actually vulnerable to attack, determine the submission that introduces the vulnerability line.

[0071] S1032, recursively use the context mapping-based row mapping algorithm to trace the introduction commits of all versions of the vulnerability row to obtain the commit sequence of the vulnerability introduction.

[0072] S1033, determining the last item of the submission sequence, that is, the earliest version of the introduction submission of the vulnerability row as the introduction submission of the vulnerability.

[0073] For example, the obtained vulnerable line is traced back, and the characteristics of the version control system are used to identify the commit that introduced this line. 1 .

[0074] Since vulnerabilities are usually fundamental, that is, they often already exist in the initial version of the code, in other words, the commit located in S1024 may not be the original version where the vulnerability exists. This commit may only be a modification commit to the earliest vulnerable line, but the fix was not completed, becoming another manifestation of the original vulnerability (also vulnerable), and the original vulnerability still exists in the earlier version. Therefore, a method is needed to smoothly associate the modified version of the vulnerability with the initial version of the vulnerability, that is, to map the modified vulnerable line to the original vulnerable line. By comparing the code lines of the initial version of the vulnerability and the modified version of the vulnerability, it can be found that their code lines are very similar in performance. This is because modifying these code lines usually only involves routine code maintenance and updates, and does not make major changes to the core functions of the code.

[0075] Specifically, Figure 2 As shown, the context-based line mapping algorithm is recursively used to further trace back to the earlier versions of the vulnerability and obtain the introduction commit sequence I = {I 1 ,…,I N}, N ≥ 1, then identify the last item I introduced into the submission sequence N The first commit that introduced this vulnerability is this commit.

[0076] Here, the context-based row mapping algorithm is as follows: for the last item I of the current introduced submission sequence n , collect the deleted lines DL in this code change = {DL 1 ,…,DL N}, N is the number of deleted rows. For each deleted row DL n , calculate its string similarity with the vulnerability line L, and record it as S = {S 1 ,…,S N}, and determine whether there is a value greater than the threshold 0.45 in S. If so, the context acquisition phase is entered; otherwise, it means that there is no earlier version of the vulnerable row, and the algorithm ends.

[0077] Furthermore, the context acquisition phase is specifically as follows: using methods such as branch switching and version tracking to find the vulnerability and introduce submission I n The history of the most recent commit P. For each S n DL of rows greater than 0.45 n , respectively obtain I n The context of L in BOC and DL in P n, calculate the similarity between the two, and record them as S'={S' 1 ,…,S' M}, M is the number of rows in DL with similarity greater than 0.45, and the maximum value in S' is compared with the threshold 0.7. If it is greater than 0.7, the row DL corresponding to the maximum value of S' is considered n It is an earlier version of the vulnerability line L, which will be DL n The introduction of commit I n+1 Add the introduced commit sequence and update the vulnerability row L to make its value DL n , and then re-call the context-based row mapping algorithm; otherwise, it means that the vulnerability row has no earlier version and the algorithm ends.

[0078] S104, finding all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determining them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

[0079] Specifically, according to the historical submission records of the software in the project repository, find the software version set V corresponding to all submissions between the vulnerability repair submission and the vulnerability introduction submission n .

[0080] Certified software version set V n It is the set of software versions that finally have vulnerabilities.

[0081] The vulnerability software version detection method can be autonomously deployed on computers and other devices with data processing capabilities. The specific method is to store the executable code used to implement the above method in the device, complete the configuration of the Python environment, and install the required dependent libraries, that is, the executable code capability of the vulnerability software version detection method can be run.

[0082] In a specific embodiment provided by the invention, the user can input a json format file containing a project name, vulnerability ID, vulnerability repair submission and vulnerability file. The project name indicates the software project affected by the vulnerability, the vulnerability ID is its unique identifier in the vulnerability database, the repair submission points to the submission record of the repair patch, and the name of the vulnerability file helps to determine the affected code file. After processing by the device, the introduction submission of the corresponding vulnerability and the corresponding vulnerability version can be output. Figure 3 The figure shows a case in which a software company uses FFmpeg open source software as a project component. During the maintenance process, the CVE-2013-3671 vulnerability of FFmpeg is discovered. A vulnerability version detection is performed on the company, and the graphical results are output. If the FFmpeg version they use is included in the output data, the company needs to perform maintenance and update on the version. Otherwise, no relevant processing is required.

[0083] In a second aspect, the present invention provides a device for detecting vulnerable software versions, the device comprising: a preprocessing module, a vulnerable row determination module, a calculation module and an output module.

[0084] A preprocessing module, used to pull warehouse data from the open source code warehouse according to the input data, and obtain the code change record and the first vulnerability line set;

[0085] A vulnerability line determination module is used to obtain vulnerability description information according to input data, screen code change records, obtain code change records related to the vulnerability, and use a large language model to filter noise on the first vulnerability line set to obtain the truly vulnerable vulnerability lines;

[0086] The calculation module is used to trace the vulnerability corresponding to the vulnerability line by using the context-based line mapping algorithm according to the vulnerability line, and obtain the introduction submission of the vulnerability;

[0087] The output module is used to find all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determine them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

[0088] In a third aspect, the present invention provides a vulnerability software version detection server, which includes a memory and a processor; the memory is used to store computer executable instructions; the processor is used to execute computer executable instructions to implement a vulnerability software version detection method.

[0089] The above storage media include but are not limited to random access memory (RAM), read-only memory (ROM), cache, hard disk (HDD) or memory card. The memory can be used to store computer program instructions.

[0090] Although the present invention provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative labor. The order of steps listed in this embodiment is only one way of executing the order of many steps and does not represent the only execution order. When the device or client product in practice is executed, it can be executed in sequence or in parallel according to the method shown in this embodiment or the accompanying drawings (for example, in a parallel processor or multi-threaded processing environment).

[0091] It can be known from the description of the above implementation mode that a person skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary hardware. Based on such an understanding, the technical solution of the present invention, in essence or in other words, the part that contributes to the prior art, can be embodied in the form of a software product, or can be embodied in the implementation process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present invention or certain parts of the embodiments.

[0092] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. All or part of the present invention can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, mobile communication terminals, multi-processor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0093] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some or all of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the present invention.

Claims

1. A method for detecting vulnerable software versions, characterized in that: include: Obtain input data, pull warehouse data from the open source code warehouse according to the input data, and obtain a code change record and a first vulnerability row set; Obtain vulnerability description information according to the input data, and filter the code change records to obtain code change records related to the vulnerability, and use a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines; According to the vulnerability line, using a context-based line mapping algorithm, the vulnerability corresponding to the vulnerability line is traced to obtain the introduction submission of the vulnerability; Find all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determine them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

2. The method for detecting vulnerable software versions according to claim 1, characterized in that: Pulling warehouse data from the open source code warehouse according to the input data and obtaining a code change record and a first vulnerability row set includes: According to the warehouse name, obtaining warehouse data corresponding to the warehouse name in the open source platform; According to the vulnerability repair submission, a code change record in the vulnerability repair submission is obtained from the warehouse data; The code change record is preprocessed to obtain a first vulnerability row set.

3. The method for detecting vulnerable software versions according to claim 2, characterized in that: The preprocessing of the code change record to obtain a first vulnerability row set includes: Determine the deleted lines in the code change record; Non-semantic rows in the deleted rows are removed to obtain a first vulnerability row set.

4. The method for detecting vulnerable software versions according to claim 1, characterized in that: The obtaining vulnerability description information according to the input data, screening the code change records to obtain code change records related to the vulnerability, and using a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines, including: Construct a vulnerability database including all data in the CVE library; According to the input CVE ID field, query the vulnerability description information corresponding to the vulnerability in the vulnerability database; Obtaining context code change information of the vulnerability line in the first vulnerability line set from the code change record, and performing text processing at the same time to obtain a vulnerability-related code change set; According to the vulnerability description information and the set of vulnerability-related code changes, prompt words are constructed using natural language, and the prompt words are input into a large language model to obtain the vulnerability lines that are truly vulnerable to attack.

5. The method for detecting vulnerable software versions according to claim 4, characterized in that: The obtaining of the context code change information of the vulnerability line in the first vulnerability line set and performing text processing to obtain a vulnerability-related code change set includes: In the vulnerability repair submission, a regular text matching method is used to find the newly added code lines in the multiple lines above and below the vulnerability line in the first vulnerability line set, and the newly added code lines are used together with the vulnerability line as the context code change information; Different annotations are performed on the added code lines and the deleted code lines in the context code change information to obtain a vulnerability-related code change set.

6. The method for detecting vulnerable software versions according to claim 1, characterized in that: The process of tracing the vulnerability corresponding to the vulnerability row by using a context-based row mapping algorithm to obtain the introduction submission of the vulnerability includes: According to the vulnerability line that is truly vulnerable to attack, determining a submission that introduces the vulnerability line; Recursively use a line mapping algorithm based on context mapping to trace the introduction commits of all versions of the vulnerability line to obtain the commit sequence where the vulnerability was introduced; The last item of the commit sequence, that is, the earliest version of the commit introducing the vulnerability is determined as the commit introducing the vulnerability.

7. The method for detecting vulnerable software versions according to claim 6, characterized in that: The use of a row mapping algorithm based on context mapping to trace the introduction submissions of all versions of the vulnerable line to obtain a submission sequence where the vulnerability is introduced includes: calculating the string similarity between the deleted line in the submission where the vulnerable line is introduced and the vulnerable line, as well as the string similarity of the context code near the two, comprehensively judging whether the vulnerable line still has an earlier version based on the two string similarities, tracing the version that introduced the vulnerable line, and obtaining the submission sequence where the vulnerable line is introduced.

8. A vulnerability software version detection device, characterized in that: include: A preprocessing module, configured to pull warehouse data from an open source code warehouse according to the input data, and obtain a code change record and a first vulnerability row set; A vulnerability line determination module, configured to obtain vulnerability description information according to the input data, filter the code change records to obtain code change records related to the vulnerability, and use a large language model to perform noise filtering on the first vulnerability line set to obtain truly vulnerable vulnerability lines; A calculation module, configured to trace the vulnerability corresponding to the vulnerability row by using a context-based row mapping algorithm according to the vulnerability row, and obtain an introduction submission of the vulnerability; The output module is used to find all version numbers between the vulnerability repair submission and the vulnerability introduction submission, and determine them as a vulnerability version set, wherein the input data includes: vulnerability repair submission.

9. A vulnerability software version detection server, characterized in that: including memory and processor; The memory is used to store computer executable instructions; The processor is used to execute the computer executable instructions to implement the vulnerable software version detection method described in any one of claims 1-7.

Images