Impact analysis device, impact analysis method and program

Abstract

This impact analysis device involves: acquiring, on the basis of a source code of a new version library and a source code of an old version of the library, a list of method information relating to a difference between the new version library and the old version library; extracting, from the list, a first difference relating to a method present in a first call graph of software which uses the old version library; extracting, from the list, a second difference relating to a method added to a second call graph, of the software, which uses the new version library; extracting a set of method information items on a call side of transition that have been added to the second call graph as compared to the first call graph; and outputting the union of the first difference, the second difference, and the set, thereby improving assistance in determining a possibility of impact of library update on the operation of the software.

Description

[Technical Field]

[0001] The present invention relates to an impact analysis device, an impact analysis method, and a program. [Background technology]

[0002] In recent years, much software has been implemented using software libraries (hereafter simply referred to as "libraries"). As the use of libraries becomes more widespread, the importance of library updates has increased as a countermeasure against potential bugs and vulnerability risks in libraries.

[0003] However, in reality, library updates are not often implemented. Much software continues to use outdated libraries. The main reason library updates are not implemented is the difficulty of verifying that software will operate correctly after a library update. New versions of libraries are not necessarily compatible with older versions. Methods have been proposed to indicate whether a new release is backward compatible (e.g., semantic versioning), but there is no mechanism to enforce that the displayed information matches the actual backward compatibility, so backward compatibility cannot be guaranteed. Therefore, software developers must verify that their software operates correctly every time they update the libraries they use. For this reason, library updates are often postponed or postponed.

[0004] In light of the above, there is a need for technology to support the confirmation of correct operation of software after a library update in order to encourage more library updates to be implemented.

[0005] Change impact analysis (or dependency impact analysis) (hereafter referred to as "impact analysis") is used to check whether the software as a whole will function properly when a change is made to a certain part of the software, focusing on the program's calling relationships (call graph). Impact analysis clarifies which parts of the software as a whole the changes to the program may affect. This makes it possible to narrow down the functions and modules whose operation needs to be checked.

[0006] Because libraries can be considered as components of the entire software, it is expected that impact analysis will also work to narrow down the scope of impact on operations when changes are made to library programs, such as library updates. Eclipse Steady (Non-Patent Document 1) is an impact analysis technology that assumes changes to library programs.

[0007] Eclipse Steady applies impact analysis to determine whether a vulnerability discovered in a library program affects the entire software. Eclipse Steady focuses on the patch that fixes the library vulnerability, considers the changes made to the library program in the patch to be the program that causes the vulnerability, and analyzes the call graph up to the changed part of the library program to determine whether the software has the potential to execute the program that causes the vulnerability. If there is no possibility that the software will execute the program that causes the vulnerability, it can be determined that the vulnerability will not affect the software as a whole. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] Serena Elisa Ponta, Henrik Plate, and Antonino Sabetta, "Detection, assessment and mitigation of vulnerabilities in open source dependencies", Empirical Software Engineering, 25(5):3175-3215, 2020. Summary of the Invention [Problem to be solved by the invention]

[0009] Some of the typical changes to library programs made in library updates make it difficult to determine the impact of changes on software behavior by analyzing the call graph of the library program changes.

[0010] Specifically, program changes known as pull-up methods (push-down methods) are often made in library updates. These changes allow the program that is called at runtime to be changed without rewriting the method's call site (the calling program). In other words, these suggest the need to consider that program changes that are determined to be inexecutable from the software's entry point through call graph analysis may actually cause changes to the behavior of the entire software. Eclipse Steady does not support such program changes, as it assumes that program changes are brought about by vulnerability fixes.

[0011] The present invention has been made in view of the above points, and aims to provide improved support for determining the possibility of an operational impact on software caused by a library update. [Means for solving the problem]

[0012] In order to solve the above problem, the impact analysis device has an acquisition unit configured to acquire a list of method information related to the differences between a new version of a library and an old version of a library based on the source code of the new version of the library and the source code of the old version of the library; a first extraction unit configured to extract, from the list, a first difference related to a method present in a first call graph of software that uses the old version of the library; a second extraction unit configured to extract, from the list, a second difference related to a method added to a second call graph of the software that uses the new version of the library; a third extraction unit configured to extract a set of method information on the call side of a transition added to the second call graph by comparing it with the first call graph; and an output unit configured to output the union of the first difference, the second difference, and the set. [Effects of the Invention]

[0013] It is possible to improve support for determining the possible operational impact on software caused by library updates. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a diagram illustrating an example of a hardware configuration of an impact analysis device 10 according to an embodiment of the present invention. [Figure 2] 1 is a diagram illustrating an example of a functional configuration of an impact analysis device 10 according to an embodiment of the present invention. [Figure 3] 10 is a flowchart illustrating an example of a processing procedure executed by the impact analysis device 10. [Figure 4] 10 is a flowchart illustrating an example of a procedure for a call graph difference analysis. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 is a diagram showing an example of the hardware configuration of an impact analysis device 10 according to an embodiment of the present invention. The impact analysis device 10 in Fig. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, and an interface device 105, which are all interconnected via a bus B.

[0016] A program that realizes processing in the impact analysis device 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101, but may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program as well as necessary files, data, etc.

[0017] When an instruction to start the program is received, the memory device 103 reads out the program from the auxiliary storage device 102 and stores it. The CPU 104 executes functions related to the impact analysis device 10 in accordance with the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

[0018] FIG. 2 is a diagram illustrating an example of the functional configuration of an impact analysis device 10 according to an embodiment of the present invention. The impact analysis device 10 performs impact analysis on changes to library programs caused by a library update, thereby supporting confirmation of normal operation of software after a library update. The impact analysis device 10 performs impact analysis by combining reach determination based on analysis of a call graph with the software's entry point (the single point where the program is supposed to be executed first) as the start method and the results of obtaining differences between the call graphs of the software before and after the library update. To perform impact analysis, as shown in FIG. 2, the impact analysis device 10 includes a preprocessing unit 11, a code difference analysis unit 12, a call graph analysis unit 13, and an output unit 14. Each of these units is realized by a process in which one or more programs installed in the impact analysis device 10 are executed by the CPU 104.

[0019] The pre-processing unit 11 inputs the source code of the software (program) that uses the library, the source code of the updated (changed) library (hereinafter also referred to as the "new version library"), and the source code of the pre-updated (pre-changed) library (hereinafter also referred to as the "old version library"), and performs pre-processing on these.

[0020] The code difference analysis unit 12 analyzes the possibility of the library update affecting the operation of the software based on the code difference before and after the library change.

[0021] The call graph analysis unit 13 analyzes the possibility of the library update affecting the operation of the software based on the call graphs before and after the library change.

[0022] The output unit 14 outputs the combined analysis results of the code difference analysis unit 12 and the call graph analysis unit 13 as the result of the impact analysis.

[0023] The results of the impact analysis are shown as a list of library code differences that affect the software. If the output list of code differences is empty, it means that there are no library code changes that could be executed by the software, and the software is guaranteed to operate correctly even after the library update. On the other hand, if the output list of code differences is not empty, there is a possibility that the software will not operate correctly after the library update due to programs that contain code differences included in the list.

[0024] Next, the data structure used in this embodiment will be defined.

[0025] [Source Code] The source code is assumed to have the following abstract syntax:

[0026]

number

[0027] [Code Diff] A code difference is a pair of class name and API name (method name) (information equivalent to the fully qualified API (method)). The entire source code difference resulting from a library update is treated as the list of code differences Δ below.

[0028]

number

[0029] Consider an element s of S, and if it can be reached from the entry point by the transition relation R, then s becomes an element of the set of methods called directly or indirectly by the software. For example, S={a,b,c,d} s0={a} R={r(a->b),r(b->d)} (x->y means "call y from x") Considering the call graph of software such that: among the elements of S, the set of methods called directly or indirectly by the software is the element {a, b, d} that can be reached by tracing the transition relation R from a.

[0030] The "relation" in transition relation means a mathematical relation (especially a binary relation). Therefore, a transition relation R is a data set that represents all the "call relations" between methods (i.e., pairs related by R) using a single data set such as a tree structure.

[0031] Here, since s∈S is a method of the program, the class name and method name (constructor name in the case of a constructor) in the program are uniquely defined for s. In this embodiment, getQName(s), which is a function that acquires the method name (method information) corresponding to s, is defined as follows:

[0032] <Definition 1(getQName)> Let S be the set of methods in the call graph, and let s∈S. Then, getQName(s)=(C s ,ns ). <==>C n is the class name of s, n s is the method name of s.

[0033] Also, define the following:

[0034] <Definition 2 (One-step transition)> s a ,s b ∈S, r∈R, then r=(s a ,s b ) to s b =r(s a ), or s a =r -1 (s b ) In r=(a,b), a is the caller and b is the callee.

[0035] [List of affected code differences] The list of affected code differences is a list (i.e., a sublist) that constitutes part of the list of source code differences.

[0036] The following describes the processing procedure executed by the impact analysis device 10. Fig. 3 is a flowchart for explaining an example of the processing procedure executed by the impact analysis device 10.

[0037] In step S101, the preprocessing unit 11 executes the new version of the library source code L N , Old version library source code L O , and software source code A. A is software that uses the library.

[0038] Next, the preprocessing unit 11 processes each input source code (L N , L O , A) and generate an Abstract Syntax Tree (AST) for each (S102). N AST of P N is substituted into L O AST of PO and the AST of A is P A is assigned to.

[0039] Next, the pre-processing unit 11 performs the following: N and P O A list of AST differences (a list of code differences between the new version and the old version of the library) Δ is generated (S103). Publicly known techniques can be used to obtain the AST differences. For example, the differences may be obtained using a tool such as gumtree diff.

[0040] Next, the preprocessing unit 11 loads the new version of the software (L O A) which calls G O is generated (S104).

[0041] Next, the preprocessing unit 11 executes the old version of the software (L N A) which calls G N is generated (S105).

[0042] It should be noted that known techniques can be used to generate the call graph in steps S104 and S105. For example, the call graph may be generated using tools such as WALA or Soot.

[0043] Next, the code difference analysis unit 12 generates a call graph G for a list Δ of code differences (differences in method information) between the new version and the old version of the library. O Based on this, code difference analysis is performed, and the analysis result Δ S The code difference analysis is to filter the list of code differences so as to leave the methods that exist on the call graph (that is, to select the call graph (here, the call graph G) from the list of code differences). O ) to extract code differences related to methods existing on the

[0044] Specifically, we define the call graph as G=(S G ,s G0 ,R G), the analysis result of the code difference is expressed as the following formula Δ S is given by

[0045]

number

[0046] Next, the call graph analysis unit 13 generates a call graph G of the code difference list Δ. O and call graph G N Based on this, a call graph differential analysis is performed, and the analysis result Δ G is output (S107).

[0047] Next, the output unit 14 outputs Δ S and Δ G and the union (Δ S ∪Δ G ) and the union is Δ F (S108).

[0048] Next, the output unit 14 outputs Δ F is output (S109).

[0049] The user can select Δ F If is an empty set, it can be determined that there is no possibility that the library update will affect the operation of the entire software, and if it is not an empty set, it can be determined that there is a possibility that the operation will be affected.

[0050] Next, details of step S107 will be described. Fig. 4 is a flowchart for explaining an example of a processing procedure for call graph difference analysis.

[0051] In step S201, the call graph analysis unit 13 generates a list of code differences Δ, a call graph G O and call graph G N Enter G N is the call graph of the (new) software after the library update, and G N =(SGN ,s N0 ,R GN ) and G O is the call graph of the software (old version) before the library update, and G O =(S GO ,s O0 ,R GO ) is what is.

[0052] Next, the call graph analysis unit 13 O Compared to G N Extract the transitions added to Σ + G (S202). G O For G N The transitions added to G N Although it is included in G O are called transitions that are not included in the

[0053] Next, the call graph analysis unit 13 O For G N Extract the method added to Θ + G (S203).

[0054] Next, the call graph analysis unit 13 selects Θ from the list of code differences Δ. + G Code difference Δ related to the method included in ω is extracted (S204).

[0055] Next, the call graph analysis unit 13 N The transition Σ added to + G Each element r=(s a ,s b ) and add up the results of applying Fold (find the union of each result) to get Δ fold (S205). Note that r is obtained by a From s b This is the transition to

[0056] Here, the definition of Fold will be explained.

[0057] In this embodiment, when a new method is added between call graphs, this change is treated as being caused by a change in the call site (the calling program (the software that uses the library, or the calling method in the call relationship between libraries)). In the pull-up method and push-down method, no change is observed in the call site, but since the method called at execution time changes, it is considered that there is a change in the call site.

[0058] Fold is a process between call graphs (in this embodiment, G0 and G N When a new transition (method call relationship) is added between (between ), the method or constructor of the call site that caused the transition is found and returned. Generally, there are multiple call sites, so Fold returns the calculation result as a set. Fold is a function that receives a method or constructor on the call graph and a memo set (φ (empty set) in S205 of Figure 4), and returns a set whose elements are methods. Fold is defined recursively as shown below, and processing proceeds by tracing the call graph. Since the transition relationship R of the call graph allows cycles, there is a possibility that Fold will continue to trace the call graph without stopping. Therefore, the call graph analysis unit 13 records methods that have been traced once in a memo and detects when a method that has been traced once is revisited, preventing Fold from continuing to trace the call graph without stopping.

[0059]

number

[0060] Next, the call graph analysis unit 13 calculates Δ ω and Δ fold The union of Δ G (S206).

[0061] Next, the call graph analysis unit 13 calculates Δ G is output as the analysis result (S207).

[0062] As described above, according to this embodiment, it is possible to determine the possibility of an operational impact on the entire software caused by a library update, including the possibility of an operational impact caused by a program change called the pull-up method (push-down method). In other words, according to this embodiment, it is possible to improve support for determining the possibility of an operational impact on the software caused by a library update.

[0063] In this embodiment, the preprocessing unit 11 is an example of an acquisition unit. The code difference analysis unit 12 is an example of a first extraction unit. The call graph analysis unit 13 is an example of a second extraction unit and a third extraction unit. Δ S is an example of the first difference. ω is an example of the second difference. fold is an example of the third difference. G O is an example of the first call graph. G N Here is an example of the second call graph:

[0064] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications and variations are possible within the scope of the gist of the present invention as described in the claims. [Explanation of symbols]

[0065] 10 Impact Analysis Device 11 Pretreatment section 12 Code Difference Analysis 13 Call graph analysis unit 14 Output section 100 Drive device 101 Recording media 102 Auxiliary storage device 103 Memory Device 104 CPU 105 Interface Device B Bus

Claims

1. an acquisition unit configured to acquire a list of method information relating to differences between the new version of the library and the old version of the library based on source code of the new version of the library and source code of the old version of the library; a first extraction unit configured to extract, from the list, a first difference related to a method present in a first call graph of the software that uses the old version of the library; a second extraction unit configured to extract, from the list, a second difference related to a method added to a second call graph of the software that uses the new version of the library; a third extractor configured to extract a set of caller method information of transitions added to the second call graph compared with the first call graph; an output unit configured to output a union of the first difference, the second difference, and the set; An impact analysis device comprising:

2. the difference between the new version of the library and the old version of the library is the difference between the abstract syntax tree of the new version of the library and the abstract syntax tree of the old version of the library; 2. The impact analysis device according to claim 1.

3. The method information is information including a class name and a method name of the method.

3. The impact analysis device according to claim 1 or 2.

4. an acquisition step of acquiring a list of method information relating to differences between the new version of the library and the old version of the library based on the source code of the new version of the library and the source code of the old version of the library; a first extraction step of extracting, from the list, a first difference related to a method present in a first call graph of the software that uses the old version of the library; a second extraction step of extracting, from the list, a second difference related to a method added to a second call graph of the software that uses the new version of the library; a third extraction step of extracting a set of caller method information of transitions added to the second call graph compared with the first call graph; an output step of outputting a union of the first difference, the second difference, and the set; The impact analysis method is characterized in that the above steps are executed by a computer.

5. an acquisition step of acquiring a list of method information relating to differences between the new version of the library and the old version of the library based on the source code of the new version of the library and the source code of the old version of the library; a first extraction step of extracting, from the list, a first difference related to a method present in a first call graph of the software that uses the old version of the library; a second extraction step of extracting, from the list, a second difference related to a method added to a second call graph of the software that uses the new version of the library; a third extraction step of extracting a set of caller method information of transitions added to the second call graph compared with the first call graph; an output step of outputting a union of the first difference, the second difference, and the set; A program characterized by causing a computer to execute the above.

Images