Detection device and detection method

Abstract

This detection device acquires the source code of software to be monitored and information indicating the type of dependency to be monitored in regard to the software. Next, the detection device generates, according to the type of the dependency to be monitored, a search query for a search for code that may have dependency of the type with the software to be monitored, and uses the search query to search for the code from a repository that stores the source code of the software, using a code search engine. Then, the detection device stores the result of the search in a search result database. Thereafter, the detection device compares the source code of the software to be monitored with the code indicated in the result of the search of the search result database to detect the presence or absence of code having dependency of the type with the software to be monitored.

Description

Detection device and detection method

[0001] The present invention relates to a detection device and a detection method for detecting software or code that has a dependency relationship with software to be monitored.

[0002] Software created by others, such as OSS (Open Source Software), carries security risks. Therefore, software users should evaluate the reliability of the software's security before using it. To evaluate the reliability of software's security, it is necessary to understand the dependencies between other software, dependencies on code containing vulnerabilities or bugs, dependencies on malicious code, etc.

[0003] Conventional techniques for analyzing software dependencies include a technique for analyzing dependencies based on code clone detection and a technique for analyzing vulnerabilities based on code clone detection.

[0004] Kanemoto Yang et al., "Software Dependency Analysis Using Multi-Index and Directory Structure Information," ICSS / IPSJ-SPT, 2023. Seunghoon Woo et al., "CENTRIS: A Precise and Scalable Approach for Identifying Modified Open-Source Software Reuse," ICSE, 2021, [online], [Retrieved May 10, 2024], Internet <URL: https: / / arxiv.org / abs / 2102.06182>. Arakawa Reika et al., "A Method for Detecting Vulnerable Code Clone in Software Using Set Similarity Calculation Algorithm," IA ICSS, 2023. Seunghoon Woo et al., "V0Finder: Discovering the Correct Origin of Publicly Reported Software Vulnerabilities," USENIX Security, 2021.

[0005] However, all of the above conventional technologies require software to be collected and registered in a database. Furthermore, to accurately detect dependencies between other software, a large-scale database is required, and analysis takes time. Furthermore, the latest software must be continuously collected and registered in the database.

[0006] Therefore, an object of the present invention is to solve the above-mentioned problems and to easily analyze software dependencies.

[0007] In order to solve the above-mentioned problems, the present invention is characterized by comprising an acquisition unit that acquires the source code of the software to be monitored and information indicating the type of dependency to be monitored for the software; a search unit that generates a search query to search for code that may have a dependency of said type with the software to be monitored according to the type of dependency to be monitored, uses the search query to search for code from a repository that accumulates software source code using a code search engine, and saves the results of the search in a search result DB (database); and a detection unit that detects the presence or absence of code that has a dependency of said type with the software to be monitored by comparing the source code of the software to be monitored with the code shown in the search results in the search result DB.

[0008] According to the present invention, software dependencies can be easily analyzed.

[0009] FIG. 1 is a diagram illustrating an overview of a detection device. FIG. 2 is a diagram illustrating an example of the configuration of a detection device. FIG. 3 is a diagram illustrating an example of a monitored object DB. FIG. 4 is a diagram illustrating an example of a relationship information DB. FIG. 5 is a diagram illustrating an example of a search performed by a code search unit and an example of a search result DB. FIG. 6 is a diagram illustrating an example of a detection result stored in a detection result DB when a relationship detection unit detects a dependency relationship with code of another software. FIG. 7 is a diagram illustrating an example of a detection result DB. FIG. 8 is a flowchart illustrating an example of a processing procedure performed by the detection device. FIG. 9 is a flowchart illustrating an example of a processing procedure performed by the detection device. FIG. 10 is a flowchart illustrating an example of a processing procedure performed by the detection device. FIG. 11 is a diagram illustrating an example of a search query generated by the code search unit. FIG. 12 is a diagram illustrating an example of a search query generated by the code search unit. FIG. 13 is a diagram illustrating an example of a search query generated by the code search unit. FIG. 14 is a diagram illustrating an example of a detection result DB. FIG. 15 is a diagram illustrating an example of a detection result DB. FIG. 16 is a diagram illustrating a modified example of the detection device. FIG. 17 is a diagram illustrating an example of a computer that executes a detection program.

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a description will be given of an embodiment of the present invention with reference to the drawings, but the present invention is not limited to the embodiment.

[0011] [Overview] An overview of the detection device 10 of this embodiment will be described below. The detection device 10 utilizes a code search engine to detect dependencies between software to be monitored.

[0012] 1 , when a detection device 10 receives a request from a user to detect dependencies of software to be monitored, the detection device 10 generates a search query for code that may have dependencies on the software, and searches for the code using a code search engine. The code search engine is, for example, a search engine that searches for code from a source code repository, such as GitHub Advanced Search.

[0013] Based on the search results, the detection device 10 then detects software that has a dependency relationship with the software being monitored. The detection device 10 then returns the detection results (relationship detection results) to the user, allowing the user to determine whether the software can be used and to assess the software.

[0014] As described above, the detection device 10 uses a code search engine to search the source code repository for code that may have dependencies on the software being monitored. This eliminates the need for the detection device 10 to maintain a large-scale software database or to keep up with software updates.

[0015] [Configuration Example] Next, an example configuration of the detection device 10 will be described using Fig. 2. As shown in Fig. 2, the detection device 10 includes, for example, a monitoring information collection unit (acquisition unit) 11, a code search unit (search unit) 12, a relationship detection unit (detection unit) 13, and a detection result reference unit 14. Each unit is realized, for example, by a CPU included in the detection device 10 executing a program in a storage device.

[0016] The detection device 10 also includes a monitoring target DB, a relationship information DB, a search result DB, and a detection result DB. The monitoring target DB, relationship information DB, search result DB, and detection result DB are stored in a storage device within the detection device 10, for example.

[0017] 2, the detection device 10 includes an input unit that receives input from an external device such as software to be monitored and the types of dependencies to be monitored for the software, and an output unit that outputs the detection results of software that has dependencies on the software to be monitored. The detection device 10 also includes a communication interface for communicating with external devices (e.g., source code repositories, user terminal devices, etc.) via a network such as the Internet.

[0018] [Monitoring Information Collection Unit] First, a description will be given of the monitoring information collection unit 11. The monitoring information collection unit 11 acquires the source code of the software to be monitored and information indicating the types of dependencies to be monitored in the software.

[0019] For example, the monitoring information collection unit 11 receives input from the user of the detection device 10 about software for which a relationship is to be detected (monitoring target software) and the type of relationship to be monitored for that software. The monitoring information collection unit 11 then stores the received information in the monitoring target DB (see FIG. 3 ).

[0020] The monitoring target DB stores, for example, as shown in FIG. 3, the software name and version of the software to be monitored, and information indicating the relationship of the software to be monitored.

[0021] The relationships to be monitored are, for example, (1) dependencies with other software code, (2) dependencies with vulnerable or buggy code, or (3) dependencies with malicious code, or a combination of these.

[0022] The monitoring information collection unit 11 acquires information necessary to detect the relationships (2) and (3) above from an external server. For example, the monitoring information collection unit 11 acquires vulnerability or bug fix patches (patch differences) from a server that stores vulnerability or bug fix patches and stores them in the relationship information DB (see FIG. 4). The monitoring information collection unit 11 also acquires malicious code from a server that stores malicious code and stores it in the relationship information DB (see FIG. 4).

[0023] The relationship information DB stores information for detecting relationships of each type for each relationship. For example, the relationship information DB stores the patch difference for the vulnerability "VULN / CVE-1234-1234" as information for detecting dependencies with vulnerable code. The relationship information DB also stores the patch difference for "BUG / github.com / XXX / xxx / issue / 1" as information for detecting dependencies with buggy code. The relationship information DB also stores the malicious code "MAL / malware.1" as information for detecting dependencies with malicious code. The information stored in this relationship information DB is used when generating search queries, which will be described later.

[0024] [Code Search Unit] Returning to the explanation of Fig. 2, the code search unit 12 generates a search query for searching for code that may have a dependency of the type to be monitored with the source code of the software to be monitored, depending on the type of dependency to be monitored.

[0025] For example, if the dependency to be monitored is (1) a dependency with code of another software, the code search unit 12 generates a search query using a code search engine to search for code similar to the source code of the software to be monitored. For example, the code search unit 12 acquires the source code of the software to be monitored, extracts expressions that serve as keywords from the acquired source code, and combines them to generate a search query.

[0026] Furthermore, if the dependency to be monitored is (2) a dependency with code that has a vulnerability or a bug, the code search unit 12 generates a search query using a code search engine to search for code that has a vulnerability or a bug.

[0027] For example, the code search unit 12 reads a patch (differential patch) to fix a vulnerability or bug in code from the relationship information DB (see FIG. 4), compares the code before and after the fix with the differential patch (the code where the vulnerability or bug remains and the code where the vulnerability or bug has been fixed), and generates a search query using an expression that exists only before the fix if there is one. On the other hand, if the code does not have an expression that exists only before the fix, the code search unit 12 generates a search query by combining an expression that is a negated form of an expression that exists only after the fix with an expression that exists both before and after the fix.

[0028] Furthermore, if the dependency to be monitored is (3) a dependency with malicious code, the code search unit 12 generates a search query for searching for malicious code using a code search engine. For example, the code search unit 12 reads malicious code from the relationship information (see FIG. 4), extracts expressions that serve as keywords from the malicious code, and combines them to generate a search query.

[0029] The code search unit 12 may identify which dependencies to monitor for the software to be monitored by referring to information stored in the monitoring target DB, or may specify the dependencies based on a user specification. The generation of search queries by the code search unit 12 will be described later using specific examples.

[0030] The code search unit 12 uses the generated search query to search for code from a repository that stores software source code using a code search engine, and stores the search results in a search result DB.

[0031] For example, as shown in FIG. 5, the code search unit 12 searches for code from the repository using a code search engine by using a search query indicated by reference numeral 501, and obtains search results indicated by reference numeral 502.

[0032] Then, the code search unit 12 stores information about the software to be monitored and the search results (for example, information about the software hit in the search) in association with each other in the search result DB.

[0033] 5, the information related to the software to be monitored includes, for example, the name and version of the software to be monitored, the file names constituting the software, the names of functions handled by the code of the file names, the creation date of the code, etc. The information related to the software hit by the search includes, for example, the name of the software in question, the file name in question, the source code in question, the name of the function in question, and the creation date of the function in question.

[0034] [Relationship Detection Unit] Returning to Figure 2, the relationship detection unit 13 detects code or software that has a dependency relationship with the software to be monitored from the search results stored in the search result DB. For example, the relationship detection unit 13 detects whether there is code or software that has a specified dependency relationship with the software to be monitored by comparing the code (function) of the software to be monitored with the code (function) shown in the search results in the search result DB. The relationship detection unit 13 then stores the detection results in the detection result DB (see Figure 6).

[0035] For example, the relationship detection unit 13 determines the software (e.g., "X") of the function (e.g., "main") that was found in the search based on the search results in the search result DB (see FIG. 5). Then, the relationship detection unit 13 calculates the ratio of the found functions (e.g., "main") to the total number of functions included in the software (e.g., "X"). If the relationship detection unit 13 determines that the calculated ratio exceeds a predetermined value (e.g., 0.1), it detects the software (e.g., "X") as software having a dependency relationship with the software to be monitored. Then, the relationship detection unit 13 stores the detection results in the detection result DB (see FIG. 6).

[0036] The detection result DB stores, for each piece of software to be monitored, information (detection results) indicating the code or software that has detected a dependency relationship with the software, as shown in Fig. 7. Examples of detection by the relationship detection unit 13 will be described later using specific examples.

[0037] [Detection Result Reference Unit] Returning to the explanation of Fig. 2, the detection result reference unit 14 references the detection results stored in the detection result DB (see Fig. 6) based on a request from a user. For example, when the detection result reference unit 14 receives the name and version (e.g., A's 1.0) of the software to be monitored from the user as search keywords, it outputs the detection results (e.g., X: 0.2) of code or software that has a dependency relationship with the software in question from the detection result DB.

[0038] [Example of Processing Procedure] Next, an example of the processing procedure executed by the detection device 10 will be described. For example, the detection device 10 collects information based on the procedure shown in Fig. 8. First, the monitoring information collection unit 11 of the detection device 10 receives input from a user or the like of software to be monitored and the relationships to be detected (types of dependency relationships to be monitored) (S1). Then, the monitoring information collection unit 11 stores the information input in S1 in the monitoring target DB (see Fig. 3).

[0039] The monitoring information collection unit 11 also collects information about the relationships to be detected (vulnerability or bug patches, malicious code, etc.) (S2). For example, the monitoring information collection unit 11 collects vulnerability or bug patches, malicious code, etc. via a network. The monitoring information collection unit 11 then stores the collected vulnerability or bug patches, malicious code, etc. in a relationship information DB (see FIG. 4).

[0040] After S2, the detection device 10 detects code or software that has a dependency relationship with the software to be monitored, for example, based on the procedure shown in Fig. 9. First, the code search unit 12 receives a specification from the user of the relationship (type of dependency relationship) to be detected (S11).

[0041] After S11, the code search unit 12 generates a search query according to the relationship specified in S11 (S12). Then, based on the search query generated in S11, the code search unit 12 searches for code from the repository using a code search engine (S13: Search based on the search query). The code search unit 12 then stores the code search results in the search result DB (see FIG. 5).

[0042] After S13, the relationship detection unit 13 detects software or code that has the relationship specified in S11 with the software to be monitored based on the search results stored in the search result DB (S14: detect relationships from search results).The relationship detection unit 13 then stores the detection results of S14 in the detection result DB (see FIG. 7) (S15).

[0043] After S15, if the detection device 10 receives a request from a user to refer to the detection results, for example, as shown in FIG. 10, the detection result reference unit 14 outputs the corresponding detection results from the detection result DB (S21: output information from the detection result DB in response to the request).

[0044] By performing the above process, the detection device 10 can output to the user software or code that has detected dependencies with the software to be monitored.

[0045] [Example of Search Query Generation] Next, an example of search query generation by the code search unit 12 will be described.

[0046] (1) When generating a search query to search for the code of other software that may have a dependency on the software being monitored When the code search unit 12 generates a search query to search for the code of other software that may have a dependency on the software being monitored, the search query is generated, for example, as follows.

[0047] 1. The code search unit 12 acquires the source code of the monitoring software from a software repository or the like, and divides the acquired source code into function units (see reference numeral 110 in FIG. 11).

[0048] 2. The code search unit 12 creates a search query from the divided source code for each function so as to find functions similar to the function in question.

[0049] Note that because code search engines cannot use symbols or regular expressions in search queries, the code search unit 12 constructs search queries using searchable character strings. For example, the code search unit 12 divides the source code into lines and extracts the longest subsequence that matches the regular expression [a-zA-Z_]+ for each line as a query candidate. Note that because numbers are likely to change, the code search unit 12 extracts only numbers with a long number of digits (e.g., 20 or more digits) or does not extract them at all.

[0050] 3. After that, the code search unit 12 extracts expressions whose character string length is equal to or greater than N and whose character string does not correspond to a general word (a general word in English) in order to exclude expressions that frequently appear in the code. Expressions that satisfy this condition are set as query candidates (see the query candidates denoted by reference numeral 111 in FIG. 11 ).

[0051] 4. Due to search engine restrictions, there may be limitations on the length of a search query or the number of AND / OR conditions that are search query modifiers. Therefore, the code search unit 12 sorts the query candidates in descending order of string length (see the query candidates sorted by priority indicated by reference numeral 111 in FIG. 11 ), and assembles a query string from the query candidates within the above restrictions.

[0052] 5. Finally, the code search unit 12 adds conditions for the repository to be searched. For example, the code search unit 12 specifies that the repository to be searched is not a forked repository and specifies the language of the source code to be searched (see reference numeral 112 in FIG. 11 ). Note that the search query shown by reference numeral 112 in FIG. 11 is an example of a search query when the query string length limit is set to 30.

[0053] (2) When generating a search query to search for code with vulnerabilities or bugs When the code search unit 12 generates a search query to search for code with vulnerabilities or bugs, the search query is generated, for example, as follows.

[0054] The code search unit 12 extracts search query candidates Qb and Qa from the code before and after the patch from the patch for the vulnerability or bug stored in the relationship information DB, in the same manner as in (1) above.

[0055] 12 from the relationship information DB. In this case, the code search unit 12 extracts search query candidates Qb and Qa indicated by reference numeral 122 from the correction patch 122. The code search unit 12 also obtains sets Qb-Qa and Qa-Qb.

[0056] Next, the code search unit 12 obtains sets by applying a negation condition (e.g., NOT) to Qb, the set Qb-Qa, and the set Qa-Qb, and combines these sets to form the search query. For example, the code search unit 12 generates the search query indicated by reference numeral 123. That is, since it is clear from the contents of the correction patch 122 that "sanitize_arg" has been added to the code by applying the patch, the code search unit 12 generates a search query with the search condition that "sanitize_arg" is not included.

[0057] When the code search unit 12 combines these expressions, there is a priority order, which is 1. the set Qb-Qa, 2. the set Qa-Qb with a negated condition, and 3. the set Qb. However, if Qb is empty, there are no candidates to search, so the code search unit 12 stops the search.

[0058] (3) When Generating a Search Query for Searching for Malicious Code When the code search unit 12 generates a search query for searching for malicious code, the search query is generated, for example, as follows.

[0059] It is known that malicious code tends to change more easily than general code in order to avoid analysis, so the code search unit 12 extracts keywords that are less likely to change from malicious code (for example, keywords related to API calls).

[0060] For example, the code search unit 12 obtains query candidates from malicious code stored in the relationship information DB in the same manner as in (2) above, and then determines which part of the malicious code the query candidate corresponds to. If the query candidate corresponds to a part of the malicious code that is prone to change (e.g., a variable name, a URL parameter, etc.), the code search unit 12 excludes the query candidate. On the other hand, if the query candidate corresponds to a part of the malicious code that is unlikely to change (e.g., an API call, an environment variable name, an OS command name), the code search unit 12 does not exclude the query candidate.

[0061] For example, as indicated by reference numeral 132 in Fig. 13 , the code search unit 12 extracts query candidates from the malicious code 131, sorts the extracted query candidates by priority in the same manner as in (2), and excludes variable names and URL parameters (e.g., "xxxx" and "http"). Then, as in (1), the code search unit 12 specifies the language (e.g., Python) of the source code to be searched. As a result, the code search unit 12 generates a search query indicated by reference numeral 133.

[0062] By performing the above process, the code search unit 12 can generate a search query for code according to the type of dependency relationship to be monitored.

[0063] [Relationship Detection Example] Next, a detection example performed by the relationship detection unit 13 will be described.

[0064] (1) Detecting dependencies with code of other software 1. First, the relationship detection unit 13 searches for a list of functions F=[f1, f2, f3, ...] of the software to be monitored (for example, 1.0 of A) to find the software names of the functions that are found in the search.

[0065] 2. Next, the relationship detection unit 13 performs the following process 3 for functions F'=[f'1, f'2, f'3, ...] that satisfy the condition that the creation date of the function list F=[f1, f2, f3, ...] is greater than the creation date of the function found in the search.

[0066] 3. The relationship detection unit 13 determines whether the proportion S of the function F' found in the search to the software containing the function F' (the software with the corresponding software name in the search result DB) exceeds a threshold T. If the relationship detection unit 13 determines that the proportion S exceeds the threshold T, it determines that the software to be monitored has a dependency relationship with the software in question. On the other hand, if the relationship detection unit 13 determines that the proportion S does not exceed the threshold T, it determines that the software to be monitored has no dependency relationship with the software in question.

[0067] For example, if the function F' found in the search is main shown in Fig. 5 and the functions included in software X are five functions including the above main, the proportion S for software X is 0.2. In the same manner as above, the relationship detection unit 13 also calculates the proportion S for software Y that includes the function test found in the search and software Z that includes the function handle found in the search.

[0068] As a result of the calculation, for example, if S={X: 0.2, Y: 0.05, Z: 0.01} and T=0.1, the relationship detection unit 13 detects that the only software that has a dependency relationship with 1.0 of the monitored software A is X. Then, the relationship detection unit 13 stores the above detection result in the detection result DB (see FIG. 6).

[0069] (2) Detecting Dependencies with Vulnerable or Buggy Code For example, the relationship detection unit 13 first determines whether the search results for vulnerable or buggy code in the search result DB contain code for the same function as the function handled by the software being monitored. Next, if the relationship detection unit 13 determines that the search results for vulnerable or buggy code in the search result DB contain code for the same function as the function handled by the software being monitored (a hit), it references a patch for the vulnerable or buggy code to identify a set of functions to be fixed by the patch. Then, if the proportion of the same functions in the identified set of functions exceeds a predetermined threshold, the relationship detection unit 13 detects the vulnerable or buggy code as code that has a dependency relationship with the software being monitored. For example, the relationship detection unit 13 performs the following process.

[0070] 1. First, the relationship detection unit 13 checks whether the software to be monitored is included in the search result DB. For example, the relationship detection unit 13 checks whether the code (function) of the software to be monitored is included in the code with vulnerabilities or bugs stored in the search result DB. If not, the process ends.

[0071] 2. Next, the relationship detection unit 13 performs the following process 3 on the function V=[v1, v2, v3, . . . ] that is corrected by the patch for correcting the vulnerability or bug.

[0072] 3. The relationship detection unit 13 calculates the proportion s = |F| / |V| of the hit functions F = [f1, f2, f3, ...] of the software to be monitored (functions included in the software to be monitored that are the same as the functions included in the code containing the vulnerability or bug) in the above V. If the calculated proportion s exceeds a predetermined threshold T, the relationship detection unit 13 determines that the software to be monitored has a dependency relationship with the code containing the vulnerability or bug. Otherwise, the relationship detection unit 13 determines that the software to be monitored does not have a dependency relationship with the code containing the vulnerability or bug.

[0073] For example, when T=1.0, if the relationship detection unit 13 determines that s={B=1.0, C=0.0} for CVE-1234-1234, it detects that the software B to be monitored has a dependency relationship with code vulnerable to CVE-1234-1234.The relationship detection unit 13 then stores the detection result in the detection result DB (see FIG. 14).

[0074] (3) When detecting dependencies with malicious code For example, the relationship detection unit 13 first determines whether the results of a search for malicious code in the search result DB include code for the same function as a function handled by the software to be monitored. Next, if the relationship detection unit 13 determines that the results of a search for malicious code in the search result DB include code for the same function as a function handled by the software to be monitored, and if the proportion of the same function in the group of functions handled by the malicious code exceeds a predetermined threshold, the relationship detection unit 13 detects the malicious code as code that has a dependency relationship with the software to be monitored. For example, the relationship detection unit 13 executes the following process.

[0075] 1. First, the relationship detection unit 13 checks whether the software to be monitored is included in the search result DB. For example, the relationship detection unit 13 checks whether the code (function) of the software to be monitored is included in the malicious code stored in the search result DB. If not, the process ends.

[0076] 2. Next, the relationship detection unit 13 performs the following process 3 on the function M=[m1, m2, m3, . . . ] used by the malicious code.

[0077] 3. The relationship detection unit 13 calculates the proportion s = |F| / |M| of the hit functions F = [f1, f2, f3, ...] of the software to be monitored (functions included in the software to be monitored that are the same as the functions included in the malicious code) in the above M. If the calculated proportion s exceeds the threshold T, the relationship detection unit 13 determines that the software to be monitored has a dependency relationship with the malicious code. Otherwise, the relationship detection unit 13 determines that the software to be monitored does not have a dependency relationship with the malicious code.

[0078] For example, when T=0.5, if the relationship detection unit 13 determines that s={B:0.0, C:0.5} for malware.1, it detects that the software C to be monitored has a dependency relationship with malware.1. The relationship detection unit 13 then stores the detection result in the detection result DB (see FIG. 15 ).

[0079] By performing the above process, the relationship detection unit 13 can detect software or code that has a dependency relationship with the software to be monitored.

[0080] Other Embodiments The detection device 10 may detect dependencies between not only public software but also private software and the software being monitored. In this case, the detection device 10 searches for code using a code search engine for private software (see FIG. 16 ). The code search engine for private software cannot return the source code itself that was found as a search result for a search query, but it can return the number of hits. Therefore, the detection device 10 can output to the user the detection results (relationship detection results) for software that has dependencies on private software based on the top hit counts.

[0081] [System Configuration, etc.] The components of each unit shown in the figure are conceptual functional units and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU and a program executed by the CPU, or can be realized as hardware using wired logic.

[0082] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[0083] [Program] The detection device 10 can be implemented by installing a program (detection program) as package software or online software on a desired computer. For example, by executing the program on an information processing device, the information processing device can function as the detection device 10. The information processing device referred to here includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as terminals such as PDAs (Personal Digital Assistants).

[0084] 17 is a diagram showing an example of a computer that executes a detection program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0085] The memory 1010 includes a read-only memory (ROM) 1011 and a random access memory (RAM) 1012. The ROM 1011 stores a boot program such as a basic input / output system (BIOS). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0086] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define the processes executed by the detection device 10 are implemented as program modules 1093 in which computer-executable code is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, the program modules 1093 for executing processes similar to those of the functional configuration of the detection device 10 are stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced with an SSD (Solid State Drive).

[0087] Data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. The CPU 1020 then reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary and executes them.

[0088] The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may also be stored in a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or a wide area network (WAN)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0089] 10 Detection device 11 Monitoring information collection unit 12 Code search unit 13 Relationship detection unit 14 Detection result reference unit

Claims

1. A detection device comprising: an acquisition unit that acquires the source code of the software to be monitored and information indicating the type of dependency to be monitored for said software; a search unit that generates a search query to search for code that may have a dependency of said type with the software to be monitored according to the type of dependency to be monitored, uses the search query to search for code from a repository that stores software source code using a code search engine, and saves the search results in a search result DB (database); and a detection unit that detects the presence or absence of code that has a dependency of said type with the software to be monitored by comparing the source code of the software to be monitored with the code shown in the search results of the search in the search result DB.

2. The detection device described in claim 1, characterized in that the type of dependency is at least one of dependency of the monitored software on other software, dependency on vulnerable or buggy code, and dependency on malicious code, and the search unit generates the search query using keywords contained in the source code of the monitored software as a search query for searching for other software on which the monitored software depends, generates the search query using keywords contained in a patch for the vulnerable or buggy code as a search query for searching for vulnerable or buggy code on which the monitored software depends, and generates the search query using keywords contained in the malicious code as a search query for searching for malicious code on which the monitored software depends.

3. The detection device described in claim 2, characterized in that the detection unit identifies other software that contains code of the software to be monitored from the results of the search of the search result DB, and if the proportion of the code in the other software exceeds a predetermined threshold, detects the other software as software that has a dependency on the software to be monitored.

4. The detection device according to claim 2, characterized in that the detection unit: when the search results for vulnerable or buggy code in the search result DB include code of the same function as a function handled by the software to be monitored, refers to a patch to fix the vulnerable or buggy code to identify a group of functions to be fixed by the patch, and when the proportion of the same functions in the identified group of functions exceeds a predetermined threshold, detects the vulnerable or buggy code as code that has a dependency on the software to be monitored; and when the search results for malicious code in the search result DB include code of the same function as a function handled by the software to be monitored, detects the malicious code as code that has a dependency on the software to be monitored if the proportion of the same functions in the group of functions handled by the malicious code exceeds a predetermined threshold.

5. A detection method executed by a detection device, comprising: a step of acquiring the source code of the software to be monitored and information indicating the type of dependency to be monitored for said software; a step of generating a search query to search for code that may have a dependency of said type with the software to be monitored according to the type of dependency to be monitored, a step of using a code search engine to search for code from a repository that accumulates software source code using the search query, and saving the search results in a search result DB (database); and a step of detecting whether or not there is code that has a dependency of said type with the software to be monitored by comparing the source code of the software to be monitored with the code shown in the search results of the search DB.

Images