Open source software reuse identification method, system and device and storage medium

Abstract

The invention discloses an open source software reuse identification method, system and device and a storage medium, and relates to the field of computers. And identifying license information of the open source code file under each target root directory in the to-be-detected software project. And according to a recursive sequence from the bottommost directory to the target root directory, sequentially taking the directories at all levels as the current directory. And determining the suspicion score of the current directory according to the suspicion score of each subdirectory under the current directory and the license information of each open source code file directly located at the next level of the current directory. And taking the target root directory with the suspicious degree score reaching a preset score value as a suspicious directory with open source software reuse. The method is not influenced by the change of the code structure of the open source software, the possibility that the open source software is reused in the target root directory is integrally analyzed at the path level according to the license information, the open source software can be effectively identified, and the method has good cross-platform and cross-linguistic properties.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method, system, apparatus and storage medium for identifying open-source software reuse. Background Technology

[0002] In recent years, the use of open-source software in software project development has increased significantly. However, the use of open-source software can also pose risks to the long-term maintainability and security of software projects. When open-source software has issues such as license violations or security vulnerabilities, the security of software projects using that open-source software will also be affected. Therefore, it is necessary to identify the open-source software used in software projects to determine its license compliance and to promptly identify and fix security vulnerabilities.

[0003] Currently, most common open-source software identification methods rely on pure code or hash value comparisons, which are easily affected by changes in code structure. They are difficult to reliably identify rewritten or repackaged open-source software, and the accuracy of identification also needs to be improved. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, device, and storage medium for identifying open-source software reuse. This method is unaffected by changes to the code structure of open-source software. Based on license information, it analyzes the overall path hierarchy to identify the possibility of open-source software reuse in the target root directory. It can effectively identify open-source software and has good cross-platform and cross-language compatibility.

[0005] To address the aforementioned technical problems, this invention provides a method for identifying open-source software reuse, comprising:

[0006] Identify the license information of all open-source code files in the root directory of each target in the software project to be tested;

[0007] For each target root directory, following the recursive order from the lowest level directory of the target root directory to the end of the target root directory, each level of directory is taken as the current directory.

[0008] The suspicion score of the current directory is determined based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file located directly below the current directory.

[0009] After determining the suspicion score of each target root directory, the target root directories whose suspicion scores reach the preset score value are regarded as suspicious directories where open source software reuse exists.

[0010] Optionally, when the current directory is the lowest-level directory, determining the suspicion score of the current directory based on the license information of each open-source code file directly below the current directory includes:

[0011] Based on the license information of each open-source code file, determine the number of license types and the number of open-source code files corresponding to each license.

[0012] The suspicion score of the current directory is determined based on the number of license types and the number of open-source code files for each type.

[0013] Optionally, when the current directory is a directory other than the lowest-level directory, determining the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file directly below the current directory includes:

[0014] The suspicion score of each subdirectory is determined based on its suspicion score and the total number of code files contained in each subdirectory.

[0015] Each of the open-source code files is used as an aggregate file. Based on the license information of each of the open-source code files, the number of license types corresponding to the aggregate file and the number of open-source code files corresponding to each license are determined.

[0016] The suspicion score of the aggregated file is determined based on the number of license types corresponding to the aggregated file and the number of each open-source code file;

[0017] The suspicion score of the current directory is determined based on the suspicion score of the subdirectory, the first preset weight corresponding to the suspicion score of the subdirectory, the suspicion score of the aggregated file, and the second preset weight corresponding to the suspicion score of the aggregated file.

[0018] Optionally, determining the suspiciousness score of the current directory based on the number of license types and the number of open-source code files includes:

[0019] When the number of license types is greater than 1, the suspicion score of the lowest level directory is determined based on the number of license types and the number of open source code files for each type using a first preset suspicion score formula.

[0020] The first preset scoring formula is: ;

[0021] in, Score the suspiciousness level. The number of the aforementioned license types, Let be the number of open-source code files corresponding to the i-th license;

[0022] When the number of license types is equal to 1, the suspicion score is determined to be 1;

[0023] When the number of license types is equal to 0, the suspicion score is determined to be 0.

[0024] Optionally, determining the suspiciousness score of the subdirectory includes:

[0025] Based on the suspicion score of each subdirectory and the total number of files, the suspicion score of each subdirectory is obtained using the second preset scoring formula;

[0026] The second preset scoring formula is: ;

[0027] in, Score the suspiciousness of the subdirectories. The number of subdirectories included in the current directory. Score the suspiciousness of the i-th subdirectory. This represents the total number of files corresponding to the i-th subdirectory;

[0028] The determination of the suspiciousness score of the aggregated files includes:

[0029] Based on the number of license types corresponding to the aggregated file and the number of each open-source code file, the suspicion score of the aggregated file is obtained using the third preset scoring formula;

[0030] The third preset scoring formula is: ;

[0031] in, Score the suspiciousness of the aggregated files. The number of license types corresponding to the aggregated file. The number of open-source code files in the aggregate file corresponding to the i-th license;

[0032] Determining the suspiciousness score of the current directory includes:

[0033] Based on the subdirectory suspicion score, the first preset weight, the aggregated file suspicion score, and the second preset weight, the suspicion score of the current directory is obtained using the fourth preset scoring formula.

[0034] The fourth preset scoring formula is: ;

[0035] in, Score the suspiciousness of the current directory. For the first preset weight, This is the second preset weight.

[0036] Optionally, before identifying the license information of all open-source code files in each target root directory of the software project to be detected, the method further includes:

[0037] Upon receiving incremental detection information, determine the detection path specified by the incremental detection information, and determine whether the detection path is a complete path from the root directory to the lowest level directory;

[0038] If so, then each root directory in the detection path will be taken as the target root directory;

[0039] If not, then determine the complete path to which the detection path belongs, and take each root directory in the complete path as the target root directory;

[0040] After determining the target root directory, proceed to the step of identifying the license information of all open-source code files in each target root directory of the software project to be tested.

[0041] Optionally, before identifying the license information of all open-source code files in each target root directory of the software project to be detected, the method further includes:

[0042] Receive the code repository address input by the user, clone the address in the code repository to the local machine, and use it as the project identification address;

[0043] After determining that the project identification address meets the project validity verification conditions, the software project corresponding to the project identification address is taken as the software project to be tested, and the process proceeds to the step of identifying the license information of all open source code files in each target root directory of the software project to be tested.

[0044] To address the aforementioned technical problems, the present invention also provides an open-source software reuse identification system, comprising:

[0045] The license identification module is used to identify the license information of all open-source code files in the root directory of each target in the software project to be tested;

[0046] The current directory determination module is used to, for each target root directory, sequentially take each level of directory as the current directory in a recursive order starting from the lowest level directory of the target root directory and ending at the target root directory;

[0047] The scoring determination module is used to determine the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open source code file located directly below the current directory.

[0048] The reuse detection module is used to identify, after determining the suspicion score of each target root directory, the target root directories whose suspicion scores reach a preset score value as suspicious directories where open source software reuse exists.

[0049] To address the aforementioned technical problems, the present invention also provides an identification device for open-source software reuse, comprising:

[0050] Memory, used to store computer programs;

[0051] A processor, used to implement the steps of any of the above-described open-source software reuse identification methods when executing the computer program.

[0052] To solve the above-mentioned technical problems, the present invention also provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-mentioned open-source software reuse identification methods.

[0053] The beneficial effects of this invention lie in providing a method, system, apparatus, and storage medium for identifying open-source software reuse. It identifies the license information of open-source code files in each target root directory of the software project to be detected. Following a recursive order from the lowest-level directory to the target root directory, each level of directory is sequentially designated as the current directory. Based on the suspicion score of each subdirectory under the current directory and the license information of each open-source code file directly below the current directory, a suspicion score for the current directory is determined. Target root directories with suspicion scores reaching a preset value are designated as suspicious directories where open-source software reuse exists. Unaffected by changes to the code structure of the open-source software, this method analyzes the possibility of open-source software reuse in the target root directory at the path level based on license information, effectively identifying open-source software and exhibiting good cross-platform and cross-language compatibility. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 A first flowchart of an open-source software reuse identification method provided by the present invention;

[0056] Figure 2 A second flowchart of an open-source software reuse identification method provided by the present invention;

[0057] Figure 3 This is a schematic diagram of a portion of the directory structure of the software project to be tested provided by the present invention.

[0058] Figure 4 A schematic diagram of the structure of an open-source software reuse identification system provided by the present invention;

[0059] Figure 5 This is a schematic diagram of the structure of an open-source software reuse identification device provided by the present invention. Detailed Implementation

[0060] The core of this invention is to provide a method, system, device, and storage medium for identifying open-source software reuse. It is not affected by changes to the code structure of open-source software. Based on license information, it analyzes the possibility of open-source software reuse in the target root directory at the path level. It can effectively identify open-source software and has good cross-platform and cross-language compatibility.

[0061] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] This application uses the license information of each open-source code file in the software project under test as the basis for analysis. It employs a recursive, layer-by-layer approach to determine the suspiciousness score of each directory level from the lowest level to the target root directory. It is not limited to identification at the level of a single code file, allowing open-source reuse risks to be revealed level by level in the overall path structure. This helps to discover deeply nested but high-risk reuse locations. Furthermore, it is unaffected by changes to the code structure of open-source software and is not limited by compilation language or platform, thus exhibiting good applicability.

[0063] Please refer to Figure 1 , Figure 1 A first flowchart of an open-source software reuse identification method provided by the present invention includes:

[0064] S101. Identify the license information of all open-source code files in the root directory of each target in the software project to be tested.

[0065] In this application, the target root directories in the software project to be tested are used as the identification objects of the open-source software reuse identification method, and the open-source software reuse locations in the project to be tested are identified at the path level. The target root directories can be all the root directories in the software project to be tested, or they can be some of the root directories in the software project to be tested, and can be set according to actual needs. This application does not make any special limitations on this.

[0066] For example, when initially identifying open-source software reuse, all root directories in the software project to be detected are used as target root directories; subsequently, if the directory structure of some root directories changes, incremental identification can be performed on the changed root directories, that is, the changed root directories are used as target root directories.

[0067] The method for determining the software project to be tested and the target root directory will be introduced in subsequent embodiments, and will not be repeated here.

[0068] This application takes into account that while the structure or content of open-source code files corresponding to open-source software may change, the license information carried by the open-source code files (including license type information and declaration content, etc.) remains relatively stable. Based on the license information of the open-source code files in the target root directory, the types of licenses involved in the target root directory and the number of each type of license can be determined, thereby reflecting the types and quantity of open-source software existing in the target root directory. That is, by using information such as the types and quantity of licenses in the target root directory, the number of types of open-source software in the target root directory and the complexity of their distribution can be measured, thereby identifying the phenomenon of open-source software reuse, unaffected by the rewriting or repackaging of the open-source code files corresponding to the open-source software.

[0069] Based on the above considerations, this application first obtains the license information of all open-source code files in each target root directory. This facilitates subsequent assessment of the likelihood of open-source software reuse within the target root directory based on the license information. This application does not impose any specific limitations on the implementation method for identifying the license information of each open-source code file. For example, it can be implemented using license detection tools such as Scancode.

[0070] S102. For each target root directory, following the recursive order from the lowest level directory of the target root directory to the target root directory, each level of directory is taken as the current directory.

[0071] S103. Determine the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file located at the next level directly below the current directory.

[0072] This application uses the directory structure of the target root directory and the license information of each open-source code file under the target root directory as the basis for analysis. It adopts a scoring method that recursively analyzes the suspicion of open-source software reuse in the target root directory from the lowest level directory to the root directory.

[0073] Specifically, the current directory is determined by recursively assigning each level of directory to the target root directory, starting from the lowest level and ending at the target root directory. The next level of the current directory includes a certain number of subdirectories and / or a certain number of open-source code files. Both subdirectories and open-source code files affect the suspicion score of the current directory. Therefore, after determining the current directory, its suspicion score is determined based on the suspicion scores of each level of subdirectory and the license information of each open-source code file directly below the current directory. The suspicion score of each subdirectory is determined based on its license information before calculating the suspicion score of the current directory.

[0074] As can be seen, the license information of subdirectories and open-source code files located one level below the current directory affects the suspicion score of the current directory. Similarly, the final suspicion score of the target root directory is a comprehensive suspicion score determined by integrating the license information of all levels of subdirectories and open-source code files, thus achieving path-level identification of open-source software reuse.

[0075] In summary, the suspiciousness scoring mechanism in this application allows the risks of open-source software reuse to be displayed hierarchically within the directory structure. This helps identify deeply nested directories with high reuse risks within the root directory, providing strong visualization support and tracing capabilities. Furthermore, the suspiciousness score of the target root directory is related to the license information of each open-source code file, regardless of the specific structure and code of the open-source code files. As long as the open-source software's source code files carry a license, it can reliably identify rewritten or repackaged open-source reuse components. Moreover, this identification method does not depend on specific language syntax or compilation paths, exhibiting good cross-platform and cross-language adaptability, and can be widely applied to the identification of various types of open-source software reuse.

[0076] S104. After determining the suspicion score of each target root directory, the target root directories whose suspicion scores reach the preset score value are regarded as suspicious directories where open source software reuse exists.

[0077] Finally, the suspicion score of each target root directory is compared with a preset score value. Target root directories with suspicion scores reaching the preset score are identified as suspicious directories where open-source software reuse exists. The preset score can be set according to actual needs, and this application does not impose any special restrictions on it. For example, through experimental analysis, the accuracy of open-source software reuse identification is relatively high when the preset score value is 0.3.

[0078] After obtaining the suspicion scores for each target root directory, the scores can be sorted, filtered, formatted, and output in a standardized manner to generate a standardized report for auditors to review, enabling the tracking and recording of paths where open-source software is reused. The output includes suspicious directories, the license types of open-source code files within those directories, and the suspicion scores corresponding to those directories.

[0079] Table 1. Statistical Table of Open Source Software Reuse Identification Results

[0080] warehouse name Result path Verifiable path Verifiability Verification correct accuracy Warehouse 1 18 17 94.44% 17 100% Warehouse 2 29 27 93.10% 27 100% Warehouse 3 11 8 72.73% 8 100% Warehouse 4 18 17 94.44% 17 100% Warehouse 5 15 14 93.33% 14 100% Warehouse 6 14 14 100% 12 85.71% total 105 97 92.38% 95 97.94%

[0081] Referring to Table 1, this application selected a representative portion of code repositories to identify open-source software reuse in the software projects to be tested. The results show that out of 105 suspicious paths, 97 paths were effectively verifiable (verifiability rate 92.38%). Of the verifiable paths, 95 were confirmed to indeed contain open-source code reuse after manual verification, achieving a verification accuracy rate of 97.94%. Most repositories achieved a 100% verification accuracy rate, demonstrating excellent overall hit rate performance. This result indicates that the present invention has high verifiability and accuracy in practical applications. Using the method provided in this application, suspicious paths that may reuse open-source software in the software projects to be tested can be identified efficiently and accurately without manual intervention.

[0082] In summary, the open-source software reuse identification method provided by this invention is unaffected by changes to the code structure of open-source software. Based on license information, it analyzes the overall path hierarchy to identify the possibility of open-source software reuse in the target root directory. It can effectively identify open-source software, assess the complexity of open-source software distribution in software projects, solve the problems of difficulty in locating open-source software in complex dependency structures and ambiguity in risk identification, and has good cross-platform and cross-language compatibility.

[0083] Furthermore, unlike previous binary judgment methods that relied solely on "hit" or "miss," this invention introduces a risk quantification mechanism based on path granularity. It comprehensively assesses multiple factors such as path complexity, license type, and cross-references to classify and determine the risk level of each directory. This provides users with specific paths containing open-source components, filenames within those paths, and their corresponding license information. This allows users to not only identify the distribution of open-source components in a project but also understand the risk level of each path, thus providing quantitative support for subsequent compliance audits and risk management.

[0084] For the various levels of directories of the software project to be tested, the lowest level directory usually only includes a certain number of code files (including open source code files corresponding to open source software, as well as code files of other non-open source software). Other levels of directories, excluding the lowest level directory, include a certain number of code files and / or a certain number of subdirectories. Therefore, the specific process for determining the suspiciousness score is different, which will be introduced separately below.

[0085] The process of determining the suspicion level score for the lowest level directory is described below.

[0086] As an optional implementation, when the current directory is the lowest-level directory, the suspicion score of the current directory is determined based on the license information of each open-source code file directly below the current directory, including:

[0087] Based on the license information of each open-source code file, determine the number of license types and the number of open-source code files corresponding to each license.

[0088] The suspicion score of the current directory is determined based on the number of license types and the number of open-source code files for each type.

[0089] This application takes into account that the more types of licenses involved in the bottom-level directory and the more open-source code files corresponding to each license, the more types and quantities of open-source software are used in the bottom-level directory, and the higher the risk of open-source software reuse in the path where the bottom-level directory is located.

[0090] Therefore, in this embodiment, the number of license types and the number of open-source code files corresponding to each license are determined based on the license information of each open-source code file at the next level down from the lowest-level directory. The license information includes the license type information and declaration content of the open-source code files. By determining whether the license type information is consistent, the number of license types corresponding to the lowest-level directory and the number of open-source code files corresponding to each license can be determined. Then, a suspicion score is determined based on the number of license types and the number of open-source code files corresponding to each license.

[0091] Please refer to Figure 2 , Figure 2 The second flowchart of an open-source software reuse identification method provided by the present invention is shown.

[0092] As an optional implementation, the suspicion score of the current directory is determined based on the number of license types and the number of open-source code files, including:

[0093] When the number of license types is greater than 1, the suspicion score of the lowest level directory is determined based on the number of license types and the number of open source code files, using the first preset suspicion score formula.

[0094] The first preset scoring formula is: ;

[0095] in, Score the suspiciousness level. For the number of license types, Let be the number of open-source code files corresponding to the i-th license;

[0096] When the number of license types is equal to 1, the suspicion score is determined to be 1;

[0097] When the number of license types is 0, the suspicion score is determined to be 0.

[0098] In this embodiment, the suspicion score of the lowest-level directory is determined based on a pre-determined first preset scoring formula. The more types of licenses involved in the lowest-level directory, the more types of open-source software are used, the higher the risk of open-source software reuse, and the higher the score determined by the first preset scoring formula. Similarly, the more open-source code files, the more open-source software is used, the higher the risk of open-source software reuse, and the higher the score determined by the first preset scoring formula.

[0099] Taking the bottom-level directories A and B as examples, directory A contains 16 code files, 9 of which are open-source. Of these 9 open-source files, 2 are licensed under license type A, 1 each under license types B, C, and D, and 4 under license type E. Directory B contains 40 code files, 3 of which are open-source. Of these 3 open-source files, 1 is licensed under license type F, and 2 are licensed under license type G.

[0100] Based on the first preset scoring formula mentioned above, the suspicion scores for the bottom-level directory A and the bottom-level directory B can be determined as follows:

[0101] ; .

[0102] It is evident that the most basic directory A, which has a relatively larger number of license types and open-source code files, has a higher suspicion score, and the path to which the most basic directory A belongs is also relatively more likely to contain reused open-source software.

[0103] Furthermore, for the case where the number of license types in the lowest-level directory is equal to 1, its suspicion score is determined to be 1; for the case where the number of license types in the lowest-level directory is equal to 0, its suspicion score is determined to be 0. However, since this application is not an open-source software reuse identification at the single file level, but rather at the path level, a suspicion score of 1 or 0 for the lowest-level directory does not necessarily indicate whether open-source software reuse exists or not. Instead, the suspicion score of the entire path is comprehensively judged by combining the suspicion scores of all levels of directories under the path to assess whether open-source software reuse exists.

[0104] The process of determining the suspiciousness score of directories other than the bottom-level directory is described below.

[0105] As an optional implementation, when the current directory is a directory other than the bottom-level directory, the suspicion score of the current directory is determined based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file directly below the current directory, including:

[0106] The suspicion score of each subdirectory is determined based on its suspicion score and the total number of code files contained in each subdirectory.

[0107] Each open-source code file is treated as an aggregate file. Based on the license information of each open-source code file, the number of license types corresponding to the aggregate file and the number of open-source code files corresponding to each license are determined.

[0108] The suspiciousness score of the aggregated file is determined based on the number of license types corresponding to the aggregated file and the number of open source code files.

[0109] The suspicion score of the current directory is determined based on the subdirectory suspicion score, the first preset weight corresponding to the subdirectory suspicion score, the aggregate file suspicion score, and the second preset weight corresponding to the aggregate file suspicion score.

[0110] Considering that the current directory consists of a certain number of subdirectories and directly open-source code files, both of which contribute to the suspicion score of the current directory, a weighted calculation method is used to calculate the suspicion score of the current directory.

[0111] First, for subdirectories, the first suspicion score for each subdirectory is determined based on its suspicion score and the total number of code files contained within it. It's important to note that the total number of files refers to both open-source and non-open-source code files. For each subdirectory within the current directory, its suspicion score is already determined. A higher total number of files indicates a lower proportion of open-source code files and a lower suspicion score.

[0112] Secondly, for the portions of open-source code files located directly below the current directory, these files are treated as aggregate files. The method for determining the suspicion score of aggregate files is similar to that for determining the suspicion score of the lowest-level directory. First, based on the license information of the aggregate files, the number of license types and the number of open-source code files corresponding to each license are determined. Then, based on the number of license types and the number of open-source code files corresponding to the aggregate files, the suspicion score of the aggregate files is determined.

[0113] Finally, the suspicion score of the current directory is determined by weighted calculation based on the subdirectory suspicion score, the first preset weight, the aggregate file suspicion score, and the second preset weight.

[0114] The first and second preset weights can be determined in advance through experiments and set to the values ​​that maximize the accuracy of open-source software reuse recognition, thus ensuring recognition accuracy. The sum of the first and second preset weights is 1. Through multiple experiments, this application found that the open-source software reuse recognition accuracy is relatively high when the first preset weight is 0.1 and the second preset weight is 0.9.

[0115] As an optional implementation, determining the suspiciousness score of a subdirectory includes:

[0116] Based on the suspicion score of each subdirectory and the total number of files, the suspicion score of the subdirectory is obtained using the second preset scoring formula;

[0117] The second preset scoring formula is: ;

[0118] in, Rate the suspiciousness of subdirectories. This represents the number of subdirectories included in the current directory. Score the suspiciousness of the i-th subdirectory. This represents the total number of files corresponding to the i-th subdirectory.

[0119] Determine the suspiciousness score of aggregated documents, including:

[0120] Based on the number of license types corresponding to the aggregated files and the number of open-source code files, the suspicion score of the aggregated files is obtained using the third preset scoring formula;

[0121] The third preset scoring formula is: ;

[0122] in, Score the suspiciousness of the aggregated documents. This represents the number of license types corresponding to the aggregated files. This represents the number of open-source code files in the aggregate file corresponding to the i-th license.

[0123] Determine the suspiciousness score of the current directory, including:

[0124] Based on the subdirectory suspicion score, the first preset weight, the aggregate file suspicion score and the second preset weight, the suspicion score of the current directory is obtained using the fourth preset scoring formula.

[0125] The fourth preset scoring formula is: ;

[0126] in, Rate the suspiciousness of the current directory. As the first preset weight, This is the second preset weight.

[0127] Please refer to Figure 2 , Figure 2 This is a second flowchart of a method for identifying open-source software reuse provided by the present invention. When calculating the suspiciousness score of the outer directory, the fourth preset scoring formula can also be expressed as:

[0128] ;

[0129] in, This indicates the suspiciousness score of the aggregated files. Equivalent to ,1- Corresponding to the first preset weight, Corresponding to the second preset weight.

[0130] In this embodiment, the suspicion score of a subdirectory is determined based on a pre-determined second preset scoring formula, and the suspicion score of an aggregated file is determined based on a third preset scoring formula. The weight allocation of subdirectories and aggregated files is controlled using a first preset weight and a second preset weight. The final suspicion score of the current directory is used to measure the complexity of the license distribution corresponding to the current path, including the quantity and proportion of different types of licenses used interchangeably, thereby reflecting the possibility of open-source reuse at this location and providing a structured quantitative basis for locating open-source contamination risks.

[0131] Please refer to Figure 3 , Figure 3 This is a schematic diagram of a portion of the directory structure of the software project to be tested provided by the present invention. Figure 3Directory A is one of the target root directories of the software project to be tested. The next level of directory A includes open-source code file 1, open-source code file 2, and directory B; the next level of directory B includes directories C and D; both directories C and D are bottom-level directories. Furthermore, following the method described above for calculating the suspicion score of the bottom-level directories, the suspicion score of bottom-level directory C has been determined to be 0.716, and the suspicion score of bottom-level directory D is 0.444. Directory C has a total of 16 files, and directory D has a total of 40 files. Open-source code file 1 and open-source code file 2 have different license types. The following uses... Figure 3 Taking the directory structure described above as an example, the process of calculating the suspicion score of the current directory will be explained.

[0132] As mentioned earlier, the suspicion score of the lowest-level directory has been determined. Following the recursive order from the lowest-level directory to the target root directory, the latest current directory is determined to be directory B. The next level of directory B only includes subdirectories C and D, excluding other directly open-source code files. Therefore, the suspicion score of directory B is consistent with the suspicion score of its corresponding subdirectories, specifically:

[0133] .

[0134] After determining the suspicion score of directory B, the process continues recursively to the next higher level directory, identifying the current directory as directory A. The next level of directory A includes subdirectory B, open-source code file 1, and open-source code file 2. Therefore, the suspicion score of directory A consists of two parts: the suspicion score of the subdirectory and the suspicion score of the aggregated files. Taking a first preset weight of 0.1 and a second preset weight of 0.9 as an example, the specific suspicion score of directory A is as follows:

[0135] .

[0136] Taking a preset score of 0.3 as an example, the path where the target root directory A is located may contain reused open source software. Subsequently, the suspiciousness score of the target root directory A, the corresponding path, the suspiciousness scores of each level of directory, and the license information of the included open source software code can be output for auditors to review.

[0137] In summary, the open-source software reuse identification method provided by this invention can analyze the possibility of open-source software reuse in the target root directory at the path level, effectively assess the complexity of open-source software distribution in software projects, solve the problems of difficulty in locating open-source software in complex dependency structures and ambiguity in risk identification, and has good cross-platform and cross-language compatibility.

[0138] The process of determining the software to be tested and the target root directory is described below.

[0139] As an optional embodiment, before identifying the license information of all open-source code files in each target root directory of the software project to be tested, the method further includes:

[0140] Receive the code repository address input by the user, clone the address in the code repository to the local machine, and use it as the project identification address;

[0141] After determining that the project identification address meets the project validity verification conditions, the software project corresponding to the project identification address is taken as the software project to be tested, and the process proceeds to identify the license information of all open source code files in each target root directory of the software project to be tested.

[0142] In this embodiment, the software project to be detected is determined based on the code repository address provided by the user. The code repository address can be used to locate the code repository containing the software project. The code repository address is cloned locally as the project identification address. After successfully cloning to obtain the project identification address, validity verification conditions can be used to verify the validity of the project identification address to determine whether the project corresponding to the project identification address exists. The software project corresponding to the project identification address is the software project to be detected.

[0143] When the code repository contains the code of multiple software projects, you can also select a specific software project to clone as the software project to be tested by using the code repository address.

[0144] As an optional embodiment, before identifying the license information of all open-source code files in each target root directory of the software project to be tested, the method further includes:

[0145] Upon receiving incremental detection information, determine the detection path specified in the incremental detection information and determine whether the detection path is a complete path from the root directory to the lowest level directory.

[0146] If so, then each root directory in the detection path will be used as the target root directory;

[0147] If not, determine the complete path to which the detection path belongs, and use each root directory in the complete path as the target root directory;

[0148] After determining the target root directory, the next step is to identify the license information of all open-source code files in each target root directory of the software project to be tested.

[0149] This application supports full detection of all target root directories in the software project to be tested, as well as incremental detection of only some target root directories. For example, when initially identifying open-source software reuse, all root directories in the software project to be tested are used as target root directories; subsequently, if the directory structure of some root directories changes, incremental identification can be performed on the changed root directories.

[0150] In this embodiment, during incremental detection, after receiving incremental detection information, the detection path specified by the incremental detection information is determined. The detection path records the directories at each level that need to be incrementally detected. In order to determine the suspicion score of each level of directory based on complete context information, this embodiment also determines whether the detection path is a complete path from the root directory to the lowest level directory. For incomplete detection paths, the complete path to which the detection path belongs is determined, and each root directory in the complete path is used as the target root directory, thereby ensuring the reliability of open source software reuse identification.

[0151] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an open-source software reuse identification system provided by the present invention. The open-source software reuse identification system includes:

[0152] The license identification module 401 is used to identify the license information of all open source code files in the target root directory of the software project to be tested.

[0153] The current directory determination module 402 is used to, for each target root directory, sequentially take each level of directory as the current directory in a recursive order starting from the lowest level directory of the target root directory and ending at the target root directory.

[0154] The scoring determination module 403 is used to determine the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open source code file located directly below the current directory.

[0155] The reuse detection module 404 is used to identify target root directories that have reached a preset score value as suspicious directories where open source software reuse exists after determining the suspiciousness score of each target root directory.

[0156] For a detailed description of the open-source software reuse identification system provided in this application, please refer to the embodiments of the above-mentioned open-source software reuse identification method, which will not be repeated here.

[0157] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of an open-source software reuse identification device provided by the present invention. The open-source software reuse identification device includes:

[0158] Memory 501 is used to store computer programs;

[0159] Processor 502 is used to implement the steps of any of the above-mentioned open-source software reuse identification methods when executing computer programs.

[0160] For a detailed description of the open-source software reuse identification device provided in this application, please refer to the embodiments of the above-mentioned open-source software reuse identification method, which will not be repeated here.

[0161] The present invention also provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described open-source software reuse identification methods.

[0162] For a detailed description of the storage medium provided in this application, please refer to the embodiments of the above-mentioned open-source software reuse identification method, which will not be repeated here.

[0163] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. It should also be noted that in this specification, relational terms such as "first" and "second" are used merely 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, 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, 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, article, or apparatus that includes said element.

[0164] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for identifying open-source software reuse, characterized in that, include: Identify the license information of all open-source code files in the root directory of each target in the software project to be tested; For each target root directory, following the recursive order from the lowest level directory of the target root directory to the end of the target root directory, each level of directory is taken as the current directory. The suspicion score of the current directory is determined based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file located directly below the current directory. After determining the suspicion score of each target root directory, the target root directories whose suspicion scores reach the preset score value are regarded as suspicious directories where open source software reuse exists.

2. The method for identifying open-source software reuse as described in claim 1, characterized in that, When the current directory is the lowest-level directory, determining the suspicion score of the current directory based on the license information of each open-source code file directly below the current directory includes: Based on the license information of each open-source code file, determine the number of license types and the number of open-source code files corresponding to each license. The suspicion score of the current directory is determined based on the number of license types and the number of open-source code files for each type.

3. The method for identifying open-source software reuse as described in claim 1, characterized in that, When the current directory is a directory other than the bottom-level directory, determining the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open-source code file directly below the current directory includes: The suspicion score of each subdirectory is determined based on its suspicion score and the total number of code files contained in each subdirectory. Each of the open-source code files is used as an aggregate file. Based on the license information of each of the open-source code files, the number of license types corresponding to the aggregate file and the number of open-source code files corresponding to each license are determined. The suspicion score of the aggregated file is determined based on the number of license types corresponding to the aggregated file and the number of each open-source code file; The suspicion score of the current directory is determined based on the suspicion score of the subdirectory, the first preset weight corresponding to the suspicion score of the subdirectory, the suspicion score of the aggregated file, and the second preset weight corresponding to the suspicion score of the aggregated file.

4. The method for identifying open-source software reuse as described in claim 2, characterized in that, The process of determining the suspicion score of the current directory based on the number of license types and the number of open-source code files includes: When the number of license types is greater than 1, the suspicion score of the lowest level directory is determined based on the number of license types and the number of open source code files for each type using a first preset suspicion score formula. The first preset scoring formula is: ; in, Score the suspiciousness level. The number of the aforementioned license types, Let be the number of open-source code files corresponding to the i-th license; When the number of license types is equal to 1, the suspicion score is determined to be 1; When the number of license types is equal to 0, the suspicion score is determined to be 0.

5. The method for identifying open-source software reuse as described in claim 3, characterized in that, The determination of the suspiciousness score of the subdirectory includes: Based on the suspicion score of each subdirectory and the total number of files, the suspicion score of each subdirectory is obtained using the second preset scoring formula; The second preset scoring formula is: ; in, Score the suspiciousness of the subdirectories. The number of subdirectories included in the current directory. Score the suspiciousness of the i-th subdirectory. This represents the total number of files corresponding to the i-th subdirectory; The determination of the suspiciousness score of the aggregated files includes: Based on the number of license types corresponding to the aggregated file and the number of each open-source code file, the suspicion score of the aggregated file is obtained using the third preset scoring formula; The third preset scoring formula is: ; in, Score the suspiciousness of the aggregated files. The number of license types corresponding to the aggregated file. The number of open-source code files in the aggregate file corresponding to the i-th license; Determining the suspiciousness score of the current directory includes: Based on the subdirectory suspicion score, the first preset weight, the aggregated file suspicion score, and the second preset weight, the suspicion score of the current directory is obtained using the fourth preset scoring formula. The fourth preset scoring formula is: ; in, Score the suspiciousness of the current directory. For the first preset weight, This is the second preset weight.

6. The method for identifying open-source software reuse as described in claim 1, characterized in that, Before identifying the license information of all open-source code files in each target root directory of the software project to be detected, the following is also included: Upon receiving incremental detection information, determine the detection path specified by the incremental detection information, and determine whether the detection path is a complete path from the root directory to the lowest level directory; If so, then each root directory in the detection path will be taken as the target root directory; If not, then determine the complete path to which the detection path belongs, and take each root directory in the complete path as the target root directory; After determining the target root directory, proceed to the step of identifying the license information of all open-source code files in each target root directory of the software project to be tested.

7. The method for identifying open-source software reuse as described in claim 1, characterized in that, Before identifying the license information of all open-source code files in each target root directory of the software project to be detected, the following is also included: Receive the code repository address input by the user, clone the address in the code repository to the local machine, and use it as the project identification address; After determining that the project identification address meets the project validity verification conditions, the software project corresponding to the project identification address is taken as the software project to be tested, and the process proceeds to the step of identifying the license information of all open source code files in each target root directory of the software project to be tested.

8. A system for identifying open-source software reuse, characterized in that, include: The license identification module is used to identify the license information of all open-source code files in the root directory of each target in the software project to be tested; The current directory determination module is used to, for each target root directory, sequentially take each level of directory as the current directory in a recursive order starting from the lowest level directory of the target root directory and ending at the target root directory; The scoring determination module is used to determine the suspicion score of the current directory based on the suspicion scores of each subdirectory under the current directory and the license information of each open source code file located directly below the current directory. The reuse detection module is used to identify, after determining the suspicion score of each target root directory, the target root directories whose suspicion scores reach a preset score value as suspicious directories where open source software reuse exists.

9. A device for identifying open-source software reuse, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the open-source software reuse identification method as described in any one of claims 1 to 7 when executing the computer program.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the open-source software reuse identification method as described in any one of claims 1 to 7.

Images