A code vulnerability marking method and device, electronic equipment and storage medium

Abstract

The application discloses a code vulnerability marking method and device, electronic equipment and a storage medium, and the method comprises the steps of obtaining a code path with a scanning frequency lower than a first preset value and containing an un-repaired vulnerability according to a code scanning history; determining the category of the path, wherein the category of the path comprises any one of the following: a development active path, a deleted path and a development inactive path; and marking the state of the vulnerability scanned by each path according to the category of the path. Through the above scheme, after periodic marking of the vulnerability, part of the invalid vulnerabilities, such as the deleted or unnecessary processing, are no longer involved in the statistics, so that more reasonable vulnerability statistical information can be obtained.

Description

Technical Field

[0001] This invention relates to the field of static code scanning, and more specifically to a method, apparatus, electronic device, and storage medium for marking code vulnerabilities. Background Technology

[0002] In software development, it is common to start development using path 1, and after a period of development, a branch path 2 is pulled from path 1 to continue development. Path 1 is no longer maintained, thus becoming an inactive path. Since unresolved vulnerabilities and bugs in path 1 will no longer be fixed, but these vulnerabilities may have been resolved in path 2, this will affect the statistical vulnerability remediation rate during code scanning and data statistics.

[0003] Normally, the code server logs can be used to deduce that path 2 originates from path 1. However, sometimes branch information cannot be obtained from the code server logs, which exacerbates the problem of duplicate statistics in the above-mentioned vulnerability. Summary of the Invention

[0004] In view of the above problems, the present invention is proposed to provide a code vulnerability marking method, apparatus, electronic device and storage medium that overcomes or at least partially solves the above problems.

[0005] According to one aspect of the present invention, a method for marking code vulnerabilities is provided, wherein the method includes:

[0006] Based on the code scanning history, obtain code paths that have been scanned less than a first preset value and contain unpatched vulnerabilities;

[0007] The path category is determined, and the path category includes any of the following: active development path, deleted path, and inactive development path;

[0008] The status of vulnerabilities detected by each path is marked according to the category of the path.

[0009] Optionally, the status includes any of the following: repaired, not repaired, cannot be repaired, deleted, other paths have been repaired, no processing required.

[0010] Optionally, if the path category is a development active path, then marking the status of vulnerabilities scanned by each path according to the path category includes:

[0011] Perform vulnerability scanning on the active development paths and mark the detected vulnerabilities as unpatched.

[0012] Optionally, if the path is classified as a deleted path, then marking the status of the vulnerabilities detected by each path according to the path category includes:

[0013] Mark vulnerabilities in deleted paths as deleted.

[0014] Optionally, if the path is classified as an inactive development path, then marking the status of vulnerabilities scanned from each path according to the path category includes:

[0015] Based on the code scanning history, obtain the paths in the inactive development path that have been scanned more than the second preset value;

[0016] Determine whether the path with more than a second preset value has a parent path. If it does, compare the vulnerability information of the parent path. If the same vulnerability exists, mark the resolved vulnerability in the parent path as fixed.

[0017] Determine whether there are sub-paths in the path whose number of scans is greater than a second preset value. If so, perform vulnerability scanning on the files in the sub-path and mark the detected vulnerabilities as unpatched.

[0018] Optionally, if the path is classified as an inactive development path, then marking the status of vulnerabilities scanned from each path according to the path category includes:

[0019] Determine the similarity between the inactive development path and the active development path within the same project, and identify paths that exceed a first similarity threshold as similar paths;

[0020] Compare the similarity of the file lists under each of the aforementioned similar paths, and determine the path with the highest similarity as the other branch path;

[0021] By comparing the vulnerability information in the inactive development path and the other branch paths, if the same vulnerability information exists, the same vulnerability that has been resolved in the other branch path will be marked as fixed.

[0022] Optionally, marking the status of vulnerabilities detected by each path according to the path category further includes:

[0023] If other branch paths of the inactive development path cannot be determined, it is determined whether the inactivity time of the inactive development path exceeds a preset period. If it does, the vulnerability in the inactive development path is marked as not requiring processing.

[0024] Optionally, the method further includes:

[0025] The vulnerability information for each path is statistically analyzed, and vulnerabilities whose status is deleted or do not require processing are identified as invalid vulnerabilities.

[0026] According to another aspect of the present invention, a code vulnerability marking device is provided, wherein the device comprises:

[0027] The path acquisition unit is suitable for acquiring code paths that contain unpatched vulnerabilities and have been scanned less than a first preset value, based on the code scanning history.

[0028] The category determination unit is adapted to determine the category of a path, wherein the path category includes any of the following: active development path, deleted path, and inactive development path;

[0029] A status marking unit is adapted to mark the status of vulnerabilities detected by each of the paths according to the category of the path.

[0030] Optionally, the status includes any of the following: repaired, not repaired, cannot be repaired, deleted, other paths have been repaired, no processing required.

[0031] Optionally, if the path category is a development active path, then the status marking unit is adapted to:

[0032] Perform vulnerability scanning on the active development paths and mark the detected vulnerabilities as unpatched.

[0033] Optionally, if the path is classified as a deleted path, the status marking unit is adapted to:

[0034] Mark vulnerabilities in deleted paths as deleted.

[0035] Optionally, if the path is classified as an inactive development path, the status marking unit is adapted to:

[0036] Based on the code scanning history, obtain the paths in the inactive development path that have been scanned more than the second preset value;

[0037] Determine whether the path with more than a second preset value has a parent path. If it does, compare the vulnerability information of the parent path. If the same vulnerability exists, mark the resolved vulnerability in the parent path as fixed.

[0038] Determine whether there are sub-paths in the path whose number of scans is greater than a second preset value. If so, perform vulnerability scanning on the files in the sub-path and mark the detected vulnerabilities as unpatched.

[0039] Optionally, if the path is classified as an inactive development path, the status marking unit is adapted to:

[0040] Determine the similarity between the inactive development path and the active development path within the same project, and identify paths that exceed a first similarity threshold as similar paths;

[0041] Compare the similarity of the file lists under each of the aforementioned similar paths, and determine the path with the highest similarity as the other branch path;

[0042] By comparing the vulnerability information in the inactive development path and the other branch paths, if the same vulnerability information exists, the same vulnerability that has been resolved in the other branch path will be marked as fixed.

[0043] Optionally, the state marking unit is further adapted to:

[0044] If other branch paths of the inactive development path cannot be determined, it is determined whether the inactivity time of the inactive development path exceeds a preset period. If it does, the vulnerability in the inactive development path is marked as not requiring processing.

[0045] Optionally, the device further includes a statistical unit, adapted to:

[0046] The vulnerability information for each path is statistically analyzed, and vulnerabilities whose status is deleted or do not require processing are identified as invalid vulnerabilities.

[0047] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform any of the methods described above.

[0048] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores one or more programs that, when executed by a processor, implement the method described above.

[0049] As described above, the code vulnerability marking scheme disclosed in this invention includes: obtaining code paths with a scan count lower than a first preset value and containing unpatched vulnerabilities based on code scanning history; determining the category of the path, wherein the path category includes any one of the following: active development path, deleted path, and inactive development path; and marking the status of vulnerabilities scanned on each path according to the path category. By implementing the above scheme to periodically mark vulnerabilities, some invalid vulnerabilities, such as deleted or unnecessary vulnerabilities, can be excluded from the statistics, thereby obtaining more reasonable vulnerability statistics information.

[0050] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0051] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0052] Figure 1 A flowchart illustrating a code vulnerability marking method according to an embodiment of the present invention is shown;

[0053] Figure 2 A schematic diagram of a code vulnerability marking device according to an embodiment of the present invention is shown;

[0054] Figure 3 A schematic diagram of the structure of an electronic device according to an embodiment of the present invention is shown;

[0055] Figure 4 A schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention is shown. Detailed Implementation

[0056] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0057] Figure 1 A flowchart illustrating a code vulnerability marking method according to an embodiment of the present invention is shown; the method includes:

[0058] Step S110: Based on the code scanning history, obtain the code paths that have been scanned less than a first preset value and contain unpatched vulnerabilities.

[0059] In identifying branch paths, the following situations may arise: improper development practices, such as directly copying files to create new branches (making it impossible to obtain the branch source from logs); multiple branch pulls requiring repeated comparisons; and even branch deletion. These issues can lead to the inability to accurately determine which branches are genuine and which paths have been abandoned and development has ceased.

[0060] To accurately determine the aforementioned path information and obtain more comprehensive path and vulnerability labeling results, paths with few scans and low scanning activity are identified from the scanning history to determine which paths may not require special attention. Specifically, paths with fewer scans than a first preset value are identified as inactive, and these inactive paths are then analyzed and processed.

[0061] Step S120: Determine the category of the path, which includes any of the following: active development path, deleted path, and inactive development path.

[0062] In scanning inactive paths, the paths were further categorized for faster processing, facilitating the subsequent use of different strategies to mark vulnerabilities in various paths.

[0063] Step S130: Mark the status of the vulnerabilities scanned by each path according to the category of the path.

[0064] To improve targeting, different processing strategies are adopted for different path categories.

[0065] In summary, the code vulnerability marking method disclosed in this embodiment first obtains code paths with a scan count lower than a first preset value and containing unpatched vulnerabilities based on the code scanning history; then, it determines the category of the path, which includes any of the following categories: active development path, deleted path, and inactive development path; finally, it marks the status of the vulnerabilities scanned on each path according to the path category. By implementing the above scheme to periodically mark vulnerabilities, some invalid vulnerabilities, such as deleted or unnecessary vulnerabilities, can be excluded from the statistics, thereby obtaining more reasonable vulnerability statistics information.

[0066] In one embodiment, the status includes any of the following: repaired, not repaired, cannot be repaired, deleted, other paths have been repaired, no action required.

[0067] In current general code scanning systems, the status of vulnerabilities can be divided into: patched, unpatched, and vulnerabilities that are not intended to be patched or cannot be patched due to reasons such as not being written by the user or the risk of handling them. For the convenience of subsequent statistics, this embodiment also includes vulnerabilities in the following three states: deleted, other branches have been patched, and vulnerabilities that do not need to be handled because they are zombie vulnerabilities.

[0068] In one embodiment, if the path category is an active development path, then step S130 of marking the status of vulnerabilities scanned by each path according to the path category includes: performing vulnerability scanning on the active development path and marking the scanned vulnerabilities as unpatched.

[0069] If the path is an active development path, it means that the path belongs to the normal development path, and the vulnerabilities under the path are marked normally.

[0070] In one embodiment, if the path is classified as a deleted path, then step S130 of marking the status of vulnerabilities scanned by each path according to the path category includes: marking vulnerabilities in deleted paths as deleted.

[0071] A deleted path indicates that the vulnerability in that path does not require handling and can simply be marked as deleted.

[0072] In one embodiment, if the path is classified as an inactive development path, then step S130 of marking the status of the vulnerabilities scanned by each path according to the path category includes: obtaining paths in the inactive development path with a scan count greater than a second preset value according to the code scanning history.

[0073] Determine whether the path with more than a second preset value has a parent path. If it does, compare the vulnerability information of the parent path. If the same vulnerability exists, mark the resolved vulnerability in the parent path as fixed.

[0074] Determine whether there are sub-paths in the path whose number of scans is greater than a second preset value. If so, perform vulnerability scanning on the files in the sub-path and mark the detected vulnerabilities as unpatched.

[0075] Setting the number of scans to be greater than the second preset value is to find actively scanned paths. If the parent path is actively scanned and contains the same vulnerability, it indicates that the vulnerability in the inactive development path has been fixed by the parent path. If a child path exists, it is a branch of the actively scanned path, which should be an update of the development code files, and is handled normally.

[0076] In one embodiment, if the path is classified as an inactive development path, then step S130 of marking the status of the vulnerabilities scanned by each path according to the path category includes: determining the similarity between the inactive development path and the active development path within the same project, and determining paths that exceed a first similarity threshold as similar paths.

[0077] By comparing the similarity of the file lists under each of the aforementioned similar paths, the path with the highest similarity is identified as another branch path.

[0078] By comparing the vulnerability information in the inactive development path and the other branch paths, if the same vulnerability information exists, the same vulnerability that has been resolved in the other branch path will be marked as fixed.

[0079] In this embodiment, the algorithm for obtaining similar path names can be the LCS algorithm, where the Longest Common Substring algorithm is used to obtain the longest common part in two path names, thereby determining the similarity between the two paths. Then, based on the file list in the two similar paths, the most similar code path is determined. Finally, by comparing the vulnerability situation of the most similar path, it is determined whether the vulnerability in the inactive development path has been fixed.

[0080] In one embodiment, step S130 of marking the status of vulnerabilities scanned by each path according to the category of the path further includes: if other branch paths of the inactive development path cannot be determined, determining whether the inactivity time of the inactive development path exceeds a preset period; if it exceeds, marking the vulnerabilities in the inactive development path as not requiring processing.

[0081] In one embodiment, the method further includes: statistically analyzing vulnerability information for each path, and identifying vulnerabilities in the vulnerability information that are in a deleted or no-processing state as invalid vulnerabilities.

[0082] By marking vulnerabilities that do not require processing or have been deleted, they will not be included in subsequent statistics, resulting in more reasonable data and giving users a more accurate understanding of the true situation of vulnerabilities, which facilitates subsequent planning and execution.

[0083] Figure 2 A schematic diagram of a code vulnerability marking device according to an embodiment of the present invention is shown; the device 200 includes:

[0084] The path acquisition unit 210 is adapted to acquire, based on the code scanning history, code paths that have been scanned less than a first preset value and contain unpatched vulnerabilities.

[0085] The category determination unit 220 is adapted to determine the category of a path, wherein the path category includes any of the following: active development path, deleted path, and inactive development path.

[0086] The status marking unit 230 is adapted to mark the status of vulnerabilities scanned by each path according to the category of the path.

[0087] The above approach can accurately mark and statistically analyze vulnerability status, thereby obtaining more reasonable remediation rate data, improving the accuracy of code scanning results, and accelerating the processing of static scanning data.

[0088] In one embodiment, the status includes any of the following: repaired, not repaired, cannot be repaired, deleted, other paths have been repaired, no action required.

[0089] In one embodiment, if the path category is an active development path, then the status marking unit 230 is adapted to:

[0090] Perform vulnerability scanning on the active development paths and mark the detected vulnerabilities as unpatched.

[0091] In one embodiment, if a path is classified as a deleted path, the status marking unit 230 is adapted to mark the vulnerability in the deleted path as deleted.

[0092] In one embodiment, if the path is classified as an inactive development path, the status marking unit 230 is adapted to: obtain paths in the inactive development path with a scan count greater than a second preset value based on the code scanning history; determine whether the path with a scan count greater than the second preset value has a parent path; if it does, compare the vulnerability information of the parent path; if the same vulnerability exists, mark the resolved vulnerability in the parent path as fixed; determine whether the path with a scan count greater than the second preset value has a sub-path; if it does, perform vulnerability scanning on the files in the sub-path and mark the scanned vulnerabilities as unfixed.

[0093] In one embodiment, if a path is classified as an inactive development path, the status marking unit 230 is adapted to: determine the similarity between the inactive development path and the active development path within the same project, and identify paths exceeding a first similarity threshold as similar paths; compare the similarity of file lists under each similar path, and identify the path with the highest similarity as other branch paths; compare the vulnerability information in the inactive development path and the other branch paths, and if there is the same vulnerability information, mark the same vulnerability that has been resolved in the other branch path as fixed.

[0094] In one embodiment, the status marking unit 230 is further adapted to: if other branch paths of the inactive development path cannot be determined, determine whether the inactivity time of the inactive development path exceeds a preset period; if it exceeds the preset period, mark the vulnerability in the inactive development path as not requiring processing.

[0095] In one embodiment, the apparatus further includes a statistics unit, adapted to: count vulnerability information for each of the paths, and determine vulnerabilities in the vulnerability information that are in a deleted or no-processing state as invalid vulnerabilities.

[0096] In summary, the code vulnerability marking scheme disclosed in this invention includes: obtaining code paths with a scan count lower than a first preset value and containing unpatched vulnerabilities based on code scanning history; determining the category of the path, wherein the path category includes any one of the following: active development path, deleted path, and inactive development path; and marking the status of vulnerabilities scanned on each path according to the path category. By implementing the above scheme to periodically mark vulnerabilities, some invalid vulnerabilities, such as deleted or unnecessary vulnerabilities, can be excluded from the statistics, thereby obtaining more reasonable vulnerability statistics information.

[0097] It should be noted that:

[0098] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. Various general-purpose devices can also be used in conjunction with the teachings herein. The required structure for constructing such devices is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0099] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0100] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0101] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0102] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0103] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the code vulnerability marking device according to embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0104] For example, Figure 3 A schematic diagram of an electronic device according to an embodiment of the present invention is shown. The electronic device 300 includes a processor 310 and a memory 320 arranged to store computer-executable instructions (computer-readable program code). The memory 320 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory 320 has a storage space 330 for storing computer-readable program code 331 for performing any of the method steps described above. For example, the storage space 330 for storing computer-readable program code may include various computer-readable program codes 331 respectively for implementing the various steps in the methods described above. The computer-readable program code 331 can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, CDs, memory cards, or floppy disks. Such computer program products are typically, for example... Figure 4 The aforementioned computer-readable storage medium. Figure 4A schematic diagram of a computer-readable storage medium according to an embodiment of the present invention is shown. The computer-readable storage medium 400 stores computer-readable program code 331 for performing the method steps according to the present invention, which can be read by the processor 310 of an electronic device 300. When the computer-readable program code 331 is executed by the electronic device 300, it causes the electronic device 300 to perform the various steps of the method described above. Specifically, the computer-readable program code 331 stored in the computer-readable storage medium can perform the methods shown in any of the above embodiments. The computer-readable program code 331 can be compressed in a suitable form.

[0105] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

Claims

1. A method for marking code vulnerabilities, wherein, The method includes: Based on the code scanning history, obtain code paths that have been scanned less than a first preset value and contain unpatched vulnerabilities; The path category is determined, and the path category includes any of the following: active development path, deleted path, and inactive development path; The status of vulnerabilities detected by each path is marked according to the category of the path. The status includes any of the following: fixed, not fixed, cannot be fixed, deleted, other paths have been fixed, no action required. Wherein, if the path is classified as an inactive development path, the step of marking the status of vulnerabilities scanned by each path according to the path category includes: according to the code scanning history, obtaining paths in the inactive development path with a scanning count greater than a second preset value; determining whether the path with a scanning count greater than the second preset value has a parent path, and if it does, comparing the vulnerability information of the parent path, and if the same vulnerability exists, marking the resolved vulnerability in the parent path as fixed; determining whether the path with a scanning count greater than the second preset value has a sub-path, and if it does, performing vulnerability scanning on the files in the sub-path, and marking the scanned vulnerabilities as unfixed; Alternatively, if the path is classified as an inactive development path, then marking the status of vulnerabilities scanned by each path according to the path category includes: determining the similarity between the inactive development path and the active development path within the same project, and identifying paths exceeding a first similarity threshold as similar paths; comparing the similarity of file lists under each similar path, and identifying the path with the highest similarity as other branch paths; comparing the vulnerability information in the inactive development path and the other branch paths, and if there is identical vulnerability information, marking the identical vulnerabilities that have been resolved in the other branch path as fixed.

2. The method as described in claim 1, wherein, If the path category is an active development path, then marking the status of vulnerabilities scanned by each path according to the path category includes: Perform vulnerability scanning on the active development paths and mark the detected vulnerabilities as unpatched.

3. The method as described in claim 1, wherein, If the path is classified as a deleted path, then marking the status of the vulnerabilities detected by each path according to the path category includes: Mark vulnerabilities in deleted paths as deleted.

4. The method of claim 1, wherein, The step of marking the status of vulnerabilities detected by each path according to the category of the path also includes: If other branch paths of the inactive development path cannot be determined, it is determined whether the inactivity time of the inactive development path exceeds a preset period. If it does, the vulnerability in the inactive development path is marked as not requiring processing.

5. The method according to any one of claims 1-4, wherein, The method further includes: The vulnerability information for each path is statistically analyzed, and vulnerabilities whose status is deleted or do not require processing are identified as invalid vulnerabilities.

6. A code vulnerability marking device, wherein, The device includes: The path acquisition unit is suitable for acquiring code paths that contain unpatched vulnerabilities and have been scanned less than a first preset value, based on the code scanning history. The category determination unit is adapted to determine the category of a path, wherein the category of the path includes any of the following: active development path, deleted path, and inactive development path; A status marking unit is adapted to mark the status of vulnerabilities scanned by each path according to the category of the path, wherein the status includes any of the following: fixed, not fixed, cannot be fixed, deleted, other paths have been fixed, no processing required; Wherein, if the path is classified as an inactive development path, the status marking unit is adapted to: obtain paths in the inactive development path with a scan count greater than a second preset value according to the code scanning history; determine whether the path with a scan count greater than the second preset value has a parent path; if it does, compare the vulnerability information of the parent path; if the same vulnerability exists, mark the resolved vulnerability in the parent path as fixed; determine whether the path with a scan count greater than the second preset value has a sub-path; if it does, perform vulnerability scanning on the files in the sub-path and mark the scanned vulnerabilities as unfixed. Alternatively, if the path is classified as an inactive development path, the status marking unit is adapted to: determine the similarity between the inactive development path and the active development path within the same project, and identify paths exceeding a first similarity threshold as similar paths; compare the similarity of file lists under each similar path, and identify the path with the highest similarity as other branch paths; compare the vulnerability information in the inactive development path and the other branch paths, and if there is the same vulnerability information, mark the same vulnerability that has been resolved in the other branch path as fixed.

7. The apparatus of claim 6, wherein, If the path category is an active development path, then the status marking unit is adapted to: Perform vulnerability scanning on the active development paths and mark the detected vulnerabilities as unpatched.

8. The apparatus of claim 6, wherein, If the path is classified as a deleted path, then the status marking unit is adapted to: Mark vulnerabilities in deleted paths as deleted.

9. The apparatus of claim 6, wherein, The status marking unit is also adapted to: If other branch paths of the inactive development path cannot be determined, it is determined whether the inactivity time of the inactive development path exceeds a preset period. If it does, the vulnerability in the inactive development path is marked as not requiring processing.

10. The apparatus according to any one of claims 6-9, wherein, The device further includes a statistical unit, adapted to: The vulnerability information for each path is statistically analyzed, and vulnerabilities whose status is deleted or do not require processing are identified as invalid vulnerabilities.

11. An electronic device, wherein, The electronic device includes: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the method as described in any one of claims 1-5.

12. A computer-readable storage medium, wherein, The computer-readable storage medium stores one or more programs that, when executed by a processor, implement the method as described in any one of claims 1-5.

Images